On Wed, Oct 28, 2015 at 10:28 AM, Schuberth, Sebastian
<sebastian.schuberth@...> wrote:

when debugging an issue in the spdx-tools verifier, I noticed the SPDX 2.0
specs seem to be inconsistent on whether "+" is a valid character in a
LicenseRef's idstring, like in LicenseRef-[idstring].

I not see any reason why a + would not be allowed in a reference, and
there is no ambiguity since the + always something attached to an id or
ref string, not some free standing symbol.

But this raises a larger question which I am sure has been
debated in the past:

Using a + is a whart. Licenses that allow the use of other versions do so
explicitly in their texts, the GPL being the most prominent but the EPL
comes to mind too. So there is no such thing as GPL-2.0 or another
version: these are the plain default GPL terms.

If I do nothing special, the GPL version I picked or any other later
version can apply. I need to go the extra mile to state that only this
version applies and no other version. I need to add a specific statement
to that effect. Actually if I only state my code is GPL-licensed without
indicating a version the GPL says that a recipient can pick *any current
or future version*

So to me it is an exception to the GPL-2.0 (or 3) to disallow the use of
other versions. A fairly common exception because it is used in the
kernel and that likely led to this flawed but widely spread approach
to be adopted by Linux distros. And later adopted by SPDX.

Essentially GPL-2.0 and GPL-2.0+ mean exactly the same the thing.
The plus is redundant and confusing. To be truly correct, every
single occurrence of the GPL that does not disallow later versions
should have a plus. It does not make sense to treat the non-default
exceptional case as the default.

Fixing this in SPDX would mean to deprecate + entirely, and add
an exception that would disallow other or future versions such as "only".

Or change the meaning and the text of the GPL-2.0 to be some
notice that states this means the GPL-2.0 applies only and no other
version. And replace the GPL-2.0 id by a GPL-2.0+ id where the text
is the actual full text.

Any thoughts?

PS: I am cross-posting to the legal list as this is ultimately there
that it should
be resolved IMHO.
--
Cordially
Philippe Ombredanne

Schuberth, Sebastian <sebastian.schuberth@...> wrote:

Using a + is a whart. Licenses that allow the use of other versions do so explicitly in their texts, the GPL being the most prominent but the EPL comes to mind too. So there is no such thing as GPL-2.0 or another version: these are the plain default GPL terms.

The issue is how the software is licensed, not what the text of the GPL (or anything else) is. The use of "+" to mean "or later" is a long-standing convention preceding SPDX.

Essentially GPL-2.0 and GPL-2.0+ mean exactly the same the thing.

No, there's a need to distinguish between "exactly this version" or "this version of later". Some software, such as the Linux kernel, are GPL version 2.0 only.

--- David A. Wheeler

Hi Philippe,

On Mon, Nov 2, 2015 at 2:07 PM, Wheeler, David A <dwheeler@...> wrote:

On Mon, Nov 2, 2015 at 10:56 AM, Philippe Ombredanne <pombredanne@...> wrote:

David:

Schuberth, Sebastian <sebastian.schuberth@...> wrote:

I think you are misquoted my reply for being from Sebastian.

The issue is how the software is licensed, not what the text of the GPL
(or anything else) is. The use of "+" to mean "or later" is a long-standing
convention preceding SPDX.

Pardon me, but I think the text(s) of the GPL define how the the
software is licensed...
As I said initially I agree this is indeed a long standing convention.
But this does not mean that this a correct convention and that the
status-quo should continue.

FWIW, I said essentially the same thing as you about the origin of
this + notation:

On Mon, Nov 2, 2015 at 10:56 AM, Philippe Ombredanne
<pombredanne@...> wrote:

So to me it [the +] is an exception to the GPL-2.0 (or 3) to disallow the use of
other versions. A fairly common exception because it is used in the
kernel and that likely led to this flawed but widely spread approach
to be adopted by Linux distros. And later adopted by SPDX.

On Mon, Nov 2, 2015 at 10:56 AM, Philippe Ombredanne
<pombredanne@...> wrote:

Essentially GPL-2.0 and GPL-2.0+ mean exactly the same the thing.

No, there's a need to distinguish between "exactly this version" or "this version of later".
Some software, such as the Linux kernel, are GPL version 2.0 only.

