Support creation of custom exception using "ExceptionRef"

[tsteenbe]

Currently the SPDX spec supports non-SPDX licenses using the "LicenseRef" prefix but such a thing does not exist for exception. Proposal is to introduce “ExceptionRef” prefix to allow SPDX users to define non-SPDX exception.

Per SPDX tech team meeting the only workaround now is to make a LicenseRef out of SPDX license and the non-SPDX exception.

Use case:
Found LGPL-3.0 with an OpenSSL-exception which we now encoded as LicenseRef-ORT-LGPL-3.0-only-with-OpenSSL-exception which means for the tooling it's a complete new license. Better solution would be the expression LGPL-3.0-only WITH ExceptionRef-OpenSSL-exception.

[swinslow]

I'm in favor of this. Agree that there should be a clearly documented way to create custom exception texts.

I assume — consistent with your milestone tagging :) — that this would be 3.0 rather than 2.2, since I think this would be a breaking change to the license expression syntax.

[richardfontana]

I am also in favor of something like this. An example where this might be useful: a project readme file that says

This software is free. You can use it under the terms of GPLv2, see LICENSE. In addition starting from version 3.0rc1 if you're offering a scanner based on testssl.sh as a public and / or paid service in the internet you need to mention to your audience that you're using this program and where to get this program from.

A different example, from the main script file in the same project:

# License: GPLv2, see https://opensource.org/licenses/gpl-2.0.php
# and accompanying license "LICENSE.txt". Redistribution + modification under this
# license permitted.
# If you enclose this script or parts of it in your software, it has to
# be accompanied by the same license (see link) and the place where to get
# the recent version of this program. Do not violate the license and if
# you do not agree to all of these terms, do not use it in the first place.

This sort of phenomenon is not uncommon in nominally *GPL-licensed projects. It could be beneficial in these cases to have an SPDX expression that includes the information that part of the license is a textually-intact license that maps to something on the SPDX license list.

These examples are not "exceptions" in FSF GPL-2.0 parlance (they would be what GPL-3.0 calls "additional requirements") and are worth capturing precisely because they raise issues of GPL compliance and non-normative (even if compliant) use of GPL licensing. So I don't know if it would be better to use a construct name not based on the notion of an "exception".

[tsteenbe]

So I don't know if it would be better to use a construct name not based on the notion of an "exception".

@richardfontana What do you think of "ConditionRef" as a way capture additional clauses that have been added a license and have "ExceptionRef" for clauses that have been removed?

[richardfontana]

@tsteenbe I don't want to get too hung up on labels, though "ConditionRef" implies a legal conclusion and making a distinction between "exception" and "condition" also implies that some legal analysis is being done, which I think SPDX in general is trying to avoid. I don't know what a good neutral label would be ... "term" is somewhat suggestive of a condition; "clause" implies it's not separate from the main license document (but usually these things are). GPLv3 uses the term "term" in a way that is supposed to encompass anything, and no one ever complained about that. TermRef? AdditionalTermRef?

[nicorikken]

A similar request was mentioned on the mailinglist of the REUSE project: https://lists.fsfe.org/pipermail/reuse/2021q4/000127.html Treating everything as a new license makes it very explicit and easy to develop SPDX-capable tooling, but makes it more cumbersome to handle a newly encountered exception (handling as custom license or requesting upstream changes). I'm mostly in favor of just defining new licenses that include the exceptions, but I can see the point of view for supporting exceptions, so perhaps SPDX should support exception?

[cdwilson]

So I don't know if it would be better to use a construct name not based on the notion of an "exception".

FWIW, the two cases I've come across recently both call these "exceptions", so "ExceptionRef" prefix would make sense for my use case:

• https://www.kicad.org/libraries/license/ "with the following exception"
• https://www.snapeda.com/about/terms/ "4.2 Design Exception 1.0"

[pombredanne]

A few comments:

• https://spdx.github.io/spdx-spec/SPDX-license-expressions/ in version spec 2.2 unfortunately limits the use of exceptions to known, listed exceptions
• ScanCode Toolkit tracks 231 license exceptions of which 107 are not known to SPDX. See https://scancode-licensedb.aboutcode.org/
• Several ScanCode users are already using these as in GPL-2.0-only WITH LicenseRef-scancode-unlimited-linking-exception-gpl

My guess unless being proven otherwise is that the vast majority if not all of the LicenseRef- used in license expressions as n exception are from ScanCode.

So I would like to enact this as the standard and avoid to create a new concept of "ExceptionRef". Instead reuse the "LicenseRef" prefix which is plenty good and enough. That would be a minor update to the license expression appendix.

[sschuberth]

Instead reuse the "LicenseRef" prefix which is plenty good and enough.

Maybe with the additional requirement that such an "exception LicenseRef" also needs to contain the string "-exception" or "-exception-"?

[pombredanne]

Maybe with the additional requirement that such an "exception LicenseRef" also needs to contain the string "-exception" or "-exception-"?

@sschuberth I am not opposed to it, but this is not even the case for exceptions on the exception list (e.g., there are "official" exceptions that do not use "exception" in their ids), so I cannot see how this could become a requirement for other exceptions.

[sschuberth]

so I cannot see how this could become a requirement for other exceptions.

Well, we have to start somewhere with establishing best practices. And of course existing exceptions would need to be updated to follow these, too, at some point.

[goneall]

Providing a link to a proposal made by @zvr - spdx/change-proposal#4

[goneall]

This was added in 3.0 as part of the change request for AdditionRef.

Closing as resolved.