Legal Team/or-later-vs-unclear-disambiguation

Introduction to Issue

Background

Originally, the SPDX License List listed variations of licenses as separate "line items". Notably, various versions of L/GPL had two listed items: one for a specific version-only, and one indicating a version-or-later. This was indicated in the list via the inclusion of the words "only" and "or later" in the full name; and via the short identifier: GPL-2.0 and GPL-2.0+ respectively. (examples throughout use GPL-2.0, but this issue applies to the entire family of GNU licenses, i.e., GPL, LGPL, FDL, APGL).

When the license expression syntax was introduced in version 2.0 of SPDX, licenses with the "or later" indication were removed as separate listed licenses, as they could now be provided for via using the "+" operator. This, along with the "with" operator solved the issue of under-representation of license-exception combinations.

However, this also created a new issue whereby the standard header which is usually where the "or later" or "only" option is indicated in practice could no longer be differentiated or captured directly.

Issue

In practice, practitioners are not always explicit about whether a license is a version only or or later option. Also, not all licenses that provide for later versions treat their application in the same way or as explicitly as the GNU family of licenses does. This, combined with the SPDX identifier not explicitly indicating "only" has the potential for people not using the accurate SPDX identifier.

Solution

Replace "GPL-2.0" identifier with "GPL-2.0-only"

This has been discussed with representatives from FSF and reflects their approval and blessing.

Implementation of Solution

The remaining question is how to implement this change.

Below are several options considered, some of which are not tenable for stated reasons. They have been included here for reference.

1) add “only” as an operator: does not solve issue as would still leave door open to use "GPL-2.0" which would be ambiguous as it would not indicate "only" or "or later". L/GPL language is clear that it is one or the other, so this could only create more confusion and not reflect the intention of the license. This could also result in people using the "only" operator with other licenses where it is not needed or shouldn't be used. NOT an option.

2) add new concept of short identifier “alias” and make "GPL-2.0" equivalent to "GPL-2.0-only": If GPL-2.0 = GPL-2.0-only, then how do you get the "or later" option? You'd end up with GPL-2.0-only+ which makes no sense! The ends result here needs to indicate: GPL-2.0-only and GPL-2.0+ and no ability to combine them. Also, short identifier "alias" concept would be a new concept and possibly over-engineering a solution for one set of licenses. NOT an option.

3) roll back + operator: remove the + operator from the license expression syntax and re-implement GPL-2.0-only and GPL-2.0+ as separate line items on the SPDX License List. This would not impact the extensibility of applying exceptions, as the "with" operator is the key factor for that. This would also solve header matching problem as it would allow the standard header field to be existing and matchable for both variations. The key downside to this solution is it means rolling back something we spent a lot of work implementing, but if the outcome provides more clarity and better license "hygiene" as well as aligning with the FSF wishes, then it is worth the work?

This seems to be the best option, but key consideration is impact on other licenses. * original argument was that + operator could be used with other licenses (not just GNU family), but do other licenses actually need it? and have people even used it with other licenses? (not that has been observed) Below is a list of the licenses with text related to later versions, relevant text, and an analysis of the licenses that have "or later version" type language. Please add to this as needed!

A/L/FD/GPL language

The GNU family of licenses (Affero, Lesser, Free Documentation, General) uses the same substantive language. Some of the minor variations (but not all) noted in [].

[The Free Software Foundation/Affero, Inc] may publish revised and/or new versions of the [Lesser/Affero] General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the [Library/Program/Document] specifies a version number of the license which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the [Library/Program/Document] does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.

GPL-3.0, AGPL-3.0, GFDL-1.3 also have the following language:

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

AGPL-1 also has the following clause:

You may also choose to redistribute modified versions of this program under any version of the Free Software Foundation's GNU General Public License version 3 or higher, so long as that version of the GNU GPL includes terms and conditions substantially equivalent to those of this license.

