I agree we should err on the inclusive side. In concept, I think the driver should be popularity more than OSS definition. It’s better for users to include commonly used open source-like license. JSON and WTFPL (maybe this complies, but it’s not on the OSI list anyway), for example. We do need to be mindful of the capacity of the team and it makes sense to prioritize compliant licenses, but at a high-level the LL is to minimize the need to locally define license in SPDX docs and so should cover the licenses that users are likely to run into. Phil
From: "spdx-legal@lists.spdx.org" <Spdx-legal@lists.spdx.org> on behalf of "mdo...@linuxfoundation.org" <mdo...@linuxfoundation.org> Date: Thursday, May 30, 2019 at 3:44 PM To: Jilayne Lovejoy <opensou...@jilayne.com> Cc: "spdx-legal@lists.spdx.org" <Spdx-legal@lists.spdx.org> Subject: Re: meeting minutes from today On Thu, May 30, 2019 at 3:23 PM J Lovejoy <opensou...@jilayne.com<mailto:opensou...@jilayne.com>> wrote: 3) Need more feedback on documentation updates - see email sent earlier this week, comment on PRs in Github · discussed licenses that aren't squarely open source and variations on how far fall out and how to deal with this potential slippery slope. Some are clearly not open source (use, technology restrictions), then there are licenses intended to be open source, but impose new copyleft-type conditions (SSPL, Parity). We don't want to get into the business of defining what is open source, but we have to make a call on these licenses - how to do this without getting into the middle of the debate? _._,_. I tend to think SPDX should error on being more inclusive as we're expecting tool providers, end users and others scanning code to recognize and match the licenses. If they're not listed in SPDX, they have to merge in another list. I completely agree the current definitions are less inclusive for good reasons, but re-defining "what is open source and others" for an SPDX license list is not going to be helpful either. That said, I look at being OSI or FSF approved as "properties" of the license. They're a feature. Some will consider them important features, but some just need to match the text in a header to some list of licenses that knows what this text in the header is. And for that we can get functionally practical. My suggestion for defining the rules for what gets in or doesn't would follow a similar logic. SPDX license list may include: * Licenses that show up in public source code repositories, * for source code that is used by a project community directly or as a dependency, * and have more than 1 known user of the project codebase SPDX license list does not include: * commercial licenses for use by a company's licensees * vanity licenses adding a proper noun, minor modification or non-licensing elements (e.g. Bitcoin donation address) to a known license * licenses that have no known users * licenses with no known integration or dependency with other codebases Maybe I'll start a huge debate with this, but if I were to draw a line in the sand without any input from others, this is where I'd probably start. So it likely needs input from others - let's refine it or throw it out for something someone has that's better. I have no emotional or intellectual attachment to this line in the sand. :-) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2601): https://lists.spdx.org/g/Spdx-legal/message/2601 Mute This Topic: https://lists.spdx.org/mt/31872337/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
