SPDX Wiki - User contributions [en]

Legal Team/Minutes/2017-11-09

2017-11-14T09:17:45Z

Wking: Link back to earlier Legal_Team/or-later-vs-unclear-disambiguation

== Attendees ==
* Kate Stewart
* Bradley Kuhn
* Bradlee Edmondson
* Alexios
* John Sullivan
* Dennis Clark
* Paul Madick
* Steve Winslow
* Mike Dolan
* Trevor King
* Gary O’Neall
* Alan Tse
* Jilayne

== Agenda ==
'''1) revisit the [[Legal_Team/or-later-vs-unclear-disambiguation|only/or later/? topic]] - see discussions from mailing list: https://lists.spdx.org/pipermail/spdx-legal/2017-November/thread.html'''
The notes below includes key points, but not all the discussion:
* John: issue with plain identifiers is if there is just a copy of license with no statement, then there’s statement in license itself that any version of GPL can be used; the copy of a version does not specify the version by itself. in response to Jilayne’s comparison to the license w/binary blob example (where the license would prevail with no other info needed in the “files”) - GPL is more specific, so not a comparison
* tension in how license list is used and different fields in spec - info in file v. conclusion; and outside an SPDX document - need to address both/all
* Trevor proposed enhancement to XML to flag error if use plain identifier (e.g., GPL0-2.0) which might only apply to conclusion fields
* could also add/make NOASSERTION as something that can be used as part of license list/expressions (not just within the spec/SPDX docs) - this would be helpful for more than this scenario.
* current proposal is easier for tooling and also leaves room for extensibility or other operators (discussion of how proxy clause would work, for example)

'''Net sum of call: possible proposals, all of which accommodate 3 options: '''
* this version only
* this or any later version
* I found the license text (of a version) only and no other information

1a) “Gary’s proposal” (same one as we’ve been talking about since beginning of this discussion):
* keep plain identifiers on license list (remove the word “only” in full name); add “only” operator; provide documentation that the plain identifier is meant to be used in the instance to show you found the text of that license

1b) “operator metadata proposal”
* Like “Gary's proposal”, but [https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html add] [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002308.html <code>compatibleWith…</code>] [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html metadata] so we can warn in tooling and on the license list that a bare <code>GPL-2.0</code> is ambiguous and that valid license-expressions SHOULD (and [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002311.html later, with SPDX 3.0, MUST]) supply a versioning operator. In this case, the “license text but no grant” case would be require an explicit [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html <code>AMBIGUOUS</code> or <code>OR-MAYBE</code> operator].

2) “Paul’s alternative proposal: provide 3 “hard-coded” options on the license list as follows:
* change current GPL-2.0 to GPL-2.0-only
* add GPL-2.0-or-later
* add GPL-2.0-text-alone (or something along those lines) to be used in the instance to show you found the text of that license)

Note: the use of people’s names is only to attribute who initiated the idea and aide in referring to the proposals :)

Need to carry on discussion of next release preparations, as well as this topic on mailing list.

Note: next call falls on Thanksgiving, so we will use tech team’s call time on Tuesday, Nov to carry on discuss so too much time does not pass!

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

2017-11-14T09:16:17Z

Wking: Possibly obsolete in favor of the proposals listed in the 2017-11-09 minutes.

Status: obsolete? (See more recent discussion in [[Legal_Team/Minutes/2017-11-09]]

==Introduction to Issue ==
===Background (SPDX)===
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).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did not at that time conduct a full analysis of the other licenses with "or later" language or how they work in practice.

===Background (additional)===

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.
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 are [[Legal Team/later-version-clauses|here]].

Notably, most license that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

The spec provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). This approach will also fail to distinguish between <code>MPL-2.0</code> and <code>MPL-2.0-no-copyleft-exception</code>, since that distinction is [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/MPL-2.0-no-copyleft-exception.xml#L43-L44 based on the blurbs]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Goals===
* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
* Ensure that there is some amount of consistency with what the short identifiers refer to
* Don't completely break the meaning for current users

==Solutions==
Various solutions were discussed on legal and tech team calls on the following dates, as well as via the mailing list.

The current proposed solution represents the most recent evolution in discussions on the topic. Items below that are left here for record, but not necessarily updated.

===Current Proposed Solution===
Based on the joint legal/tech call on 17 August 2017, we coalesced around a solution similar to "alternative option" from 8 Aug joint call:

* Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use'.
** add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
** This avoids SPDX having to make an interpretation as to what the licenses mean/intend.
** Allows for use of GPL-2.0 when you find just the license file with the text of GPL-2.0 and still provides option for Concluded License to be GPL-1.0+ if no other info is found
* Remove "only" from full name of GPL family.
* This solution allows the license text to speak for itself and uses the 'only' and '+' operators to be explicit in intent. It also avoids conflicting operators by retaining the "plain" license identifier.

Potential issues:
* Backwards compatibility for GPL-2.0 meaning 'v2-only' to now meaning 'whatever the license says' creates some inconsistency as the default position of the license text with no other info is "or later" or "any version", not "only". However, it was pointed out on the call that those people conscientious enough to be using GPL-2.0 correctly, will be more likely to be conscientious enough to add the "-only" operator as needed/once it's available. All seemed to agree that use of GPL-2.0 is probably not thought through as to "or later" or "only", and thus in these situations, there is no different meaning.
* Does not make clear indication of "ambiguous" situation to push people towards using 'only' and '+' operators to be explicit (preferred). However, we don't have a clear indication of ambiguity now either (is ambiguity ever clear?).
* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license. However, all agreed that when you have a machine scanning code with no other license info other than a file with the license text of GPL-2.0, this is not entirely clear situation.

===Joint call 8 Aug 2017 proposed solution ===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background (SPDX)|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):
* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - create <code>-only</code> and <code>PROXY {TEXT}</code> operators for licenses that explicitly declare their compatibility===
* Create an <code>-only</code> operator for “only this version of the license is intended for use”.
* Create a <code>PROXY {TEXT}</code> operator for the proxy declaration in the GPL-3.0 and similar (see [[#Background (SPDX)|the KDE example above]]).
* The <code>+</code> operator would remain with the same definition.
* Change the name and description of the GPL family of licenses to remove [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-2.0.xml#L1 “only” references].
* Add fields to the [https://spdx.org/spdx-specification-21-web-version#h.1v1yuxt license metadata] and the license-list's XML for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. For example, <code>GPL-2.0</code> would be compatible with <code>-only</code> and <code>+</code>; <code>GPL-3.0</code> would be compatible with <code>-only</code>, <code>+</code>, and <code>PROXY {TEXT}</code>; <code>NPL-1.0</code> would be compatible with <code>-only</code>, although it's use would not be recommended, and <code>BSD-2-Clause</code> would be compatible with none of these operators.
* Add metadata flagging licenses which should be explicitly versioned. For example, the GPL and CDDL families would declare “should explicitly version”. Then tooling could warn if a license expression had, for example, <code>GPL-3.0</code> unmodified by <code>-only</code>, <code>+</code>, or <code>PROXY {TEXT}</code>. Tooling should consider <code>GPL-2.0 OR GPL-3.0</code> to be explicitly versioned, even though it uses none of the versioning operators.

Potential issues:
* This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
* This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.
* This has the same “<code>-only</code> operator used with an inappropriate license” issue as [[#Current_Proposed_Solution|the current proposal]], but again, now we can warn in these cases.
* This has the same “no generic way to say ‘I just found this license text and am not sure about the grant’” issue as [[#Current_Proposed_Solution|the current proposal]], but since that's a generic problem with an existing out-of-license-expression solution, I'd argue for not solving it in the license expression. For examples outside of a SPDX declaration, see GitHub's [https://developer.github.com/v3/licenses/ “not a law firm”] and [https://github.com/spdx/tools/blob/master/LICENSE “not legal advice”] [https://help.github.com/articles/licensing-a-repository/#disclaimer caveats].

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== Selected responses/ideas/commentary from mailing list ==
''' NOTE:''' Please feel free to add/clarify below
link to SPDX-legal mailing list from this thread can be found here: https://lists.spdx.org/pipermail/spdx-legal/2017-May/thread.html

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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

Legal Team/Minutes/2017-11-09

2017-11-09T22:10:54Z

Wking: Mention that the “license text but no grant” case will need an additional AMBIGUOUS or OR-MAYBE operator

== Attendees ==
* Kate Stewart
* Bradley Kuhn
* Bradlee Edmondson
* Alexios
* John Sullivan
* Dennis Clark
* Paul Madick
* Steve Winslow
* Mike Dolan
* Trevor King
* Gary O’Neall
* Alan Tse
* Jilayne

== Agenda ==
'''1) revisit the only/or later/? topic - see discussions from mailing list: https://lists.spdx.org/pipermail/spdx-legal/2017-November/thread.html'''
The notes below includes key points, but not all the discussion:
* John: issue with plain identifiers is if there is just a copy of license with no statement, then there’s statement in license itself that any version of GPL can be used; the copy of a version does not specify the version by itself. in response to Jilayne’s comparison to the license w/binary blob example (where the license would prevail with no other info needed in the “files”) - GPL is more specific, so not a comparison
* tension in how license list is used and different fields in spec - info in file v. conclusion; and outside an SPDX document - need to address both/all
* Trevor proposed enhancement to XML to flag error if use plain identifier (e.g., GPL0-2.0) which might only apply to conclusion fields
* could also add/make NOASSERTION as something that can be used as part of license list/expressions (not just within the spec/SPDX docs) - this would be helpful for more than this scenario.
* current proposal is easier for tooling and also leaves room for extensibility or other operators (discussion of how proxy clause would work, for example)

'''Net sum of call: possible proposals, all of which accommodate 3 options: '''
* this version only
* this or any later version
* I found the license text (of a version) only and no other information

1a) “Gary’s proposal” (same one as we’ve been talking about since beginning of this discussion):
* keep plain identifiers on license list (remove the word “only” in full name); add “only” operator; provide documentation that the plain identifier is meant to be used in the instance to show you found the text of that license

1b) “operator metadata proposal”
* Like “Gary's proposal”, but [https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html add] [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002308.html <code>compatibleWith…</code>] [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html metadata] so we can warn in tooling and on the license list that a bare <code>GPL-2.0</code> is ambiguous and that valid license-expressions SHOULD (and [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002311.html later, with SPDX 3.0, MUST]) supply a versioning operator. In this case, the “license text but no grant” case would be require an explicit [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html <code>AMBIGUOUS</code> or <code>OR-MAYBE</code> operator].

2) “Paul’s alternative proposal: provide 3 “hard-coded” options on the license list as follows:
* change current GPL-2.0 to GPL-2.0-only
* add GPL-2.0-or-later
* add GPL-2.0-text-alone (or something along those lines) to be used in the instance to show you found the text of that license)

Note: the use of people’s names is only to attribute who initiated the idea and aide in referring to the proposals :)

Need to carry on discussion of next release preparations, as well as this topic on mailing list.

Note: next call falls on Thanksgiving, so we will use tech team’s call time on Tuesday, Nov to carry on discuss so too much time does not pass!

Legal Team/Minutes/2017-11-09

2017-11-09T22:08:49Z

Wking: Add the “operator metadata proposal”, since I think it addresses the concerns which motivate (2) while still allowing for a future ‘PROXY {text}’ operator

== Attendees ==
* Kate Stewart
* Bradley Kuhn
* Bradlee Edmondson
* Alexios
* John Sullivan
* Dennis Clark
* Paul Madick
* Steve Winslow
* Mike Dolan
* Trevor King
* Gary O’Neall
* Alan Tse
* Jilayne

== Agenda ==
'''1) revisit the only/or later/? topic - see discussions from mailing list: https://lists.spdx.org/pipermail/spdx-legal/2017-November/thread.html'''
The notes below includes key points, but not all the discussion:
* John: issue with plain identifiers is if there is just a copy of license with no statement, then there’s statement in license itself that any version of GPL can be used; the copy of a version does not specify the version by itself. in response to Jilayne’s comparison to the license w/binary blob example (where the license would prevail with no other info needed in the “files”) - GPL is more specific, so not a comparison
* tension in how license list is used and different fields in spec - info in file v. conclusion; and outside an SPDX document - need to address both/all
* Trevor proposed enhancement to XML to flag error if use plain identifier (e.g., GPL0-2.0) which might only apply to conclusion fields
* could also add/make NOASSERTION as something that can be used as part of license list/expressions (not just within the spec/SPDX docs) - this would be helpful for more than this scenario.
* current proposal is easier for tooling and also leaves room for extensibility or other operators (discussion of how proxy clause would work, for example)

'''Net sum of call: two possible proposals, both of which accommodate 3 options: '''
* this version only
* this or any later version
* I found the license text (of a version) only and no other information

1a) “Gary’s proposal” (same one as we’ve been talking about since beginning of this discussion):
* keep plain identifiers on license list (remove the word “only” in full name); add “only” operator; provide documentation that the plain identifier is meant to be used in the instance to show you found the text of that license

1b) “operator metadata proposal”
* Like “Gary's proposal”, but [https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html add] [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002308.html <code>compatibleWith…</code>] [https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html metadata] so we can warn in tooling and on the license list that a bare <code>GPL-2.0</code> is ambiguous and that valid license-expressions SHOULD (and [https://lists.spdx.org/pipermail/spdx-legal/2017-November/002311.html later, with SPDX 3.0, MUST]) supply a versioning operator.

2) “Paul’s alternative proposal: provide 3 “hard-coded” options on the license list as follows:
* change current GPL-2.0 to GPL-2.0-only
* add GPL-2.0-or-later
* add GPL-2.0-text-alone (or something along those lines) to be used in the instance to show you found the text of that license)