Analysis: {add link to Bradley's email)

EPL-1.0, CPL-1.0, IPL-1.0

Each new version of the Agreement will be given a distinguishing version number.

The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved.

Analysis:

NPL-1.0, MPL-1.0, MPL-1.1, MPL-2.0

Each version will be given a distinguishing version number. 6.2. Effect of New Versions. Once Covered Code has been published under a particular version of the License, You may always continue to use it under the terms of that version. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape. No one other than Netscape has the right to modify the terms applicable to Covered Code created under this License.


MPL-2.0 is more concise, but has same effect:

Each version will be given a distinguishing version number. 10.2. Effect of New Versions 
You may distribute the Covered Software under the terms of the version of the License under which You originally received the Covered Software, or under the terms of any subsequent version published by the license steward.

Analysis:

other licenses

add

Selected responses/ideas/commentary from mailing list =

NOTE: Please feel free to add/clarify below

At the same time as conversations between SPDX leaders and FSF representatives were on-going, this topic bubbled up on SPDX mailing list. Below is a summary of such conversations.

D. Wheeler 5/25/2017

Technically “GPL-2.0” in SPDX means “only this version”, but in practice many practitioners & tools are sloppy about this. Part of the problem is that tools can easily determine that “GPL version 2.0 is in this package” but in many cases they cannot easily determine automatically a distinction between “2.0 or greater” versus “2.0 and no other”. In addition, in many cases it doesn’t matter, so the increased effort would be a waste of time. What the tools really need to indicate is a way in SPDX to indicate “2.0 at least is here, and I don’t know if ‘or later’ is okay”. Since SPDX doesn’t have a mechanism to report this, “GPL-2.0” is sometimes being used to report of “I know 2.0 is here, and I don’t know if ‘or later’ is okay” - even though it’s technically not compliant with the SDPX spec.

It’d be helpful to have a simple way to indicate “I really mean this specific version” (my “!” suffix) vs. “this version at least is okay, and I’m not sure about later versions” (which is how “GPL-2.0” is currently interpreted; maybe another suffix like “?” or “*” would help to mark this case).

K. Stewart 5/25/2017

We've started having some discussions with FSF about what they'd prefer, and their preference seems to be GPL-2.0-only, so we probably want to go that way rather than introducing the "!" idea.

D. Wheeler 5/25/2017

 K. Stewart: We've started having some discussions with FSF about what they'd prefer, and their preference seems to be GPL-2.0-only,  so we probably want to go that way rather than introducing the "!" idea.

Okay. Although that's less flexible, that's much easier to transition (you don't have to change any parsing code), so I see the advantages of this.

If this is done: 1. It needs to cover all the licenses where this is likely. At *least* GPL and LGPL; I think MPL is probably in this case too. 2. The original license terms need to *stay* in SPDX, with modified clarifying text. Something like this:

GPL-2.0: The GNU General Public License (GPL), version 2.0 is acceptable, and without any clear statement if later versions are acceptable. Where practical, try to use more specific license expressions such as "GPL-2.0+", "GPL-2.0-only", or "(GPL-2.0-only OR GPL-3.0-only)". Historically this indicator meant "GPL version 2.0 only", but in practice tools often can't determine if later ones are acceptable (or not) & used this term in such cases. This specification acknowledges this practice and provides more specific alternatives when that information is available.

D. Wheeler 5/26/2017

We need at least *3* cases. Here they are, with potential names/expressions:

• GPL-2.0-only. I *know* that *only* the GPL version 2.0 is acceptable. I had originally proposed a "!" suffix.
• GPL-2.0+. I *know* that GPL version 2.0, or later, is acceptable.
• GPL-2.0. I *know* that at least GPL version 2.0 is acceptable (e.g., I found its license text). However, I'm not entirely certain whether or not later versions are acceptable, so I make *no* assertion either way. This appears to be what "GPL-2.0" has become, in some cases, in spite of the spec. Which is why we need a way to mark certainty vs. uncertainty. If you prefer, you could label this "GPL-2.0-at-least", or add a "?" suffix to mean "I don't know if later/other versions are acceptable".

The problem is that while tools can detect the presence of a license, it's often difficult for them to determine if an "or later" clause is valid in some cases. In many cases SPDX is capturing tool output, so we need for there to be a valid expression for tools to output. My understanding is that some tools that find GPL version 2.0 will currently report "GPL-2.0"... even if a later version is also acceptable... and as a result, "GPL-2.0" is not being interpreted as originally intended.

What's more, without a third case, it'll just happen again. Tools can't easily determine if "or later" applies, and in many cases you do *NOT* need more information than this. It can take a lot of effort ($) to determine if it's really "GPL-2.0-only" or "GPL-2.0+", and if the spec only supports those two options, then that's a problem.. because people are *not* going to spend effort unnecessarily.

If "GPL-2.0" is deprecated, then tools will start reporting "GPL-2.0-only" when they're not sure if later versions apply, because in many cases they can't easily determine it. Then we'll be back to the original problem, where "GPL-2.0-only" may mean "I found GPL 2.0 but maybe later versions will be okay". Ugh. Since many tools can only determine "at least this version", there needs to be a standard way to report it.

T. King 5/26/2017

Digging at this “acceptable” idea a bit more, I'm guessing it's something like “adapters may share adapted works under”. But the SPDX isn't just about copyleft (e.g. it includes CC-BY-ND-*). I think it makes more sense to focus on licenses (just the text, e.g. GPL-2.0) and license grants. For example, here are some SPDX License Expressions translated into grants:

• GPL-2.0: You can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.

• GPL-2.0+: You can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

• CC-BY-SA-4.0: This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

You can distribute an adaptation under a later version of the CC BY-SA because that's part of the CC-BY-SA-4.0 [1].

• CC-BY-SA-4.0+: This work is licensed under a Creative Commons Attribution 4.0 International License; either version 4.0 of the License, or (at your option) any later version.

The CC-BY-SA-4.0 tries to grant you that right anyway, but regardless of how you read the CC-BY-SA-4.0, I'm granting you that right directly.

> CC-BY-SA-3.0+ would be a synonym for CC-BY-SA-3.0 [6], but I don't > see a problem with that. It would probably be useful to call that > out in the wording that forbids the -only suffix for CC-BY-SA-3.0…

If the SPDX doesn't want to get into the business of determining when licenses grant + semantics, then we probably don't want an -only suffix and we certainly don't want a GPL-2.0-only short identifier.

But if you want to be in the business of warning users about the lack of built-in or-later wording in the GPL, CC-BY-ND-4.0, etc. and the presence of built-in or-later in the CC-BY-SA-4.0, etc., I don't see how you'd avoid making claims about whether the license had built-in or-later wording.

D. Seaward 5/26/2017

Perhaps "GPL-2.0"could be deprecated and instead whoever is tagging must use one of:

• GPL-2.0-only
• GPL-2.0+
• GPL-2.0?

...where "only" means only, "+" means "or later" and "?" means unclear. Legacy data still tagged "GPL-2.0" would be treated as "GPL-2.0?" until updated. (This assumes the SPDX team want people tagging things as unclear!)