- Alexios Zavras
Provide a concise statement of the problem or issue that you want to solve, new use case you wish to cover, etc. Optionally include any issues that you would consider to be out of scope for your proposal.
Briefly describe why existing capabilities of SPDX don’t effectively address this problem or issue.
In many cases in real-world projects, the actual license that a piece of software is under is a "standard" license with the "addition" of some text -- which may or may not be legally significant. This additional text may modify the rights granted or obligations imposed by the license, or may even be simply informational.
The SPDX Project has traditionally called such additions that are adding rights or removing obligations "Exceptions" and maintains a list. These can be used in SPDX License Expressions with the WITH operator.
The current specification does not allow for recording these additional texts standalone, but only as parts of a license. The latest guideline is to "use a single LicenseRef- to represent the entire license terms, including the exception."
Provide a proposed resolution to solve this problem or issue.
The proposed solution is to amend the specification, so that any additional text to a given license can be recorded like regular license text and be referenced by using the new prefix syntax AdditionRef-.
Such additions will be able to be used in SPDX License Expressions in the right-hand side of the WITH operator.
AdditionID: AdditionRef-1
ExtractedText: <text>Please consider the political implications of your work.</text>
Describe the audience in the SPDX ecosystem this proposal serves. Include a statement as to how this fits into the overall mission/vision of SPDX.
The proposed change allows recording and expressing more accurate licensing information, which closely aligns with the SPDX project mission and vision.
Indicate which existing parts of the SPDX project are impacted.
The Specification will be updated to introduce the new syntax.
Obviously, an updated syntax in the specification will impact the SPDX language libraries as well, since they will have to be updated to support the new syntax.
The Ontology in its current state will not be affected, since it does not include information on the content of a LicenseException, the same way that it does not distinguish between licenses in the SPDX License List and licenses defined with LicenseRef.
Include any additional information that is relevant or may be helpful to understand the context and/or use case for this change proposal. Also include here links to any related, existing issue or discussions.
The topic has been discussed in the past a number of times, almost as soon as the Exceptions were introduced in the SPDX License List.
The most recent discussion was in issue 153 of spdx-spec repo
The current specification allows any license to be named and referenced with the prefix LicenseRef-. If the definition were extended for this to refer to any legal text, even partial, there will be no need for introducing a new syntax convention.
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).
Similar to the existing LicenseRef- for Licenses, when considering Exceptions the obvious choice would be ExceptionRef-.
However, as described in the issue statement section above, the additional texts are not always exceptions in the legal sense, since there can be cases where they add obigations or even remove rights, not to mention the common case of simple informative text. Rather than using the term "exception", using the neutral term "addition" does not introduce any significance to the type of changes this additional text has on the license text.