My point here is that when I refer to the GPL 2.0 I have by default
the rights to use any other
version, unless as a special EXCEPTION you are telling me that I can
use only this version
and no other version.
So GPL-2.0 with no-other-version would be capturing better the
exceptional nature of the
version restriction, than GPL-2.0+ does in forcing a plus in the general case

--
Cordially
Philippe Ombredanne

So we're all on the same page in this discussion: are you are referring to this section of the GPL-2.0 license:

======================
Each version is given a distinguishing version number. If the Program specifies a version number of this 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 this License, you may choose any version ever published by the Free Software Foundation.
======================

Tom Incorvia; tom.incorvia@...; O: (512) 340-1336; M: (215) 500 8838; Shoretel (Internal): X27015

On Wed, Oct 28, 2015 at 10:28 AM, Schuberth, Sebastian wrote:

when debugging an issue in the spdx-tools verifier, I noticed the
SPDX 2.0 specs seem to be inconsistent on whether "+" is a
valid character in a LicenseRef's idstring, like in LicenseRef-[idstring].

I wrote:

I not see any reason why a + would not be allowed in a reference, and
there is no ambiguity since the + always something attached to an id or
ref string, not some free standing symbol.

On Mon, Nov 2, 2015 at 7:02 PM, Gary O'Neall <gary@...> wrote:

In the 2.0 spec, the + is a unary operator with a specific meaning
(see Appendix IV of the 2.0 spec "Simple License Expressions" subsection
page 82). If we are to use it as an operator with License Ref's, it would
be difficult for a parser to determine when it is part of a reference string
and when it is intended as an operator.

This + is a suffix and not a freestanding character, right?
So "GPL-2.0+" is valid but "GPL-2.0 +" would not be valid?
In this case there would be no issue to have a plus as part of a licenseref:
there is no possible ambiguity.

Then again we would be better off to get rid of the plus entirely!

--
Cordially
Philippe Ombredanne

Philippe Ombredanne:

This + is a suffix and not a freestanding character, right?
Then again we would be better off to get rid of the plus entirely!

You may be confusing a SPDX "license identifier" and a SPDX "license expression". It's a subtle point.

The purpose of a "license identifier" is to identify a specific text of a specific license text, using a short name. In SPDX 2.0 there is no "+" in a standard license identifier. In particular, "GPL-2.0" is a license identifier, and "GPL-2.0+" is *NOT*. If all you want to do is identify a particular license text, use a license identifier. No "+" exists at the end of a license identifier.

However, a "license identifier" is often inadequate for describing the licensing requirements imposed on users and later developers. Many packages have different subcomponents with different licenses. Many packages include the text of some license (such as the GPL version 2.0), but there are often two possible cases:
- You must use this particular version of the license.
- You may use this or any later version of the license.

Thus, SPDX 2.0 defines a "license expression" for describing how license texts apply to software packages,. A license expression is built out of license identifiers but adds ways to describe how the license texts are used. A "+" appended after the name of a license identifier means "or any later version may also be used". E.G., the license expressions "(GPL-2.0+ WITH Classpath-Exception-2.0)" and "(MIT AND BSD-3-CLAUSE)" express how the license text requirements are imposed on recipients (users and developers). License expressions use the long-standing convention is that if software is licensed using "this or any later version" you add a "+" to the name of the license. You can argue that the "+" should be the default, but standards typically work best if they build on pre-existing conventions, and that was certainly the case here.

--- David A. Wheeler

I said:

In particular, "GPL-2.0" is a license identifier, and "GPL-2.0+" is *NOT*.

Just a few nitpicks on my previous email:
* I realize that "GPL-2.0+" is in the list of "deprecated" license identifiers, so in some sense there is a "GPL-2.0+" license identifier. But I think it's clear what the *intent* is; the deprecated entry is only for legacy use.
* I only talked about pre-defined license identifiers with short forms. I realize that there can be licenses not in the list, and those are handled differently.

--- David A. Wheeler

Hi Philippe,

This + is a suffix and not a freestanding character, right?
So "GPL-2.0+" is valid but "GPL-2.0 +" would not be valid?

