Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Tue, Jun 12, 2018 at 2:27 PM, Thomas Gleixner wrote:
> Yang,
>
> On Tue, 12 Jun 2018, Yang Li wrote:
>> On Thu, Dec 28, 2017 at 4:17 PM, Thomas Gleixner wrote:
>> > On Thu, 28 Dec 2017, Thomas Gleixner wrote:
>> >
>> > Sorry for the spam. I somehow missed to refresh the patch before generating
>> > the mbox. Find below the correct version of that one which has ALL braces
>> > removed which we don't need.
>
>> I'm not sure how we reached the conclusion that we should remove ALL
>> braces? I cannot find related discussion in the archive except for
>> the "WITH" case.
>
> https://lkml.kernel.org/r/caofm3uepm_tberkovqghcy+wbw0i4msnafpbrc3hyzvqjss...@mail.gmail.com
Thanks Thomas, But this email is mostly discussing the "WITH" case as
I said, and it does mentioned that braces is (weakly) needed for other
cases.
>
>> This is conflicting with the current SPDX spec at
>> https://spdx.org/spdx-specification-21-web-version quoted below and
>> also the explenation in your own file.
>>
>> Quote from SPDX spec 2.1: More expressive composite license
>> expressions can be constructed using "OR", "AND", and "WITH" operators
>> similar to constructing mathematical expressions using arithmetic
>> operators. For the Tag:value format, any license expression that
>> consists of more than one license identifier and/or LicenseRef, should
>> be encapsulated by parentheses: "( )".
>
> This is not relevant here:
>
>For the Tag:value format, .
>
> The kernel does not generate SPDX files in Tag:value format. The kernel
> uses SPDX license identifiers to reflect the actual license of a file.
I'm not sure if I understood the Tag:value term correctly. But it
looks like to me that the "SPDX-License-Identifier: " is a tag:value in the SPDX spec.
"The tag should appear on its own line in the source file, generally
as part of a comment.
SPDX-License-Identifier: "
>
>> > + A is either an SPDX short form license
>> > + identifier found on the SPDX License List, or the combination of two
>> > + SPDX short form license identifiers separated by "WITH" when a license
>> > + exception applies. When multiple licenses apply, an expression consists
>> > + of keywords "AND", "OR" separating sub-expressions and surrounded by
>> > + "(", ")" .
>>
>> Conflicting with the example
>
> No, The keyword is 'separating sub-expressions'. It does not say license
> identifiers.
But the first sentense declared that an expression can just be a short
form license identifier.
And the examples provided in the spec also proves it:
"Examples:
SPDX-License-Identifier: (GPL-2.0 OR MIT)
SPDX-License-Identifier: (LGPL-2.1 AND BSD-2-CLAUSE)
SPDX-License-Identifier: (GPL-2.0+ WITH Bison-exception-2.2)"
>
> So these examples are completely compliant with the documentation:
>
>> > + // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
>> > + // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
>> > + // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>
> Two license (exception) identifiers plus a operator. That's perfectly well
> defined.
>
>> > + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
>
> This is actually a case where you need parentheses and they separate the
> sub-expression 'ID with EXC'.
>
> Adding extra parentheses around any simple 'ID operator [ID|EXC]'
> expression is really overkill and does not make stuff more
> readable. Likewise in programming languages. Why would anyone write:
>
> C et al.: a = (b || c);
> Pyhton: a = (b and c)
I think I agree with you that not having parentheses in these cases
probably make more sense. But I think we are having a conflict with
the spec now, probably we should update the SPDX spec to be aligned?
Actually a lot of the current SPDX tags in kernel tree are following
the spec to use the parentheses. We should do something to avoid the
confusion in the future IMO.
Regards,
Leo
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
Yang,
On Tue, 12 Jun 2018, Yang Li wrote:
> On Thu, Dec 28, 2017 at 4:17 PM, Thomas Gleixner wrote:
> > On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> >
> > Sorry for the spam. I somehow missed to refresh the patch before generating
> > the mbox. Find below the correct version of that one which has ALL braces
> > removed which we don't need.
> I'm not sure how we reached the conclusion that we should remove ALL
> braces? I cannot find related discussion in the archive except for
> the "WITH" case.
https://lkml.kernel.org/r/caofm3uepm_tberkovqghcy+wbw0i4msnafpbrc3hyzvqjss...@mail.gmail.com
> This is conflicting with the current SPDX spec at
> https://spdx.org/spdx-specification-21-web-version quoted below and
> also the explenation in your own file.
>
> Quote from SPDX spec 2.1: More expressive composite license
> expressions can be constructed using "OR", "AND", and "WITH" operators
> similar to constructing mathematical expressions using arithmetic
> operators. For the Tag:value format, any license expression that
> consists of more than one license identifier and/or LicenseRef, should
> be encapsulated by parentheses: "( )".
This is not relevant here:
For the Tag:value format, .
The kernel does not generate SPDX files in Tag:value format. The kernel
uses SPDX license identifiers to reflect the actual license of a file.
> > + A is either an SPDX short form license
> > + identifier found on the SPDX License List, or the combination of two
> > + SPDX short form license identifiers separated by "WITH" when a license
> > + exception applies. When multiple licenses apply, an expression consists
> > + of keywords "AND", "OR" separating sub-expressions and surrounded by
> > + "(", ")" .
>
> Conflicting with the example
No, The keyword is 'separating sub-expressions'. It does not say license
identifiers.
So these examples are completely compliant with the documentation:
> > + // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> > + // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
> > + // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
Two license (exception) identifiers plus a operator. That's perfectly well
defined.
> > + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
This is actually a case where you need parentheses and they separate the
sub-expression 'ID with EXC'.
Adding extra parentheses around any simple 'ID operator [ID|EXC]'
expression is really overkill and does not make stuff more
readable. Likewise in programming languages. Why would anyone write:
C et al.: a = (b || c);
Pyhton: a = (b and c)
Thanks,
tglx
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Thu, Dec 28, 2017 at 4:17 PM, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Thomas Gleixner wrote:
>
> Sorry for the spam. I somehow missed to refresh the patch before generating
> the mbox. Find below the correct version of that one which has ALL braces
> removed which we don't need.
Hi Thomas,
I'm not sure how we reached the conclusion that we should remove ALL
braces? I cannot find related discussion in the archive except for
the "WITH" case.
This is conflicting with the current SPDX spec at
https://spdx.org/spdx-specification-21-web-version quoted below and
also the explenation in your own file.
Quote from SPDX spec 2.1: More expressive composite license
expressions can be constructed using "OR", "AND", and "WITH" operators
similar to constructing mathematical expressions using arithmetic
operators. For the Tag:value format, any license expression that
consists of more than one license identifier and/or LicenseRef, should
be encapsulated by parentheses: "( )".
> +
> + A is either an SPDX short form license
> + identifier found on the SPDX License List, or the combination of two
> + SPDX short form license identifiers separated by "WITH" when a license
> + exception applies. When multiple licenses apply, an expression consists
> + of keywords "AND", "OR" separating sub-expressions and surrounded by
> + "(", ")" .
Conflicting with the example
> +
> + 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::
> +
> + // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
> + // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
> +
> + Exceptions can only be used with particular License identifiers. The
> + valid License identifiers are listed in the tags of the exception text
> + file. For details see the point `Exceptions`_ in the chapter `License
> + identifiers`_.
> +
> + 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::
> +
> + // SPDX-License-Identifier: GPL-2.0 OR MIT
> + // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> + // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
> + // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1
> + // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
> + // SPDX-License-Identifier: 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 other example where both sets of license terms need to be
> + adhered to is::
> +
> + // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
> +
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Thu, Dec 28, 2017 at 04:27:11PM +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 and Greg for review and editing and Jonas for the > suggestions concerning the meta tags in the licenses files. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Jonas Oberg > Reviewed-by: Jonathan Corbet > Reviewed-by: Philippe Ombredanne > Reviewed-by: Kate Stewart > Reviewed-by: Greg Kroah-Hartman > /me hasn't done any deep dive legal analysis of this, but I can live with this as a tag-file-with-license convention, so... Acked-by: Darrick J. Wong --D > --- > Documentation/index.rst | 12 + > Documentation/process/license-rules.rst | 370 > > 2 files changed, 382 insertions(+) > create mode 100644 Documentation/license-rules.rst > > --- 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 > + > + process/license-rules.rst > + > User-oriented documentation > --- > > --- /dev/null > +++ b/Documentation/process/license-rules.rst > @@ -0,0 +1,370 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +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, > +e.g. one of the compatible GPL variants and alternatively under a > +permissive license like BSD, MIT etc. > + > +The User-space 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 it 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 boilerplate text into the top comment of the file. Due to > +formatting, typos etc. these "boilerplates" are hard to validate for > +tools which are used in the context of license compliance. > + > +An alternative to boilerplate text is the use of Software Package Data > +Exchange (SPDX) license identifiers in each source file. SPDX license > +identifiers are machine parsable and precise shorthands for the license > +under which the content of the file is contributed. 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 explained in the section > +`License identifiers`_ and have been retrieved from the official SPDX > +license list at https://spdx.org/licenses/ along with the license texts. > + > +License identifier syntax > +- > + > +1. Placement: > + > + 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 > + or files this is the first line, except for script
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Dec 29, 2017, at 9:15 PM, Theodore Ts'o wrote: > > On Fri, Dec 29, 2017 at 11:17:54PM +0100, Philippe Ombredanne wrote: >>> As far as I know, none of the licenses explicitly say >>> copyright license must be on each file. Just that the distribution of >>> source must include the copyright and license statement. Exactly how >>> that is done is not explicitly specified. >> >> This is also my take. What is done here is not much different than >> refactoring duplicated code so it leaves in a single place: >> >> - by "value" at the root in COPYING and in the Documentation. >> - by "reference" in the code proper as SPDX ids. >> >> Therefore essential and common requirements to include the license >> text is fulfilled in the kernel. >> >> Note that there are a few offenders that will need to clean up their >> acts as they came up will both long and "un-removable and >> un-alterable" crazy legalese blurbs [1] prefix this: >> >> "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER" >> >> These will have to be taken care on a case by case basis. These are >> pretty stupid and IMHO should have never been allowed to be added to >> the kernel in the first place and are ugly warts. It could very well >> be that these are not really GPL-compliant notices FWIW: keeping >> notices and copyrights is quite different from a restriction of >> altering things by moving them around which is exactly what is >> happening with the SPDX-ification here. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5 > > Lustre is now owned by Intel so I suspect that some throat clearing > noises in the right direction could easily take care of the issue with > those files To correct this, the copyright on the Lustre code is not owned by Intel. The copyright on the original Lustre code was transferred from Oracle to Seagate a few years ago, but the code that Whamcloud->Intel used for their release (which is what the kernel client is based on) was forked many years ago from the Oracle version (all under GPL). There is no single copyright holder anymore, since there is no copyright assignment for new contributions and it is copyright by whomever contributed it, as with the kernel itself. I don't see any issue with leaving those header blocks as-is? Cheers, Andreas
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, 29 Dec 2017, Theodore Ts'o wrote: > On Fri, Dec 29, 2017 at 08:19:59AM -0800, Joe Perches wrote: > > > > Has it been legally reviewed and accepted that removal > > of the BSD license text from individual source files is > > appropriate and meets the legal requirements of > > following the BSD license on a per-file basis? > > > > And if so, who did this review? > > > > Is there any license that does not allow removal of the > > license text and does not allow simple substitution of > > the SPDX license identifier in each individual file? > > The work to use SPDX lines instead of individual licenses was done by > Greg K-H in close consultation with Linux Foundation counsels, so I > would assume that they did look at that particular issue. > > IANAL, but I've talked to lawyers about this issue, and in my > experience if you talk to three lawyers you will easily get six > opinions. As far as I know, none of the licenses explicitly say > copyright license must be on each file. Just that the distribution of > source must include the copyright and license statement. Exactly how > that is done is not explicitly specified. Aside of that we are not removing anything, except the obvious one liners like This file is licensed under GPLV2 For licensing see COPYING and similar constructs. Replacing the full boilerplate text is done by talking to the respective copyright holders, which usually involves lawyers when the copyright holder is a corporate. See for example: commit 987b154983f0e70b02edf6fc75fcc2f6e6d670b9 Author: Martin Schwidefsky Date: Mon Dec 4 10:57:02 2017 +0100 s390: Remove redudant license text where the removal has been done by IBM in files copyrighted by IBM. Thanks, tglx
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, Dec 29, 2017 at 11:17:54PM +0100, Philippe Ombredanne wrote: > > As far as I know, none of the licenses explicitly say > > copyright license must be on each file. Just that the distribution of > > source must include the copyright and license statement. Exactly how > > that is done is not explicitly specified. > > This is also my take. What is done here is not much different than > refactoring duplicated code so it leaves in a single place: > > - by "value" at the root in COPYING and in the Documentation. > - by "reference" in the code proper as SPDX ids. > > Therefore essential and common requirements to include the license > text is fulfilled in the kernel. > > Note that there are a few offenders that will need to clean up their > acts as they came up will both long and "un-removable and > un-alterable" crazy legalese blurbs [1] prefix this: > > "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER" > > These will have to be taken care on a case by case basis. These are > pretty stupid and IMHO should have never been allowed to be added to > the kernel in the first place and are ugly warts. It could very well > be that these are not really GPL-compliant notices FWIW: keeping > notices and copyrights is quite different from a restriction of > altering things by moving them around which is exactly what is > happening with the SPDX-ification here. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5 Lustre is now owned by Intel so I suspect that some throat clearing noises in the right direction could easily take care of the issue with those files - Ted
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, Dec 29, 2017 at 7:54 PM, Theodore Ts'o wrote: > On Fri, Dec 29, 2017 at 08:19:59AM -0800, Joe Perches wrote: >> >> Has it been legally reviewed and accepted that removal >> of the BSD license text from individual source files is >> appropriate and meets the legal requirements of >> following the BSD license on a per-file basis? >> >> And if so, who did this review? >> >> Is there any license that does not allow removal of the >> license text and does not allow simple substitution of >> the SPDX license identifier in each individual file? > > The work to use SPDX lines instead of individual licenses was done by > Greg K-H in close consultation with Linux Foundation counsels, so I > would assume that they did look at that particular issue. This is correct. And this is in addition to the discussion in the SPDX group at the LF (that includes several FOSS-savvy and prominent FOSS lawyers) that did design the SPDX spec. > IANAL, but I've talked to lawyers about this issue, and in my > experience if you talk to three lawyers you will easily get six > opinions. And that's on a good day: you may get more than six on a bad one. But on the other hand, they tend also to defer to standards, and established community norms. > As far as I know, none of the licenses explicitly say > copyright license must be on each file. Just that the distribution of > source must include the copyright and license statement. Exactly how > that is done is not explicitly specified. This is also my take. What is done here is not much different than refactoring duplicated code so it leaves in a single place: - by "value" at the root in COPYING and in the Documentation. - by "reference" in the code proper as SPDX ids. Therefore essential and common requirements to include the license text is fulfilled in the kernel. Note that there are a few offenders that will need to clean up their acts as they came up will both long and "un-removable and un-alterable" crazy legalese blurbs [1] prefix this: "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER" These will have to be taken care on a case by case basis. These are pretty stupid and IMHO should have never been allowed to be added to the kernel in the first place and are ugly warts. It could very well be that these are not really GPL-compliant notices FWIW: keeping notices and copyrights is quite different from a restriction of altering things by moving them around which is exactly what is happening with the SPDX-ification here. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5 -- Cordially Philippe Ombredanne
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, Dec 29, 2017 at 08:19:59AM -0800, Joe Perches wrote: > > Has it been legally reviewed and accepted that removal > of the BSD license text from individual source files is > appropriate and meets the legal requirements of > following the BSD license on a per-file basis? > > And if so, who did this review? > > Is there any license that does not allow removal of the > license text and does not allow simple substitution of > the SPDX license identifier in each individual file? The work to use SPDX lines instead of individual licenses was done by Greg K-H in close consultation with Linux Foundation counsels, so I would assume that they did look at that particular issue. IANAL, but I've talked to lawyers about this issue, and in my experience if you talk to three lawyers you will easily get six opinions. As far as I know, none of the licenses explicitly say copyright license must be on each file. Just that the distribution of source must include the copyright and license statement. Exactly how that is done is not explicitly specified. - Ted
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, 2017-12-29 at 14:21 +0100, Philippe Ombredanne wrote: > Thomas, > > On Thu, Dec 28, 2017 at 11:17 PM, Thomas Gleixner wrote: > > On Thu, 28 Dec 2017, Thomas Gleixner wrote: > > > > Sorry for the spam. I somehow missed to refresh the patch before generating > > the mbox. Find below the correct version of that one which has ALL braces > > removed which we don't need. Has it been legally reviewed and accepted that removal of the BSD license text from individual source files is appropriate and meets the legal requirements of following the BSD license on a per-file basis? And if so, who did this review? Is there any license that does not allow removal of the license text and does not allow simple substitution of the SPDX license identifier in each individual file?
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
Thomas, On Thu, Dec 28, 2017 at 11:17 PM, Thomas Gleixner wrote: > On Thu, 28 Dec 2017, Thomas Gleixner wrote: > > Sorry for the spam. I somehow missed to refresh the patch before generating > the mbox. Find below the correct version of that one which has ALL braces > removed which we don't need. > > Thanks, > > tglx > > 8<-- > Subject: Documentation: Add license-rules.rst to describe how to properly > identify file licenses > From: Thomas Gleixner > Date: Fri, 10 Nov 2017 09:30:00 +0100 > > 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 > Reviewed-by: Jonas Oberg > Reviewed-by: Jonathan Corbet > Reviewed-by: Philippe Ombredanne > Reviewed-by: Kate Stewart > Reviewed-by: Greg Kroah-Hartman > > --- > Documentation/index.rst | 12 + > Documentation/process/license-rules.rst | 370 > > 2 files changed, 382 insertions(+) > create mode 100644 Documentation/license-rules.rst > > --- 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 > + > + process/license-rules.rst > + > User-oriented documentation > --- > > --- /dev/null > +++ b/Documentation/process/license-rules.rst > @@ -0,0 +1,370 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +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, > +e.g. one of the compatible GPL variants and alternatively under a > +permissive license like BSD, MIT etc. > + > +The User-space 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 it 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 boilerplate text into the top comment of the file. Due to > +formatting, typos etc. these "boilerplates" are hard to validate for > +tools which are used in the context of license compliance. > + > +An alternative to boilerplate text is the use of Software Package Data > +Exchange (SPDX) license identifiers in each source file. SPDX license > +identifiers are machine parsable and precise shorthands for the license > +under which the content of the file is contributed. 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 explained in the section > +`License identifiers`_ and have been retrieved from the official SPDX > +license list at https://spdx.org/licenses/ along with the license texts.
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Thu, 28 Dec 2017, Thomas Gleixner wrote: Sorry for the spam. I somehow missed to refresh the patch before generating the mbox. Find below the correct version of that one which has ALL braces removed which we don't need. Thanks, tglx 8<-- Subject: Documentation: Add license-rules.rst to describe how to properly identify file licenses From: Thomas Gleixner Date: Fri, 10 Nov 2017 09:30:00 +0100 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 Reviewed-by: Jonas Oberg Reviewed-by: Jonathan Corbet Reviewed-by: Philippe Ombredanne Reviewed-by: Kate Stewart Reviewed-by: Greg Kroah-Hartman --- Documentation/index.rst | 12 + Documentation/process/license-rules.rst | 370 2 files changed, 382 insertions(+) create mode 100644 Documentation/license-rules.rst --- 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 + + process/license-rules.rst + User-oriented documentation --- --- /dev/null +++ b/Documentation/process/license-rules.rst @@ -0,0 +1,370 @@ +.. SPDX-License-Identifier: GPL-2.0 + +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, +e.g. one of the compatible GPL variants and alternatively under a +permissive license like BSD, MIT etc. + +The User-space 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 it 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 boilerplate text into the top comment of the file. Due to +formatting, typos etc. these "boilerplates" are hard to validate for +tools which are used in the context of license compliance. + +An alternative to boilerplate text is the use of Software Package Data +Exchange (SPDX) license identifiers in each source file. SPDX license +identifiers are machine parsable and precise shorthands for the license +under which the content of the file is contributed. 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 explained in the section +`License identifiers`_ and have been retrieved from the official SPDX +license list at https://spdx.org/licenses/ along with the license texts. + +License identifier syntax +- + +1. Placement: + + 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 + or files this is the first line, except for scripts
[patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify 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 Reviewed-by: Jonas Oberg Reviewed-by: Jonathan Corbet Reviewed-by: Philippe Ombredanne Reviewed-by: Kate Stewart Reviewed-by: Greg Kroah-Hartman --- Documentation/index.rst | 12 + Documentation/process/license-rules.rst | 370 2 files changed, 382 insertions(+) create mode 100644 Documentation/license-rules.rst --- 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 + + process/license-rules.rst + User-oriented documentation --- --- /dev/null +++ b/Documentation/process/license-rules.rst @@ -0,0 +1,370 @@ +.. SPDX-License-Identifier: GPL-2.0 + +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, +e.g. one of the compatible GPL variants and alternatively under a +permissive license like BSD, MIT etc. + +The User-space 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 it 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 boilerplate text into the top comment of the file. Due to +formatting, typos etc. these "boilerplates" are hard to validate for +tools which are used in the context of license compliance. + +An alternative to boilerplate text is the use of Software Package Data +Exchange (SPDX) license identifiers in each source file. SPDX license +identifiers are machine parsable and precise shorthands for the license +under which the content of the file is contributed. 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 explained in the section +`License identifiers`_ and have been retrieved from the official SPDX +license list at https://spdx.org/licenses/ along with the license texts. + +License identifier syntax +- + +1. Placement: + + 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 + or 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. + +| + +2. Style: + + The SPDX license identifier is added in form of a comment. The comment + style depends on the file type:: + + C source:// SPDX-License-Identifier: + C header:/* SPDX-License-Identifier: */ + ASM: /* SPDX-License-Identifier: */ + scr
