The call yesterday revealed to me that there are *two* kinds of license version 
ambiguity in SPDX license expressions.

I don't know if this is actually a problem, or if it is, that solving it is 
worth the trouble.  For many people the "second kind" is probably immaterial.  
However, I want to record the subtlety here for the record, and for discussion 
in case people think that this *is* a problem that needs solving.  I thought it 
should at least be captured somewhere, so that others can determine whether or 
not this subtlety is important.  Details below.

Thanks.

--- David A. Wheeler

=== DETAILS ===

In short, there are two different kinds of version number ambiguities in a 
license:
1. A particular version of a license is known to be acceptable, but it's 
unclear if later versions are acceptable.  This is what we've focused on.
2. A license name is referenced, but no particular version of it is identified, 
so it's unclear *which* version(s) of the license are acceptable.

I'm primarily concerned with case #1.  It's becoming quite common to copy a 
particular license (with a particular version) into a repository, and that is 
the *ONLY* information explaining what license is acceptable.  At that point, 
it's not always clear if "or later" is acceptable unless the license 
*specifically* says that later versions are automatically acceptable.  The FSF 
rep yesterday noted that people should be following license instructions on how 
to include the license, which is fair enough, but people don't always follow 
directions :-).  The current proposals (e.g., on an ONLY operator) focus on 
this issue, and I think this is the main concern today.

Case #2 is a different situation, where we have *no* idea what license version 
is being applied.  It can occur when (for example) someone says "This is 
licensed under the GPL" or "This is licensed under the CC-BY license".  SPDX's 
license expressions do not have a direct way to say "I don't know which 
version", and license identifiers are all tied to a specific version.

It's not clear that that case #2 is *really* a significant problem.  If all you 
care about is "what is acceptable", in many cases a SPDX license expression can 
capture the final result of what's acceptable, though that appears to depend on 
the text of the individual license.  In particular, all versions of the GPL 
license (so far!) say that if you don't specify a version, the recipient can 
use any version.  So you can express the rights granted by "GPL no version 
specified" as the license expression "GPL-1.0+".  However, this expression 
appears to depend on the specifics of the license, and I suspect that you 
cannot do this with all licenses.  There's also a small loss of information, as 
you can't distinguish between "This is licensed under any version of LICENSE" 
and "This is licensed under LICENSE (but I won't tell you which version)" - 
which is probably irrelevant for the GPL, but might be important for some other 
licenses.

If SDPX wanted to capture case#2, the situation where "version number 
completely unknown", one approach would be to allow license identifiers to 
*omit* the version number to mean "version number unknown".  E.g., "GPL" would 
mean "GPL, I don't know which version(s)".  However, that would create 
hardships for unversioned licenses like MIT - if there is ever an MIT license 
version 2.0, then "MIT-2.0" would suddenly render all the uses of "MIT" 
ambiguous.  I think that would be unacceptable.  In any case, it's a common 
mistake to just use "GPL" when a specific version *is* present, and we don't 
want to make it easy to make hard-to-detect mistakes.  So instead, I think 
replacing "-version" with a special marker like "-?" or "-UNKNOWN" would be the 
better approach.  You'd then capture this situation as "GPL-?" or 
"GPL-UNKNOWN".  That would expressly capture "version number uncertain". I 
think that'd be the way to go *if* this case #2 is worth capturing.

That said, it's not clear to me that this information of case#2 really needs to 
be captured.  Others may know of more critical cases, though, so I thought it'd 
be important to record this.

Thanks for reading all the way to the end...!

_______________________________________________
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Reply via email to