[Gary]
[Gary] My interpretation of the spec "GPL-2.0 +" and "GPL-2.0+" are both syntactically valid (as well as MIT+, LicenseRef-21+ and any other listed license ID or licenseRef). This is not any statement on the interpretation, just the license expression syntax (I'll leave the interpretation discussions to a separate thread).

In general, I would prefer any operator character(s) to be excluded from the allowed characters for a license reference to keep the parsing clear and easier to implement.

Gary

Good point.

What makes this particular syntax more confusing is that pre-2.0 the + was
considered part of the license identifier. It was promoted to an operator
in the 2.0 spec which does create some backwards compatibility issues (as
well as some confusion).

Gary

On Mon, Nov 2, 2015 at 8:17 PM, Tom Incorvia
<tom.incorvia@...> wrote:

So we're all on the same page in this discussion: are you are
referring to this section of the GPL-2.0 license:

======================
Each version is given a distinguishing version number. If the Program
specifies a version number of this 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 this License, you may choose any version ever
published by the Free Software Foundation.
======================

Yes, exactly that, and the related text found in the proposed
notice text found at the end of the GPL text:

========================
This program is free software; 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.
========================

... which is the default notice I see in most cases (except for
the not-so-uncommon case of the Kernel).

My take is that the large majority of programmers applying the
GPL to their work just take the default notice and only a very
few make an exception and restrict this to an exact version.

I even have pseudo scientific evidence to support this claim ;)
http://www.googlefight.com/free+software+foundation+and+no+other+version-vs-free+software+foundation%3B+either+version+2.php

--
Cordially
Philippe Ombredanne

On Mon, Nov 2, 2015 at 10:36 PM, Gary O'Neall <gary@...> wrote:

This + is a suffix and not a freestanding character, right?
So "GPL-2.0+" is valid but "GPL-2.0 +" would not be valid?

