Re: Is "+" a valid character of a LicenseRef idstring?
Philippe Ombredanne
On Tue, Nov 3, 2015 at 3:45 AM, Wheeler, David A <dwheeler@...> wrote:
Philippe Ombredanne wrote:[...] David:You say:That's not just what I say. That's what the spec says, and has 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 otherThe 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 isThis 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 |
|