Date
1 - 4 of 4
SPDX License List license inclusion guidelines
J Lovejoy
Hi Kyle,
toggle quoted message
Show quoted text
Thanks for having a look. As to your question: we had a discussion on one of the many calls we discussed this topic and ran the hypothetical of what if there were no “rules” or the rules were very relaxed. One extreme might look like this: anyone can add a license, any time and the SPDX License List becomes bloated and so long that nothing is reliable any more - we’d end up with duplicate licenses (b/c no one was minding the Matching Guidelines), duplicate ids (the horror!) etc. It would certainly lose it’s value. If there is something we can amend on the current proposal, then there has been plenty of opportunity to say so, and there is still (a little) time. The proposed revision substantially relaxes the previous guidelines - as you well know. there are a number of licenses in the queue that we’ve put on hold knowing that if we changed the guidelines, they would be easy submissions. We also made some obvious things explicit like not adding a license that would match an existing license - we probably all assumed that one, but it wasn’t actually written down! I’m still unclear as to what the actual issue and suggestion is out of this thread. Thanks, Jilayne On Mar 13, 2020, at 4:25 PM, Kyle Mitchell <kyle@...> wrote: |
|
Kyle Mitchell
All,
I am both impressed by the work Jilayne and others have put into the guidelines, and in strong sympathy with the general thrust Philippe reports from the conference. I didn't go to FOSDEM, but judging from Philippe's notes, I wouldn't have had much else to add. I keep returning to the _why_ behind rules and proposed rules. Is the overbearing issue, from the SPDX-side point of view, still too many license submissions, too fast to handle? -- Kyle Mitchell, attorney // Oakland // (510) 712 - 0933 |
|
Philippe Ombredanne
Hi Jilayne:
On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy <opensource@...> wrote: I’m sending this to both the legal and general mailing lists to ensureOn January 31st a compliance tooling meeting and hackathon took place in Brussels before FOSDEM [1]. One of the session topics was SPDX. Everyone there agreed that SPDX license inclusion criteria should be relaxed. Adding more restrictions and filters is IMHO counterproductive in several ways: - it requires more work to apply these restrictions and filters - more work means fewer licenses are added - as a shared "vocabulary" the utility function of the license list is directly related to the number of "words" we can use. Restricting the number of words in the license vocabulary only means that these words cannot be used in shared conversation about licenses. But these licenses still exist, so the restrictions impact mostly the usefulness and expressiveness of SPDX, especially in the more common cases where license expressions are used without an SPDX document. This could increasingly make the SPDX License list irrelevant if it is missing important license vocabulary. The existing and proposed license inclusion criteria seem counterproductive and likely to subtract value from SPDX. The community does not need SPDX to police or enforce OSS license "purity" via the license list. Instead there should be fewer barriers to adding new licenses to the list in order to optimize the utility of the SPDX license list and the number of common licenses SPDX expressions can deal with. Since SPDX does not interpret license conditions, the inclusion guidelines should be loosened to include commonly-used and public licenses without an OSS litmus test (e.g. free proprietary licenses). This will become more important for SPDX as more organizations become more focused on compliance and are looking for a way to account for all licenses detected from scans or other analysis. [1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit# -- Cordially Philippe Ombredanne |
|
J Lovejoy
Hi all,
I’m sending this to both the legal and general mailing lists to ensure greatest visibility. The legal team has come up with a final draft of the license inclusion guidelines based on various conversations and feedback over the past 8 months of intermittent discussion. The pull request representing this draft is located here: https://github.com/spdx/license-list-XML/pull/990 We are looking to provide another two weeks for review and comment and then finalize and publish this. Please do comment either on the PR, the issue below or the legal team mailing list. (including +1 if you think it’s all good!) The issue where some of the discussion has taken place is here: https://github.com/spdx/license-list-XML/issues/925 Thanks! Jilayne SPDX legal team co-lead |
|