My interpretation of the spec "GPL-2.0 +" and "GPL-2.0+" are both syntactically
valid (as well as MIT+, LicenseRef-21+ and any other listed license ID or
licenseRef). This is not any statement on the interpretation, just the license
expression syntax (I'll leave the interpretation discussions to a separate thread).
In general, I would prefer any operator character(s) to be excluded from the
allowed characters for a license reference to keep the parsing clear and
easier to implement.

Gary, I cannot envision a simpler implementation than splitting on spaces.

A plus sign specified as a suffix that is not attached to a license key would
no longer be a suffix to me, but something entirely different.

My interpretation of the spec is that the + sign must be attached to the license
key and all examples provided in the spec support this interpretation.
If that part is not clear, let's fix the spec. This is not something frozen.

Now that said, I do not like the plus at all and we should remove entirely from
the spec.

--
Cordially
Philippe Ombredanne

On Mon, Nov 2, 2015 at 9:12 PM, Wheeler, David A <dwheeler@...> wrote:

Philippe Ombredanne:

This + is a suffix and not a freestanding character, right?
Then again we would be better off to get rid of the plus entirely!

You may be confusing a SPDX "license identifier" and a SPDX "license
expression". It's a subtle point.

I am not confusing these at all. The gist of what I am saying is that
the plus is a legacy that should not be there. It does not make sense to
add to the large majority of GPL in the wild a + just to deal with a few
exceptions that do not allow other versions. Exceptions should be dealt
with an exception not with an extra + in an expression.

The purpose of a "license identifier" is to identify a specific text
of a specific license text, using a short name. In SPDX 2.0 there is
no "+" in a standard license identifier. In particular, "GPL-2.0" is
a license identifier, and "GPL-2.0+" is *NOT*. If all you want to do
is identify a particular license text, use a license identifier. No
"+"exists at the end of a license identifier.

However, a "license identifier" is often inadequate for describing
the licensing requirements imposed on users and later developers.
Many packages have different subcomponents with different licenses.
Many packages include the text of some license (such as the GPL
version 2.0), but there are often two possible cases:
- You must use this particular version of the license.
- You may use this or any later version of the license.
Thus, SPDX 2.0 defines a "license expression" for describing how
license texts apply to software packages,. A license expression is
built out of license identifiers but adds ways to describe how the
license texts are used. A "+" appended after the name of a license
identifier means "or any later version may also be used". E.G., the
license expressions "(GPL-2.0+ WITH Classpath-Exception-2.0)" and
"(MIT AND BSD-3-CLAUSE)" express how the license text requirements
are imposed on recipients (users and developers). License expressions
use the long-standing convention is that if software is licensed
using "this or any later version" you add a "+" to the name of the
license. You can argue that the "+" should be the default,
but standards typically work best if they build on pre-existing
conventions, and that was certainly the case here.

David:
What you saying in substance is that every time I want state
that code is licensed under the GPL 2.0 or any other version
(which is the default), you want me to craft a special license
expression with a plus. And If do not craft that expression,
then the SPDX meaning is that only the current version applies
and not any later version.

I am saying this instead: Since the default for the GPL is to allow
later versions, we should by default state the opposite:
The few times that "only the current version" should be used, state
this explicitly with an exception.


You say:
GPL-2.0 ==> implies GPL 2.0 only
GPL-2.0+ ==> implies GPL 2.0 or later

I say:
GPL-2.0 ==> implies GPL 2.0 with its defaults (including later versions)
GPL-2.0 with no-other-version ==> implies GPL 2.0 and no other version

Explicit is better than implicit.


My rationale:
Practically the use of a GPL version "only" is much less frequent
than the default "or later" and therefore forcing me to add a plus
is a source of confusion.

The most common use case should be the default and should not
require a special addition of a character in an expression.

"only" should be an exception and not the default, because it is
not the default, nor the prevalent usage of the GPL: it is exceptional.

The fact that the + convention has been used by Linux distros
package maintainers and neither always strictly nor consistently
does not make this right and something that should be endorsed blindly.

So to recap:
I am NOT arguing about the syntax to express this.

I am arguing about the essence of the meaning of the plain GPL-2.0
license key in a simple expression.

The mere use of a GPL-2.0 identifier should convey that the license
is GPL-2.0 or any other version.

We should have an exception to convey the rarer cases when only
the stated version applies.

The benefits are:
1. no ambiguity about the meaning of widely used licenses such as
the GPL.
2. simpler spec
2. simpler expressions in most cases, more verbose and more explicit
expressions when needed in some rarer cases.

--
Cordially
Philippe Ombredanne

Philippe Ombredanne:

I am not confusing these at all. The gist of what I am saying is that the plus is a legacy that should not be there. It does not make sense to add to the large majority of GPL in the wild a + just to deal with a few exceptions that do not allow other versions. Exceptions should be dealt with an exception not with an extra + in an expression. What you saying in substance is that every time I want state that code is licensed under the GPL 2.0 or any other version (which is the default), you want me to craft a special license expression with a plus. And If do not craft that expression, then the SPDX meaning is that only the current version applies and not any later version.
I am saying this instead: Since the default for the GPL is to allow later versions, we should by default state the opposite: The few times that "only the current version" should be used, state this explicitly with an exception.
You say:
GPL-2.0 ==> implies GPL 2.0 only
GPL-2.0+ ==> implies GPL 2.0 or later

That's not just what I say. That's what the spec says, and has clearly stated since circa 2010.

I say:
GPL-2.0 ==> implies GPL 2.0 with its defaults (including later versions)
GPL-2.0 with no-other-version ==> implies GPL 2.0 and no other version
Explicit is better than implicit.
My rationale:
Practically the use of a GPL version "only" is much less frequent than the default "or later" and therefore forcing me to add a plus is a source of confusion.
The most common use case should be the default and should not require a special addition of a character in an expression.
"only" should be an exception and not the default, because it is not the default, nor the prevalent usage of the GPL: it is exceptional.
The fact that the + convention has been used by Linux distros package maintainers and neither always strictly nor consistently does not make this right and something that should be endorsed blindly.
I am arguing about the essence of the meaning of the plain GPL-2.0 license key in a simple expression.
The mere use of a GPL-2.0 identifier should convey that the license is GPL-2.0 or any other version.
We should have an exception to convey the rarer cases when only the stated version applies.

This would have been a useful argument to raise in 2010 (when SPDX was drafted). But this group doesn't exist to create a new spec where none has existed. For more than 5 years SPDX has consistently stated that "GPL-2.0" means ONLY GPL-2.0 and nothing else. This builds on previous history of Fedora and Debian, who also use "+" this way, e.g., see: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing . While I know you're focusing on the GPL, there are many other licenses, and most licenses do NOT have a "this or later version" clause; having the default be what's common in MOST licenses is actually sensible.

Changing the meaning of "GPL-2.0" now, 5 years after the original version was released in beta, would be a terrible idea. This would be a broadly backwards-incompatible change. Even worse, it's a backwards-incompatible change that cannot be easily detected by tools. The result would be that no one would know what "GPL-2.0" actually meant - does it mean "2.0 or later" or "exactly 2.0"? Many existing SPDX license expressions could be subtly wrong. That is *NOT* a good direction.

The benefits are:
1. no ambiguity about the meaning of widely used licenses such as the GPL.
2. simpler spec
3. simpler expressions in most cases, more verbose and more explicit expressions when needed in some rarer cases.

I disagree, in fact, it would create widespread ambiguity. People already use SPDX, with the terms as stated; there are many tools that build on it. It *might* have been better to have defined it some other way many years ago, but that ship has sailed.

Standards have to pick some common agreement that most people can live with. Adding a "+" suffix to a particular license name does not seem like a serious burden.

--- David A. Wheeler

On Tue, Nov 3, 2015 at 3:45 AM, Wheeler, David A <dwheeler@...> wrote:

Philippe Ombredanne wrote:

[...]

You say:
GPL-2.0 ==> implies GPL 2.0 only
GPL-2.0+ ==> implies GPL 2.0 or later

That's not just what I say. That's what the spec says, and has
clearly stated since circa 2010.
This would have been a useful argument to raise in 2010 (when SPDX was
drafted). But this group doesn't exist to create a new spec where
none has existed. For more than 5 years SPDX has consistently stated
that "GPL-2.0" means ONLY GPL-2.0 and nothing else. This builds on
previous history of Fedora and Debian, who also use "+" this way,
e.g., see: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing

David:
I know this as I was part of it and that does not make it more right ...
FWIW, I have been around SPDX for quite a while ;).
See "A Short History of SPDX": https://spdx.org/about-spdx/what-is-spdx

