On Thu, May 30, 2019 at 3:23 PM J Lovejoy <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 (#2600): https://lists.spdx.org/g/Spdx-legal/message/2600 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] -=-=-=-=-=-=-=-=-=-=-=-
