Specify which licenses are compatible with the "+" operator

[vargenau]

Currently, the standard does not specify which licenses are compatible with the "+" operator.

We should explicitly list in the standard the licenses that cannot use the "+" operator.
We have at least:

• GPL-1.0-only
• GPL-2.0-only
• GPL-3.0-only
• LGPL-2.0-only
• LGPL-2.1-only
• LGPL-3.0-only
• AGPL-1.0-only
• AGPL-3.0-only
• GPL-1.0-or-later
• GPL-2.0-or-later
• GPL-3.0-or-later
• LGPL-2.0-or-later
• LGPL-2.1-or-later
• LGPL-3.0-or-later
• AGPL-1.0-or-later
• AGPL-3.0-or-later

[swinslow]

I'm -1 on incorporating this into the spec, at least as far as it goes for defining the syntax of valid SPDX license expressions.

Syntactically, the license expression grammar should continue to permit license expressions where any valid license ID can have a + appended to it. I'll defer to the tool makers, but I assume it would greatly complicate the grammar to try to define a subcategory of only certain identifiers which are permitted to have, or forbidden from having, a + following them.

Semantically, I'm probably also a -1 on defining this.

Agreed that there are plenty of identifiers where appending a + probably doesn't make sense, such as the ones you listed. But this also probably applies to any license ID without a version number; for instance, MIT+ or CNRI-Python+ seems to be just as nonsensical. And even for those identifiers that appear to have version numbers, I don't think it's machine-definable how the + operator would operate; for instance, does LPPL-1.3a+ mean that it can be used under LPPL-1.3c, or is W3C-19980720+ usable under W3C-20150513?

I think that attempting to answer this in any machine-encoded fashion is likely to get SPDX into the business of interpreting the meanings of licenses and license expressions, which is something we've avoided doing wherever possible. Because of that, I'm in favor of keeping + available as an option for folks to use, or not; and if they do use it, then the consumer of that license expression will have to figure out how it applies in the particular context, as with any other aspects of the license.

[vargenau]

Thank you for your comments.

I was not thinking of changing the grammar or the parser.

My idea was more to add one more column in the https://spdx.org/licenses/ page. We already have "FSF Free/Libre?" and "OSI Approved?". We could have "+ Operator compatible?".

What do you think?

[swinslow]

Thanks @vargenau, apologies that I hadn't understood your proposal when I responded earlier.

I think the question is partly who is making the determination. For both the FSF and the OSI columns, we defer to those organizations for what they've approved; the SPDX project is just reflecting their determinations, not making any conclusions ourselves of which licenses fit these definitions.

For "+ Operator compatible", I think the challenge remains that I described earlier. I think any question of "is this license compatible with the use of a + operator" is ultimately driven by the author or steward of each license, not by the SPDX project. For instance, looking at some of the examples I mentioned above, I don't think SPDX is really in a position to establish whether LPPL-1.3a or W3C-19980720 are compatible with the + operator.

Ultimately, any sort of rules we might come up with are still going to require users of license expressions to make legal determinations when they figure out how to apply the license expression to their use case. For instance, let's say that OFL-1.0-no-RFN is labeled "+ Operator compatible", since there's a family of OFL-1.1 licenses. The question of whether something under OFL-1.0-no-RFN+ can be used under OFL-1.1, or OFL-1.1-no-RFN, or whatever, is going to require legal interpretation. And given that, I don't think there's going to be much value in the SPDX project declaring whether OFL-1.0-no-RFN+ is considered "compatible".

I'm still leaning towards thinking that this should remain driven by the syntax -- such that any license ID can have + following it, and SPDX as a project doesn't get into declaring which uses are semantically "compatible". But I'd welcome input from other Legal Team participants as well -- cc @jlovejoy @pmadick or any others who want to weigh in here too!

[silverhook]

I’m with @swinslow on that.

((…if anything, I’d be in favour of reverting the *GPL family to be back in line with the + operand, but that’s probably not likely. Had to be said though))

[goneall]

Based on the above comments, the change is significant enough we should open a change proposal if we want to implement the solution.

I'm closing this issue as part of the SPDX 3.0 release cleanup.