summaryrefslogtreecommitdiff
path: root/Documentation/process/license-rules.rst
AgeCommit message (Collapse)Author
2019-05-03LICENSES: Rename other to deprecatedChristoph Hellwig
Make it clear in the directory name that these are not intended for new code. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-05-03LICENSES: Clearly mark dual license only licensesChristoph Hellwig
Just like the CDDL the Apache license and the MPL must only be used as a choice in additional to an GPL2 compatible license. Copy over the boilerplate from the CDDL file to the other two after fixing it up to make it clear the licenses need to be GPL2 compatible, not just the more generic GPL compatible. For example the Apache 2 license is GPL3 compatible, but that doesn't matter for the kernel. Also move these licenses to a separate directory and document the rules in license-rules.rst. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-05-03docs: Don't reference the ZLib license in license-rules.rstChristoph Hellwig
We never had a file called LICENSES/other/ZLib in the tree, so don't reference it. Instead mention the GPL v1 as an (bad) example. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-02-22doc: fix typos in license-rules.rstFederico Vaga
The patches fixes some typos in process/license-rules.rst Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-02-11module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosityThomas Gleixner
The original MODULE_LICENSE string for kernel modules licensed under the GPL v2 (only / or later) was simply "GPL", which was - and still is - completely sufficient for the purpose of module loading and checking whether the module is free software or proprietary. In January 2003 this was changed with commit 3344ea3ad4b7 ("[PATCH] MODULE_LICENSE and EXPORT_SYMBOL_GPL support"). This commit can be found in the history git repository which holds the 1:1 import of Linus' bitkeeper repository: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=3344ea3ad4b7c302c846a680dbaeedf96ed45c02 The main intention of the patch was to refuse linking proprietary modules against symbols exported with EXPORT_SYMBOL_GPL() at module load time. As a completely undocumented side effect it also introduced the distinction between "GPL" and "GPL v2" MODULE_LICENSE() strings: * "GPL" [GNU Public License v2 or later] * "GPL v2" [GNU Public License v2] * "GPL and additional rights" [GNU Public License v2 rights and more] * "Dual BSD/GPL" [GNU Public License v2 * or BSD license choice] * "Dual MPL/GPL" [GNU Public License v2 * or Mozilla license choice] This distinction was and still is wrong in several aspects: 1) It broke all modules which were using the "GPL" string in the MODULE_LICENSE() already and were licensed under GPL v2 only. A quick license scan over the tree at that time shows that at least 480 out of 1484 modules have been affected by this change back then. The number is probably way higher as this was just a quick check for clearly identifiable license information. There was exactly ONE instance of a "GPL v2" module license string in the kernel back then - drivers/net/tulip/xircom_tulip_cb.c which otherwise had no license information at all. There is no indication that the change above is any way related to this driver. The change happend with the 2.4.11 release which was on Oct. 9 2001 - so quite some time before the above commit. Unfortunately there is no trace on the intertubes to any discussion of this. 2) The dual licensed strings became ill defined as well because following the "GPL" vs. "GPL v2" distinction all dual licensed (or additional rights) MODULE_LICENSE strings would either require those dual licensed modules to be licensed under GPL v2 or later or just be unspecified for the dual licensing case. Neither choice is coherent with the GPL distinction. Due to the lack of a proper changelog and no real discussion on the patch submission other than a few implementation details, it's completely unclear why this distinction was introduced at all. Other than the comment in the module header file exists no documentation for this at all. From a license compliance and license scanning POV this distinction is a total nightmare. As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are conflicting with the actual license in the source code (either SPDX or license boilerplate/reference). A comparison between the scan of the history tree and a scan of current Linus tree shows to the extent that the git rename detection over Linus tree grafted with the history tree is halfways complete that almost none of the files which got broken in 2003 have been cleaned up vs. the MODULE_LICENSE string. So subtracting those 480 known instances from the conflicting 2800 of today more than 25% of the module authors got it wrong and it's a high propability that a large portion of the rest just got it right by chance. There is no value for the module loader to convey the detailed license information as the only decision to be made is whether the module is free software or not. The "and additional rights", "BSD" and "MPL" strings are not conclusive license information either. So there is no point in trying to make the GPL part conclusive and exact. As shown above it's already non conclusive for dual licensing and incoherent with a large portion of the module source. As an unintended side effect this distinction causes a major headache for license compliance, license scanners and the ongoing effort to clean up the license mess of the kernel. Therefore remove the well meant, but ill defined, distinction between "GPL" and "GPL v2" and document that: - "GPL" and "GPL v2" both express that the module is licensed under GPLv2 (without a distinction of 'only' and 'or later') and is therefore kernel license compliant. - None of the MODULE_LICENSE strings can be used for expressing or determining the exact license - Their sole purpose is to decide whether the module is free software or not. Add a MODULE_LICENSE subsection to the license rule documentation as well. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Philippe Ombredanne <pombredanne@nexb.com> Acked-by: Joe Perches <joe@perches.com> [jc: Did s/merily/merely/ ] Acked-by: Jessica Yu <jeyu@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2018-08-31docs: tidy up TOCs and refs to license-rules.rstMarkus Heiser
The documentation and TOCs are organized in a manner of a tree. Adding a TOC to the root, which refers to a file which is located in a subfolder forms a grid. Those TOCs are a bit confusing and thats why we get additional error messages while building partial documentation:: $ make SPHINXDIRS=process htmldocs ... checking consistency... Documentation/process/license-rules.rst: \ WARNING: document isn't included in any toctree To fix it, the *root-license-TOC* is replaced by a reference and the 'license-roles.txt' is added to the Documentation/process/index.rst TOC. BTW: there was an old licences remark in Documentation/process/howto.rst which is also updated, mentioning SPDX and pointing to the license-rules.rst Signed-off-by: Markus Heiser <markus.heiser@darmarit.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2018-03-23COPYING: create a new file with points to the Kernel license filesMauro Carvalho Chehab
With the addition of SPDX patchset, the contents of COPYING file is now duplicated at two other files under LICENSE: LICENSES/preferred/GPL-2.0 LICENSES/exceptions/Linux-syscall-note It is easy to check that the contents of the licence written on those files are identical with COPYING using: $ diff -upr COPYING LICENSES/preferred/GPL-2.0 $ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less Also, a new file was added, with describes how SPDX should work at the Kernel source files: Documentation/process/license-rules.rst Instead fo having it copying the contents of two files, and not even mentioning the third one, replace it by a file whose content points to the other tree files, preserving the Kernel's license. Adjust license-rules.rst accordingly. Please notice that this file preserves the Kernel license as is, without any changes. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2018-01-06Documentation: Add license-rules.rst to describe how to properly identify ↵Thomas Gleixner
file licenses Add a file to the Documentation directory to describe how file licenses should be described in all kernel files, using the SPDX identifier, as well as where all licenses should be in the kernel source tree for people to refer to (LICENSES/). Thanks to Kate and Greg for review and editing and Jonas for the suggestions concerning the meta tags in the licenses files. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jonas Oberg <jonas@fsfe.org> Reviewed-by: Jonathan Corbet <corbet@lwn.net> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>