Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 5/25/22 1:13 PM, Bradley M. Kuhn wrote:
In answering Thomas' question …

Thomas Gleixner wrote at 14:10 (PDT) on Monday:
If I want to remove this option, then how do I express this with a SPDX
license identifier?
… some licensing/SPDX background is in order.  (I apologize in advance for a
few paragraphs of license-splaining, as I know that many on this thread know
these points already, but I suspect most only have only vague familiarity
with this issue.)

copyleft-next 0.3.1 reads:
+11. Later License Versions
+    The Copyleft-Next Project may release new versions of copyleft-next,
+    designated by a distinguishing version number ("Later Versions").
Many don't realize that GPL is (or was, pre-copyleft-next) unique in
structure among copyleft licenses in that the -or-later clause of all
licenses in the GPL family is configurable.  That yields the complex forms
of: GPLv1-only, GPLv1-or-later, GPLv2-only, GPLv2-or-later, etc.  GPLv3 even
added the proxy upgrade clause (— a formulation SPDX can't handle at all).

Other non-trivial FOSS licenses — such as Mozilla Public License (MPL),
Common Development and Distribution License (CDDL), and Eclipse Public
License (EPL) (as just three examples) — all have “automatic -or-later”.
Thus, “MPLv2.0” *always* means “MPLv2.0-or-later”, so if you use the SPDX
moniker for that (“MPL-2.0”), it really is akin to using “GPLv2-or-later”.
Meanwhile, there is no *actual* way to license code under “MPLv2-only” — the
license text itself prohibits it.
A few folks on the SPDX legal team did a summary chart of all the nuances and while I'm not going to go down that road again, suffice to say, the "or later" clauses have more variation than most people would think (which is probably b/c most people don't need to pay attention to it). The "+" operator is always available if someone so chooses to apply it as needed.

All that's to say: the GPL has (historically) always been a huge FOSS
licensing special-case because of the complex configurability of its
“-or-later” clause.
Agreed.

One of the last activities I did with SPDX (in late 2017) was to help
negotiate a solution on reworking the GPL identifiers to deal with this
special case.  The solution was a classic political compromise — where
*everyone* left unhappy — but that's what led to the deprecation of SPDX's
“GPL-2.0” identifier in favor of “GPL-2.0-or-later” and “GPL-2.0-only”.
I would agree with this characterization, except this was the outcome the FSF wanted, so ostensibly they were happy (and you forgot that GPL-2.0+ ). (And to give credit where credit is due, Bradley's input during that challenging "negotiation" was very helpful. :)

So, this problem that Thomas notes above is definitely an error by the SPDX
project, *just like* the one that exists for the deprecated “GPL-2.0”
To be clear, the GPL-2.0 identifier was never an error by the SPDX team - we were always very clear as to what it meant/means. It was that the FSF didn't like it. That is clearly explained in the blog post on the SPDX website, as well as the post on the FSF site on the subject.

Jilayne



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux