Change Proposal: AdditionRef-

[jlovejoy]

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

To be reviewed by SPDX-legal and SPDX-tech team.

Please indicate in this issue, if you think this proposal should move forward or not at this time, which a brief supporting statement for your decision.

If there is support to move forward, then we will move the discussion to the appropriate team for discussion related implementation.

[goneall]

+1 on the change proposal.

One suggestion - we should also support external document references to ExceptionRef's in the same way we support external document references to LicenseRef's.

[jlovejoy]

I think this would be a good addition. I like the distinction of ExceptionRef- rather than allowing LicenseRef- on both sides of the WITH operator, as it seems to avoid confusion.

Implications for spec:

• Section 10 https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/
• Annex D https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
• possibly some other updates in related items in SPDX License List repo and documentation

[richardfontana]

+1 consistent with what I said a couple of years ago. However, I urge that this not be tied to the existing narrow, FSF-doctrinally-influenced SPDX notion of what an "exception" is, which does not match up with real-world uses of FOSS/FOSS-like licenses coupled with additional terms. An "ExceptionRef" construct for use with WITH would be useful to represent terms that are clearly or possibly not characterizable as "additional permissions" or "exceptions" in the orthodox GPL sense. See the examples in my comment on the issue linked above (though I have no recollection of where I encountered them).

Update: I think @pombredanne's counterproposal is preferable because it seems to address (in this one limited context) my basic objection to SPDX's tying itself to a narrow, normative understanding of what an "exception" is, instead of attempting to devise an objective way of representing the actual kinds of license term supplementation that occurs in practice, which would be more consistent with how SPDX treats license representation. I am still +1 for the proposal because there is a pressing need for user-defined supplementary term identifiers and this would get us there provided the use of the ExceptionRef- construct with non-FSF-normative types of additional terms is not treated as improper.

Further update: Having just dealt with a real-world case of some terms that could be characterized either as an orthodox GPL exception or as an alternative (non-FOSS) license, and in the process concluding that we needed to have two data files in the Fedora license data repository (with two different SPDX expressions) to represent both interpretations, I am now mildly -1 on this proposal and instead support @pombredanne's suggestion for allowing LicenseRef- to be used in WITH subexpressions.

