copyleft-next May 2022

copyleft-next@lists.fedorahosted.org

4 participants
10 discussions

OSI submission
by Richard Fontana 25 May '22

25 May '22

Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval? I had given a little thought to the idea in the past, but while I was on the OSI board (2013-2019) I considered it to be inappropriate. Richard

10 10

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain 25 May '22

25 May '22

On Wed, May 25, 2022 at 10:51:43PM +0200, Thomas Gleixner wrote: > On Wed, May 25 2022 at 09:57, Luis Chamberlain wrote: > > On Mon, May 23, 2022 at 11:22:36PM +0200, Thomas Gleixner wrote: > >> This paragraph is not really understandable for Joe Developer. > >> > >> copyleft-next-0.3.1 is explicitly compatible with GPLv2 (or later) and > >> can therefore be used for kernel code. Though the best and recommended > >> practice is to express this in the SPDX license identifier by > >> licensing the code under both licenses expressed by the OR operator. > >> > >> Hmm? > > > > Let me try clarifying this further, how about: > > > > copyleft-next-0.3.1 is explicitly compatible with GPLv2 (or later) and > > can therefore be used for kernel code. Despite this, if you use > > copyleft-next-0.3.1 on Linux, the recommended practice is to express > > dual licensing with GPL using in the SPDX license identifiers by > > using by the OR operator. > > 'using in the ..' ? > > and > > 'by using by' is off by one 'by' :) > > I'm not seeing how that clarifies stuff further. I might be biased, but > the version I suggested is crystal clear. Oh sorry, I didn't realize the paragraph you posted was a suggestion, I thought it was the one you were indicating needed further enhancement! I'll just take yours then. > >> > + To use the copyleft-next-0.3.1 license put the following SPDX tag/value > >> > + pair into a comment according to the placement guidelines in the > >> > + licensing rules documentation: > >> > + SPDX-License-Identifier: GPL-2.0 OR copyleft-next-0.3.1 > >> > + SPDX-License-Identifier: GPL-2.0-only OR copyleft-next 0.3.1 > >> > + SPDX-License-Identifier: GPL-2.0+ OR copyleft-next-0.3.1 > >> > + SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 > >> > >> Please don't propagate the GPL-2.0 and GPL-2.0+ tags. They are > >> outdated (still valid) in the SPDX spec, which reminds me that I should > >> update the relevant documentation... > > > > OK thanks for the recommendation, I'll leave it at: > > > > + SPDX-License-Identifier: GPL-2.0 OR copyleft-next-0.3.1 > > SPDX-License-Identifier: GPL-2.0-only OR copyleft-next-0.3.1 > > please. See my previous reply quoted above. > > > + SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 Sorry I hadn't had my coffee yet so I should only list: SPDX-License-Identifier: GPL-2.0-only OR copyleft-next 0.3.1 SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 Will do this on the next spin. Luis

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Bradley M. Kuhn 25 May '22

25 May '22

