| Message ID | 20211029184500.2821444-2-mcgrof@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | test_sysfs: add new selftest for sysfs | expand |
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? Sigh! tglx
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 ? > + 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? > + 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... Thanks, tglx
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...
On Mon, May 23, 2022 at 5:10 PM Thomas Gleixner <tglx@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
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
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
> -----Original Message----- > From: Luis Chamberlain <mcgrof@infradead.org> On Behalf Of 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. I don't begrudge Luis his licensing choice, but one of the main reasons to stick with a well-known and reviewed license is to avoid kernel developers having to do license-vetting themselves. I know it's being submitted as an OR, but I question the value of introducing another license into the kernel's licensing mix. -- Tim
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
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
> -----Original Message----- > From: Luis Chamberlain <mcgrof@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. > > 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. Um, yes we can dictate that. There were good reasons that the original BSD dual-licenses were allowed. Those same reasons don't apply here. Each license added to the kernel (even when added as an OR), requires additional legal analysis. Corporate lawyers don't usually rely on the interpretation of novel licenses from external sources. They do it themselves. This means that hundreds of lawyers may find themselves reading and trying to interpret the copyleft-next license. And here's the thing. The copyleft-next license has a number of legal issues that make it problematic. 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. Regards, -- Tim
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
On Wed, May 25, 2022 at 07:05:31PM +0000, Bird, Tim wrote: > > -----Original Message----- > > From: Luis Chamberlain <mcgrof@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
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. >> > + 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 Thanks, tglx
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
Tim! On Wed, May 25 2022 at 19:05, Bird, Tim wrote: >> From: Luis Chamberlain <mcgrof@infradead.org> On Behalf Of Luis Chamberlain >> 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. No! > There were good reasons that the original BSD dual-licenses were > allowed. Those same reasons don't apply here. That's just wrong. The reason why dual licensing is allowed is to share code across licesce preferences. The very same reason applies here. > Each license added to the kernel (even when added as an OR), requires > additional legal analysis. Corporate lawyers don't usually rely on > the interpretation of novel licenses from external sources. They do > it themselves. This means that hundreds of lawyers may find > themselves reading and trying to interpret the copyleft-next license. It's none of our problems that corporate lawyers are obviously unable to act, cooperate and to agree on something. The license in question is around since 2016 and the kernel carries code under that license since 2017. So what the hell are you complaining 5 years after the fact? The whole point here is to convert this to SPDX identifiers. Aside of that I'm impressed by your chutzpah to make up an argument on corporate lawyer costs. Do you realize how much costs the very same crowd of corporate lawyers created by ill advising their employees to put corporate defined boiler plate into every other kernel source code file or by not advising them at all and let them add random crap? Do you realize that the costs to cleanup this mess have been mostly covered by community members with the help from a _very_ small subset of corporate lawyers? Do you realize that it's hilarious that your so costly corporate lawyers only need to react now that we are trying to convert licensing information to SPDX 5 years after the fact? Do you realize that the SPDX cleanup effort is reducing the costs for everyone including _all_ of the corporate lawyers you are so concerned of? Sure, complaining about your individual corporate costs is way simpler than: - contributing to community efforts to reduce those costs - acknowledging that the community efforts even without contribution or your particular organization are reducing those costs Try again. > And here's the thing. > The copyleft-next license has a number of legal issues that make it problematic. > 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. And here is the thing: Whether you consider it to be a good license or not, does not matter in this context. The license _IS_ GPLv2 compatible which is even understandable for mere mortals, i.e. non lawyers. That's the only relevant point for including code under this license into the kernel. Your way-back machine argument is beyond hilarious. Guess what the folks who try to cleanup the corporate lawyers induced mess in the kernel rely on? But that's absolutely not applicable to this problem. Why? The kernel has very strict rules for licensing today. Any valid SPDX tag in a source file has to be accompanied with a corresponding machine readable license file. This license file is version controlled and if there is a dependency on any other license in the context then the dependency is also available in the git history. So no, you do not need Internet archive for this at all simply because if the kernel git history vanishes from the planet then this particular licensing problem is the least of your worries. Maybe it's about time to move your corporate lawyers, who are caught in their own past sins, to the reality of today. Thanks, Thomas
J Lovejoy wrote: > (And to give credit where credit is due, Bradley's input during that > challenging "negotiation" was very helpful. :)
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
> -----Original Message----- > From: Thomas Gleixner <tglx@linutronix.de> > > Tim! > > On Wed, May 25 2022 at 19:05, Bird, Tim wrote: > >> From: Luis Chamberlain <mcgrof@infradead.org> On Behalf Of Luis Chamberlain > >> 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. > > No! Sorry for the delayed response. I was on vacation over memorial day weekend (holiday in the US.) I think that the option to reject a contribution based on its license should be available to the community, using criteria beyond those that Luis has mentioned (and that you mention below). I could create a license that was GPL-2.0-only compatible, and use it to cover a new contribution to the Linux kernel (in dual-license format), in order to get exposure for the license or to promote it. We could use the SPDX identifier "Tims-license-0.1". I think it would be fair for the community to reject a contribution based on those license circumstances, even though it met all the criteria you mention. I don't think that the Linux kernel should be used for license promotion, but if it is, then it should be used to promote GPL-v2-only. > > > There were good reasons that the original BSD dual-licenses were > > allowed. Those same reasons don't apply here. > > That's just wrong. The reason why dual licensing is allowed is to share > code across licesce preferences. The very same reason applies here. I was talking about why dual licensing was originally introduced, which was a situation different from what went on in 2016, when the copyleft-next dual license was discussed. Dual-licensing in the Linux kernel was originally introduced because code was being taken from BSD and placed into Linux (under GPL v2), often by someone other than the original author. This created a bit of hard feelings between the BSD community and the Linux community. So dual-licensing was introduced so that derivative works (created by Linux developers) of BSD code could flow back into the BSD project. This was code that existed before being introduced into Linux, and there was no notion of using the kernel to promote the BSD license. I have a problem with the statement: "The reason why dual licensing is allowed is to share code across license preferences. The very same reason applies here." I'm concerned about license proliferation, and that statement has no limiting principle. Although you do raise some limiting principles below, I don't think they are adequate. I don't think it should be the mission of the kernel to allow shared code across [any and all] license preferences. Just by way of example, I would hesitate to support the adoption into the kernel of any license that had an "or later" provision. That's true, even on the other side of an "OR" clause. Also, my preference would be to limit new licenses to OSI-approved licenses, which have already had extensive vetting. > > > Each license added to the kernel (even when added as an OR), requires > > additional legal analysis. Corporate lawyers don't usually rely on > > the interpretation of novel licenses from external sources. They do > > it themselves. This means that hundreds of lawyers may find > > themselves reading and trying to interpret the copyleft-next license. > > It's none of our problems that corporate lawyers are obviously unable to > act, cooperate and to agree on something. That's an over-generalization. > > The license in question is around since 2016 and the kernel carries > code under that license since 2017. > > So what the hell are you complaining 5 years after the fact? The whole > point here is to convert this to SPDX identifiers. I missed the original discussion, and the license was limited in application. I agree that my complaint is late, but this conversion to SPDX adds the license text to LICENSES, which IMHO makes this license stand out more than it has previously, and possibly provides an implied endorsement. I think it's a good thing to convert from the current language to an SPDX identifier. And that I'm late to the party with complaints about this particular license. But I'd rather not encourage developers to use this license going forward. > > Aside of that I'm impressed by your chutzpah to make up an argument on > corporate lawyer costs. Burden on corporate lawyers (and, dare I say, OSPO people like myself who deal in license training at our respective companies) has been a consideration in past discussions of contributions. The 2016 LKML thread about the original submission included discussion about the amount of "lawyer ink" required for different licensing constructs and development scenarios. For example, see https://lore.kernel.org/lkml/20170518221205.gcfs2t4ihlpx5kj6@thunk.org/#t > > Do you realize how much costs the very same crowd of corporate lawyers "very same crowd"? > created by ill advising their employees to put corporate defined > boiler plate into every other kernel source code file or by not > advising them at all and let them add random crap? I think we're talking about different sets of lawyers, so the rest of the complaint about some lawyers and the costs they've imposed on the kernel community I think is unrelated. > > Do you realize that the costs to cleanup this mess have been mostly > covered by community members with the help from a _very_ small subset > of corporate lawyers? > > Do you realize that it's hilarious that your so costly corporate > lawyers only need to react now that we are trying to convert licensing > information to SPDX 5 years after the fact? The fact that the conversion being discussed *now* may not yield an identical licensing situation seems to warrant some legal discussion. I assume Luis is on-board with the change in licensing situation due to the conversion, but I have yet to see the final patches. > > Do you realize that the SPDX cleanup effort is reducing the costs for > everyone including _all_ of the corporate lawyers you are so concerned > of? Yes. I'm supportive of using SPDX in the kernel, as are all the lawyers I work with. > > Sure, complaining about your individual corporate costs is way simpler > than: > > - contributing to community efforts to reduce those costs > > - acknowledging that the community efforts even without contribution > or your particular organization are reducing those costs > > Try again. Try what again? Communicating a preference on license proliferation? That's what this message is. > > > And here's the thing. > > The copyleft-next license has a number of legal issues that make it problematic. > > 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. > > And here is the thing: > > Whether you consider it to be a good license or not, does not matter > in this context. > > The license _IS_ GPLv2 compatible which is even understandable for > mere mortals, i.e. non lawyers. That's the only relevant point for > including code under this license into the kernel. I disagree. There are other relevant points if the kernel is being used to promote a license. I have made all my contributions to the Linux kernel (meager though they are) under GPL-v2-only. I think straying from this should be rare and well-justified. > > Your way-back machine argument is beyond hilarious. Guess what the > folks who try to cleanup the corporate lawyers induced mess in the > kernel rely on? But that's absolutely not applicable to this > problem. Why? > > The kernel has very strict rules for licensing today. Any valid > SPDX tag in a source file has to be accompanied with a > corresponding machine readable license file. > > This license file is version controlled and if there is a > dependency on any other license in the context then the > dependency is also available in the git history. > > So no, you do not need Internet archive for this at all simply > because if the kernel git history vanishes from the planet > then this particular licensing problem is the least of your > worries. I said that the textual terms of copyleft-next require the Internet archive to interpret. That's completely independent of what version control system you use to track the license and its application to the kernel. Linux kernel git logs are not going to tell you what the OSI and FSF-approved licenses were in 2016. > > Maybe it's about time to move your corporate lawyers, who are > caught in their own past sins, to the reality of today. *My* corporate lawyers and their "past sins"? I think you're taking actions by some lawyers and overgeneralizing them. It is not unheard-of to consider the cost in legal overhead in licensing considerations in the kernel. I believe Luis is working on an independent patch that isolates the SPDX conversion from the changes to the testing module code. As such, I'll give feedback on new patches going forward. Regards, -- Tim
On Thu, Jun 02, 2022 at 04:11:16AM +0000, Bird, Tim wrote: > > -----Original Message----- > > From: Thomas Gleixner <tglx@linutronix.de> > > > > Tim! > > > > On Wed, May 25 2022 at 19:05, Bird, Tim wrote: > > >> From: Luis Chamberlain <mcgrof@infradead.org> On Behalf Of Luis Chamberlain > > >> 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. > > > > No! > Sorry for the delayed response. I was on vacation over memorial day weekend > (holiday in the US.) > > I think that the option to reject a contribution based on its license should be > available to the community, using criteria beyond those that Luis has mentioned > (and that you mention below). > > I could create a license that was GPL-2.0-only compatible, and use it to cover a new > contribution to the Linux kernel (in dual-license format), in order to get exposure > for the license or to promote it. We could use the SPDX identifier "Tims-license-0.1". > I think it would be fair for the community to reject a contribution based > on those license circumstances, even though it met all the criteria you mention. > > I don't think that the Linux kernel should be used for license promotion, but if it is, > then it should be used to promote GPL-v2-only. I agree, and in a way, I feel like that is what is happening here for this original submission. See below for more... > > > There were good reasons that the original BSD dual-licenses were > > > allowed. Those same reasons don't apply here. > > > > That's just wrong. The reason why dual licensing is allowed is to share > > code across licesce preferences. The very same reason applies here. > > I was talking about why dual licensing was originally introduced, which was > a situation different from what went on in 2016, when the copyleft-next > dual license was discussed. > > Dual-licensing in the Linux kernel was originally introduced because code was being > taken from BSD and placed into Linux (under GPL v2), often by someone other than the > original author. This created a bit of hard feelings between the BSD community > and the Linux community. So dual-licensing was introduced so that derivative works > (created by Linux developers) of BSD code could flow back into the BSD project. > > This was code that existed before being introduced into Linux, and there was > no notion of using the kernel to promote the BSD license. I agree, dual licensed code that is added to the kernel is either done: - because the original code had a non-GPL license and it was added so that it could be compatible so that it could be added to Linux. - because the code being accepted into Linux can also be used in another non-Linux codebase now or in the future. The submission here was neither of these. It was to test core Linux kernel functionality that is ONLY GPL-v2. That functionality and interactions within the Linux core could never be used in any non-Linux project as it does not make any sense. Or if it could be used in a non-Linux project, that would only be if that project was also GPLv2 licensed as the kernel core code would have been copied out of Linux into that other project. I feel that the dual-license of this code is purely done to support an additional license and give it attention as it could never be invoked on this codebase due to the contents of it. Which makes it not necessary and has only distracted us from the real technical issues of why I rejected this code in the first place :( thanks, greg k-h
On Thu, Jun 02, 2022 at 04:11:16AM +0000, Bird, Tim wrote: > I don't think that the Linux kernel should be used for license promotion, but if it is, > then it should be used to promote GPL-v2-only. I already *used* copyleft-next on Linux on a dual licensed manner, the patches in question are about using SPDX to simpllify things and adaopt the SPDX annotations. And, to re-iterate once more, I'm using copyeft-next as that is *my* license of choice for *any* new software projects I use and I want to enable cross prolination between them. I have been doing this since I wrote CRDA many years ago. I have many reasons for using copyleft-next and I've listed many of the reasons why a free software developer would care to enable this cross polination but yet again you seem to be disregarding all that. This is similar to how 2-cluase BSD is compatible with the GPL and is used for cross polination to BSDs even though in practice a lot of that cross polination may not happen. There are practical uses here and I've been using this license for years now and I have no intention on stopping. Luis
On Thu, Jun 02, 2022 at 08:20:18AM +0200, gregkh@linuxfoundation.org wrote: > On Thu, Jun 02, 2022 at 04:11:16AM +0000, Bird, Tim wrote: > > I don't think that the Linux kernel should be used for license promotion, but if it is, > > then it should be used to promote GPL-v2-only. > > I agree, and in a way, I feel like that is what is happening here for > this original submission. See below for more... I have been using copyleft-next for years and cross polination for me is real. > I agree, dual licensed code that is added to the kernel is either done: > - because the original code had a non-GPL license and it was > added so that it could be compatible so that it could be added > to Linux. > - because the code being accepted into Linux can also be used in > another non-Linux codebase now or in the future. Sometimes such cross polination is purely speculative, but we don't stop and ask people for evidence of this. You forgot that another reason is because some attorneys like some permissive license more. That's it. The Clear BSD license is an example. In that case it was a new license to Linux. So let us be clear that one could argue that was a bit of license promotion. > The submission here was neither of these. You are incorrect. I have a vision for Linux kernel testing and I have put *years* of effort in this regard and thinking about architecture behind all this. So yes cross polination is *extremely* important to me and hence some of this effort. Luis
diff --git a/LICENSES/dual/copyleft-next-0.3.1 b/LICENSES/dual/copyleft-next-0.3.1 new file mode 100644 index 000000000000..086bcb74b478 --- /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, + it's best to only use it together with a GPL2 compatible license using "OR". + 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 +License-Text: + +======================================================================= + + copyleft-next 0.3.1 ("this License") + Release date: 2016-04-29 + +1. License Grants; No Trademark License + + Subject to the terms of this License, I grant You: + + a) A non-exclusive, worldwide, perpetual, royalty-free, irrevocable + copyright license, to reproduce, Distribute, prepare derivative works + of, publicly perform and publicly display My Work. + + b) A non-exclusive, worldwide, perpetual, royalty-free, irrevocable + patent license under Licensed Patents to make, have made, use, sell, + offer for sale, and import Covered Works. + + This License does not grant any rights in My name, trademarks, service + marks, or logos. + +2. Distribution: General Conditions + + You may Distribute Covered Works, provided that You (i) inform + recipients how they can obtain a copy of this License; (ii) satisfy the + applicable conditions of sections 3 through 6; and (iii) preserve all + Legal Notices contained in My Work (to the extent they remain + pertinent). "Legal Notices" means copyright notices, license notices, + license texts, and author attributions, but does not include logos, + other graphical images, trademarks or trademark legends. + +3. Conditions for Distributing Derived Works; Outbound GPL Compatibility + + If You Distribute a Derived Work, You must license the entire Derived + Work as a whole under this License, with prominent notice of such + licensing. This condition may not be avoided through such means as + separate Distribution of portions of the Derived Work. + + If the Derived Work includes material licensed under the GPL, You may + instead license the Derived Work under the GPL. + +4. Condition Against Further Restrictions; Inbound License Compatibility + + When Distributing a Covered Work, You may not impose further + restrictions on the exercise of rights in the Covered Work granted under + this License. This condition is not excused merely because such + restrictions result from Your compliance with conditions or obligations + extrinsic to this License (such as a court order or an agreement with a + third party). + + However, You may Distribute a Covered Work incorporating material + governed by a license that is both OSI-Approved and FSF-Free as of the + release date of this License, provided that compliance with such + other license would not conflict with any conditions stated in other + sections of this License. + +5. Conditions for Distributing Object Code + + You may Distribute an Object Code form of a Covered Work, provided that + you accompany the Object Code with a URL through which the Corresponding + Source is made available, at no charge, by some standard or customary + means of providing network access to source code. + + If you Distribute the Object Code in a physical product or tangible + storage medium ("Product"), the Corresponding Source must be available + through such URL for two years from the date of Your most recent + Distribution of the Object Code in the Product. However, if the Product + itself contains or is accompanied by the Corresponding Source (made + available in a customarily accessible manner), You need not also comply + with the first paragraph of this section. + + Each direct and indirect recipient of the Covered Work from You is an + intended third-party beneficiary of this License solely as to this + section 5, with the right to enforce its terms. + +6. Symmetrical Licensing Condition for Upstream Contributions + + If You Distribute a work to Me specifically for inclusion in or + modification of a Covered Work (a "Patch"), and no explicit licensing + terms apply to the Patch, You license the Patch under this License, to + the extent of Your copyright in the Patch. This condition does not + negate the other conditions of this License, if applicable to the Patch. + +7. Nullification of Copyleft/Proprietary Dual Licensing + + If I offer to license, for a fee, a Covered Work under terms other than + a license that is OSI-Approved or FSF-Free as of the release date of this + License or a numbered version of copyleft-next released by the + Copyleft-Next Project, then the license I grant You under section 1 is no + longer subject to the conditions in sections 3 through 5. + +8. Copyleft Sunset + + The conditions in sections 3 through 5 no longer apply once fifteen + years have elapsed from the date of My first Distribution of My Work + under this License. + +9. Pass-Through + + When You Distribute a Covered Work, the recipient automatically receives + a license to My Work from Me, subject to the terms of this License. + +10. Termination + + Your license grants under section 1 are automatically terminated if You + + a) fail to comply with the conditions of this License, unless You cure + such noncompliance within thirty days after becoming aware of it, or + + b) initiate a patent infringement litigation claim (excluding + declaratory judgment actions, counterclaims, and cross-claims) + alleging that any part of My Work directly or indirectly infringes + any patent. + + Termination of Your license grants extends to all copies of Covered + Works You subsequently obtain. Termination does not terminate the + rights of those who have received copies or rights from You subject to + this License. + + To the extent permission to make copies of a Covered Work is necessary + merely for running it, such permission is not terminable. + +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. + +** 12. No Warranty ** +** ** +** My Work is provided "as-is", without warranty. You bear the risk ** +** of using it. To the extent permitted by applicable law, each ** +** Distributor of My Work excludes the implied warranties of title, ** +** merchantability, fitness for a particular purpose and ** +** non-infringement. ** + +** 13. Limitation of Liability ** +** ** +** To the extent permitted by applicable law, in no event will any ** +** Distributor of My Work be liable to You for any damages ** +** whatsoever, whether direct, indirect, special, incidental, or ** +** consequential damages, whether arising under contract, tort ** +** (including negligence), or otherwise, even where the Distributor ** +** knew or should have known about the possibility of such damages. ** + +14. Severability + + The invalidity or unenforceability of any provision of this License + does not affect the validity or enforceability of the remainder of + this License. Such provision is to be reformed to the minimum extent + necessary to make it valid and enforceable. + +15. Definitions + + "Copyleft-Next Project" means the project that maintains the source + code repository at <https://github.com/copyleft-next/copyleft-next.git/> + as of the release date of this License. + + "Corresponding Source" of a Covered Work in Object Code form means (i) + the Source Code form of the Covered Work; (ii) all scripts, + instructions and similar information that are reasonably necessary for + a skilled developer to generate such Object Code from the Source Code + provided under (i); and (iii) a list clearly identifying all Separate + Works (other than those provided in compliance with (ii)) that were + specifically used in building and (if applicable) installing the + Covered Work (for example, a specified proprietary compiler including + its version number). Corresponding Source must be machine-readable. + + "Covered Work" means My Work or a Derived Work. + + "Derived Work" means a work of authorship that copies from, modifies, + adapts, is based on, is a derivative work of, transforms, translates or + contains all or part of My Work, such that copyright permission is + required. The following are not Derived Works: (i) Mere Aggregation; + (ii) a mere reproduction of My Work; and (iii) if My Work fails to + explicitly state an expectation otherwise, a work that merely makes + reference to My Work. + + "Distribute" means to distribute, transfer or make a copy available to + someone else, such that copyright permission is required. + + "Distributor" means Me and anyone else who Distributes a Covered Work. + + "FSF-Free" means classified as 'free' by the Free Software Foundation. + + "GPL" means a version of the GNU General Public License or the GNU + Affero General Public License. + + "I"/"Me"/"My" refers to the individual or legal entity that places My + Work under this License. "You"/"Your" refers to the individual or legal + entity exercising rights in My Work under this License. A legal entity + includes each entity that controls, is controlled by, or is under + common control with such legal entity. "Control" means (a) the power to + direct the actions of such legal entity, whether by contract or + otherwise, or (b) ownership of more than fifty percent of the + outstanding shares or beneficial ownership of such legal entity. + + "Licensed Patents" means all patent claims licensable royalty-free by + Me, now or in the future, that are necessarily infringed by making, + using, or selling My Work, and excludes claims that would be infringed + only as a consequence of further modification of My Work. + + "Mere Aggregation" means an aggregation of a Covered Work with a + Separate Work. + + "My Work" means the particular work of authorship I license to You + under this License. + + "Object Code" means any form of a work that is not Source Code. + + "OSI-Approved" means approved as 'Open Source' by the Open Source + Initiative. + + "Separate Work" means a work that is separate from and independent of a + particular Covered Work and is not by its nature an extension or + enhancement of the Covered Work, and/or a runtime library, standard + library or similar component that is used to generate an Object Code + form of a Covered Work. + + "Source Code" means the preferred form of a work for making + modifications to it.
Add the full text of the copyleft-next-0.3.1 license to the kernel tree as well as the required tags for reference and tooling. The license text was copied directly from the copyleft-next project's git tree [0]. Discussion of using copyleft-next-0.3.1 on Linux started since June, 2016 [1]. In the end Linus' preference was to have drivers use MODULE_LICENSE("GPL") to make it clear that the GPL applies when it comes to Linux [2]. Additionally, even though copyleft-next-0.3.1 has been found to be to be GPLv2 compatible by three attorneys at SUSE and Redhat [3], to err on the side of caution we simply recommend to always use the "OR" language for this license [4]. Even though it has been a goal of the project to be GPL-v2 compatible to be certain in 2016 I asked for a clarification about what makes copyleft-next GPLv2 compatible and also asked for a summary of benefits. This prompted some small minor changes to make compatibility even further clear and as of copyleft 0.3.1 compatibility should be crystal clear [5]. The summary of why copyleft-next 0.3.1 is compatible with GPLv2 is explained as follows: Like GPLv2, copyleft-next requires distribution of derivative works ("Derived Works" in copyleft-next 0.3.x) to be under the same license. Ordinarily this would make the two licenses incompatible. However, copyleft-next 0.3.1 says: "If the Derived Work includes material licensed under the GPL, You may instead license the Derived Work under the GPL." "GPL" is defined to include GPLv2. In practice this means copyleft-next code in Linux may be licensed under the GPL2, however there are additional obvious gains for bringing contributions from Linux outbound where copyleft-next is preferred. A summary of benefits why projects outside of Linux might prefer to use copyleft-next >= 0.3.1 over GPLv2: o It is much shorter and simpler o It has an explicit patent license grant, unlike GPLv2 o Its notice preservation conditions are clearer o More free software/open source licenses are compatible with it (via section 4) o The source code requirement triggered by binary distribution is much simpler in a procedural sense o Recipients potentially have a contract claim against distributors who are noncompliant with the source code requirement o There is a built-in inbound=outbound policy for upstream contributions (cf. Apache License 2.0 section 5) o There are disincentives to engage in the controversial practice of copyleft/ proprietary dual-licensing o In 15 years copyleft expires, which can be advantageous for legacy code o There are explicit disincentives to bringing patent infringement claims accusing the licensed work of infringement (see 10b) o There is a cure period for licensees who are not compliant with the license (there is no cure opportunity in GPLv2) o copyleft-next has a 'built-in or-later' provision The first driver submission to Linux under this dual strategy was lib/test_sysctl.c through commit 9308f2f9e7f05 ("test_sysctl: add dedicated proc sysctl test driver") merged in July 2017. Shortly after that I also added test_kmod through commit d9c6a72d6fa29 ("kmod: add test driver to stress test the module loader") in the same month. These two drivers went in just a few months before the SPDX license practice kicked in. In 2018 Kuno Woudt went through the process to get SPDX identifiers for copyleft-next [6] [7]. Although there are SPDX tags for copyleft-next-0.3.0, we only document use in Linux starting from copyleft-next-0.3.1 which makes GPLv2 compatibility crystal clear. This patch will let us update the two Linux selftest drivers in subsequent patches with their respective SPDX license identifiers and let us remove repetitive license boiler plate. [0] https://github.com/copyleft-next/copyleft-next/blob/master/Releases/copyleft-next-0.3.1 [1] https://lore.kernel.org/lkml/1465929311-13509-1-git-send-email-mcgrof@kernel.org/ [2] https://lore.kernel.org/lkml/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aKLsOu0Og@mail.gmail.com/ [3] https://lore.kernel.org/lkml/20170516232702.GL17314@wotan.suse.de/ [4] https://lkml.kernel.org/r/1495234558.7848.122.camel@linux.intel.com [5] https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOCT4UVNOOCRGBN2UJIKHZ [6] https://spdx.org/licenses/copyleft-next-0.3.0.html [7] https://spdx.org/licenses/copyleft-next-0.3.1.html Cc: Goldwyn Rodrigues <rgoldwyn@suse.com> Cc: Kuno Woudt <kuno@frob.nl> Cc: Richard Fontana <fontana@sharpeleven.org> Cc: copyleft-next@lists.fedorahosted.org Cc: Ciaran Farrell <Ciaran.Farrell@suse.com> Cc: Christopher De Nicolo <Christopher.DeNicolo@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thorsten Leemhuis <linux@leemhuis.info> Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> --- LICENSES/dual/copyleft-next-0.3.1 | 237 ++++++++++++++++++++++++++++++ 1 file changed, 237 insertions(+) create mode 100644 LICENSES/dual/copyleft-next-0.3.1