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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a8c4636b-707c-2563-c521-2455ac08237c@jilayne.com>
Date:   Wed, 25 May 2022 15:50:23 -0600
From:   J Lovejoy <opensource@...ayne.com>
To:     "Bradley M. Kuhn" <bkuhn@....org>,
        Thomas Gleixner <tglx@...utronix.de>,
        copyleft-next@...ts.fedorahosted.org
Cc:     Luis Chamberlain <mcgrof@...nel.org>, tj@...nel.org,
        gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
        jeyu@...nel.org, shuah@...nel.org, bvanassche@....org,
        dan.j.williams@...el.com, joe@...ches.com, keescook@...omium.org,
        rostedt@...dmis.org, minchan@...nel.org,
        linux-spdx@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
        Goldwyn Rodrigues <rgoldwyn@...e.com>,
        Kuno Woudt <kuno@...b.nl>,
        Richard Fontana <fontana@...rpeleven.org>,
        Ciaran Farrell <Ciaran.Farrell@...e.com>,
        Christopher De Nicolo <Christopher.DeNicolo@...e.com>,
        Christoph Hellwig <hch@....de>,
        Jonathan Corbet <corbet@....net>,
        Thorsten Leemhuis <linux@...mhuis.info>
Subject: Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license



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