J Lovejoy wrote: > (And to give credit where credit is due, Bradley's input during that > challenging "negotiation" was very helpful. :) 😊 … thank you! I'd written today: >> 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” J Lovejoy replied: > 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. … but notwithstanding a clear definition of a moniker (which I agree indeed you've made for most SPDX identifiers), if that definition fails to adequately match historically understanding (and/or fails to take into account nuances in the document it represents), confusion ensues for users. Users *were* confused about “GPL-2.0” (remember, we did a small (admittedly non-scientific) survey at a session at a conference — FOSDEM I think it was?) Most SPDX *users* won't speak its defined terms fluently; I suspect most of Linux's licensors (and even most licensees) don't speak SPDX fluently, so presumably you want SPDX identifiers to have some intuitiveness — particularly for the use case of linux-spdx, which requires the identifiers to be *both* human-readable and machine-readable. This is relevant to the copyleft-next-0.3.1 identifier. SPDX could define “copyleft-next-0.3.1” to mean for SPDX purposes: “the text of copyleft-next without any options in its terms exercised/removed” (— although I note https://spdx.org/licenses/copyleft-next-0.3.1.html seems to be wholly silent regarding options exercising/removing). However, there is currently confusion — shown in the fact that Thomas still asked: >>>> If I want to remove this option, then how do I express this with a SPDX >>>> license identifier? Sigh! … upon noticing this part of copyleft-next: >>> + Unless I explicitly remove the option of Distributing Covered Works >>> + under Later Versions, You may Distribute Covered Works under any Later >>> + Version. Anyway, I'm pointing out SPDX's shortcomings on this point *not* to captiously admonish SPDX, but rather to point out that any issues with SPDX identifiers and their formal definitions shouldn't influence a decision about what licenses are acceptable for inclusion as dual-license options in Linux. Plus, I remain hopeful that over the long-term, the SPDX project will take feedback from efforts like linux-spdx to solve the kinds of problems that have come up in this thread and others. Finally, I've already started a sub-thread on the copyleft-next list to start discussing maybe the license (in future versions) shouldn't have this option anyway (for unrelated policy reasons). That might yield a side-benefit of making the problem evaporate entirely for SPDX. (Anyway, after 25 years of living with GPL's “-or-later vs. -only” mess — I, for one, am convinced new licenses like copyleft-next should try very hard to not repeat that mistake.) -- bkuhn

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Bradley M. Kuhn 25 May '22

25 May '22

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

1 1

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain 25 May '22

25 May '22

On Wed, May 25, 2022 at 07:05:31PM +0000, Bird, Tim wrote: > > -----Original Message----- > > From: Luis Chamberlain <mcgrof(a)infradead.org> On Behalf Of Luis Chamberlain > > > > On Wed, May 25, 2022 at 05:05:54PM +0000, Bird, Tim wrote: > > > I know it's being submitted as an OR, but I question > > > the value of introducing another license into the kernel's licensing mix. > > > > I agree that we want to keep the number of licenses as small as > > possible but we cannot really dictate which dual licensing options a > > submitter selects unless the license is GPL-2.0-only incompatible, > > which copyleft-next is not. > > Um, yes we can dictate that. The statement about us not being able to dictate which dual licensing options a submitter selects does not actually come from me, Thomas noted this [0]. [0] https://lkml.kernel.org/r/87fsl1iqg0.ffs@tglx > There were good reasons that the original > BSD dual-licenses were allowed. I helped spearhead some of that effort. > Those same reasons don't apply here. Correct, and I noted my own reasoning for now dual licensing with copyleft-next, which you seem to be disregarding? > Each license added to the kernel (even when added as an OR), requires > additional legal analysis. And I noted in my cover letter that copyleft-next-0.3.1 has been found to be to be GPLv2 compatible by three attorneys at SUSE and Redhat [1], but to err on the side of caution we simply recommend to always use the "OR" language for this license [2]. [1] https://lore.kernel.org/lkml/20170516232702.GL17314@wotan.suse.de/ [2] https://lkml.kernel.org/r/1495234558.7848.122.camel@linux.intel.com > And here's the thing. > The copyleft-next license has a number of legal issues that make it problematic. You say number of legal issues. > Not the least of which are that some of its terms are dependent on external > situations that can change over time, in a matter that is uncontrolled by either > the licensor or the licensee. In order to determine what terms are effective, you > have to know when the license was granted, and what the FSF and OSI approved > licenses were at various points in time. You literally have to use the Internet > Archive wayback machine, and do a bunch of research, to interpret the license terms. > It is not, as currently constructed, a good license, due to this lack of legal clarity. But the above seems to indicate one technical pain point in so far as two sections: 4. Condition Against Further Restrictions; Inbound License Compatibility 7. Nullification of Copyleft/Proprietary Dual Licensing If you are going to offer to pay for an alternative proprietary licensing, I'm sure you can do the work. And if in so far as clause 4 is concerned, yeah I think wayback machine is a sensible solution. Good idea, seems like we have that covered since 1999 [3]. [3] https://web.archive.org/web/*/https://opensource.org/licenses Luis

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain 25 May '22

25 May '22

On Wed, May 25, 2022 at 05:05:54PM +0000, Bird, Tim wrote: > I know it's being submitted as an OR, but I question > the value of introducing another license into the kernel's licensing mix. As a free software hacker *I* value the evolution of copyleft and copyleft-next does just that. Some may have thought that it may not have been possible to evolve copyleft and work with an evolved license on Linux, but copyleft-next shows it is possible. Here in lies the value I see in it. I agree that we want to keep the number of licenses as small as possible but we cannot really dictate which dual licensing options a submitter selects unless the license is GPL-2.0-only incompatible, which copyleft-next is not. Luis

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain 25 May '22

25 May '22

On Mon, May 23, 2022 at 11:10:37PM +0200, Thomas Gleixner wrote: > On Fri, Oct 29 2021 at 11:44, Luis Chamberlain wrote: > > preferred. A summary of benefits why projects outside of Linux might > > prefer to use copyleft-next >= 0.3.1 over GPLv2: > > > <snip> > > > > o copyleft-next has a 'built-in or-later' provision > > Not convinced that this is a benefit under all circumstances, I'll just drop it. > but that's > a philosopical problem. The real problem is this: > > +Valid-License-Identifier: copyleft-next-0.3.1 > > and Why is this an issue? > > +11. Later License Versions > > + > > + The Copyleft-Next Project may release new versions of copyleft-next, > > + designated by a distinguishing version number ("Later Versions"). > > + Unless I explicitly remove the option of Distributing Covered Works > > + under Later Versions, You may Distribute Covered Works under any Later > > + Version. > > If I want to remove this option, then how do I express this with a SPDX > license identifier? Good question, souinds like generic semantics for SPDX evolution? Luis

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain 25 May '22

25 May '22

On Mon, May 23, 2022 at 11:22:36PM +0200, Thomas Gleixner wrote: > On Fri, Oct 29 2021 at 11:44, Luis Chamberlain wrote: > > --- /dev/null > > +++ b/LICENSES/dual/copyleft-next-0.3.1 > > @@ -0,0 +1,237 @@ > > +Valid-License-Identifier: copyleft-next-0.3.1 > > +SPDX-URL: https://spdx.org/licenses/copyleft-next-0.3.1 > > +Usage-Guide: > > + This license can be used in code, it has been found to be GPLv2 compatible > > + by attorneys at Redhat and SUSE, however to air on the side of caution, > > air ? Hehe, thanks I'll fix in the next spin. > > + it's best to only use it together with a GPL2 compatible license using "OR". > > This paragraph is not really understandable for Joe Developer. > > copyleft-next-0.3.1 is explicitly compatible with GPLv2 (or later) and > can therefore be used for kernel code. Though the best and recommended > practice is to express this in the SPDX license identifier by > licensing the code under both licenses expressed by the OR operator. > > Hmm? Let me try clarifying this further, how about: copyleft-next-0.3.1 is explicitly compatible with GPLv2 (or later) and can therefore be used for kernel code. Despite this, if you use copyleft-next-0.3.1 on Linux, the recommended practice is to express dual licensing with GPL using in the SPDX license identifiers by using by the OR operator. > > + To use the copyleft-next-0.3.1 license put the following SPDX tag/value > > + pair into a comment according to the placement guidelines in the > > + licensing rules documentation: > > + SPDX-License-Identifier: GPL-2.0 OR copyleft-next-0.3.1 > > + SPDX-License-Identifier: GPL-2.0-only OR copyleft-next 0.3.1 > > + SPDX-License-Identifier: GPL-2.0+ OR copyleft-next-0.3.1 > > + SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 > > Please don't propagate the GPL-2.0 and GPL-2.0+ tags. They are > outdated (still valid) in the SPDX spec, which reminds me that I should > update the relevant documentation... OK thanks for the recommendation, I'll leave it at: + SPDX-License-Identifier: GPL-2.0 OR copyleft-next-0.3.1 + SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 Luis

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain 25 May '22

25 May '22

On Mon, May 23, 2022 at 11:27:34PM +0200, Thomas Gleixner wrote: > On Fri, Oct 29 2021 at 11:44, Luis Chamberlain wrote: > > + "FSF-Free" means classified as 'free' by the Free Software Foundation. > > + > > + "OSI-Approved" means approved as 'Open Source' by the Open Source > > + Initiative. > > copyleft-next is neither nor. Confused... The terms are used in two clauses: 4. Condition Against Further Restrictions; Inbound License Compatibility 7. Nullification of Copyleft/Proprietary Dual Licensing IANAL but at least as per my reading, in both cases it is used to refer to "other licenses", not itself, so I see no issue with that use. If there is an issue it would be nice to hear more details about it, so that perhaps new versions of the license can make this clearer somehow, if not already. Luis

1 0

Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Richard Fontana 24 May '22

24 May '22

On Mon, May 23, 2022 at 5:10 PM Thomas Gleixner <tglx(a)linutronix.de> wrote: > > On Fri, Oct 29 2021 at 11:44, Luis Chamberlain wrote: > > preferred. A summary of benefits why projects outside of Linux might > > prefer to use copyleft-next >= 0.3.1 over GPLv2: > > > <snip> > > > > o copyleft-next has a 'built-in or-later' provision > > Not convinced that this is a benefit under all circumstances, but that's > a philosopical problem. The real problem is this: > > > +Valid-License-Identifier: copyleft-next-0.3.1 > > and > > > +11. Later License Versions > > + > > + The Copyleft-Next Project may release new versions of copyleft-next, > > + designated by a distinguishing version number ("Later Versions"). > > + Unless I explicitly remove the option of Distributing Covered Works > > + under Later Versions, You may Distribute Covered Works under any Later > > + Version. > > If I want to remove this option, then how do I express this with a SPDX > license identifier? Probably off-topic but: I think as things currently stand in SPDX you would have to use an ad hoc LicenseRef- identifier to express the entirety of copyleft-next-0.3.1 coupled with an amendment that sort of strikes the later versions provision. This issue is also somewhat relevant: https://github.com/spdx/spdx-spec/issues/153 FWIW, built-in 'or-later' clauses are actually common in copyleft open source licenses; the GPL family is the oddity here. (Then again, the whole idea of a downstream license upgradability option is sort of unusual in the bigger scheme of things, but that's another topic.) Richard

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next May 2022