| Message ID | 20171112192142.525567667@linutronix.de (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Sun, 2017-11-12 at 20:18 +0100, Thomas Gleixner wrote: > 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, Philippe and Greg for review and editing! p[ > --- /dev/null > +++ b/Documentation/license-rules.rst [] > +The common way of expressing the license of a source file is to add the > +matching boiler plate text into the top comment of the file. Due to > +formatting, typos etc. These "boiler plates" are hard to validate for > +tools, which are used in the context of license compliance. There is bad sentence construction here and it is a little difficult to parse what is intended. "These" should not be capitalized. This SPDX info should also be place in the Documentation/process content somewhere. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 12 Nov 2017, Joe Perches wrote: > On Sun, 2017-11-12 at 20:18 +0100, Thomas Gleixner wrote: > > 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, Philippe and Greg for review and editing! > p[ > > --- /dev/null > > +++ b/Documentation/license-rules.rst > [] > > +The common way of expressing the license of a source file is to add the > > +matching boiler plate text into the top comment of the file. Due to > > +formatting, typos etc. These "boiler plates" are hard to validate for > > +tools, which are used in the context of license compliance. > > There is bad sentence construction here and it is a > little difficult to parse what is intended. > > "These" should not be capitalized. Indeed. > This SPDX info should also be place in the Documentation/process > content somewhere. Works for me. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 12 Nov 2017 20:18:22 +0100 Thomas Gleixner <tglx@linutronix.de> wrote: > 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/). Some nits...somebody's gotta do it... > > --- /dev/null > +++ b/Documentation/license-rules.rst > @@ -0,0 +1,310 @@ > +Linux kernel licensing rules > +============================ > + > +The Linux Kernel is provided under the terms of the GNU General Public > +License version 2 only (GPL-2.0), as published by the Free Software > +Foundation, and provided in the COPYING file. This documentation file is > +not meant to replace the COPYING file, but provides a description of how > +each source file should be annotated to make the licensing it is governed > +under clear and unambiguous. > + > +The license in the COPYING file applies to the kernel source as a whole, > +though individual source files can have a different license which is > +required to be compatible with the GPL-2.0: > + > +:: > + > + GPL-1.0+ : GNU General Public License v1.0 or later > + GPL-2.0+ : GNU General Public License v2.0 or later > + LGPL-2.0 : GNU Library General Public License v2 only > + LGPL-2.0+ : GNU Library General Public License v2 or later > + LGPL-2.1 : GNU Lesser General Public License v2.1 only > + LGPL-2.1+ : GNU Lesser General Public License v2.1 or later > + > +Aside from that, individual files can be provided under a dual license, > +i.e. one of the compatible GPL variants and alternatively under a > +permissive license like BSD, MIT etc. > + > +The Userspace API (UAPI) header files, which describe the interface of user > +space programs to the kernel are a special case. According to the note comma after "kernel" > +in the kernel COPYING file the syscall interface is a clear boundary, comma after "file" > +which does not extend the GPL requirements to any software which uses > +them to communicate with the kernel. Because the UAPI headers must be which uses *it* (subject is "the syscall interface") > +includable into any source files which create an executable running on > +the Linux kernel, the exception must be documented by a special license > +expression. > + > +The common way of expressing the license of a source file is to add the > +matching boiler plate text into the top comment of the file. Due to > +formatting, typos etc. These "boiler plates" are hard to validate for > +tools, which are used in the context of license compliance. > + > +To avoid license inconsistencies and to help tooling it is required to I'd grab the comma from after "tools" two lines up and put it after "tooling" instead. > +add a Software Package Data Exchange (SPDX) license identifier to each > +source file. SPDX license identifiers are machine parsable and precise > +shorthands for the license under which the content of the file is > +contributed under. SPDX license identifiers are managed by the SPDX This is over-undered. I'd delete the second 'under'. > +Workgroup at the Linux Foundation and have been agreed on by partners > +throughout the industry, tool vendors, and legal teams. For further > +information see https://spdx.org/ > + > +The Linux kernel requires the precise SPDX identifier in all source files. > +The valid identifiers used in the kernel are described in the section > +`License identifiers`_ bottom of this file and have been retrieved from the > +official SPDX license list at https://spdx.org/licenses/ > + > +License identifier syntax > +------------------------- > + > +The SPDX license identifier in kernel files shall be added at the first > +possible line in a file which can contain a comment. For the majority > +of files this is the first line, except for scripts which require the > +'#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX > +identifier goes into the second line. > + > +The SPDX license identifier is added in form of a comment. The comment > +style depends on the file type: > + > +:: > + > + C source: // SPDX-License-Identifier: <SPDX License Expression> > + C header: /* SPDX-License-Identifier: <SPDX License Expression> */ So I can't be the only person with nothing better to do than to wonder why source and header files use a different comment syntax. Maybe the document could explain that? > + ASM: /* SPDX-License-Identifier: <SPDX License Expression> */ > + scripts: # SPDX-License-Identifier: <SPDX License Expression> > + > +If a specific tool cannot handle the standard comment style, then the > +appropriate comment mechanism which the tool accepts shall be used. > + > +An <SPDX License Expression> is either an SPDX short form license > +identifier found on the SPDX License List, or when multiple licenses > +apply, an expression consisting of keywords "AND", "OR", and "WITH" > +separating SPDX short form license identifiers surrounded by "(", ")". > + > +License identifiers for licenses like [L]GPL with the 'or later' option > +are constructed by using a "+" for indicating the 'or later' option. > + > +:: > + > + // SPDX-License-Identifier: GPL-2.0+ > + // SPDX-License-Identifier: LGPL-2.1+ > + > +WITH should be used when there is a modifier to a license needed. > +For example, the linux kernel UAPI files use the expression: > + > +:: > + > + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) > + // SPDX-License-Identifier: (GPL-2.0+ WITH Linux-syscall-note) > + > +Other examples using WITH exceptions found in the kernel are: > + > +:: > + > + (GPL-2.0 WITH mif-exception) > + (GPL-2.0+ WITH GCC-exception-2.0) > + > +OR should be used if the file is dual licensed and only one license is > +to be selected. For example, some dtsi files are available under dual > +licenses: It would be good to document the set of permissible WITH exceptions. Or people will surely get creative in making up new ones. OK, I see that has been done, so amend that comment to suggest a line saying that the set of exceptions is documented below. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 12 Nov 2017, Jonathan Corbet wrote: > On Sun, 12 Nov 2017 20:18:22 +0100 > Thomas Gleixner <tglx@linutronix.de> wrote: > > + C source: // SPDX-License-Identifier: <SPDX License Expression> > > + C header: /* SPDX-License-Identifier: <SPDX License Expression> */ > > So I can't be the only person with nothing better to do than to wonder why > source and header files use a different comment syntax. Maybe the document > could explain that? Will do. The reason is that some build steps, one of them related to generated .lds files fail with C++ style comments. Linus fixed the .lds one, but there is at least an older ASM tool which doesn't like them. > > + ASM: /* SPDX-License-Identifier: <SPDX License Expression> */ > > +OR should be used if the file is dual licensed and only one license is > > +to be selected. For example, some dtsi files are available under dual > > +licenses: > > It would be good to document the set of permissible WITH exceptions. Or > people will surely get creative in making up new ones. > > > OK, I see that has been done, so amend that comment to suggest a line > saying that the set of exceptions is documented below. Will do. The other thing is, that the exception files have the applicable licenses in it so something like checkpatch.pl can verify it. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Looks like this superseeds my patches - https://patchwork.kernel.org/patch/10054727/ - https://patchwork.kernel.org/patch/10054719/ - https://patchwork.kernel.org/patch/10054721/ - https://patchwork.kernel.org/patch/10054725/ - https://patchwork.kernel.org/patch/10054723/ > +License identifier syntax > +------------------------- > + > +The SPDX license identifier in kernel files shall be added at the first > +possible line in a file which can contain a comment. For the majority > +of files this is the first line, except for scripts which require the > +'#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX > +identifier goes into the second line. > + > +The SPDX license identifier is added in form of a comment. The comment > +style depends on the file type: > + > +:: > + > + C source: // SPDX-License-Identifier: <SPDX License Expression> > + C header: /* SPDX-License-Identifier: <SPDX License Expression> */ > + ASM: /* SPDX-License-Identifier: <SPDX License Expression> */ > + scripts: # SPDX-License-Identifier: <SPDX License Expression> > + > +If a specific tool cannot handle the standard comment style, then the > +appropriate comment mechanism which the tool accepts shall be used. Most of the things sound good. But I really don't get the first-line thing and the C++ single line comments in C sources. First there are already tools [1] from the FSFE REUSE project [2] that support it after the copyright header. For example, the REUSE example project uses this style for cURL [3]. But is also looks quite out of place in the source files. Here what it looks like right now in the kernel: // SPDX-License-Identifier: GPL-2.0 /* * Copyright(c) 2015 EZchip Technologies. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, * version 2, as published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. * * The full GNU General Public License is included in this distribution in * the file called "COPYING". */ The REUSE cURL way would look more like: /* * Copyright(c) 2015 EZchip Technologies. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, * version 2, as published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. * * License-Filename: LICENSES/preferred/GPL-2.0 * SPDX-License-Identifier: GPL-2.0 */ And to the C++ style comments in C-source files. Way wouldn't it possible to use a common style in C source files an C header files? C source: /* SPDX-License-Identifier: <SPDX License Expression> */ C header: /* SPDX-License-Identifier: <SPDX License Expression> */ Thanks, Charlemagne Lasse [1] https://git.fsfe.org/reuse/reuse [2] https://reuse.software/ [3] https://git.fsfe.org/jonas/curl/src/reuse-compliant/src/slist_wc.c -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 13 Nov 2017, Charlemagne Lasse wrote: > > +If a specific tool cannot handle the standard comment style, then the > > +appropriate comment mechanism which the tool accepts shall be used. > > Most of the things sound good. But I really don't get the first-line > thing and the C++ single line comments in C sources. That's been a decision from Linus and probably not going to change, even if you argue in circles. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2017-11-13 13:26 GMT+01:00 Thomas Gleixner <tglx@linutronix.de>: > On Mon, 13 Nov 2017, Charlemagne Lasse wrote: >> > +If a specific tool cannot handle the standard comment style, then the >> > +appropriate comment mechanism which the tool accepts shall be used. >> >> Most of the things sound good. But I really don't get the first-line >> thing and the C++ single line comments in C sources. > > That's been a decision from Linus and probably not going to change, even if > you argue in circles. I always thought that Linus is the person reponsible for unfriendly responses. But ok, when it is not wanted to discuss anything then please ignore me. Thanks, Charlemagne Lasse -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 13 Nov 2017, Charlemagne Lasse wrote: > 2017-11-13 13:26 GMT+01:00 Thomas Gleixner <tglx@linutronix.de>: > > On Mon, 13 Nov 2017, Charlemagne Lasse wrote: > >> > +If a specific tool cannot handle the standard comment style, then the > >> > +appropriate comment mechanism which the tool accepts shall be used. > >> > >> Most of the things sound good. But I really don't get the first-line > >> thing and the C++ single line comments in C sources. > > > > That's been a decision from Linus and probably not going to change, even if > > you argue in circles. > > I always thought that Linus is the person reponsible for unfriendly > responses. But ok, when it is not wanted to discuss anything then please > ignore me. That was not meant unfriendly. I merily tried to make it clear that it's a decision which I'm pretty sure that it won't be changed. Feel free to discuss it with Linus. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 12 Nov 2017 20:18:22 +0100 Thomas Gleixner <tglx@linutronix.de> wrote: > --- /dev/null > +++ b/Documentation/license-rules.rst > @@ -0,0 +1,310 @@ > +Linux kernel licensing rules > +============================ > + > +The Linux Kernel is provided under the terms of the GNU General Public > +License version 2 only (GPL-2.0), as published by the Free Software > +Foundation, and provided in the COPYING file. This documentation file is One other thing that occurred to me is that documentation files, too, are copyrightable and should have license identifiers. So maybe the documentation on these identifiers should set a good example :) The RST version would be: .. SPDX-License-Identifier: GPL-2.0 I'll try to find some time to start fixing up Documentation/ in general. jon -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, > One other thing that occurred to me is that documentation files, too, > are copyrightable and should have license identifiers. Would it make sense to take an incremental approach to this? Get the source code and identifiers worked on by Thomas et al through first, then think about and fix up potential other issues, like the top level COPYING file, or documentation :-)
On Thu, 16 Nov 2017, Jonas Oberg wrote: > > One other thing that occurred to me is that documentation files, too, > > are copyrightable and should have license identifiers. > > Would it make sense to take an incremental approach to this? Get the > source code and identifiers worked on by Thomas et al through first, then > think about and fix up potential other issues, like the top level COPYING > file, or documentation :-) The top level COPYING file is historic, in terms of computer age even palaeontologic. We can't fix it :) Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 16, 2017 at 4:15 PM, Jonas Oberg <jonas@fsfe.org> wrote: > Hi, > >> One other thing that occurred to me is that documentation files, too, >> are copyrightable and should have license identifiers. > > Would it make sense to take an incremental approach to this? Get the > source code and identifiers worked on by Thomas et al through first, then > think about and fix up potential other issues, like the top level COPYING > file, or documentation :-) I could not agree more... code first! FWIW I scanned the whole docs with scancode as part of this exercise. They are rather ... messy license-wise, but even though I got through it eventually they also generally less critical license-wise IMHO. You can see some details of these scans in [1] though they are not 100% up to date: I did not post every intermediate scans and review there as things are moving at a fast pace. There are probably more pressing things to fix such as discrepancies between a MODULE_LICENSE and the licensing of a file when they do not match. Here [2] the top level comment is a plain GPL-2.0 "only" while the MODULE_LICENSE is a GPL-2.0+ "or later" (based on the plain "GPL" definition in module.h [3] and this is just one of many examples of this weirdness. Or fix the non-standard redefinition of the MODULE_LICENSE macro as DRIVER_LICENSE as in [2] and found elsewhere with grep -r . -e "DRIVER_LICENSE" These break the otherwise nicely grepable MODULE_LICENSE macros with this kind of warty redirection I stumbled upon while reviewing kernel license scans: #define DRIVER_LICENSE "GPL" [...] MODULE_LICENSE(DRIVER_LICENSE); [1] https://github.com/pombredanne/linux-kernel-scans/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/alpha/kernel/srm_env.c?h=v4.14#n13 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?h=v4.14#n174 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/gma500/psb_drv.h?h=v4.14#n39
On Fri, Nov 17, 2017 at 08:37:28AM +0100, Philippe Ombredanne wrote: > Or fix the non-standard redefinition of the MODULE_LICENSE macro as > DRIVER_LICENSE as in [2] and found elsewhere with > grep -r . -e "DRIVER_LICENSE" > > These break the otherwise nicely grepable MODULE_LICENSE macros > with this kind of warty redirection I stumbled upon while reviewing kernel > license scans: > > #define DRIVER_LICENSE "GPL" > [...] > MODULE_LICENSE(DRIVER_LICENSE); Yes, those should be cleaned up, there's only 11 instances of them, should be simple enough to do. I can knock up a patch series for them... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 17, 2017 at 9:57 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Fri, Nov 17, 2017 at 08:37:28AM +0100, Philippe Ombredanne wrote: >> Or fix the non-standard redefinition of the MODULE_LICENSE macro as >> DRIVER_LICENSE as in [2] and found elsewhere with >> grep -r . -e "DRIVER_LICENSE" >> >> These break the otherwise nicely grepable MODULE_LICENSE macros >> with this kind of warty redirection I stumbled upon while reviewing kernel >> license scans: >> >> #define DRIVER_LICENSE "GPL" >> [...] >> MODULE_LICENSE(DRIVER_LICENSE); > > Yes, those should be cleaned up, there's only 11 instances of them, > should be simple enough to do. I can knock up a patch series for > them... That would be awesome and you are probably a million times faster than me at that. There are actually more like 29 locations with such an oddity around AFAIK. Here is a better, more comprehensive grep: egrep "MODULE_LICENSE\([^\"]|DRIVER_LICENSE|DRV_LICENSE|MOD_LICENSE" -r . | egrep -v "module\.h|nand_ecc\.c|Documentation|scripts|az6007\.c|mt2063.c" yielding these: ./drivers/ntb/test/ntb_perf.c:#define DRIVER_LICENSE "Dual BSD/GPL" ./drivers/ntb/test/ntb_perf.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/ntb/test/ntb_tool.c:#define DRIVER_LICENSE "Dual BSD/GPL" ./drivers/ntb/test/ntb_tool.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/ntb/test/ntb_pingpong.c:#define DRIVER_LICENSE "Dual BSD/GPL" ./drivers/ntb/test/ntb_pingpong.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/ntb/ntb.c:#define DRIVER_LICENSE "Dual BSD/GPL" ./drivers/ntb/ntb.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/input/tablet/hanwang.c:#define DRIVER_LICENSE "GPL" ./drivers/input/tablet/hanwang.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/input/tablet/kbtab.c:#define DRIVER_LICENSE "GPL" ./drivers/input/tablet/kbtab.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/input/tablet/acecad.c:#define DRIVER_LICENSE "GPL" ./drivers/input/tablet/acecad.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/input/misc/keyspan_remote.c:#define DRIVER_LICENSE "GPL" ./drivers/input/misc/keyspan_remote.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/gpu/drm/gma500/psb_drv.h:#define DRIVER_LICENSE "GPL" ./drivers/gpu/drm/gma500/psb_drv.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/net/usb/hso.c:#define MOD_LICENSE "GPL" ./drivers/net/usb/hso.c:MODULE_LICENSE(MOD_LICENSE); ./drivers/scsi/csiostor/csio_init.c:MODULE_LICENSE(CSIO_DRV_LICENSE); ./drivers/scsi/csiostor/csio_init.h:#define CSIO_DRV_LICENSE "Dual BSD/GPL" ./drivers/media/usb/usbvision/usbvision-video.c:#define DRIVER_LICENSE "GPL" ./drivers/media/usb/usbvision/usbvision-video.c:MODULE_LICENSE(DRIVER_LICENSE); ./drivers/watchdog/pcwd_usb.c:#define DRIVER_LICENSE "GPL" ./drivers/watchdog/pcwd_usb.c:MODULE_LICENSE(DRIVER_LICENSE); ./include/linux/raid/pq.h:#define MODULE_LICENSE(licence)
On Fri, Nov 17, 2017 at 11:53:01AM +0100, Philippe Ombredanne wrote: > On Fri, Nov 17, 2017 at 9:57 AM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Fri, Nov 17, 2017 at 08:37:28AM +0100, Philippe Ombredanne wrote: > >> Or fix the non-standard redefinition of the MODULE_LICENSE macro as > >> DRIVER_LICENSE as in [2] and found elsewhere with > >> grep -r . -e "DRIVER_LICENSE" > >> > >> These break the otherwise nicely grepable MODULE_LICENSE macros > >> with this kind of warty redirection I stumbled upon while reviewing kernel > >> license scans: > >> > >> #define DRIVER_LICENSE "GPL" > >> [...] > >> MODULE_LICENSE(DRIVER_LICENSE); > > > > Yes, those should be cleaned up, there's only 11 instances of them, > > should be simple enough to do. I can knock up a patch series for > > them... > > That would be awesome and you are probably a million times faster than > me at that. > > There are actually more like 29 locations with such an oddity around AFAIK. > > Here is a better, more comprehensive grep: > > egrep "MODULE_LICENSE\([^\"]|DRIVER_LICENSE|DRV_LICENSE|MOD_LICENSE" > -r . | egrep -v > "module\.h|nand_ecc\.c|Documentation|scripts|az6007\.c|mt2063.c" > > yielding these: > > ./drivers/ntb/test/ntb_perf.c:#define DRIVER_LICENSE "Dual BSD/GPL" > ./drivers/ntb/test/ntb_perf.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/ntb/test/ntb_tool.c:#define DRIVER_LICENSE "Dual BSD/GPL" > ./drivers/ntb/test/ntb_tool.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/ntb/test/ntb_pingpong.c:#define DRIVER_LICENSE "Dual BSD/GPL" > ./drivers/ntb/test/ntb_pingpong.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/ntb/ntb.c:#define DRIVER_LICENSE "Dual BSD/GPL" > ./drivers/ntb/ntb.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/input/tablet/hanwang.c:#define DRIVER_LICENSE "GPL" > ./drivers/input/tablet/hanwang.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/input/tablet/kbtab.c:#define DRIVER_LICENSE "GPL" > ./drivers/input/tablet/kbtab.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/input/tablet/acecad.c:#define DRIVER_LICENSE "GPL" > ./drivers/input/tablet/acecad.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/input/misc/keyspan_remote.c:#define DRIVER_LICENSE "GPL" > ./drivers/input/misc/keyspan_remote.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/gpu/drm/gma500/psb_drv.h:#define DRIVER_LICENSE "GPL" > ./drivers/gpu/drm/gma500/psb_drv.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/net/usb/hso.c:#define MOD_LICENSE "GPL" > ./drivers/net/usb/hso.c:MODULE_LICENSE(MOD_LICENSE); > ./drivers/scsi/csiostor/csio_init.c:MODULE_LICENSE(CSIO_DRV_LICENSE); > ./drivers/scsi/csiostor/csio_init.h:#define CSIO_DRV_LICENSE "Dual BSD/GPL" > ./drivers/media/usb/usbvision/usbvision-video.c:#define DRIVER_LICENSE "GPL" > ./drivers/media/usb/usbvision/usbvision-video.c:MODULE_LICENSE(DRIVER_LICENSE); > ./drivers/watchdog/pcwd_usb.c:#define DRIVER_LICENSE "GPL" > ./drivers/watchdog/pcwd_usb.c:MODULE_LICENSE(DRIVER_LICENSE); > ./include/linux/raid/pq.h:#define MODULE_LICENSE(licence) Thanks, I think I got all of these, but that last one should be left alone, it's ok and for when the code is being built outside of the kernel tree. I'll send the patches out this afternoon. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -13,6 +13,18 @@ documents into a coherent whole. Please documentation are welcome; join the linux-doc list at vger.kernel.org if you want to help out. +Licensing documentation +----------------------- + +The following describes the license of the Linux kernel source code +(GPLv2), how to properly mark the license of individual files in the source +tree, as well as links to the full license text. + +.. toctree:: + :maxdepth: 2 + + license-rules.rst + User-oriented documentation --------------------------- --- /dev/null +++ b/Documentation/license-rules.rst @@ -0,0 +1,310 @@ +Linux kernel licensing rules +============================ + +The Linux Kernel is provided under the terms of the GNU General Public +License version 2 only (GPL-2.0), as published by the Free Software +Foundation, and provided in the COPYING file. This documentation file is +not meant to replace the COPYING file, but provides a description of how +each source file should be annotated to make the licensing it is governed +under clear and unambiguous. + +The license in the COPYING file applies to the kernel source as a whole, +though individual source files can have a different license which is +required to be compatible with the GPL-2.0: + +:: + + GPL-1.0+ : GNU General Public License v1.0 or later + GPL-2.0+ : GNU General Public License v2.0 or later + LGPL-2.0 : GNU Library General Public License v2 only + LGPL-2.0+ : GNU Library General Public License v2 or later + LGPL-2.1 : GNU Lesser General Public License v2.1 only + LGPL-2.1+ : GNU Lesser General Public License v2.1 or later + +Aside from that, individual files can be provided under a dual license, +i.e. one of the compatible GPL variants and alternatively under a +permissive license like BSD, MIT etc. + +The Userspace API (UAPI) header files, which describe the interface of user +space programs to the kernel are a special case. According to the note +in the kernel COPYING file the syscall interface is a clear boundary, +which does not extend the GPL requirements to any software which uses +them to communicate with the kernel. Because the UAPI headers must be +includable into any source files which create an executable running on +the Linux kernel, the exception must be documented by a special license +expression. + +The common way of expressing the license of a source file is to add the +matching boiler plate text into the top comment of the file. Due to +formatting, typos etc. These "boiler plates" are hard to validate for +tools, which are used in the context of license compliance. + +To avoid license inconsistencies and to help tooling it is required to +add a Software Package Data Exchange (SPDX) license identifier to each +source file. SPDX license identifiers are machine parsable and precise +shorthands for the license under which the content of the file is +contributed under. SPDX license identifiers are managed by the SPDX +Workgroup at the Linux Foundation and have been agreed on by partners +throughout the industry, tool vendors, and legal teams. For further +information see https://spdx.org/ + +The Linux kernel requires the precise SPDX identifier in all source files. +The valid identifiers used in the kernel are described in the section +`License identifiers`_ bottom of this file and have been retrieved from the +official SPDX license list at https://spdx.org/licenses/ + +License identifier syntax +------------------------- + +The SPDX license identifier in kernel files shall be added at the first +possible line in a file which can contain a comment. For the majority +of files this is the first line, except for scripts which require the +'#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX +identifier goes into the second line. + +The SPDX license identifier is added in form of a comment. The comment +style depends on the file type: + +:: + + C source: // SPDX-License-Identifier: <SPDX License Expression> + C header: /* SPDX-License-Identifier: <SPDX License Expression> */ + ASM: /* SPDX-License-Identifier: <SPDX License Expression> */ + scripts: # SPDX-License-Identifier: <SPDX License Expression> + +If a specific tool cannot handle the standard comment style, then the +appropriate comment mechanism which the tool accepts shall be used. + +An <SPDX License Expression> is either an SPDX short form license +identifier found on the SPDX License List, or when multiple licenses +apply, an expression consisting of keywords "AND", "OR", and "WITH" +separating SPDX short form license identifiers surrounded by "(", ")". + +License identifiers for licenses like [L]GPL with the 'or later' option +are constructed by using a "+" for indicating the 'or later' option. + +:: + + // SPDX-License-Identifier: GPL-2.0+ + // SPDX-License-Identifier: LGPL-2.1+ + +WITH should be used when there is a modifier to a license needed. +For example, the linux kernel UAPI files use the expression: + +:: + + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) + // SPDX-License-Identifier: (GPL-2.0+ WITH Linux-syscall-note) + +Other examples using WITH exceptions found in the kernel are: + +:: + + (GPL-2.0 WITH mif-exception) + (GPL-2.0+ WITH GCC-exception-2.0) + +OR should be used if the file is dual licensed and only one license is +to be selected. For example, some dtsi files are available under dual +licenses: + +:: + + // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) + +Examples from the kernel for license expressions in dual licensed files: + +:: + + (GPL-2.0 OR MIT) + (GPL-2.0 OR BSD-2-Clause) + (GPL-2.0 OR Apache-2.0) + (GPL-2.0 OR MPL-1.1) + ((GPL-2.0 WITH Linux-syscall-note) OR MIT) + ((GPL-1.0+ OR BSD-3-Clause) OR OpenSSL) + +AND should be used if the file has multiple licenses whose terms all apply +to use the file. For example, if code is inherited from another project +and permission has been given to put it in the kernel, but the original +license terms need to remain in effect: + +:: + + // SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) AND MIT) + +Another example where both sets of license terms need to be +adhered to is: + +:: + + (GPL-1.0+ AND LGPL-2.1+) + +License identifiers +------------------- + +The licenses currently used, as well as the licenses for code added to the +kernel can be broken down into: + +1) Preferred licenses: + +Whenever possible these licenses should be used as they are known to be +fully compatible and widely used. These licenses are available from the +directory: + +:: + + LICENSES/preferred/ + +in the kernel source tree. The files in this directory contain + + - the proper syntax of the SPDX License identifier + - the proper syntax for possible License options, e.g. 'or later' + - reference(s) to the original license text + - reference to the SPDX page + - the full license text + +The file names are identical to the SPDX license identifier which shall be +used for the license in source files. + +Examples: + +:: + + LICENSES/preferred/GPL-2.0 + + contains the GPL version 2 license text and the required references + +:: + + LICENSES/preferred/MIT + + contains the MIT license text and the required references + +File format examples: + +:: + + SPDX-License-Identifier: GPL-2.0 // GPLv2 only + SPDX-License-Identifier: GPL-2.0+ // GPLv2 or later + LICENSE-URL: http://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html + LICENSE-URL: http://www.opensource.org/licenses/GPL-2.0 + SPDX-URL: https://spdx.org/licenses/GPL-2.0.html + + Full license text + +:: + + SPDX-License-Identifier: MIT + LICENSE-URL: http://www.opensource.org/licenses/MIT + SPDX-URL: https://spdx.org/licenses/MIT.html + + Full license text + +2) Not recommended licenses. + +These licenses should only be used for existing code or for importing +code from a different project. These licenses are available from the +directory: + +:: + + LICENSES/other/ + +in the kernel source tree. The files in this directory contain: + + - the proper syntax of the SPDX License identifier + - reference(s) to the original license text + - reference to the SPDX page + - the full license text + +license text, a reference to the origin and the SPDX page. The file +names are identical to the SPDX license identifier which shall be used +for the license in source files. + +Examples: + +:: + + LICENSES/other/ISC + + contains the Internet Systems Consortium license text and the + required references + +:: + + LICENSES/other/ZLib + + contains the ZLIB license text and the required references + +File format example: + +:: + + SPDX-License-Identifier: ISC + LICENSE-URL: http://www.isc.org/software/license + LICENSE-URL: http://www.opensource.org/licenses/ISC + SPDX-URL: https://spdx.org/licenses/ISC.html + + Full license text + +3) Exceptions: + +Some licenses can be amended with exceptions which grant certain rights +which the original license does not. These exceptions are available +from the directory: + +:: + + LICENSES/exceptions/ + +in the kernel source tree. The files in this directory contain the full +exception text, a reference to the origin and the SPDX page. Further +the file contains the SPDX identifier(s) of the license(s) to which the +exception applies, so it can be verified that an exception is valid with +the license to which the SPDX identifier expression refers. The file +names are identical to the SPDX license exception identifier which +shall be used for the license in source files. + +Examples: + +:: + + LICENSES/exceptions/Linux-syscall-note + + contains the Linux syscall exception as documented in the COPYING + file of the Linux kernel, which is used for UAPI header files. + e.g. /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ + +:: + + LICENSES/exceptions/GCC-exception-2.0 + + contains the GCC 'linking exception' which allows to link any + binary independent of its license against the compiled version of a + file marked with this exception. This is required for creating + runnable executables from source code which is not compatible with + the GPL. + +File format examples: + +:: + + SPDX-Exception-Identifier: Linux-syscall-note + LICENSE-URL: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING + SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html + SPDX-LICENSES: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+ + + Full exception text + +:: + + SPDX-Exception-Identifier: GCC-exception-2.0 + LICENSE-URL: + SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html + SPDX-LICENSES: GPL-2.0, GPL-2.0+ + + Full exception text + +SPDX license identifiers and exceptions must have a corresponding file in +the LICENSING subdirectories. This is required to allow tool verification +(e.g. checkpatch.pl) and to have the licenses ready to read and extract +right from the source, which is recommended by various FOSS organizations.