While I know you're focusing on the GPL, there are many other
licenses, and most licenses do NOT have a "this or later version"
clause;

The focus is not only on the GPL:
well over 25% of the SPDX licenses DO HAVE a "this or later version"
clause. Here are some examples:

- Most of the FSF licenses: The GPL and LGPL and all their versions.
But also the AGPL, the GFDL, etc.
- all the Mozilla-like license: NPLs, MPLs and all the MPL derivatives
such as SPL, CPAL, Erlang, RPL, APSL, Gsoap, ZIMBRA, SISL, etc.
- most of the Creative Common licenses,
- The Eclipse licenses and the CPLs,
- the CDDLs,
- the PHP license,
- OpenLDAP, Latex/LPPL, LPL, Condor, CATOSL, RPSL, CECILL, etc.

For all SPDX licenses allowing other versions, the bare identifier means
"or later version", except for the L/GPL where this means "only the
current version" unless you create an expression with a "+".

So the decision procedure to use a plus or not is roughly like this:

If licensing allows to use "other license versions":
- If and only if GPL or LGPL, add a + to the license identifier.
"other license versions" is NOT implied.

- Otherwise, if this not GPL or LGPL, do NOT add a +.
"other license versions" is implied if the license allows such thing.
Do this ONLY for any versions of these two licenses. Do not apply
this approach to other FSF licenses such AGPL, GFDL and others.

- Except if you are a Linux packager for Debian or Fedora and their
derivatives, because then you may use the + for other FSF
licenses beyond the L/GPL. The + is already used with GFDL,
AGPL, etc. Do not use a plus for non-FSF licenses that
have an "or later" clause.

If licensing does NOT allow to use "other license versions":
- If and only if LGPL or LGPL, use the bare license identifier.
"no other license version" is implied by a bare id.

- Except if you are a Linux packager because you apply
the same approach for other FSF licenses.

- If this is another license, then?
"other license version" IS implied in a bare id here.
SPDX does not help you there, and you could create an
exception.This is a rare case anyway.

having the default be what's common in MOST licenses is
actually sensible.

This is exactly my point. The common sense and default usage for L/GPL
is ". And Linux distros and SPDX have made the default "or later"
exceptional and the less common "only" exception the default.

So how to resolve this situation?

In the grand scheme of things, "only" and "or later" are minute
technicalities that the large majority of software users do not care
for. The licenses requirements are essentially the same and
"later or not later" is not the question.
Only a few licensing mavens care about this and they know how to deal
with it.

But SPDX is likely stuck with this inconsistent legacy and yes this is
hard to escape without creating more mess. It does not mean that we
cannot try to clarify and improve things.

