kernel/linux.git/LICENSES, branch v6.18.21

LICENSES: Replace the obsolete address of the FSF in the GFDL-1.2

2025-07-24T09:15:39+00:00

The FSF does not reside in the Franklin street anymore. Let's update the address with the link to their website, as suggested in the latest revisions of their GFDL-1.2 license: https://www.gnu.org/licenses/old-licenses/fdl-1.2.txt Signed-off-by: Thomas Huth Signed-off-by: Greg Kroah-Hartman

LICENSES: Replace the obsolete address of the FSF in the GFDL-1.1

2025-07-24T09:15:39+00:00

The FSF does not reside in the Franklin street anymore. Let's update the address with the link to their website, as suggested in the latest revisions of their GFDL-1.1 license: https://www.gnu.org/licenses/old-licenses/fdl-1.1.txt Signed-off-by: Thomas Huth Signed-off-by: Greg Kroah-Hartman

LICENSES: Replace the obsolete address of the FSF in the LGPL-2.1

2025-07-24T09:15:39+00:00

The FSF does not reside in the Franklin street anymore. Let's update the address with the link to their website, as suggested in the latest revisions of their LGPL-2.1 license: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt Signed-off-by: Thomas Huth Signed-off-by: Greg Kroah-Hartman

LICENSES: Replace the obsolete address of the FSF in the LGPL-2.0

2025-07-24T09:15:39+00:00

The FSF does not reside in the Franklin street anymore. Let's update the address with the link to their website, as suggested in the latest revisions of their LGPL-2.0 license: https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt Signed-off-by: Thomas Huth Signed-off-by: Greg Kroah-Hartman

LICENSES: Replace the obsolete address of the FSF in the GPL-2.0

2025-07-24T09:15:39+00:00

The FSF does not reside in the Franklin street anymore. Let's update the address with the link to their website, as suggested in the latest revisions of their GPL-2.0 license: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt Signed-off-by: Thomas Huth Signed-off-by: Greg Kroah-Hartman

LICENSES: Replace the obsolete address of the FSF in the GPL-1.0

2025-07-24T09:15:39+00:00

The FSF does not reside in the Mass Ave anymore. Let's update the address with the link to their website, as suggested in the latest revisions of their GPL-1.0 license: https://www.gnu.org/licenses/old-licenses/gpl-1.0.txt Signed-off-by: Thomas Huth Signed-off-by: Greg Kroah-Hartman

LICENSES: add CC0-1.0 license text

2025-05-21T12:54:17+00:00

Commit cbbd847d107f ("tools/x86/kcpuid: Introduce a complete cpuid bitfields CSV file") turns the tools/arch/x86/kcpuid/cpuid.csv to be an auto-generated file from an input file maintained at x86-cpuid.org project. The x86-cpuid.org project clearly states that the auto-generated file is to be licensed with CC0-1.0 (see Link below). So, the SPDX-License-Identifier CC0-1.0 in the file is correct as intended. The spdxcheck.py script reports that tools/arch/x86/kcpuid/cpuid.csv uses an Invalid License ID: CC0-1.0, though, as the LICENSES directory in the kernel tree does not contain a file with license information for CC0-1.0. Add a suitable CC0-1.0 file with the license text into LICENSES/deprecated to make spdxcheck.py happy. The directory deprecated is the best fit, by exclusion of the alternatives. CC0-1.0 should not be considered among the preferred licenses in the kernel, nor is it a license exception case or intended for dual-licensing some copyrighted material. So, deprecated is the best fit here, even if the license and its use is fine and it does not suggest to actually deprecate use of this license. The license text for the CC0-1.0 file was obtained from the spdx license-list-data git repository (see Link below). Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.4/LICENSE.rst Link: https://github.com/spdx/license-list-data/blob/main/text/CC0-1.0.txt Signed-off-by: Lukas Bulwahn Signed-off-by: Greg Kroah-Hartman

LICENSES: add 0BSD license text

2024-09-02T03:43:24+00:00

The license text was copied from: https://spdx.org/licenses/0BSD.html Link: https://lkml.kernel.org/r/20240721133633.47721-3-lasse.collin@tukaani.org Signed-off-by: Lasse Collin Reviewed-by: Sam James Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Albert Ou Cc: Catalin Marinas Cc: Emil Renner Berthing Cc: Herbert Xu Cc: Joel Stanley Cc: Jonathan Corbet Cc: Jubin Zhong Cc: Jules Maselbas Cc: Krzysztof Kozlowski Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Randy Dunlap Cc: Rui Li Cc: Simon Glass Cc: Will Deacon Signed-off-by: Andrew Morton

LICENSES: Add the copyleft-next-0.3.1 license

2022-11-08T14:44:01+00:00

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 Cc: Kuno Woudt Cc: Richard Fontana Cc: copyleft-next@lists.fedorahosted.org Cc: Ciaran Farrell Cc: Christopher De Nicolo Cc: Christoph Hellwig Cc: Greg Kroah-Hartman Cc: Thomas Gleixner Cc: Jonathan Corbet Cc: Thorsten Leemhuis Cc: Andrew Morton Reviewed-by: Kees Cook Signed-off-by: Luis Chamberlain Reviewed-by: Tim Bird Signed-off-by: Greg Kroah-Hartman

LICENSES/LGPL-2.1: Add LGPL-2.1-or-later as valid identifiers

2021-12-16T13:33:10+00:00

Some files have been flagged with the new LGPL-2.1-or-later identifier which replace the original LGPL-2.1+ in the SPDX license identifier specification, but the identifiers are not mentioned as valid in the LGPL-2.1 license file. Add it, together with the LGPL-2.1-only at the the license file. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/12f38ebde4dcd8b1ecbd37df1b6ce2018426f6dd.1639657049.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman