OSI submission
by Richard Fontana
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
1 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Bradley M. Kuhn
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Bradley M. Kuhn
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by 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.
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Luis Chamberlain
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 year, 4 months
Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license
by Richard Fontana
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 year, 4 months