linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
@ 2021-07-07 18:43 Luis Chamberlain
  2021-07-07 18:43 ` [PATCH 1/2] LICENSES: Add the copyleft-next-0.3.1 license Luis Chamberlain
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Luis Chamberlain @ 2021-07-07 18:43 UTC (permalink / raw)
  To: gregkh, tglx, akpm, shuah
  Cc: rafael, rgoldwyn, kuno, fontana, Ciaran.Farrell,
	Christopher.DeNicolo, hch, corbet, linux, ast, andriin, daniel,
	atenart, alobakin, weiwan, ap420073, tj, jeyu, ngupta,
	sergey.senozhatsky.work, minchan, mcgrof, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

-- 
2.27.0


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/2] LICENSES: Add the copyleft-next-0.3.1 license
  2021-07-07 18:43 [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Luis Chamberlain
@ 2021-07-07 18:43 ` Luis Chamberlain
  2021-07-07 18:43 ` [PATCH 2/2] testing: use the copyleft-next-0.3.1 SPDX tag Luis Chamberlain
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Luis Chamberlain @ 2021-07-07 18:43 UTC (permalink / raw)
  To: gregkh, tglx, akpm, shuah
  Cc: rafael, rgoldwyn, kuno, fontana, Ciaran.Farrell,
	Christopher.DeNicolo, hch, corbet, linux, ast, andriin, daniel,
	atenart, alobakin, weiwan, ap420073, tj, jeyu, ngupta,
	sergey.senozhatsky.work, minchan, mcgrof, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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>
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.
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 2/2] testing: use the copyleft-next-0.3.1 SPDX tag
  2021-07-07 18:43 [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Luis Chamberlain
  2021-07-07 18:43 ` [PATCH 1/2] LICENSES: Add the copyleft-next-0.3.1 license Luis Chamberlain
