lkml.org 
[lkml]   [2022]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
From


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

\
 
 \ /
  Last update: 2022-05-25 23:51    [W:3.288 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site