Essentially, the concern that 'LicenseRef-1 WITH LicenseRef-2' (to use @Pizza-Ria's example) is undesirable is IMO misplaced because in some situations you might want to use LicenseRef-2 outside of a WITH context.

@pombredanne says:

there is nothing in the SPDX standards to define the validity of license elements within a license expression, nor does it make sense for SPDX to cover that. There is no specific meaning attached to the exception identifiers to reliably determine if a license id on the SPDX license list is for a license or an exception short of getting more data beyond the identifier alone.

This is related to why I find SPDX's treatment of exceptions confusing given what I thought was a "just the facts" principle. The SPDX spec says of WITH: "Sometimes a set of license terms apply except under special circumstances." And the SPDX exception list says: "These exceptions grant an exception to a license condition or additional permissions beyond those granted in a license; they are not stand-alone licenses." This implies SPDX is making some kind of nontrivial legal interpretation of what are often informal and confusing terms. In reality, we have things in FOSS/pseudo-FOSS characterized as 'exceptions' that are probably not really "granting an exception" in any meaningful sense (see for example the old license of Liberation Fonts). We also might have highly restrictive terms that have been constructed to look like an orthodox GPL exception. SPDX should not deciding whether supplementary terms, whether or not characterized by the licensor as an 'exception', are actually additional permissions or something else.

[Pizza-Ria]

+1 - Seems to align with already documented exceptions provided at https://spdx.org/licenses/exceptions-index.html and offer an easier way to identify them especially considering the final note in the writeup of the ambiguity of only using "with" (i.e., "However, this would result in an impossibility to distinguish between Licenses and Exceptions, therefore a construct like LicenseRef-1 WITH LicenseRef-2 might be valid (if it were similar to Apache-2.0 WITH LLVM-exception) or not (if it were similar to Apache-2.0 WITH BSD-3-Clause)."

[silverhook]

I agree with both @zvr ’s suggestion and @richardfontana ’s comment above.

(as pretty much always, likely won’t be able to make the call due to a clash)

[goneall]

Providing a link to an existing issue in the SPDX spec proposing same: spdx/spdx-spec#153

[pombredanne]

-1 I do not agree with this proposed change.

This is consistent with my previous comment on the topic spdx/spdx-spec#153 (comment) a few years back. Having a separate prefix for an identifier did not make sense then and it does not make more sense today.

The latest guideline is to "use a single LicenseRef- to represent the entire license terms, including the exception."
As the representative of one of the primary open source projects that actively collects, defines and uses exceptions that are not listed in the SPDX license list, it would wreak havoc on the existing user base for ScanCode licenses where we consistently have used a LicenseRef prefix in these cases. These users represent a large number of the open source tools in the space. We track about 100 such exceptions that are not on the SPDX list at this time.

I also wrote back then: spdx/spdx-spec#153 (comment) : “My guess is that the majority, if not all, of the LicenseRef- used in license expressions as an exception are from ScanCode.”
Introducing an ExceptionRef prefix would break tools and validators including tools that merely parse and validate license expressions. The syntax would need to be updated https://spdx.github.io/spdx-spec/SPDX-license-expressions/

Counter proposal

The only thing that seems reasonable is to allow the use of LicenseRef values in the WITH part of a license expression. Some key supporting points:

1. This approach is already used in practice

2. It requires only a minor relaxation of the spec and validation tools and does not introduce new constructs nor would it break existing license expression handling tools.

Note that this approach is already considered in https://github.com/spdx/change-proposal/blob/main/proposals/ExceptionRef.md#not-introducing-new-prefix. A concern expressed here is:
“However, this would result in an impossibility to distinguish between Licenses and Exceptions, therefore a construct like LicenseRef-1 WITH LicenseRef-2 might be valid (if it were similar to Apache-2.0 WITH LLVM-exception) or not (if it were similar to Apache-2.0 WITH BSD-3-Clause).”

This is already the case because there is nothing in the SPDX standards to define the validity of license elements within a license expression, nor does it make sense for SPDX to cover that. There is no specific meaning attached to the exception identifiers to reliably determine if a license id on the SPDX license list is for a license or an exception short of getting more data beyond the identifier alone.

Existing exception identifiers are not prefixed or suffixed consistently in the license list, so adding an arbitrary convention for non-SPDX listed exceptions does not make sense. If someone mistakenly records “Apache-2.0 WITH BSD-3-Clause” instead of “Apache-2.0 AND BSD-3-Clause”, most people would understand the meaning. A good way to think of this is that WITH is a special case of AND to alert you to the fact that the next license in the license expression is an exception.

Using a consistent convention to include the word "exception" in the license id would be a good thing and is probably all that is needed. See suggestion by @sschuberth in spdx/spdx-spec#153 (comment)

[swinslow]

I haven't had a chance to think about this in detail, but based on an initial review of the proposal and the comments above, here are my thoughts:

Overall: I'm +1 to the original proposal. Open to some modifications to it, but as a baseline I think there needs to be some way to support user-defined exceptions within the existing SPDX license expression syntax and license data model.

Exceptions on the license list itself:

For purposes of the exceptions actually on the SPDX License List, to respond to @richardfontana I do think there has been value in keeping it to the narrow definition of "additional permissions" or "exceptions."

Briefly, by limiting it to those exceptions, you can look at an expression using WITH, like GPL-2.0-only WITH GCC-exception-2.0, and know that you at least have the rights in GPL-2.0-only itself. A WITH expression might indicate that fewer restrictions apply, but at a minimum the recipient can elect to disregard the WITH and know that they could just use it under the original license. By contrast, if exceptions could be any modifier -- e.g. if you could have GPL-2.0-only WITH Commons-Clause -- then this presumption no longer holds.

So I think there's value in it having worked this way in the past. All that said, I could also be open to an argument that the value there is outweighed by replacing "exceptions" with a more general "modifier" concept. But I think that's outside the scope of this particular change proposal.

If the question is just whether custom ExceptionRef- exceptions should be required to be strict "exceptions" under this definition, I'm less tied to that and I could be okay with flexibility here. If the ExceptionRef- prefix is present, then as with LicenseRef- licenses, all bets are off regarding stability, structure, etc., since there's no community review / curation for custom identifiers and their content.

Prefix for custom exceptions:

I'm -1 to the comments above indicating that LicenseRef- should be used as the prefix for BOTH licenses and exceptions.

Licenses are different from exceptions to licenses (and/or modifiers to licenses). They are defined differently on the SPDX license list (licenses vs. exceptions); in the location and permitted syntax for the license-list-XML templates (schema); and in the RDF objects that represent them in the underlying SPDX data model (licenses vs. exceptions).

Changing the license expression syntax to permit LicenseRef-'s to be used in WITH expressions would, I suspect, require treating licenses and license exceptions as identical in the underlying SPDX data model. I think this would break existing assumptions for tools and communities that have relied on the expression syntax and object model. I also think this could introduce confusion by conflating AND/OR and WITH. I don't really see the benefit that would outweigh these.

I would suggest that the discussion here be focused on the specific proposal at hand, and whether to adopt this (as-is or with minor/moderate changes) in the near term. If people want to propose more significant changes to the underlying SPDX data model, license expression syntax, etc., then I would suggest it's probably appropriate for those to be submitted as a separate change proposal so that it can be similarly considered and discussed.

[jlovejoy]

NOTE - we will discuss this Change Proposal in terms of 1) proceeding with it or not (yes or no); and 2) if yes, then specifics as to implementation.