Note: the use of people’s names is only to attribute who initiated the idea and aide in referring to the proposals :)

Need to carry on discussion of next release preparations, as well as this topic on mailing list.

Note: next call falls on Thanksgiving, so we will use tech team’s call time on Tuesday, Nov to carry on discuss so too much time does not pass!

Legal Team/only-operator-proposal

2017-09-07T19:38:28Z

Wking: Mention version-operator-compatiblity metadata as a way to automatically detect ambiguous license expressions

==Introduction to Issue ==
===Historical 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: <code>GPL-2.0</code> and <code>GPL-2.0+</code> respectively. (examples throughout this page use GPL-2.0, but this issue applies to the entire family of GNU licenses, i.e., GPL, LGPL, FDL, APGL).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the <code>+</code> operator. This enabled the use of the <code>+</code> operator with other licenses, as applicable.

The ability to create license expressions using the <code>+</code> operator along with the <code>with</code> operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name where/when the <code>+</code>.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did, not at that time, conduct a full analysis of the other licenses with "or later" language or how they work in practice.

===Other License with "or later" Clauses===

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.
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 are listed on this page: https://wiki.spdx.org/view/Legal_Team/later-version-clauses

Notably, most licenses that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) does declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) does not (and is therefore presumably CDDL-1.0+).

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. Also, because the "only" or "or later" distinction often is found outside the actual license text (e.g., in a license notice or header in the source files), machines (and humans) need a way to identify the license file itself without determining (yet) if the package is "only" or "or later". In other words, there is currently no way to express 'I just found this license text and am not sure what the package license is' using only license expressions.

