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

["Bradley M. Kuhn" <bkuhn@ebb.org>]

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.

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.

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 wasn't involved with SPDX anymore when they (much later) created the
identifier “copyleft-next-0.3.1” — but it appears it was a case of “those
who forget the past is condemned to repeat it” — because copyleft-next's
SPDX identifier indeed has a similarly confusing ambiguity to “GPL-2.0”:

copyleft-next 0.3.1 text reads further:
>> +    Unless I explicitly remove the option of Distributing Covered Works
>> +    under Later Versions, You may Distribute Covered Works under any Later
>> +    Version.
Thomas Gleixner noted about it at 14:10 (PDT) on Monday:
> If I want to remove this option, then how do I express this with a SPDX
> license identifier?  Sigh!

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”
identifier.  But, that isn't copyleft-next's fault [0], nor Luis's fault.
IMO, Luis shouldn't be punished (i.e., by being prohibited by the Linux
project from licensing under the GPLv2-compatible terms of his choosing)
simply because the SPDX project erred.

Fortunately, the problem *is* hypothetical here because Luis has *not*
indicated that he's licensing under “copyleft-next-0.3.1 REVOKING
new-version-upgrade”, so it's not a problem for Luis' patch that SPDX offers
no way to represent that licensing sub-option in copyleft-next.

[0] Nevertheless, I am wondering, given that (a) opting-out-of-auto-upgrade is
    *so* GPL-specific, and (b) the auto-upgrade opt out has caused decades
    of pain and woe throughout the GPL-using community (and for SPDX!),
    maybe copyleft-next should, in fact, drop that clause entirely in future
    versions. Discussion of that is likely not of interest to most folks on
    this wide thread, so I'll pick up that conversation more narrowly just
    on the copyleft-next list from here …

 -- bkuhn