search

spdx / change-proposal

Repository for change proposal for the SPDX project
3 stars 3 forks source link

Change Proposal: Extended Modifier Support #6

Open swinslow opened 1 year ago

swinslow commented 1 year ago

Please review a new Change Proposal for adding an ExceptionRef here: https://github.com/spdx/change-proposal/blob/main/proposals/Modifiers.md submitted by @karsten-klein

Please add comments in this issue thread regarding questions and thoughts on the proposal.

swinslow commented 1 year ago

Having read this proposal, I admit that I do not understand what the requested change is here.

The best I can tell, it is requesting three changes:

  1. Permit WITH expressions to be used not only with exceptions on the SPDX Exceptions List, but also any broader set of user-defined custom "modifiers" to licenses
  2. If 1, then additionally expand the principles for what is on the SPDX Exceptions List to have SPDX also include non-exception "modifiers" on the List
  3. If 1 and 2, then additionally revise existing licenses on the License List (e.g. ANTLR-PD-fallback for the given example) to break them apart into new "modifier" entries on the List

For 1, I believe this is the same as what's being discussed in Change Proposal 4 so I'm not sure how this proposal is adding anything on that particular point?

For 2, this was discussed earlier this year on the call about Change Proposal 4. The decision as I understood it is that the community still sees value in keeping the official SPDX Exceptions List limited to exceptions, not generalized modifiers, and personally I remain in favor of keeping it limited to exceptions.

For 3, I see zero real-world value in going through and revising existing licenses in this way. I don't think there is likely to be any practical value whatsoever in revising existing license IDs to break them apart into new conceptual "modifiers". This seems to me like churn just for the sake of churn.

karsten-klein commented 1 year ago

Your conclusions from the change proposal are already quite good. However, I would regard the proposal as a more generalized concept. You pick only on some highlights.

Change Proposal 4 is - my understanding - only opening the exceptions to provide custom ones. This change proposal goes way beyond, but also covers Change Proposal 4. However, I would not use LicenseRef to prefix a modifier, but rather something like ModifierRef to distinguish the different concepts (a license is not modifier and a modifier is not a license; a license is not an exception and an exception is not a license).

Regarding you comment on point 2. I account myself to the SPDX community and I see the proposed change as tremendous improvement to SPDX supporting to overcome a major conceptional limitation. New concepts or extended concepts mean nothing bad. I would argue that there currently is a lot of indication that such new concepts are required. Otherwise we would not see Jilayne struggling with certain constructs (such as the patent amendments, which we don't want to talk about, but permanently do). The proposal is also written in a way that it opens SPDX for more options; while being still conservative on the inclusion principles side.

Your point 3 is a personal opinion I obviously do not share - otherwise it would not make much sense to take the time to write the proposal and to comment here. I don't see it (the revision of the license and exception list) as must, but also think when a new concept is introduced, it also should be applied. I guess we agree to differ here and require to collect further perspectives from others.

Eventually, I hope I could convey the idea and the potential of the propsal. I didn't meant to cause churn, but I also guess that every change proposal does (at least to some extend). And: it's just a proposal; some thoughts I unselfishly share.

swinslow commented 1 year ago

Thank you @karsten-klein! I appreciate your response and appreciate you submitting the proposal for consideration. Apologies if I was blunt in my earlier comments and thanks for your quick replies to it. I do want to make sure that others feel free to weigh in here as well!

jlovejoy commented 1 year ago

I've had a read of the proposal and am a bit fuzzy, but let me try to parse out some bits, by asking @karsten-klein a couple questions: 1) I think you are in favor of some form of implementation of #4

and

2) want to extend (not sure that is the best word) that concept to licenses that include some form of modifier, for example, you note in your table:

which are all licenses already on the SPDX License List. I think you are suggesting we essentially "break apart" some of these and use their parts with the operator WITH ?

I can sort of see the logic in this for the licenses like MPL-2.0 and CAL-1.0 that include in them clauses that can be included or not (which is not my favorite drafting, to be honest), but where would this end? BSD-2-Clause-Patent was drafted and intended to be a standalone license. To break it apart would be counter to its intentions. I think this could impose a lot of extra work and wrangling (more than we already have? or maybe a different flavor) to determine where the line is drawn.

oops, meant to add: to give each Change Proposal fair consideration, can we focus on a conclusion to #4 first, which I think your change proposal sort of includes. And then come back to this separately? Perhaps, depending on if/how #4 is implemented, you might want to update this one, but TBD. Would that be ok?

swinslow commented 1 year ago

Just to add to @jlovejoy's comment, to the extent that this proposal relates to licenses with multiple selectable "options", please see the discussion at https://github.com/spdx/license-list-XML/issues/970.

In the first half of 2020 the legal team community had a lengthy discussion regarding licenses that use a single license text, but where the licensor can select from multiple "options" or "choices". Some examples might include e.g. the OFL licenses, where the licensor might or might not choose to trigger the "reserved font name" provisions; or similar choices for MPL-2.0 or CAL-1.0 as you noted.

Based on the discussion in 2020, the team's consensus was not to change the license expression syntax or otherwise provide formal mechanisms to reflect these different choices or options. Rather, the preference was, where appropriate, to add separate identifiers to the license list to reflect the different choices. And anyone who wants to customize things beyond that is of course always free to use a LicenseRef-.

For this piece of the proposal, then, I would be inclined to stick with the current decision that was reached a few years ago, unless there's a clear reason and consensus to change it.

Regarding licenses such as BSD-2-Clause-Patent, 100% agree with @jlovejoy that it would be inappropriate to break that apart into separate components such as BSD-2-Clause WITH Patent-Clause-1.0.

swinslow commented 1 year ago

Discussed briefly on 2023-10-26 with reference to https://metacpan.org/release/DPARIS/Crypt-Blowfish-2.14/source/COPYRIGHT#L7 as another example to consider here (cc @karsten-klein)