This adds the copyleft-next-0.3.1 SPDX tag and replaces existing boilerplate with the tag.
Luis Chamberlain (2): LICENSES: Add the copyleft-next-0.3.1 license testing: use the copyleft-next-0.3.1 SPDX tag
LICENSES/dual/copyleft-next-0.3.1 | 237 +++++++++++++++++++++++ lib/test_kmod.c | 12 +- lib/test_sysctl.c | 12 +- tools/testing/selftests/kmod/kmod.sh | 13 +- tools/testing/selftests/sysctl/sysctl.sh | 12 +- 5 files changed, 241 insertions(+), 45 deletions(-) create mode 100644 LICENSES/dual/copyleft-next-0.3.1
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... [1] https://lore.kernel.org/lkml/1465929311-13509-1-git-send-email-mcgrof@kernel... [2] https://lore.kernel.org/lkml/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aKLsO... [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.fedorahoste... [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 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
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.
Two selftests drivers exist under the copyleft-next license. These drivers were added prior to SPDX practice taking full swing in the kernel. Now that we have an SPDX tag for copylef-next-0.3.1 documented, embrace it and remove the boiler plate.
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 Signed-off-by: Luis Chamberlain mcgrof@kernel.org --- lib/test_kmod.c | 12 +----------- lib/test_sysctl.c | 12 +----------- tools/testing/selftests/kmod/kmod.sh | 13 +------------ tools/testing/selftests/sysctl/sysctl.sh | 12 +----------- 4 files changed, 4 insertions(+), 45 deletions(-)
diff --git a/lib/test_kmod.c b/lib/test_kmod.c index ce1589391413..d62afd89dc63 100644 --- a/lib/test_kmod.c +++ b/lib/test_kmod.c @@ -1,18 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 /* * kmod stress test driver * * Copyright (C) 2017 Luis R. Rodriguez mcgrof@kernel.org - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the Free - * Software Foundation; either version 2 of the License, or at your option any - * later version; or, when distributed separately from the Linux kernel or - * when incorporated into other software packages, subject to the following - * license: - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of copyleft-next (version 0.3.1 or later) as published - * at http://copyleft-next.org/. */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c index 3750323973f4..9e5bd10a930a 100644 --- a/lib/test_sysctl.c +++ b/lib/test_sysctl.c @@ -1,18 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 /* * proc sysctl test driver * * Copyright (C) 2017 Luis R. Rodriguez mcgrof@kernel.org - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the Free - * Software Foundation; either version 2 of the License, or at your option any - * later version; or, when distributed separately from the Linux kernel or - * when incorporated into other software packages, subject to the following - * license: - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of copyleft-next (version 0.3.1 or later) as published - * at http://copyleft-next.org/. */
/* diff --git a/tools/testing/selftests/kmod/kmod.sh b/tools/testing/selftests/kmod/kmod.sh index afd42387e8b2..7189715d7960 100755 --- a/tools/testing/selftests/kmod/kmod.sh +++ b/tools/testing/selftests/kmod/kmod.sh @@ -1,18 +1,7 @@ #!/bin/bash -# +# SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 # Copyright (C) 2017 Luis R. Rodriguez mcgrof@kernel.org # -# This program is free software; you can redistribute it and/or modify it -# under the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 of the License, or at your option any -# later version; or, when distributed separately from the Linux kernel or -# when incorporated into other software packages, subject to the following -# license: -# -# This program is free software; you can redistribute it and/or modify it -# under the terms of copyleft-next (version 0.3.1 or later) as published -# at http://copyleft-next.org/. - # This is a stress test script for kmod, the kernel module loader. It uses # test_kmod which exposes a series of knobs for the API for us so we can # tweak each test in userspace rather than in kernelspace. diff --git a/tools/testing/selftests/sysctl/sysctl.sh b/tools/testing/selftests/sysctl/sysctl.sh index 19515dcb7d04..2046c603a4d4 100755 --- a/tools/testing/selftests/sysctl/sysctl.sh +++ b/tools/testing/selftests/sysctl/sysctl.sh @@ -1,16 +1,6 @@ #!/bin/bash +# SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1 # Copyright (C) 2017 Luis R. Rodriguez mcgrof@kernel.org -# -# This program is free software; you can redistribute it and/or modify it -# under the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 of the License, or at your option any -# later version; or, when distributed separately from the Linux kernel or -# when incorporated into other software packages, subject to the following -# license: -# -# This program is free software; you can redistribute it and/or modify it -# under the terms of copyleft-next (version 0.3.1 or later) as published -# at http://copyleft-next.org/.
# This performs a series tests against the proc sysctl interface.
On Wed, Jul 07, 2021 at 11:43:08AM -0700, Luis Chamberlain wrote:
This adds the copyleft-next-0.3.1 SPDX tag and replaces existing boilerplate with the tag.
Why do we need a random weirdo license in the kernel tree? Is there any benefit? If so it needs to be clearly spelled out.
On Thu, Jul 08, 2021 at 06:14:46AM +0200, Christoph Hellwig wrote:
On Wed, Jul 07, 2021 at 11:43:08AM -0700, Luis Chamberlain wrote:
This adds the copyleft-next-0.3.1 SPDX tag and replaces existing boilerplate with the tag.
Why do we need a random weirdo license in the kernel tree?
Its already present in the kernel. This patch just adds the respective SPDX license tag so we can remove the boiler plate.
Is there any benefit? If so it needs to be clearly spelled out.
The benefits are described in the first patch, I hope that's clear enough. Let me know if its not!
Luis
On Wed, Jul 07, 2021 at 11:43:08AM -0700, Luis Chamberlain wrote:
This adds the copyleft-next-0.3.1 SPDX tag and replaces existing boilerplate with the tag.
Luis Chamberlain (2): LICENSES: Add the copyleft-next-0.3.1 license testing: use the copyleft-next-0.3.1 SPDX tag
LICENSES/dual/copyleft-next-0.3.1 | 237 +++++++++++++++++++++++ lib/test_kmod.c | 12 +- lib/test_sysctl.c | 12 +- tools/testing/selftests/kmod/kmod.sh | 13 +- tools/testing/selftests/sysctl/sysctl.sh | 12 +-
As we only have 4 usages of this license in the tree, we have the opportunity to actually remove it and keep the list of licenses that we use in the kernel source smaller.
Any chance you wish to just change the license of these files, given that you are the only one that has tried to use it for kernel code?
As a follow-up to this, I do not want to see your "test_sysfs.c" module as a dual-licensed file, as that makes no sense whatsoever. It is directly testing GPL-v2-only code, so the attempt to dual license it makes no sense to me. How could anyone take that code and do anything with it under the copyleft-next license only? And where would that happen?
I understand the appeal of copyleft-next in that it resolves many of the "grey" areas around gplv2, but given that no one is rushing to advise us to relicense all of the kernel with this thing, there is no need to encourage the spread of it given the added complexity and confusion that adding another license to our mix can only cause.
So please, no, I don't want to see new licenses added to the tree, if anything we should be trimming them down to be less as it makes things simpler and more obvious.
thanks,
greg k-h
[ Full Disclosure: I've written parts of copyleft-next, have been involved with the initiative basically since its inception, and obviously I like the license a lot. Take my comments with the recommend dose NaCl granules those facts require. ]
Greg KH wrote:
Any chance you wish to just change the license of these files, given that you are the only one that has tried to use it for kernel code?
There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in Linux. Many corporate copyright holders have well documented strong reasons for wanting that. (Those policy goals and the analysis behind them, I find problematic and sometimes outright wrong, but nonetheless it's their right to license their copyrights that way, and the license *is* GPLv2-only compatible, as is Luis'!).
I assume that you're not asking those companies to relicense to pure GPLv2-only. While those companies perhaps faced early resistance when they began their dual-licensing-in-upstream endeavor, it was ultimately accepted and that opens the door, IMO, to accepting any form of GPL-compatible dual-licensing upstream. There is no cogent argument that I can see that says “(GPLv2-only|{2,3}-Clause-BSD) is so special that it should be grandfathered in over other forms of dual licensing”.
(Ironically, IIRC, (then acting on behalf of Qualcomm/Atheros, Luis — the person proposing the (GPLv2-only|copyleft-next) dual-licensing *now* was a champion of upstreaming (GPLv2-only|{2,3}-Clause-BSD) code years ago before it was a wide and common practice.)
As a follow-up to this, I do not want to see your "test_sysfs.c" module as a dual-licensed file, as that makes no sense whatsoever. It is directly testing GPL-v2-only code, so the attempt to dual license it makes no sense to me. How could anyone take that code and do anything with it under the copyleft-next license only? And where would that happen?
But, it's a valid compatible license, so there is no harm. And, see below, regarding policy reasons …
I understand the appeal of copyleft-next in that it resolves many of the "grey" areas around gplv2, but given that no one is rushing to advise us to relicense all of the kernel with this thing,
Consider me to be the first to advise that! I realize it's a tough thing to do, but every great adventure to solve a big problem starts with a first step! I further realize it's a non-starter, but please don't say again no one has advised you such!
BTW, the only reason I didn't advise it because I know a top-level license change away from straight, no-exceptions/no-additional-permissions GPLv2-only is a non-starter for the Linux community. (Great, BTW, that you've stuck so firmly to your steadfast plan on this!)
Greg continued:
there is no need to encourage the spread of it given the added complexity and confusion that adding another license to our mix can only cause.
Relatedly, Christoph asked (footnote mine):
Why do we need a random weirdo [0] license in the kernel tree? Is there any benefit?
To be frank, we in the copyleft-next community were very excited to learn that such dual-licensed code had been added to upstream Linux, back when it was many years ago. It's a vote of confidence from a well-known developer who really is excited about our policy goals. FOSS licensing isn't just about simplicity and cleanliness. Like budgets, which seem dry topics on surface, they are actual moral documents that make a statement about the philosophy and aspirations for software freedom by the licensor. Of course, we all know it's completely symbolic to dual license (GPLv2-only|copyleft-next), just like it's purely symbolic to dual license (GPLv2-only|2-Clause-BSD) upstream [1]. But it makes a statement that I think is a good one.
Finally, while GPLv2-only compatibility has been a mainstay so far in copyleft-next drafting, it's not clear to me that we can keep that compatibility forever and reach copyleft-next's policy goals. There's been no discussion of this yet, but it's certainly in the realm of possibility. If GPLv2-incompatibility ultimately happens in future copyleft-next versions, having dual-licensed code out there will be a huge help as it will assure that code can forever be used both on GPLv2-only and copyleft-next sides of future single-license-project equations.
Thanks for listening; of course it's the sole prerogative for the copyright holder to decide whether to change the license of their code or not, and I hope that they don't bow to pressure, just as Qualcomm wouldn't bow to pressure if you started asking them to stop dual licensing all their upstream Linux code under BSD licenses.
[0] BTW, Christoph, I remember when I started in FOSS in the early 1990s, everyone called the GPL a “random weirdo license”. The incumbent always seems not as random and weirdo as the challenger.
[1] There is the argument that 2-Clause-BSD has fewer requirements than GPLv2-only; however, that's not an argument to release the code *upstream* that way, it's an argument to release a separate version under 2-Clause-BSD.
-- Bradley M. Kuhn - he/him
Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Thu, Jul 08, 2021 at 07:59:13AM -0700, Bradley M. Kuhn wrote:
Greg KH wrote:
Any chance you wish to just change the license of these files, given that you are the only one that has tried to use it for kernel code?
There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in Linux. Many corporate copyright holders have well documented strong reasons for wanting that. (Those policy goals and the analysis behind them, I find problematic and sometimes outright wrong, but nonetheless it's their right to license their copyrights that way, and the license *is* GPLv2-only compatible, as is Luis'!).
I assume that you're not asking those companies to relicense to pure GPLv2-only.
On the contrary, I have stated in public many times to companies that try to add dual-licensed new kernel code that they should only do so if they provide a really good reason, and pushed back on them numerous times. See the mailing list archives for details if you care.
So yes, I am asking them, this is not anything new.
Let's keep it simple please, and not add new licenses for no real good reason if at all possible.
thanks,
greg k-h
On Thu, 2021-07-08 at 17:32 +0200, Greg KH wrote:
On Thu, Jul 08, 2021 at 07:59:13AM -0700, Bradley M. Kuhn wrote:
Greg KH wrote:
Any chance you wish to just change the license of these files, given that you are the only one that has tried to use it for kernel code?
There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in Linux. Many corporate copyright holders have well documented strong reasons for wanting that. (Those policy goals and the analysis behind them, I find problematic and sometimes outright wrong, but nonetheless it's their right to license their copyrights that way, and the license *is* GPLv2-only compatible, as is Luis'!).
I assume that you're not asking those companies to relicense to pure GPLv2-only.
On the contrary, I have stated in public many times to companies that try to add dual-licensed new kernel code that they should only do so if they provide a really good reason, and pushed back on them numerous times. See the mailing list archives for details if you care.
So yes, I am asking them, this is not anything new.
Let's keep it simple please, and not add new licenses for no real good reason if at all possible.
You can ask but it's the submitter's choice to license their code however they desire.
Greg KH wrote:
Let's keep it simple please, and not add new licenses for no real good reason if at all possible.
I've stated a number of real good reasons to keep copyleft-next as a dual-licensing option; they seem to have not been refuted here. Indeed, this point is quite salient:
Joe Perches wrote:
You can ask but it's the submitter's choice to license their code however they desire.
… to which I'd add, as long as the license is GPLv2-only-compatible, which of course (GPLv2-only|copyleft-next) is.
Rest is admittedly a bit OT:
Greg also noted:
I have stated in public many times to companies that try to add dual-licensed new kernel code that they should only do so if they provide a really good reason
We can agree to disagree on the differences in how company vs. individual requests and their "good reasons" are handled/prioritized; I think we'd both agree it's actually moot anyway. While it's an important topic, I apologize for raising that as it was off-topic to the issue at hand.
On that off-topic point, Tim Bird added:
It's not at all purely symbolic to dual license (GPLv2-only|2-Clause-BSD). That dual-licensing has allowed the interchange of a lot of code between the BSD Unixes and Linux, that otherwise would not have happened.
This is a good point, but the same argument is of course valid for copyleft-next-licensed projects. While there are currently fewer than those than BSD-ish projects, I don't think Linux should stand on ceremony of “your project must be this tall to ride this ride” and share code with us … and then there are the aspirational arguments that I made in my prior email. -- Bradley M. Kuhn - he/him
Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Thu, 8 Jul 2021 10:52:54 -0700 "Bradley M. Kuhn" bkuhn@ebb.org wrote:
Joe Perches wrote:
You can ask but it's the submitter's choice to license their code however they desire.
… to which I'd add, as long as the license is GPLv2-only-compatible, which of course (GPLv2-only|copyleft-next) is.
I agree with Joe on this, but I have to ask; What happens when someone makes a change to this file? The default kernel license is GPL-v2. Does this change automatically become the same as the file itself, or is the new change under the dual license?
I've made changes to code that had a dual license that wasn't GPL compatible, and the company involved asked me to sign off on the other license (which I did).
-- Steve
On Thu, Jul 08, 2021 at 03:01:58PM -0400, Steven Rostedt wrote:
On Thu, 8 Jul 2021 10:52:54 -0700 "Bradley M. Kuhn" bkuhn@ebb.org wrote:
Joe Perches wrote:
You can ask but it's the submitter's choice to license their code however they desire.
… to which I'd add, as long as the license is GPLv2-only-compatible, which of course (GPLv2-only|copyleft-next) is.
I agree with Joe on this, but I have to ask; What happens when someone makes a change to this file? The default kernel license is GPL-v2. Does this change automatically become the same as the file itself, or is the new change under the dual license?
I've made changes to code that had a dual license that wasn't GPL compatible, and the company involved asked me to sign off on the other license (which I did).
The Signed-off-by tag implies you are making a contribution under the same license as the license file states. The more people are aware of this fact, the better, and its then why we made DCO a public thing and now other projects embrace it.
Luis
On Thu, 8 Jul 2021 12:37:46 -0700 Luis Chamberlain mcgrof@kernel.org wrote:
The Signed-off-by tag implies you are making a contribution under the same license as the license file states. The more people are aware of this fact, the better, and its then why we made DCO a public thing and now other projects embrace it.
Ah, I forgot it was "per-file" and not "per-project". That's the difference.
-- Steve
-----Original Message----- From: Bradley M. Kuhn bkuhn@ebb.org
[ Full Disclosure: I've written parts of copyleft-next, have been involved with the initiative basically since its inception, and obviously I like the license a lot. Take my comments with the recommend dose NaCl granules those facts require. ]
Greg KH wrote:
Any chance you wish to just change the license of these files, given that you are the only one that has tried to use it for kernel code?
There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in Linux. Many corporate copyright holders have well documented strong reasons for wanting that. (Those policy goals and the analysis behind them, I find problematic and sometimes outright wrong, but nonetheless it's their right to license their copyrights that way, and the license *is* GPLv2-only compatible, as is Luis'!).
I assume that you're not asking those companies to relicense to pure GPLv2-only. While those companies perhaps faced early resistance when they began their dual-licensing-in-upstream endeavor, it was ultimately accepted and that opens the door, IMO, to accepting any form of GPL-compatible dual-licensing upstream. There is no cogent argument that I can see that says “(GPLv2-only|{2,3}-Clause-BSD) is so special that it should be grandfathered in over other forms of dual licensing”.
(Ironically, IIRC, (then acting on behalf of Qualcomm/Atheros, Luis — the person proposing the (GPLv2-only|copyleft-next) dual-licensing *now* was a champion of upstreaming (GPLv2-only|{2,3}-Clause-BSD) code years ago before it was a wide and common practice.)
As a follow-up to this, I do not want to see your "test_sysfs.c" module as a dual-licensed file, as that makes no sense whatsoever. It is directly testing GPL-v2-only code, so the attempt to dual license it makes no sense to me. How could anyone take that code and do anything with it under the copyleft-next license only? And where would that happen?
But, it's a valid compatible license, so there is no harm. And, see below, regarding policy reasons …
I understand the appeal of copyleft-next in that it resolves many of the "grey" areas around gplv2, but given that no one is rushing to advise us to relicense all of the kernel with this thing,
Consider me to be the first to advise that! I realize it's a tough thing to do, but every great adventure to solve a big problem starts with a first step! I further realize it's a non-starter, but please don't say again no one has advised you such!
BTW, the only reason I didn't advise it because I know a top-level license change away from straight, no-exceptions/no-additional-permissions GPLv2-only is a non-starter for the Linux community. (Great, BTW, that you've stuck so firmly to your steadfast plan on this!)
Greg continued:
there is no need to encourage the spread of it given the added complexity and confusion that adding another license to our mix can only cause.
Relatedly, Christoph asked (footnote mine):
Why do we need a random weirdo [0] license in the kernel tree? Is there any benefit?
To be frank, we in the copyleft-next community were very excited to learn that such dual-licensed code had been added to upstream Linux, back when it was many years ago. It's a vote of confidence from a well-known developer who really is excited about our policy goals. FOSS licensing isn't just about simplicity and cleanliness. Like budgets, which seem dry topics on surface, they are actual moral documents that make a statement about the philosophy and aspirations for software freedom by the licensor. Of course, we all know it's completely symbolic to dual license (GPLv2-only|copyleft-next), just like it's purely symbolic to dual license (GPLv2-only|2-Clause-BSD) upstream [1].
It's not at all purely symbolic to dual license (GPLv2-only|2-Clause-BSD). That dual-licensing has allowed the interchange of a lot of code between the BSD Unixes and Linux, that otherwise would not have happened.
It's very much in the spirit of Linus' tit-for-tat compact to allow the BSD Unixes to benefit from improvements made to code that originated there and made it's way to Linux. -- Tim
But it makes a statement that I think is a good one.
Finally, while GPLv2-only compatibility has been a mainstay so far in copyleft-next drafting, it's not clear to me that we can keep that compatibility forever and reach copyleft-next's policy goals. There's been no discussion of this yet, but it's certainly in the realm of possibility. If GPLv2-incompatibility ultimately happens in future copyleft-next versions, having dual-licensed code out there will be a huge help as it will assure that code can forever be used both on GPLv2-only and copyleft-next sides of future single-license-project equations.
Thanks for listening; of course it's the sole prerogative for the copyright holder to decide whether to change the license of their code or not, and I hope that they don't bow to pressure, just as Qualcomm wouldn't bow to pressure if you started asking them to stop dual licensing all their upstream Linux code under BSD licenses.
[0] BTW, Christoph, I remember when I started in FOSS in the early 1990s, everyone called the GPL a “random weirdo license”. The incumbent always seems not as random and weirdo as the challenger.
[1] There is the argument that 2-Clause-BSD has fewer requirements than GPLv2-only; however, that's not an argument to release the code *upstream* that way, it's an argument to release a separate version under 2-Clause-BSD.
-- Bradley M. Kuhn - he/him
Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Thu, Jul 08, 2021 at 08:22:26AM +0200, Greg KH wrote:
On Wed, Jul 07, 2021 at 11:43:08AM -0700, Luis Chamberlain wrote:
This adds the copyleft-next-0.3.1 SPDX tag and replaces existing boilerplate with the tag.
Luis Chamberlain (2): LICENSES: Add the copyleft-next-0.3.1 license testing: use the copyleft-next-0.3.1 SPDX tag
LICENSES/dual/copyleft-next-0.3.1 | 237 +++++++++++++++++++++++ lib/test_kmod.c | 12 +- lib/test_sysctl.c | 12 +- tools/testing/selftests/kmod/kmod.sh | 13 +- tools/testing/selftests/sysctl/sysctl.sh | 12 +-
As we only have 4 usages of this license in the tree, we have the opportunity to actually remove it and keep the list of licenses that we use in the kernel source smaller.
Any chance you wish to just change the license of these files, given that you are the only one that has tried to use it for kernel code?
Since it is a "relatively" new license (2012, used in Linux since 2017) obviously not many people would have used it, but one cannot assume it is not because one does not want, but rather one is not aware.
I myself have used the license for all new projects, and the agreement I reached with SUSE was I'd be using this license when I can for my own projects and contributions. I'm not a zealot though, and I also take care for proper considerations for such a large project such as Linux. It is why I had the license vetted by attorneys at SUSE in 2017, and also drew up a public discussion over its possible use on Linux. My goal then, in so far as Linux is concerned, is to use it for selftests as a safe place, which won't grow folks weary or concerned.
And then let things evolve from there.
Of all the items listed on patch #1 for which I prefer using copyleft-next the most important one for me is an explicit patent grant. Although GPL applies to Linux I do feel very strongly about propagation of more projects with such type of licenses and I feel we should be happy to help such projects grow by allowing cross polination.
As a follow-up to this, I do not want to see your "test_sysfs.c" module as a dual-licensed file, as that makes no sense whatsoever.
You can ignore the patch then, its a selftest driver, not a core sysfs change. I believe it should be up to the selftest maintainer?
The changes I am making to sysfs are explicitly under GPLv2, and has nothing to do with copyleft-next. I am using dual licensing with copyleft-next only for selftests for now. I have support from SUSE to use this license.
It is directly testing GPL-v2-only code, so the attempt to dual license it makes no sense to me.
So what? I can have BSD licensed code testing GPLv2 code. In fact folks out there use proprietary licensed code to test GPLv2 code as well. I don't see your the rationale here.
How could anyone take that code and do anything with it under the copyleft-next license only? And where would that happen?
That's up to the users. In my case I am heavily involved with doing automation of testing and so *I care* as I am building automation of testing for all things kernel. My project kdevops, will soon be relicensed to copyleft-next.
My personal development goal is I will embrace copyleft-next for anything new I write, and only use GPLv2 or another license when I am required to do so. I believe I am being reasonable also in using this only for sefltests for now as discussions and awareness of the license grows.
I understand the appeal of copyleft-next in that it resolves many of the "grey" areas around gplv2, but given that no one is rushing to advise us to relicense all of the kernel with this thing, there is no need to encourage the spread of it given the added complexity and confusion that adding another license to our mix can only cause.
"Need" is subjective. I feel strongly about a need to have explicit patent grants propagating in our community. So the more we can do this outside of Linux and allow code from Linux to be used in such projects the better.
The license is one of the only few licenses (if not only?) which is GPLv2 compatible and also has an clear patent grant. I have reasons to believe, we as a community face serious challenges if we don't grow our collection of code with explicit patent grants. And so any new project I create will have such licenses. It is simply my preference, and if I can contribute code to Linux in a "safe place" to slowly build traction of it, then fantastic.
So please, no, I don't want to see new licenses added to the tree, if anything we should be trimming them down to be less as it makes things simpler and more obvious.
Too late. Dual GPLv2 / copyleft-next code was added in 2017 and I had a clear community discussion over it.
I take caution and care about this. I do feel this discussion is worth having and hence my contributions in 2017 and now adding the respective SPDX license tag.
Luis
linux-kselftest-mirror@lists.linaro.org
-
Bradley M. Kuhn -
Christoph Hellwig -
Greg KH -
Joe Perches -
Luis Chamberlain -
Steven Rostedt -
Tim.Bird＠sony.com