First we need to distinguish two types of licenses allowing
"other versions":

a. FSF licenses such as the A/L/GPL. These are the only licenses were a
plus + convention has been used by Linux distros and SPDX with some
consistency.

b. Non-FSF licenses. I cannot find cases where the plus + convention
has been used in the wild or with SPDX for these.


Some ways out could include:

Option 1. Do mostly nothing.
---------
Keep the status quo and clarify the current ambiguities:
We document the procedure I described above and move on.
We accept this is a mess and make it a documented mess.
This is an OK option. And requires little or no work.


Option 2. Change the meaning of every bare license id that allow
"or later" to mean "this version only". FSF or not FSF.
--------
No change of license ids is needed, only the SPDX full names and notes
need to be updated the same way the full name of the GPL-2.0 is:
"GNU General Public License v2.0 only"

And we explain that to express the default case of "or later" you always
need to create an expression with a +. This would provide a consistent and
homogeneous treatment of all SPDX licenses.
This is not the way Linux distros have used non-FSF licenses.
And this would change the meaning of any non-FSF licenses that have been
used without a plus until now.
This is not really an OK option. And requires quite some work.


Option 3. Reinstate/un-deprecate the "+" to use it as part of the
identifier when needed only for FSF licenses and deprecate the
usage of the + in license expressions.
--------
Here and ONLY for FSF licenses, we deprecate GPL-2.0 and related
identifiers and replace them with new ids such as GPL-2.0-only and
AGPL-3.0-only. We reinstate the GPL-2.0+ or create similar identifiers
(e.g. AGPL-3.0+) that become the default.

Note that we could also consider keeping multiple ids as "aliases" for
FSF licenses instead of deprecating the GPL-2.0 bare ids.

And we deprecate the use of the plus in license expressions
now no longer needed.

For the cases of non-FSF licenses supporting "or later" and if you
want to restrict usage to "only this version", we add a new exception
such as "No other version" or "only this version", rarely needed.

This approach would be compatible with the past and the present and
consistent with the ways the plus is used in Debian and Fedora distros
for FSF licenses beyond the L/GPL:

- GPL-2.0+ always means/meant "or later".
- GPL-2.0 and GPL-2.0-only always means/meant "only".

And tools that parse SPDX expressions can look up the license ids
with + first or handle the deprecated + without ambiguities.

It is still inconsistent with the general default meaning of "GPL 2.0".
So when you migrate to SPDX, any places where you used "GPL 2.0"
with the general default meaning of "or later" you need to map this to
GPL-2.0+.

This is an OK option. And requires some work.

--
Cordially
Philippe Ombredanne

Philippe Ombredanne:

The focus is not only on the GPL: well over 25% of the SPDX licenses DO HAVE a "this or later version" clause....
In the grand scheme of things, "only" and "or later" are minute technicalities that the large majority of software users do not care for. The licenses requirements are essentially the same and "later or not later" is not the question. Only a few licensing mavens care about this and they know how to deal with it.

These are not minor technicalities from a legal point of view; versions are important. They control what is allowed and not allowed.

It's true that many developers don't care about license versions, but many developers don't care about licensing or if what they're doing is legal. I know we *do* agree that we should work for a higher standard :-).

But SPDX is likely stuck with this inconsistent legacy and yes this is hard to escape without creating more mess. It does not mean that we cannot try to clarify and improve things.

Sure, but I think "GPL-2.0" MUST continue to mean "GPL version 2.0 and no other version", because that's the spec that everyone is depending on, this is a common case, and this is the convention that all other license naming systems also. Changing a key existing meaning in a standard is a bad thing.

Perhaps SPDX should add an additional postfix operation like "!" to mean "exactly this version and no other". Then encourage always using the postfixes "+" or "!" in license expressions for licenses that have "or any later version" text. E.G., "GPL-2.0!" might be the preferred way to express "exactly GPL version 2.0" while "GPL-2.0+" would continue to mean "GPL version 2.0 or later". Then you can deprecate license expressions where a license uses "or any later version" text and omits a postfix (e.g., "GPL-2.0" is a legal name of a license but a deprecated license expression). You could even allow postfix "?" to mean it's unknown if later versions are allowed or not, a plausible tool result. This would mean that SPDX would need to track which licenses have "or later version" text, to encourage people add the postfix operation, but that's easily done.

--- David A. Wheeler