The SPDX specification provides a way to distinguish between what is [https://spdx.org/spdx-specification-21-web-version#h.111kx3o detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.2lwamvv concluded file license] as well as similar fields at the package level when creating an SPDX document. But before getting to that point, tools must have ways to correctly identify what is precisely found in the files without having to draw a conclusion. Also, as discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]).

===Examples / Challenges===
The scenarios below map out various examples and how one would identify the [https://spdx.org/spdx-specification-21-web-version#h.111kx3o License Information in File] using SPDX short identifiers and bearing in mind machine reading for this task. Some of these scenarios have been discussed on the various calls on this topic as to how one would identify the license short identifier for each file currently (and under the proposal, see below). In any case, these scenarios need to have clear indication as to appropriate interpretation:

# '''you find: 1 text file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which include the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which include the language "any later version" = <code>GPL-2.0+</code>
## Concluded package license = <code>GPL-2.0+</code>
## Note: in the current reality, <code>GPL-2.0</code> for the license text file would mean "only", yet one cannot determine from that file alone if the copyright holder intends to use the version only or the or later option. Also note, that a machine can positively identify the "or later" option via the use of recommended standard license header.
# '''you find: 1 file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which omits the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which omits the language "any later version" = <code>GPL-2.0</code>
## Concluded package license = <code>GPL-2.0</code>
## Note: Same comment as #1 re: license text file. Also note, that a machine can positively identify the "only" option via the use of recommended standard license header which omits the "any later version" text.
# '''you find: no license file; 4 source files with the statement, “this is licensed under GPL" '''
## 4 source files = <code>GPL-1.0+</code>
## Concluded package = <code>GPL-1.0+</code>
## Note: The determination of <code>GPL-1.0+</code> would most likely need to be made by a human. But given the language of the GPL stating, "If the Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation." and no version indicated in any manner whatsoever, we can feel reasonably confidant that any version can be applied and the short identifier <code>GPL-1.0+</code> covers any version.
# '''you find: 1 license file with GPL-2.0 license text; 4 source files with no license information whatsoever'''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with no license information whatsoever = NONE (as per SPDX specification)
## Concluded license = ??
## Question: Is including a copy of a particular version of the license "the Program specif[ying] a version number of the license which applies to it" and thus we can confidantly conclude the package is GPL-2.0+?
## Answer: John Sullivan was [[Legal_Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Do_Not_Deprecated_GPL-2.0|going to check for a FSF position on this]]. I'm not clear on what his reported findings were, but I expect they decided not to take a formal position on it.

==Goals==
* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
* Ensure that there is some amount of consistency with what the short identifiers mean / Don't completely break the meaning for current users

==Proposed Solution: add <code>only</code> operator==
Based on the various legal and tech calls and including representatives from the FSF, SFC, and LF (some notes in [[Legal Team/or-later-vs-unclear-disambiguation]]), we coalesced around the following proposal:

'''Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use' '''

For licenses that may include “only” or “or later” (or both) clauses in the license text, having explicit <code>+</code> and <code>only</code> operators to use in SPDX identifiers reduces the chance that an unfamiliar user mis-uses or misinterprets the identifier and provides a way to be explicit and accurate that was arguably not available before. This solution allows the license text to speak for itself (via the "plain" license identifier) and uses the <code>only</code> and <code>+</code> operators to be explicit in intent.

This leaves the ability to use the "plain" license identifier (without an operator) to indicate the existence of the license text itself or other scenarios where it is not clear whether the "or later" or "only" options are articulated by the copyright holder. This avoids SPDX having to make an interpretation as to what the licenses mean or intend. This would also bring into consistency the use of "plain" identifiers for all other licenses that have "or later" clauses.

The + operator would remain with the same definition.

Necessary/associated changes:
* add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language as to how/when to use it.
* Remove "only" from full name of GNU family licenses on SPDX License List
* clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used (in Appendix IV or V?)

Potential issues:
* Backwards compatibility for GPL-2.0 meaning 'only' to now meaning 'whatever the license says' creates some inconsistency as the default position of the license text with no other info is "or later" or "any version", not "only". However, it was pointed out on the call that those people conscientious enough to be using GPL-2.0 correctly, will be more likely to be conscientious enough to add the <code>only</code> operator as needed once it's available. All seemed to agree that use of GPL-2.0 is probably not thought through as to "or later" or "only", and thus in these situations, there is no different meaning.
* Does not make clear indication of "ambiguous" situation to push people towards using 'only' and '+' operators to be explicit (preferred). However, we don't have a clear indication of ambiguity now either (is ambiguity ever clear?). You can clearly detect the ambiguous situations in tooling if you add metadata to license definitions recording whether they are compatible with the various version-related operators (as discussed [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_create_-only_and_PROXY_.7BTEXT.7D_operators_for_licenses_that_explicitly_declare_their_compatibility|here]] and [https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html here]).
* GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license. However, all agreed that when you have a machine scanning code with no other license info other than a file with the license text of GPL-2.0, this is not entirely clear situation.

Legal Team/only-operator-proposal

2017-09-07T19:31:07Z

Wking: Mention John Sullivan checking with the FSF for the license version implied by a copy of the license text (although I don't know what he found)

==Introduction to Issue ==
===Historical 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: <code>GPL-2.0</code> and <code>GPL-2.0+</code> respectively. (examples throughout this page use GPL-2.0, but this issue applies to the entire family of GNU licenses, i.e., GPL, LGPL, FDL, APGL).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the <code>+</code> operator. This enabled the use of the <code>+</code> operator with other licenses, as applicable.

The ability to create license expressions using the <code>+</code> operator along with the <code>with</code> operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name where/when the <code>+</code>.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did, not at that time, conduct a full analysis of the other licenses with "or later" language or how they work in practice.

===Other License with "or later" Clauses===

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.
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 are listed on this page: https://wiki.spdx.org/view/Legal_Team/later-version-clauses

Notably, most licenses that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) does declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) does not (and is therefore presumably CDDL-1.0+).

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. Also, because the "only" or "or later" distinction often is found outside the actual license text (e.g., in a license notice or header in the source files), machines (and humans) need a way to identify the license file itself without determining (yet) if the package is "only" or "or later". In other words, there is currently no way to express 'I just found this license text and am not sure what the package license is' using only license expressions.

The SPDX specification provides a way to distinguish between what is [https://spdx.org/spdx-specification-21-web-version#h.111kx3o detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.2lwamvv concluded file license] as well as similar fields at the package level when creating an SPDX document. But before getting to that point, tools must have ways to correctly identify what is precisely found in the files without having to draw a conclusion. Also, as discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]).

===Examples / Challenges===
The scenarios below map out various examples and how one would identify the [https://spdx.org/spdx-specification-21-web-version#h.111kx3o License Information in File] using SPDX short identifiers and bearing in mind machine reading for this task. Some of these scenarios have been discussed on the various calls on this topic as to how one would identify the license short identifier for each file currently (and under the proposal, see below). In any case, these scenarios need to have clear indication as to appropriate interpretation:

# '''you find: 1 text file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which include the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which include the language "any later version" = <code>GPL-2.0+</code>
## Concluded package license = <code>GPL-2.0+</code>
## Note: in the current reality, <code>GPL-2.0</code> for the license text file would mean "only", yet one cannot determine from that file alone if the copyright holder intends to use the version only or the or later option. Also note, that a machine can positively identify the "or later" option via the use of recommended standard license header.
# '''you find: 1 file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which omits the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which omits the language "any later version" = <code>GPL-2.0</code>
## Concluded package license = <code>GPL-2.0</code>
## Note: Same comment as #1 re: license text file. Also note, that a machine can positively identify the "only" option via the use of recommended standard license header which omits the "any later version" text.
# '''you find: no license file; 4 source files with the statement, “this is licensed under GPL" '''
## 4 source files = <code>GPL-1.0+</code>
## Concluded package = <code>GPL-1.0+</code>
## Note: The determination of <code>GPL-1.0+</code> would most likely need to be made by a human. But given the language of the GPL stating, "If the Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation." and no version indicated in any manner whatsoever, we can feel reasonably confidant that any version can be applied and the short identifier <code>GPL-1.0+</code> covers any version.
# '''you find: 1 license file with GPL-2.0 license text; 4 source files with no license information whatsoever'''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with no license information whatsoever = NONE (as per SPDX specification)
## Concluded license = ??
## Question: Is including a copy of a particular version of the license "the Program specif[ying] a version number of the license which applies to it" and thus we can confidantly conclude the package is GPL-2.0+?
## Answer: John Sullivan was [[Legal_Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Do_Not_Deprecated_GPL-2.0|going to check for a FSF position on this]]. I'm not clear on what his reported findings were, but I expect they decided not to take a formal position on it.

==Goals==
* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
* Ensure that there is some amount of consistency with what the short identifiers mean / Don't completely break the meaning for current users

==Proposed Solution: add <code>only</code> operator==
Based on the various legal and tech calls and including representatives from the FSF, SFC, and LF (some notes in [[Legal Team/or-later-vs-unclear-disambiguation]]), we coalesced around the following proposal:

'''Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use' '''

For licenses that may include “only” or “or later” (or both) clauses in the license text, having explicit <code>+</code> and <code>only</code> operators to use in SPDX identifiers reduces the chance that an unfamiliar user mis-uses or misinterprets the identifier and provides a way to be explicit and accurate that was arguably not available before. This solution allows the license text to speak for itself (via the "plain" license identifier) and uses the <code>only</code> and <code>+</code> operators to be explicit in intent.

This leaves the ability to use the "plain" license identifier (without an operator) to indicate the existence of the license text itself or other scenarios where it is not clear whether the "or later" or "only" options are articulated by the copyright holder. This avoids SPDX having to make an interpretation as to what the licenses mean or intend. This would also bring into consistency the use of "plain" identifiers for all other licenses that have "or later" clauses.

The + operator would remain with the same definition.

Necessary/associated changes:
* add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language as to how/when to use it.
* Remove "only" from full name of GNU family licenses on SPDX License List
* clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used (in Appendix IV or V?)

Potential issues:
* Backwards compatibility for GPL-2.0 meaning 'only' to now meaning 'whatever the license says' creates some inconsistency as the default position of the license text with no other info is "or later" or "any version", not "only". However, it was pointed out on the call that those people conscientious enough to be using GPL-2.0 correctly, will be more likely to be conscientious enough to add the <code>only</code> operator as needed once it's available. All seemed to agree that use of GPL-2.0 is probably not thought through as to "or later" or "only", and thus in these situations, there is no different meaning.
* Does not make clear indication of "ambiguous" situation to push people towards using 'only' and '+' operators to be explicit (preferred). However, we don't have a clear indication of ambiguity now either (is ambiguity ever clear?).
* GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license. However, all agreed that when you have a machine scanning code with no other license info other than a file with the license text of GPL-2.0, this is not entirely clear situation.

Legal Team/only-operator-proposal

2017-09-07T19:04:25Z

Wking: Fix “do” → “does” typos for CDDL examples

==Introduction to Issue ==
===Historical 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: <code>GPL-2.0</code> and <code>GPL-2.0+</code> respectively. (examples throughout this page use GPL-2.0, but this issue applies to the entire family of GNU licenses, i.e., GPL, LGPL, FDL, APGL).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the <code>+</code> operator. This enabled the use of the <code>+</code> operator with other licenses, as applicable.

The ability to create license expressions using the <code>+</code> operator along with the <code>with</code> operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name where/when the <code>+</code>.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did, not at that time, conduct a full analysis of the other licenses with "or later" language or how they work in practice.

===Other License with "or later" Clauses===

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.
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 are listed on this page: https://wiki.spdx.org/view/Legal_Team/later-version-clauses

Notably, most licenses that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) does declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) does not (and is therefore presumably CDDL-1.0+).

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. Also, because the "only" or "or later" distinction often is found outside the actual license text (e.g., in a license notice or header in the source files), machines (and humans) need a way to identify the license file itself without determining (yet) if the package is "only" or "or later". In other words, there is currently no way to express 'I just found this license text and am not sure what the package license is' using only license expressions.

The SPDX specification provides a way to distinguish between what is [https://spdx.org/spdx-specification-21-web-version#h.111kx3o detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.2lwamvv concluded file license] as well as similar fields at the package level when creating an SPDX document. But before getting to that point, tools must have ways to correctly identify what is precisely found in the files without having to draw a conclusion. Also, as discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]).

===Examples / Challenges===
The scenarios below map out various examples and how one would identify the [https://spdx.org/spdx-specification-21-web-version#h.111kx3o License Information in File] using SPDX short identifiers and bearing in mind machine reading for this task. Some of these scenarios have been discussed on the various calls on this topic as to how one would identify the license short identifier for each file currently (and under the proposal, see below). In any case, these scenarios need to have clear indication as to appropriate interpretation:

# '''you find: 1 text file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which include the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which include the language "any later version" = <code>GPL-2.0+</code>
## Concluded package license = <code>GPL-2.0+</code>
## Note: in the current reality, <code>GPL-2.0</code> for the license text file would mean "only", yet one cannot determine from that file alone if the copyright holder intends to use the version only or the or later option. Also note, that a machine can positively identify the "or later" option via the use of recommended standard license header.
# '''you find: 1 file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which omits the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which omits the language "any later version" = <code>GPL-2.0</code>
## Concluded package license = <code>GPL-2.0</code>
## Note: Same comment as #1 re: license text file. Also note, that a machine can positively identify the "only" option via the use of recommended standard license header which omits the "any later version" text.
# '''you find: no license file; 4 source files with the statement, “this is licensed under GPL" '''
## 4 source files = <code>GPL-1.0+</code>
## Concluded package = <code>GPL-1.0+</code>
## Note: The determination of <code>GPL-1.0+</code> would most likely need to be made by a human. But given the language of the GPL stating, "If the Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation." and no version indicated in any manner whatsoever, we can feel reasonably confidant that any version can be applied and the short identifier <code>GPL-1.0+</code> covers any version.
# '''you find: 1 license file with GPL-2.0 license text; 4 source files with no license information whatsoever'''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with no license information whatsoever = NONE (as per SPDX specification)
## Concluded license = ??
## Question: Is including a copy of a particular version of the license "the Program specif[ying] a version number of the license which applies to it" and thus we can confidantly conclude the package is GPL-2.0+?

==Goals==
* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
* Ensure that there is some amount of consistency with what the short identifiers mean / Don't completely break the meaning for current users

==Proposed Solution: add <code>only</code> operator==
Based on the various legal and tech calls and including representatives from the FSF, SFC, and LF (some notes in [[Legal Team/or-later-vs-unclear-disambiguation]]), we coalesced around the following proposal:

'''Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use' '''

For licenses that may include “only” or “or later” (or both) clauses in the license text, having explicit <code>+</code> and <code>only</code> operators to use in SPDX identifiers reduces the chance that an unfamiliar user mis-uses or misinterprets the identifier and provides a way to be explicit and accurate that was arguably not available before. This solution allows the license text to speak for itself (via the "plain" license identifier) and uses the <code>only</code> and <code>+</code> operators to be explicit in intent.

This leaves the ability to use the "plain" license identifier (without an operator) to indicate the existence of the license text itself or other scenarios where it is not clear whether the "or later" or "only" options are articulated by the copyright holder. This avoids SPDX having to make an interpretation as to what the licenses mean or intend. This would also bring into consistency the use of "plain" identifiers for all other licenses that have "or later" clauses.

The + operator would remain with the same definition.

Necessary/associated changes:
* add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language as to how/when to use it.
* Remove "only" from full name of GNU family licenses on SPDX License List
* clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used (in Appendix IV or V?)

Potential issues:
* Backwards compatibility for GPL-2.0 meaning 'only' to now meaning 'whatever the license says' creates some inconsistency as the default position of the license text with no other info is "or later" or "any version", not "only". However, it was pointed out on the call that those people conscientious enough to be using GPL-2.0 correctly, will be more likely to be conscientious enough to add the <code>only</code> operator as needed once it's available. All seemed to agree that use of GPL-2.0 is probably not thought through as to "or later" or "only", and thus in these situations, there is no different meaning.
* Does not make clear indication of "ambiguous" situation to push people towards using 'only' and '+' operators to be explicit (preferred). However, we don't have a clear indication of ambiguity now either (is ambiguity ever clear?).
* GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license. However, all agreed that when you have a machine scanning code with no other license info other than a file with the license text of GPL-2.0, this is not entirely clear situation.

Legal Team/only-operator-proposal

2017-09-07T19:01:59Z

Wking: Link back to Legal_Team/or-later-vs-unclear-disambiguation

==Introduction to Issue ==
===Historical 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: <code>GPL-2.0</code> and <code>GPL-2.0+</code> respectively. (examples throughout this page use GPL-2.0, but this issue applies to the entire family of GNU licenses, i.e., GPL, LGPL, FDL, APGL).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the <code>+</code> operator. This enabled the use of the <code>+</code> operator with other licenses, as applicable.

The ability to create license expressions using the <code>+</code> operator along with the <code>with</code> operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name where/when the <code>+</code>.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did, not at that time, conduct a full analysis of the other licenses with "or later" language or how they work in practice.

===Other License with "or later" Clauses===

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.
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 are listed on this page: https://wiki.spdx.org/view/Legal_Team/later-version-clauses

Notably, most licenses that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. Also, because the "only" or "or later" distinction often is found outside the actual license text (e.g., in a license notice or header in the source files), machines (and humans) need a way to identify the license file itself without determining (yet) if the package is "only" or "or later". In other words, there is currently no way to express 'I just found this license text and am not sure what the package license is' using only license expressions.

The SPDX specification provides a way to distinguish between what is [https://spdx.org/spdx-specification-21-web-version#h.111kx3o detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.2lwamvv concluded file license] as well as similar fields at the package level when creating an SPDX document. But before getting to that point, tools must have ways to correctly identify what is precisely found in the files without having to draw a conclusion. Also, as discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]).

===Examples / Challenges===
The scenarios below map out various examples and how one would identify the [https://spdx.org/spdx-specification-21-web-version#h.111kx3o License Information in File] using SPDX short identifiers and bearing in mind machine reading for this task. Some of these scenarios have been discussed on the various calls on this topic as to how one would identify the license short identifier for each file currently (and under the proposal, see below). In any case, these scenarios need to have clear indication as to appropriate interpretation:

# '''you find: 1 text file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which include the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which include the language "any later version" = <code>GPL-2.0+</code>
## Concluded package license = <code>GPL-2.0+</code>
## Note: in the current reality, <code>GPL-2.0</code> for the license text file would mean "only", yet one cannot determine from that file alone if the copyright holder intends to use the version only or the or later option. Also note, that a machine can positively identify the "or later" option via the use of recommended standard license header.
# '''you find: 1 file with the license text of GPL-2.0; and 4 source files with the standard header for GPL-2.0, which omits the language "any later version" '''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with standard header for GPL-2.0, which omits the language "any later version" = <code>GPL-2.0</code>
## Concluded package license = <code>GPL-2.0</code>
## Note: Same comment as #1 re: license text file. Also note, that a machine can positively identify the "only" option via the use of recommended standard license header which omits the "any later version" text.
# '''you find: no license file; 4 source files with the statement, “this is licensed under GPL" '''
## 4 source files = <code>GPL-1.0+</code>
## Concluded package = <code>GPL-1.0+</code>
## Note: The determination of <code>GPL-1.0+</code> would most likely need to be made by a human. But given the language of the GPL stating, "If the Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation." and no version indicated in any manner whatsoever, we can feel reasonably confidant that any version can be applied and the short identifier <code>GPL-1.0+</code> covers any version.
# '''you find: 1 license file with GPL-2.0 license text; 4 source files with no license information whatsoever'''
## 1 text file with license text of GPL-2.0 = <code>GPL-2.0</code>
## 4 source files with no license information whatsoever = NONE (as per SPDX specification)
## Concluded license = ??
## Question: Is including a copy of a particular version of the license "the Program specif[ying] a version number of the license which applies to it" and thus we can confidantly conclude the package is GPL-2.0+?

==Goals==
* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
* Ensure that there is some amount of consistency with what the short identifiers mean / Don't completely break the meaning for current users

==Proposed Solution: add <code>only</code> operator==
Based on the various legal and tech calls and including representatives from the FSF, SFC, and LF (some notes in [[Legal Team/or-later-vs-unclear-disambiguation]]), we coalesced around the following proposal:

'''Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use' '''

For licenses that may include “only” or “or later” (or both) clauses in the license text, having explicit <code>+</code> and <code>only</code> operators to use in SPDX identifiers reduces the chance that an unfamiliar user mis-uses or misinterprets the identifier and provides a way to be explicit and accurate that was arguably not available before. This solution allows the license text to speak for itself (via the "plain" license identifier) and uses the <code>only</code> and <code>+</code> operators to be explicit in intent.

This leaves the ability to use the "plain" license identifier (without an operator) to indicate the existence of the license text itself or other scenarios where it is not clear whether the "or later" or "only" options are articulated by the copyright holder. This avoids SPDX having to make an interpretation as to what the licenses mean or intend. This would also bring into consistency the use of "plain" identifiers for all other licenses that have "or later" clauses.

The + operator would remain with the same definition.

Necessary/associated changes:
* add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language as to how/when to use it.
* Remove "only" from full name of GNU family licenses on SPDX License List
* clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used (in Appendix IV or V?)

Potential issues:
* Backwards compatibility for GPL-2.0 meaning 'only' to now meaning 'whatever the license says' creates some inconsistency as the default position of the license text with no other info is "or later" or "any version", not "only". However, it was pointed out on the call that those people conscientious enough to be using GPL-2.0 correctly, will be more likely to be conscientious enough to add the <code>only</code> operator as needed once it's available. All seemed to agree that use of GPL-2.0 is probably not thought through as to "or later" or "only", and thus in these situations, there is no different meaning.
* Does not make clear indication of "ambiguous" situation to push people towards using 'only' and '+' operators to be explicit (preferred). However, we don't have a clear indication of ambiguity now either (is ambiguity ever clear?).
* GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license. However, all agreed that when you have a machine scanning code with no other license info other than a file with the license text of GPL-2.0, this is not entirely clear situation.

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

2017-09-07T19:00:19Z

Wking: Obsolete this page in favor of Legal_Team/only-operator-proposal

Status: obsolete (See more recent discussion in [[Legal Team/only-operator-proposal]])

==Introduction to Issue ==
===Background (SPDX)===
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).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did not at that time conduct a full analysis of the other licenses with "or later" language or how they work in practice.

===Background (additional)===

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.
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 are [[Legal Team/later-version-clauses|here]].

Notably, most license that reference the possibility of later versions can be read to say you can take and redistribute the work under the license you found it with or any other later version with no explicit option of 'this version only.'

The CDDL family is slightly different in that the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

The spec provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). This approach will also fail to distinguish between <code>MPL-2.0</code> and <code>MPL-2.0-no-copyleft-exception</code>, since that distinction is [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/MPL-2.0-no-copyleft-exception.xml#L43-L44 based on the blurbs]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Goals===
* Provide way to get to "GPL-2.0-only" (or the like) identifier to enable better clarity for that option/scenario
* Ensure we accommodate the reality of other licenses with language re: later versions such that all options can be represented appropriately
* Ensure that there is some amount of consistency with what the short identifiers refer to
* Don't completely break the meaning for current users

==Solutions==
Various solutions were discussed on legal and tech team calls on the following dates, as well as via the mailing list.

The current proposed solution represents the most recent evolution in discussions on the topic. Items below that are left here for record, but not necessarily updated.

===Current Proposed Solution===
Based on the joint legal/tech call on 17 August 2017, we coalesced around a solution similar to "alternative option" from 8 Aug joint call:

* Create an "only" operator defined as to be used to indicate 'only the version of the license is intended for use'.
** add new "only" operator to Appendix IV: SPDX License Expressions of spec and explanatory language
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
** This avoids SPDX having to make an interpretation as to what the licenses mean/intend.
** Allows for use of GPL-2.0 when you find just the license file with the text of GPL-2.0 and still provides option for Concluded License to be GPL-1.0+ if no other info is found
* Remove "only" from full name of GPL family.
* This solution allows the license text to speak for itself and uses the 'only' and '+' operators to be explicit in intent. It also avoids conflicting operators by retaining the "plain" license identifier.

Potential issues:
* Backwards compatibility for GPL-2.0 meaning 'v2-only' to now meaning 'whatever the license says' creates some inconsistency as the default position of the license text with no other info is "or later" or "any version", not "only". However, it was pointed out on the call that those people conscientious enough to be using GPL-2.0 correctly, will be more likely to be conscientious enough to add the "-only" operator as needed/once it's available. All seemed to agree that use of GPL-2.0 is probably not thought through as to "or later" or "only", and thus in these situations, there is no different meaning.
* Does not make clear indication of "ambiguous" situation to push people towards using 'only' and '+' operators to be explicit (preferred). However, we don't have a clear indication of ambiguity now either (is ambiguity ever clear?).
* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license. However, all agreed that when you have a machine scanning code with no other license info other than a file with the license text of GPL-2.0, this is not entirely clear situation.

===Joint call 8 Aug 2017 proposed solution ===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background (SPDX)|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):
* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - create <code>-only</code> and <code>PROXY {TEXT}</code> operators for licenses that explicitly declare their compatibility===
* Create an <code>-only</code> operator for “only this version of the license is intended for use”.
* Create a <code>PROXY {TEXT}</code> operator for the proxy declaration in the GPL-3.0 and similar (see [[#Background (SPDX)|the KDE example above]]).
* The <code>+</code> operator would remain with the same definition.
* Change the name and description of the GPL family of licenses to remove [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-2.0.xml#L1 “only” references].
* Add fields to the [https://spdx.org/spdx-specification-21-web-version#h.1v1yuxt license metadata] and the license-list's XML for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. For example, <code>GPL-2.0</code> would be compatible with <code>-only</code> and <code>+</code>; <code>GPL-3.0</code> would be compatible with <code>-only</code>, <code>+</code>, and <code>PROXY {TEXT}</code>; <code>NPL-1.0</code> would be compatible with <code>-only</code>, although it's use would not be recommended, and <code>BSD-2-Clause</code> would be compatible with none of these operators.
* Add metadata flagging licenses which should be explicitly versioned. For example, the GPL and CDDL families would declare “should explicitly version”. Then tooling could warn if a license expression had, for example, <code>GPL-3.0</code> unmodified by <code>-only</code>, <code>+</code>, or <code>PROXY {TEXT}</code>. Tooling should consider <code>GPL-2.0 OR GPL-3.0</code> to be explicitly versioned, even though it uses none of the versioning operators.

Potential issues:
* This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
* This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.
* This has the same “<code>-only</code> operator used with an inappropriate license” issue as [[#Current_Proposed_Solution|the current proposal]], but again, now we can warn in these cases.
* This has the same “no generic way to say ‘I just found this license text and am not sure about the grant’” issue as [[#Current_Proposed_Solution|the current proposal]], but since that's a generic problem with an existing out-of-license-expression solution, I'd argue for not solving it in the license expression. For examples outside of a SPDX declaration, see GitHub's [https://developer.github.com/v3/licenses/ “not a law firm”] and [https://github.com/spdx/tools/blob/master/LICENSE “not legal advice”] [https://help.github.com/articles/licensing-a-repository/#disclaimer caveats].

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== Selected responses/ideas/commentary from mailing list ==
''' NOTE:''' Please feel free to add/clarify below
link to SPDX-legal mailing list from this thread can be found here: https://lists.spdx.org/pipermail/spdx-legal/2017-May/thread.html

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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-17T19:21:59Z

Wking: Update background links to catch up with the "(SPDX)" addition from 2017-08-17T19:17 (oldid 4410)

==Introduction to Issue ==
===Background (SPDX)===
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).

For example, the pre-version-2.0 SPDX License List looked like this:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). However, to anyone's memory we did not at that time conduct a full analysis of the other licenses with "or later" language or how they work in practice.

The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). This approach will also fail to distinguish between <code>MPL-2.0</code> and <code>MPL-2.0-no-copyleft-exception</code>, since that distinction is [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/MPL-2.0-no-copyleft-exception.xml#L43-L44 based on the blurbs]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background (SPDX)|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - create <code>-only</code> and <code>PROXY {TEXT}</code> operators for licenses that explicitly declare their compatibility===
* Create an <code>-only</code> operator for “only this version of the license is intended for use”.
* Create a <code>PROXY {TEXT}</code> operator for the proxy declaration in the GPL-3.0 and similar (see [[#Background (SPDX)|the KDE example above]]).
* The <code>+</code> operator would remain with the same definition.
* Change the name and description of the GPL family of licenses to remove [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-2.0.xml#L1 “only” references].
* Add fields to the [https://spdx.org/spdx-specification-21-web-version#h.1v1yuxt license metadata] and the license-list's XML for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. For example, <code>GPL-2.0</code> would be compatible with <code>-only</code> and <code>+</code>; <code>GPL-3.0</code> would be compatible with <code>-only</code>, <code>+</code>, and <code>PROXY {TEXT}</code>; <code>NPL-1.0</code> would be compatible with <code>-only</code>, although it's use would not be recommended, and <code>BSD-2-Clause</code> would be compatible with none of these operators.
* Add metadata flagging licenses which should be explicitly versioned. For example, the GPL and CDDL families would declare “should explicitly version”. Then tooling could warn if a license expression had, for example, <code>GPL-3.0</code> unmodified by <code>-only</code>, <code>+</code>, or <code>PROXY {TEXT}</code>. Tooling should consider <code>GPL-2.0 OR GPL-3.0</code> to be explicitly versioned, even though it uses none of the versioning operators.

Potential issues:

* This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
* This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.
* This has the same “<code>-only</code> operator used with an inappropriate license” issue as [[#Current_Proposed_Solution|the current proposal]], but again, now we can warn in these cases.
* This has the same “no generic way to say ‘I just found this license text and am not sure about the grant’” issue as [[#Current_Proposed_Solution|the current proposal]], but since that's a generic problem with an existing out-of-license-expression solution, I'd argue for not solving it in the license expression. For examples outside of a SPDX declaration, see GitHub's [https://developer.github.com/v3/licenses/ “not a law firm”] and [https://github.com/spdx/tools/blob/master/LICENSE “not legal advice”] [https://help.github.com/articles/licensing-a-repository/#disclaimer caveats].

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-09T07:39:59Z

Wking: Add MPL-2.0 vs. MPL-2.0-no-copyleft-exception as a non-version distinction which is based on blurbs (vs. the content of license files)

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). This approach will also fail to distinguish between <code>MPL-2.0</code> and <code>MPL-2.0-no-copyleft-exception</code>, since that distinction is [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/MPL-2.0-no-copyleft-exception.xml#L43-L44 based on the blurbs]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - create <code>-only</code> and <code>PROXY {TEXT}</code> operators for licenses that explicitly declare their compatibility===
* Create an <code>-only</code> operator for “only this version of the license is intended for use”.
* Create a <code>PROXY {TEXT}</code> operator for the proxy declaration in the GPL-3.0 and similar (see [[#Background|the KDE example above]]).
* The <code>+</code> operator would remain with the same definition.
* Change the name and description of the GPL family of licenses to remove [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-2.0.xml#L1 “only” references].
* Add fields to the [https://spdx.org/spdx-specification-21-web-version#h.1v1yuxt license metadata] and the license-list's XML for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. For example, <code>GPL-2.0</code> would be compatible with <code>-only</code> and <code>+</code>; <code>GPL-3.0</code> would be compatible with <code>-only</code>, <code>+</code>, and <code>PROXY {TEXT}</code>; <code>NPL-1.0</code> would be compatible with <code>-only</code>, although it's use would not be recommended, and <code>BSD-2-Clause</code> would be compatible with none of these operators.
* Add metadata flagging licenses which should be explicitly versioned. For example, the GPL and CDDL families would declare “should explicitly version”. Then tooling could warn if a license expression had, for example, <code>GPL-3.0</code> unmodified by <code>-only</code>, <code>+</code>, or <code>PROXY {TEXT}</code>. Tooling should consider <code>GPL-2.0 OR GPL-3.0</code> to be explicitly versioned, even though it uses none of the versioning operators.

Potential issues:

* This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
* This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.
* This has the same “<code>-only</code> operator used with an inappropriate license” issue as [[#Current_Proposed_Solution|the current proposal]], but again, now we can warn in these cases.
* This has the same “no generic way to say ‘I just found this license text and am not sure about the grant’” issue as [[#Current_Proposed_Solution|the current proposal]], but since that's a generic problem with an existing out-of-license-expression solution, I'd argue for not solving it in the license expression. For examples outside of a SPDX declaration, see GitHub's [https://developer.github.com/v3/licenses/ “not a law firm”] and [https://github.com/spdx/tools/blob/master/LICENSE “not legal advice”] [https://help.github.com/articles/licensing-a-repository/#disclaimer caveats].

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T21:06:45Z

Wking: Mention that the GitHub caveat examples are a way to declare “we're not really sure” even without an explicit SPDX document

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - create <code>-only</code> and <code>PROXY {TEXT}</code> operators for licenses that explicitly declare their compatibility===
* Create an <code>-only</code> operator for “only this version of the license is intended for use”.
* Create a <code>PROXY {TEXT}</code> operator for the proxy declaration in the GPL-3.0 and similar (see [[#Background|the KDE example above]]).
* The <code>+</code> operator would remain with the same definition.
* Change the name and description of the GPL family of licenses to remove [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-2.0.xml#L1 “only” references].
* Add fields to the [https://spdx.org/spdx-specification-21-web-version#h.1v1yuxt license metadata] and the license-list's XML for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. For example, <code>GPL-2.0</code> would be compatible with <code>-only</code> and <code>+</code>; <code>GPL-3.0</code> would be compatible with <code>-only</code>, <code>+</code>, and <code>PROXY {TEXT}</code>; <code>NPL-1.0</code> would be compatible with <code>-only</code>, although it's use would not be recommended, and <code>BSD-2-Clause</code> would be compatible with none of these operators.
* Add metadata flagging licenses which should be explicitly versioned. For example, the GPL and CDDL families would declare “should explicitly version”. Then tooling could warn if a license expression had, for example, <code>GPL-3.0</code> unmodified by <code>-only</code>, <code>+</code>, or <code>PROXY {TEXT}</code>. Tooling should consider <code>GPL-2.0 OR GPL-3.0</code> to be explicitly versioned, even though it uses none of the versioning operators.

Potential issues:

* This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
* This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.
* This has the same “<code>-only</code> operator used with an inappropriate license” issue as [[#Current_Proposed_Solution|the current proposal]], but again, now we can warn in these cases.
* This has the same “no generic way to say ‘I just found this license text and am not sure about the grant’” issue as [[#Current_Proposed_Solution|the current proposal]], but since that's a generic problem with an existing out-of-license-expression solution, I'd argue for not solving it in the license expression. For examples outside of a SPDX declaration, see GitHub's [https://developer.github.com/v3/licenses/ “not a law firm”] and [https://github.com/spdx/tools/blob/master/LICENSE “not legal advice”] [https://help.github.com/articles/licensing-a-repository/#disclaimer caveats].

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T21:05:12Z

Wking: Add a new proposal with a PROXY operator and more license metadata (operator compatibility and should-be-explicitly-versioned)

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - create <code>-only</code> and <code>PROXY {TEXT}</code> operators for licenses that explicitly declare their compatibility===
* Create an <code>-only</code> operator for “only this version of the license is intended for use”.
* Create a <code>PROXY {TEXT}</code> operator for the proxy declaration in the GPL-3.0 and similar (see [[#Background|the KDE example above]]).
* The <code>+</code> operator would remain with the same definition.
* Change the name and description of the GPL family of licenses to remove [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-2.0.xml#L1 “only” references].
* Add fields to the [https://spdx.org/spdx-specification-21-web-version#h.1v1yuxt license metadata] and the license-list's XML for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. For example, <code>GPL-2.0</code> would be compatible with <code>-only</code> and <code>+</code>; <code>GPL-3.0</code> would be compatible with <code>-only</code>, <code>+</code>, and <code>PROXY {TEXT}</code>; <code>NPL-1.0</code> would be compatible with <code>-only</code>, although it's use would not be recommended, and <code>BSD-2-Clause</code> would be compatible with none of these operators.
* Add metadata flagging licenses which should be explicitly versioned. For example, the GPL and CDDL families would declare “should explicitly version”. Then tooling could warn if a license expression had, for example, <code>GPL-3.0</code> unmodified by <code>-only</code>, <code>+</code>, or <code>PROXY {TEXT}</code>. Tooling should consider <code>GPL-2.0 OR GPL-3.0</code> to be explicitly versioned, even though it uses none of the versioning operators.

Potential issues:

* This has the same “ambiguous bare <code>GPL-2.0</code> declaration” issue as [[#Current_Proposed_Solution|the current proposal]], but at least now we can warn in these cases.
* This has the same “current <code>GPL-2.0</code> users should update to a more specific identifier” issue as the two proposals above, but <code>GPL-2.0 AND GPL-3.0</code> folks are not obsolete with this proposal.
* This has the same “<code>-only</code> operator used with an inappropriate license” issue as [[#Current_Proposed_Solution|the current proposal]], but again, now we can warn in these cases.
* This has the same “no generic way to say ‘I just found this license text and am not sure about the grant’” issue as [[#Current_Proposed_Solution|the current proposal]], but since that's a generic problem with an existing out-of-license-expression solution, I'd argue for not solving it in the license expression. For example, see GitHub's [https://developer.github.com/v3/licenses/ “not a law firm”] and [https://github.com/spdx/tools/blob/master/LICENSE “not legal advice”] [https://help.github.com/articles/licensing-a-repository/#disclaimer caveats].

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T20:17:13Z

Wking: Use page-internal anchor links, dropping the repeated title for this page

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T20:15:45Z

Wking: Link to background section for the “detected license files vs. concluded package license” distinction

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation. As noted in the [[#Background|the background section]], there is already a generic way to make this distinction in the SPDX spec; there's just no current way to make it in a license expression.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T20:09:26Z

Wking: Fix “<code>” → “</code>” typo which I'd just introduced to the alias proposal

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+</code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T20:08:44Z

Wking: Copy-edits for the "alias" proposal, including splitting the push-back into a “Potential issues” section to match the other proposals

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
Add new concept of short identifier “alias” and make <code>GPL-2.0</code> equivalent to <code>GPL-2.0-only</code>.

Potential issues:

* If <code>GPL-2.0</code> is equivalent to <code>GPL-2.0-only</code>, then what is the canonical "or later" option? You could end up with <code>GPL-2.0-only+<code> which makes no sense! The ends result here needs to indicate: <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> with no ability to combine them. Also, a short identifier "alias" would be a new concept and possibly over-engineering a solution for one set of licenses.

NOT an option.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T20:04:54Z

Wking: Mention the “GPL-2.0-only OR GPL-3.0-only” issue for the +-reversion proposal as well

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
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.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

Potential issues:

* This has the same <code>GPL-2.0-only OR GPL-3.0-only</code> [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_GPL-2.0-only_license_ID|issue]] as the bare <code>GPL-2.0</code> → <code>GPL-2.0-only</code> rename.

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T20:02:37Z

Wking: Give “GPL-2.0-only OR GPL-3.0-only” as a counter-argument against a bare GPL-2.0 → GPL-2.0-only rename

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

Potential issues:

* <code>GPL-2.0-only OR GPL-3.0-only</code> is as strange a license designation as <code>GPL-2.0-only+</code> which is one of the reasons given for rejecting the [[Legal Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_Add_an_.E2.80.9Calias.E2.80.9D_concept_and_make_GPL-2.0_and_GPL-2.0-only.2C_etc._equivalent|alias approach]].

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
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.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T19:58:55Z

Wking: Split “Discussion of Other Possible Approaches” entries into their own sections (to match the other alternatives listed above this section)

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

===Alternative Solution - Add an “alias” concept and make <code>GPL-2.0</code> and <code>GPL-2.0-only</code>, etc. equivalent===
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.

===Alternative Solution - Revert the <code>+</code> operator and return to <code>GPL-2.0-only</code> and <code>GPL-2.0+</code> as separate licenses===
Remove the <code>+</code> 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T19:52:25Z

Wking: Point out that the current proposed solution does not cover the related GPL-3.0 proxy designation

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.
* Does not provide a mechanism for encoding GPL-3.0 proxies, or even for encoding that a proxy has been designated.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T19:50:45Z

Wking: Remove “in the absence of license wording about designating proxies” sentence (the KDE grant included the GPL-3.0, which covers proxies)

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]).

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

Talk:Legal Team/later-version-clauses

2017-08-08T19:21:24Z

Wking: Document ambiguity for “you have a copy of the GPL-2.0 (or whatever) but no further grant”

On 2017-08-03 09:59, [[User:Jlovejoy]] [https://wiki.spdx.org/index.php?title=Legal_Team%2Flater-version-clauses&diff=4342&oldid=4336 marked Motosoto as “no "only option”]. But because the only source of later licenses is the Licensor, the distinction seems less clear. If the Licensor wants only semantics, they can just never publish a later version of the license. Motosoto looks like a one-off license (only useful to Motosoto.Com B.V., because the opening paragraph is so specific), but the same sort of issue applies to the APL-1.0 (which is setup to be project-generic). The GPL, CC, and similar families are different because they are generic licenses whose future is goverened by a third party (so the licensor needs to make the only/or-later call at licensing time, vs. making the call at “maybe I'll write a new version of this license” time). I've marked the APL-1.0 as allowing only, but we should probably figure out which way we want to go on this for consistency.

I don't think we're being consistent about marking defaults. For example, the CDDL family allows later versions unless “the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License”, while the GPL family allows later versions only if the program specified “any later version”, and yet both are marked with “or later” as the default. I think the default logic should be what happens if someone hands you a paper copy of the license text, and says “I'm licensing this work to you under these terms”. In that case, the GPL family would default to “only” (because there is no explicit “any later version” grant). UPDATE (2017-08-08): in today's meeting, there wasn't agreement about what the implied terms were if someone just hands you a copy of the license with no further grant. John Sullivan is going to discuss this case with the other FSF folks and see if they have an opinion.

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

2017-08-08T19:15:23Z

Wking: Propose -only/+ compatibility metadata to mitigate “-only used for a license that doesn't support it” and similar.

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used. This could be mitigated by declaring license metadata for “compatible with <code>-only</code>”, “compatible with <code>+</code>”, etc. Then it would be easy to write tooling to validate a given license expression (“You used <code>NPL-1.0-only</code>, but <code>NPL-1.0</code> is not compatible with <code>-only</code>”), but that doesn't mean users would validate their license expressions.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T19:04:09Z

Wking: Give “GPL-2.0 AND/OR Apache-2.0” as an example of a situation which cannot be represented by license expressions alone (either currently or with this Gary's proposal)

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used.
* “I just found this license text and am not sure about the grant” isn't specific to or-later-ness. For example, if you find text for <code>GPL-2.0</code> and text for <code>Apache-2.0</code>, the project is likely either <code>GPL-2.0 AND Apache-2.0</code> or <code>GPL-2.0 OR Apache-2.0</code>, but without (finding and parsing) an explicit licence grant you can't figure out which was intended. If we have a GPL-specific solution (listing neither <code>+</code> nor <code>only</code>) to representing this situation, there's no license-expression syntax for representing the <code>GPL-2.0 AND/OR Apache-2.0</code> situation.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T18:57:51Z

Wking: Add missing close-paren to the Licensee/GitHub parenthetical

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]). And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T18:57:07Z

Wking: Fix the Licensee link (I'd pasted in the npm link again by mistake)

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md Licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T18:55:23Z

Wking: Document “I just found these license files” as something you can express in an SPDX file but not with just a license expression

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

The spec also provides a way to distinguish between [https://spdx.org/spdx-specification-21-web-version#h.32hioqz detected license files] and the [https://spdx.org/spdx-specification-21-web-version#h.ihv636 concluded package license]. As discussed in the 2017-08-08 meeting, some ecosystems restrict themselves to license expressions (e.g. [https://docs.npmjs.com/files/package.json#license npm allows SPDX 2.0 license expressions]), and some tools attempt to detect package licenses by looking only at the license files and not at license-grant blurbs (e.g. [https://docs.npmjs.com/files/package.json#license licensee], which is [https://developer.github.com/v3/licenses/ used by the GitHub license API]. And there is currently no way to express “I just found these licenses and am not sure what the package license is” using only license expressions.

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T18:39:52Z

Wking: Shift the “only”-operator alternative discussion into Gary's proposal and it's alternative. Also mention the ambiguous nature of a project including GPL license text with no explicit licensing blurb

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

Potential issues:

* L/GPL language is clear that it is one or the other, so this could create more confusion and not reflect the intention of the license.
* This could also result in people using the <code>only</code> operator with other licenses where it is not needed or shouldn't be used.

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

Potential issues (in addition to those listed for the previous proposal):

* If the GPL license text (in the absence of an explicit licensing blurb, e.g. in a file header) is determined to imply something other than “only” semantics, instances of <code>GPL-2.0</code> become unclear (with the old logic, they clearly mean “only” and with the new logic they would not. John Sullivan is checking with the FSF to determine their position on the intended version(s) if a project has the GPL license text in a file but no explicit licensing blurb.

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

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

1) 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.

2) roll back the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

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

2017-08-08T18:32:45Z

Wking: Move Gary's proposal into a new “Solutions” section, since it's not part of the background.

==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). For example:

GNU General Public License v2.0 only GPL-2.0
GNU General Public License v2.0 or later GPL-2.0+

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 ("deprecated"), as the "or later" option could now be provided for via using the "+" operator. The ability to use license expressions via the "+" operator, along with the "with" operator also 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. This also resulted in the full license name having "only" with no real way to modify that to "or later" in the full license name.

The original argument for the <code>+</code> operator was that it could be used with other licenses (not just GNU family). The CDDL family is in a similar situation, except that while the GPL is “only” by default and “or later” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L509-L514 special grant wording], the CDDL is “or later” by default and “only” with [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.1.xml#L279-L289 an explicit notice prohibiting later versions]. There's currently no <code>only</code> operator for the CDDL, although some code (e.g. [https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5 parts of FreeBSD's ZFS implementation]) do declare that prohibition while other code (e.g. [https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19 some illumos userspace tools]) do not (and are therefore presumably CDDL-1.0+).

And to make versioned license grants even more complicated, the GPL-3.0 and similar have grown a [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517 proxy clause] that was not in earlier GPL versions. The CC has [https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CC-BY-SA-4.0.xml#L66-L67 similar proxy designation], but they don't give users a choice to change the proxy in their license grant. And similar proxy designation has come up before with the KDE's LGPL grant (see [https://lists.spdx.org/pipermail/spdx/2011-May/000389.html here] and [[FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29|here]]). The KDE example shows proxy designation in the grant even in the absence of license wording about designating proxies.

Are there other licenses that need something like the GPL's “any later version” grant or the CDDL's later version prohibition? [[Legal Team/later-version-clauses|Not that we've found]].

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.
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 are [[Legal Team/later-version-clauses|here]].

===Issue===
In practice, practitioners are not always explicit about whether a license is a version only or or later option. For licenses that may include either “only” or “or later” semantics depending on the grant, having an explicit <code>+</code>, <code>only</code>, or <code>PROXY {TEXT}</code> (or similar) in the grant's SPDX identifier reduces the chance that an unfamiliar user misinterprets the identifier.

==Solutions==

===Current Proposed Solution Solution===
Based on the joint tech/legal call on 8 August 2017, following is a proposed solution:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Create new license ID's GPLv1.0, GPLv2.0, GPLv3.0, LGPLv2.0, LGPLv2.1, LGPLv3.0 to replace the current license GPL family of license ID's which are defined to mean "only"
* Deprecated the license ID's GPL-1.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0 with a description that the license ID which replaces it should be used with the only operator

===Alternative Solution - Do Not Deprecated GPL-2.0===
Similar to the above proposal, but does not deprecate the GPL family of license IDs:
* Create an "only" operator defined as only the version of the license is intended for use.
* The + operator would remain with the same definition.
* In the spec, clarify that the license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used.
* Change the name and description of the GPL family of licenses to remove "only" references

===Alternative Solution - GPL-2.0-only license ID===
Replace "GPL-2.0" identifier with "GPL-2.0-only"

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

===Discussion of Other Possible Approaches===
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: Concerns with the proposed approach:
* 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.

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 the + 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?

== 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!)
=== Gary O'Neall 8/3/2017===
Summary of proposal made on the legal call.
Proposal to create an "only" operator. The semantics would be the only operator indicates that only the version of the license is intended for use. The + operator would remain with the same definition. The license ID used by itself would indicate that the license text itself should be used to determine if later versions of the license could be used. The advantage of this proposal is allows the author of the SPDX document to describe many of the scenarios found in the license header text explicitly. The disadvantage is it doesn't solve the problem of the current GPL license ID's having an explicit "only" version which contradicts the language of the license itself. I can think of 2 possible solutions:
* Create new license short ID's and deprecate the original ones. For example, we could add GPLv2 instead of GPL-2.0. There are several other possible naming conventions (e.g. GPL-v2.0, GPL2.0). The important aspect is that the new license ID is different. We could then deprecate the old license ID's.
* Rely on the license list version to interpret the "only" aspect of the GPL licenses. Versions prior to the implementation of the only operator would interpret the GPL to be ONLY, after implementation of the only operator it would be interpreted per the license text. The issue with this approach is not all license expressions have an associated license list version.

Legal Team/later-version-clauses

2017-08-08T16:51:09Z

Wking: Cross-link or-later-vs-unclear-disambiguation page

==Licenses with later-version clauses==

See also the discussion of only vs. or-later grants [[Legal Team/or-later-vs-unclear-disambiguation|here]].

===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* GNU 3.0+ family of licenses = AGPL-3.0, GPL-3.0, LGPL-3.0
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1
* Watcom family = PHP-3.01, Watcom-1.0, Zend-2.0

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|GNU 3.0+ family
|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.
|y
|y
|unclear
|The AGPL-3.0 phrasing uses “Affero General” instead of “General”. The LGPL-3.0 phrasing uses “the Library [as you received it]” instead of “the Program”, “shall apply” instead of “can be used”, some shuffled authorization wording, and “Lesser General” instead of “General”.
This approach is similar to the CC's nominating themselves as a proxy for their ShareAlike licenses
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
|Watcom family
|Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|n
|y
|or later
|The PHP-3.01 and Zend-2.0 phrasing uses “covered code” instead of “Original code” and “the license” instead of “this License”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

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

2017-08-08T16:48:49Z

Wking: Remove extra trailing ‘=’ from mailing list header

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

2017-08-04T23:49:07Z

Wking: Link to LGPL with a KDE proxy example

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

2017-08-04T23:43:34Z

Wking: Mention proxy designation in the issue wording

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

2017-08-04T23:32:05Z

Wking: Document GPL 3.0+ grant-designated-proxy and compare it with the CC's license-designated-proxy

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

2017-08-04T23:24:09Z

Wking: Close paren for illumos-gate example

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

2017-08-04T23:23:41Z

Wking: Add illumos-gate example of CDDL-1.0+

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

2017-08-04T23:19:30Z

Wking: Add FreeBSD's ZFS implementation as an example of CDDL-1.0-only

Legal Team/later-version-clauses

2017-08-04T23:10:43Z

Wking: Add a GNU 3.0+ family to document the proxy clause

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* GNU 3.0+ family of licenses = AGPL-3.0, GPL-3.0, LGPL-3.0
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1
* Watcom family = PHP-3.01, Watcom-1.0, Zend-2.0

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|GNU 3.0+ family
|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.
|y
|y
|unclear
|The AGPL-3.0 phrasing uses “Affero General” instead of “General”. The LGPL-3.0 phrasing uses “the Library [as you received it]” instead of “the Program”, “shall apply” instead of “can be used”, some shuffled authorization wording, and “Lesser General” instead of “General”.
This approach is similar to the CC's nominating themselves as a proxy for their ShareAlike licenses
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
|Watcom family
|Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|n
|y
|or later
|The PHP-3.01 and Zend-2.0 phrasing uses “covered code” instead of “Original code” and “the license” instead of “this License”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

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

2017-08-04T22:55:44Z

Wking: Use wiki-link syntax for the later-version-clauses link

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

2017-08-04T22:55:07Z

Wking: Mention CDDL as also depending on the grant wording (vs. the license text itself). Also link to later-version-clauses for the “we're not aware of anything else”

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

2017-08-04T22:42:57Z

Wking: Rephrase issue as "reduce the chance of an unfamiliar user misinterpreting the identifier"

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

2017-08-04T22:38:05Z

Wking: Shift original argument and list of licenses paragraphs from “Implementation of Solution” to “Background”

Legal Team/later-version-clauses

2017-08-04T21:06:48Z

Wking: Collapse PHP-3.01 into the Watcom family, because the wording is very similar

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1
* Watcom family = PHP-3.01, Watcom-1.0, Zend-2.0

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
|Watcom family
|Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|n
|y
|or later
|The PHP-3.01 and Zend-2.0 phrasing uses “covered code” instead of “Original code” and “the license” instead of “this License”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

Legal Team/later-version-clauses

2017-08-04T21:04:54Z

Wking: Shift the Watcom family entry up in the table so we lead off with the family entries (following the order of the family list in “Notes”)

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1
* Watcom family = Watcom-1.0, Zend-2.0

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
|Watcom family
|Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|n
|y
|or later
|The Zend-2.0 phrasing uses “covered code” instead of “Original code” and “the license” instead of “this License”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
|PHP-3.01
| 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

Legal Team/later-version-clauses

2017-08-04T21:03:28Z

Wking: Shift the Watcom family entry up in the table so we lead off with the family entries

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1
* Watcom family = Watcom-1.0, Zend-2.0

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
|Watcom family
|Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|n
|y
|or later
|The Zend-2.0 phrasing uses “covered code” instead of “Original code” and “the license” instead of “this License”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
|PHP-3.01
| 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

Legal Team/later-version-clauses

2017-08-04T21:02:31Z

Wking: Collect Watcom-1.1 and Zend-2.0 together under the “Watcom family”

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1
* Watcom family = Watcom-1.0, Zend-2.0

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
|PHP-3.01
| 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
|Watcom family
|Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|n
|y
|or later
|The Zend-2.0 phrasing uses “covered code” instead of “Original code” and “the license” instead of “this License”.
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

Legal Team/later-version-clauses

2017-08-04T20:58:16Z

Wking: Classify Zend-2.0 as only allowing "or later"

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
|PHP-3.01
| 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
| Zend-2.0
| 4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
|Watcom-1.0
| 7. Versions of the License. Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|
|
|
|
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

Legal Team/later-version-clauses

2017-08-04T20:56:58Z

Wking: Collapse RSCPL into the NPL family, because the wording is very similar

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, RSCPL, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”. The RSCPL phrasing uses “Governed” instead of “Covered”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
|PHP-3.01
| 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
| Zend-2.0
| 4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to modify the terms applicable to covered code created under this License.
|
|
|
|
|-
|Watcom-1.0
| 7. Versions of the License. Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|
|
|
|
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}

Legal Team/later-version-clauses

2017-08-04T20:55:13Z

Wking: Collapse Nokia into the NPL family, because the wording is very similar

==Licenses with later-version clauses==
===Notes===
* GNU family of licenses = Affero, Lesser, Free Documentation, General. Uses the same substantive language (with variations only in subject, e.g., Document, Library, Program, etc.).
* EPL family = EPL-1.0, CPL-1.0, IPL-1.0
* NPL family = Nokia, NOSL, NPL-1.0, Motosoto, MPL-1.0, MPL-1.1, SISSL-1.2, SNIA
* CDDL family = CDDL-1.0, CDDL-1.1

===Table of license text===
{| class="wikitable"

|-
|License Family
|Relevant Text
|Allows only
|Allows or later
|Default
|Notes
|-
|GNU family
| The Free Software Foundation may publish revised and/or new versions of the 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 Program 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 Program does not specify a version number of the license, you may choose any version ever published by the Free Software Foundation.
|y
|y
|or later
| if no version specified, then any version ever published (=GPL-1.0+)
|-
|EPL family
| 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.
|n
|y
|or later
|
|-
|NPL family
|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. 
|n
|y
|or later
|The SISSL-1.2 phrasing uses “Original” instead of “Covered” and lacks “created under this License”. The Motosoto phrasing uses “Licensed Product” instead of “Covered Code”.
|-
|APL-1.0
|EFFECT OF NEW VERSIONS. Once the Licensed Work or any portion thereof has been published by Initial Contributor under a particular version of the License, Recipient may choose to continue to use it under the terms of that version. However, if a Recipient chooses to use the Licensed Work under the terms of any subsequent version of the License published by the Initial Contributor, then from the date of making this choice, the Recipient must comply with the terms of that subsequent version with respect to all further reproduction, preparation of derivative works, public display of, public performance of, distribution and sublicensing by the Recipient in connection with the Licensed Work. No one other than the Initial Contributor has the right to modify the terms applicable to the Licensed Work.
|y
|y
|or later
|Only the Initial Contributor may publish revised/new versions. If the Recipient chooses to use a subsequent version, they can't go back to the terms of a previous version.
|-
|MPL-2.0
| 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.
|n
|y
|or later
|
|-
|PHP-3.01
| 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
|n
|y
|or later
|
|-
| Zend-2.0
| 4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. 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 Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to modify the terms applicable to covered code created under this License.
|
|
|
|
|-
|Watcom-1.0
| 7. Versions of the License. Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License.
|
|
|
|
|-
|RSCPL
|6.2. Effect of New Versions. Once Governed 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 Governed Code under the terms of any subsequent version of the License published by RSV. No one other than RSV has the right to modify the terms applicable to Governed Code created under this License.
|
|
|
|
|-
| CDDL family
| 4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
|y
|y
|or later
|only the Initial Developer may choose "only"
|-
| CC-BY-SA and CC-BY-NC-SA families (since 2.0)
| Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.

[…]

b. ShareAlike.

1. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-NC-SA Compatible License.
|n
|y
|or later
| Relevant text taken from CC-BY-NC-SA-4.0, but similar in all CC licenses with SA, from 2.0 onward.
Compatible licenses are determined by the CC and listed [https://creativecommons.org/compatiblelicenses here]. So it's closer to “or anything the CC decides is compatible”, which is broader than “or later versions of this license”.
|-
|}