On Thursday, Jan 12th at noon US eastern time using the Legal team dial-in. I will also send an email reminder to both the legal and tech mailing lists.

[jlovejoy]

Having re-read this thread, I think there are a few tangents and I want to make sure we stay focused on our call Thursday. To use an illustrative example:

If I found a package licensed under Apache-2.0 (which is on the SPDX License List), and it also applied the Commons Clause (which is not on the SPDX License List):

1. Status quo: as the spec currently stands (see section 10) I would represent this as:
   LicenseRef-somename in 10.1 License identifier field and capture the total of the text of Apache-2.0 and the Commons Clause in 10.2 Extracted text field

2. This Change Proposal proposes to instead, be able to use: 'Apache-2.0 WITH ExceptionRef-CommonsClause' in 10.1 License identifier field and capture the text of only the Commons Clause in 10.2 Extracted text file

2a) An alternative implementation option (suggested by @pombredanne and which, if I understand correctly, is what Scancode has already been doing?) would to be able to use: 'Apache-2.0 WITH LicenseRef-CommonsClause' in 10.1 License identifier field and capture the text of only the Commons Clause in 10.2 Extracted text field.

[vargenau]

Will this proposed change be in 2.3.1, 2.4 or 3.0?

[jlovejoy]

Discussed on Jan 12th legal call https://github.com/spdx/meetings/blob/main/legal/2023-01-12.md

Everyone in favor of allowing more extensible ability to represent things not on SPDX License List on right side of WITH operator.

Still need to decide on implementation and meaning.

Next steps:

• Alexios to prepare PR for how spec would change if allowed different term than LicenseRef (whether ExceptionRef or ModifierRef as discussed)
• Dennis/Phillippe to prepare PR for how spec would change if extended use of LicenseRef to allow that to represent things on right side of WITH

To revisit once PRs are posted after FOSDEM - probably mid-Feb

[pombredanne]

Dennis/Phillippe to prepare PR for how spec would change if extended use of LicenseRef to allow that to represent things on right side of WITH

I drafted this PR spdx/spdx-spec#829