@ 2021-07-07 18:43 ` Luis Chamberlain
  2021-07-08  4:14 ` [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Christoph Hellwig
  2021-07-08  6:22 ` Greg KH
  3 siblings, 0 replies; 15+ messages in thread
From: Luis Chamberlain @ 2021-07-07 18:43 UTC (permalink / raw)
  To: gregkh, tglx, akpm, shuah
  Cc: rafael, rgoldwyn, kuno, fontana, Ciaran.Farrell,
	Christopher.DeNicolo, hch, corbet, linux, ast, andriin, daniel,
	atenart, alobakin, weiwan, ap420073, tj, jeyu, ngupta,
	sergey.senozhatsky.work, minchan, mcgrof, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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.
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-07 18:43 [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Luis Chamberlain
  2021-07-07 18:43 ` [PATCH 1/2] LICENSES: Add the copyleft-next-0.3.1 license Luis Chamberlain
  2021-07-07 18:43 ` [PATCH 2/2] testing: use the copyleft-next-0.3.1 SPDX tag Luis Chamberlain
@ 2021-07-08  4:14 ` Christoph Hellwig
  2021-07-08 19:00   ` Luis Chamberlain
  2021-07-08  6:22 ` Greg KH
  3 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2021-07-08  4:14 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: gregkh, tglx, akpm, shuah, rafael, rgoldwyn, kuno, fontana,
	Ciaran.Farrell, Christopher.DeNicolo, hch, corbet, linux, ast,
	andriin, daniel, atenart, alobakin, weiwan, ap420073, tj, jeyu,
	ngupta, sergey.senozhatsky.work, minchan, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-07 18:43 [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Luis Chamberlain
                   ` (2 preceding siblings ...)
  2021-07-08  4:14 ` [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Christoph Hellwig
@ 2021-07-08  6:22 ` Greg KH
  2021-07-08 14:59   ` Bradley M. Kuhn
  2021-07-08 19:33   ` Luis Chamberlain
  3 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2021-07-08  6:22 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: tglx, akpm, shuah, rafael, rgoldwyn, kuno, fontana,
	Ciaran.Farrell, Christopher.DeNicolo, hch, corbet, linux, ast,
	andriin, daniel, atenart, alobakin, weiwan, ap420073, tj, jeyu,
	ngupta, sergey.senozhatsky.work, minchan, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08  6:22 ` Greg KH
@ 2021-07-08 14:59   ` Bradley M. Kuhn
  2021-07-08 15:32     ` Greg KH
  2021-07-08 17:08     ` Tim.Bird
  2021-07-08 19:33   ` Luis Chamberlain
  1 sibling, 2 replies; 15+ messages in thread
From: Bradley M. Kuhn @ 2021-07-08 14:59 UTC (permalink / raw)
  To: Greg KH
  Cc: Luis Chamberlain, tglx, akpm, shuah, rafael, rgoldwyn, kuno,
	fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next


[ 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/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 14:59   ` Bradley M. Kuhn
@ 2021-07-08 15:32     ` Greg KH
  2021-07-08 16:56       ` Joe Perches
  2021-07-08 17:52       ` Bradley M. Kuhn
  2021-07-08 17:08     ` Tim.Bird
  1 sibling, 2 replies; 15+ messages in thread
From: Greg KH @ 2021-07-08 15:32 UTC (permalink / raw)
  To: Bradley M. Kuhn
  Cc: Luis Chamberlain, tglx, akpm, shuah, rafael, rgoldwyn, kuno,
	fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 15:32     ` Greg KH
@ 2021-07-08 16:56       ` Joe Perches
  2021-07-08 17:52       ` Bradley M. Kuhn
  1 sibling, 0 replies; 15+ messages in thread
From: Joe Perches @ 2021-07-08 16:56 UTC (permalink / raw)
  To: Greg KH, Bradley M. Kuhn
  Cc: Luis Chamberlain, tglx, akpm, shuah, rafael, rgoldwyn, kuno,
	fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 14:59   ` Bradley M. Kuhn
  2021-07-08 15:32     ` Greg KH
@ 2021-07-08 17:08     ` Tim.Bird
  1 sibling, 0 replies; 15+ messages in thread
From: Tim.Bird @ 2021-07-08 17:08 UTC (permalink / raw)
  To: bkuhn, gregkh
  Cc: mcgrof, tglx, akpm, shuah, rafael, rgoldwyn, kuno, fontana,
	Ciaran.Farrell, Christopher.DeNicolo, hch, corbet, linux, ast,
	andriin, daniel, atenart, alobakin, weiwan, ap420073, tj, jeyu,
	ngupta, sergey.senozhatsky.work, minchan, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

> -----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/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 15:32     ` Greg KH
  2021-07-08 16:56       ` Joe Perches
@ 2021-07-08 17:52       ` Bradley M. Kuhn
  2021-07-08 19:01         ` Steven Rostedt
  1 sibling, 1 reply; 15+ messages in thread
From: Bradley M. Kuhn @ 2021-07-08 17:52 UTC (permalink / raw)
  To: Greg KH
  Cc: Luis Chamberlain, tglx, akpm, shuah, rafael, rgoldwyn, kuno,
	fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08  4:14 ` [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Christoph Hellwig
@ 2021-07-08 19:00   ` Luis Chamberlain
  0 siblings, 0 replies; 15+ messages in thread
From: Luis Chamberlain @ 2021-07-08 19:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: gregkh, tglx, akpm, shuah, rafael, rgoldwyn, kuno, fontana,
	Ciaran.Farrell, Christopher.DeNicolo, corbet, linux, ast,
	andriin, daniel, atenart, alobakin, weiwan, ap420073, tj, jeyu,
	ngupta, sergey.senozhatsky.work, minchan, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 17:52       ` Bradley M. Kuhn
@ 2021-07-08 19:01         ` Steven Rostedt
  2021-07-08 19:37           ` Luis Chamberlain
  0 siblings, 1 reply; 15+ messages in thread
From: Steven Rostedt @ 2021-07-08 19:01 UTC (permalink / raw)
  To: Bradley M. Kuhn
  Cc: Greg KH, Luis Chamberlain, tglx, akpm, shuah, rafael, rgoldwyn,
	kuno, fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08  6:22 ` Greg KH
  2021-07-08 14:59   ` Bradley M. Kuhn
@ 2021-07-08 19:33   ` Luis Chamberlain
  1 sibling, 0 replies; 15+ messages in thread
From: Luis Chamberlain @ 2021-07-08 19:33 UTC (permalink / raw)
  To: Greg KH
  Cc: tglx, akpm, shuah, rafael, rgoldwyn, kuno, fontana,
	Ciaran.Farrell, Christopher.DeNicolo, hch, corbet, linux, ast,
	andriin, daniel, atenart, alobakin, weiwan, ap420073, tj, jeyu,
	ngupta, sergey.senozhatsky.work, minchan, axboe, mbenes,
	jpoimboe, keescook, jikos, rostedt, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 19:01         ` Steven Rostedt
@ 2021-07-08 19:37           ` Luis Chamberlain
  2021-07-08 20:08             ` Steven Rostedt
  0 siblings, 1 reply; 15+ messages in thread
From: Luis Chamberlain @ 2021-07-08 19:37 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Bradley M. Kuhn, Greg KH, tglx, akpm, shuah, rafael, rgoldwyn,
	kuno, fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
  2021-07-08 19:37           ` Luis Chamberlain
@ 2021-07-08 20:08             ` Steven Rostedt
  0 siblings, 0 replies; 15+ messages in thread
From: Steven Rostedt @ 2021-07-08 20:08 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Bradley M. Kuhn, Greg KH, tglx, akpm, shuah, rafael, rgoldwyn,
	kuno, fontana, Ciaran.Farrell, Christopher.DeNicolo, hch, corbet,
	linux, ast, andriin, daniel, atenart, alobakin, weiwan, ap420073,
	tj, jeyu, ngupta, sergey.senozhatsky.work, minchan, axboe,
	mbenes, jpoimboe, keescook, jikos, peterz, linux-block,
	linux-spdx, linux-kselftest, linux-kernel, copyleft-next

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-07-08 20:08 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-07 18:43 [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Luis Chamberlain
2021-07-07 18:43 ` [PATCH 1/2] LICENSES: Add the copyleft-next-0.3.1 license Luis Chamberlain
2021-07-07 18:43 ` [PATCH 2/2] testing: use the copyleft-next-0.3.1 SPDX tag Luis Chamberlain
2021-07-08  4:14 ` [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1 Christoph Hellwig
2021-07-08 19:00   ` Luis Chamberlain
2021-07-08  6:22 ` Greg KH
2021-07-08 14:59   ` Bradley M. Kuhn
2021-07-08 15:32     ` Greg KH
2021-07-08 16:56       ` Joe Perches
2021-07-08 17:52       ` Bradley M. Kuhn
2021-07-08 19:01         ` Steven Rostedt
2021-07-08 19:37           ` Luis Chamberlain
2021-07-08 20:08             ` Steven Rostedt
2021-07-08 17:08     ` Tim.Bird
2021-07-08 19:33   ` Luis Chamberlain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).