some ideas on guidelines

some ideas on guidelines

[J Lovejoy]

Hi all,

Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.  

I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency. 

The key points I’ve come up with are as follows. PLEASE NOTE - I have tried to format this so it will read correctly in plain text. When responding, please do not cut out large parts of this as the context will be lost and a different meaning may be implied. (I know this is breaking Greg’s rules, but it’s kind of important to keep the whole context in this case.)  At the bottom of this email, I have identified specific feedback from specific people which would be really helpful. 

========
GOAL: The over-arching goal here is to provide clear, concise, and machine-readable license information at the file-level for the Linux kernel by placing SPDX License List short identifiers at the top of each file in order to make it easier for downstream users and distributors to use automated processes and comply with the applicable license terms.

NOTE: The guidance is either to REPLACE the existing license notice with the SPDX license identifier or ADD the SPDX license identifier. The rationale here is that where the license notice is clear, then replacing should be okay as this is essentially upgrading the current notice to something more modern and machine readable. But everywhere else, a conservative approach of adding the SPDX identifiers (and as such, keeping the existing license notice info) means that others can see both. This also avoids the need to create or retain some file with all the removed notices, which seems to be distasteful and untenable based on the threads related to that topic. The SPDX identifier still needs to be accurate, of course. 

TOOLING CONSIDERATION: To make it easier on tooling, putting some kind of START/END notation, as Steve has recommended, thus allowing tooling to ignore what’s enclosed there and just read the SPDX identifier as the definitive license notice. As time goes by, if copyright holders come across these files and want to remove the original notices, then they have the right to do so. 

GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.

The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.

#1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.

#2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.

#3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.

NOTES RELATED TO #1-3:
The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.

Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
*  Although the license text itself recommends the use of the standard license notice, it is not a hard requirement of the license. The definitive text, as always, is the full text of the license itself. Notably, the license author/steward, the Free Software Foundation (FSF), encourages use of the standard header, but more broadly recommends clear communication of the license variant chosen for the given work as seen in various pages on their site.[1] Furthermore, Richard Stallman endorsed the use of the revised SPDX identifiers for helping provide clarity as to whether a licensor has chosen the license-version-only or any-later-version option.[2]
*  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.

[1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
[2] See https://www.gnu.org/licenses/identify-licenses-clearly.html

#4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
    Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.

#5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
    Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

#6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
	
		#6a  An existing known additional license or exception for which there is an SPDX identifier
			 —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
			 —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders

		#6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
			--  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
			-- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
			-- If some mess of a license that is unclear, an abomination, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation 

		#6c   An additional or different disclaimer or warranty text:
			— Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL
			—  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
				—> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
				—> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0
	
========

Please note: while I am a lawyer, I do not represent any kernel developers nor any of the people involved in this work. I understand that no lawyer could represent the interest of the Linux kernel and its many copyright holders in total. We can, however, discuss this in a public forum and come up with some consensus as to reasonable guidelines and rationale for such.

I have tried to collect the various thoughts and opinions expressed on the mailing list on these topics. 
I’m particularly interested in the following feedback:
A) This takes a somewhat conservative approach regarding retaining some of the license notices and adding SPDX identifiers, rather than replacing. I’d like to know from those involved in using scanning tools (Thomas, Philippe) if this would be tenable. 
B) Related to A, are there examples above noted for ADD, that you would feel comfortable with being REPLACE and if so, explain.
C) I’m especially interested in Richard, Bradley and John’s view on #1-3 as they seemed to have the most initial concern here.

Finally - don’t shoot the messenger :)


Thanks,
Jilayne

Re: some ideas on guidelines

[Philippe Ombredanne]

Hi Jilayne:

On Wed, Jun 12, 2019 at 7:25 AM J Lovejoy <opensource@jilayne.com> wrote:
>
> GOAL: The over-arching goal here is to provide clear, concise, and
> machine-readable license information at the file-level for the Linux
> kernel by placing SPDX License List short identifiers at the top of
> each file in order to make it easier for downstream users and
> distributors to use automated processes and comply with the applicable
> license terms.
>
> NOTE: The guidance is either to REPLACE the existing license notice
> with the SPDX license identifier or ADD the SPDX license identifier.
> The rationale here is that where the license notice is clear, then
> replacing should be okay as this is essentially upgrading the current
> notice to something more modern and machine readable. But everywhere
> else, a conservative approach of adding the SPDX identifiers (and as
> such, keeping the existing license notice info) means that others can
> see both. This also avoids the need to create or retain some file with
> all the removed notices, which seems to be distasteful and untenable
> based on the threads related to that topic. The SPDX identifier still
> needs to be accurate, of course.
>
> TOOLING CONSIDERATION: To make it easier on tooling, putting some kind
> of START/END notation, as Steve has recommended,

Having some convention to enclose a notice in some markers would have
no impact and would not make it easier for scancode: the notice would
be detected and reported if is enclosed in markers or not. This could
be leveraged later as a way to speed things up of course, but that's
minor.

If tagging notice text boundaries is the route selected for the
kernel, then it is worth crafting something that is well thought out
as the kernel ways **will** surely be adopted by other projects.

FWIW, here are a few examples of using such markers that exist in the
wild from a quick grep in scancode license notices database:

- Mozilla: BEGIN LICENSE BLOCK/ END LICENSE BLOCK
- Apple: @APPLE_LICENSE_HEADER_START@
@APPLE_LICENSE_HEADER_END@ and some variations
- Oracle: CDDL HEADER START/END , GPL HEADER START/END, LGPL HEADER
START/END used with their highly impractical "DO NOT ALTER OR REMOVE
COPYRIGHT NOTICES OR THIS FILE HEADER."
- LICENSE_START/LICENSE_END (and variations such as %%%LICENSE_START
used in some man pages and tools including the kernel)
- BSDCOPYRIGHTBEGIN, ECOSGPLCOPYRIGHTBEGIN and other variations in eCos.
- Qt and KDE: QT_BEGIN_LICENSE with variations
- COPYRIGHTBEGIN/END
- Begin-Header/End-Header
- BEGIN LICENSE TEXT/END LICENSE TEXT

> thus allowing tooling
> to ignore what’s enclosed there and just read the SPDX identifier as
> the definitive license notice.

There is something inconsistent here: either a custom notice or
disclaimer is needed and has some legal importance, or it has none and
should be removed. If it has some importance and needs to be kept,
then I cannot "just read the SPDX identifier as the definitive license
notice" as you wrote, I think I would need to consider both the id and
extra notice. Or am I missing something?

>  As time goes by, if copyright holders
> come across these files and want to remove the original notices, then
> they have the right to do so.
>
> GUIDANCE: The following is meant to provide some high-level guidance
> for how to handle common scenarios and triage the approaches to reach
> the stated goal.
> The following is not intended to be legal advice. Rather, it is meant
> to reflect the intention of the participating individuals to improve
> the quality and machine-readability of the applicable license
> information in Linux kernel files. The approach described below has
> been developed with the Linux kernel in mind and might not be
> appropriate for other projects or communities.
>
> #1   Where a file contains the standard license notice as stated in
> the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no
> other license information whatsoever —> then REPLACE the standard
> license notice with the SPDX identifier for the relevant license.
>
> #2   Where a file contains a non-substantive variation on the standard
> GPL-2.0 license notice, but still provides clear distinction as to
> GPL-2.0-only or GPL-or-later consistent with the intent of the
> standard license notice and no other license information whatsoever
> —> then REPLACE the standard license notice with the SPDX identifier
> for the relevant license.
>
> #3   Where a file contains a license notice that is non-standard as
> compared to that stated in the GPL-2.0 license text but is nonetheless
> clear as to GPL-2.0-only or GPL-2.0-or-later and no other license
> information whatsoever —> then REPLACE the standard license notice
> with the SPDX identifier for the relevant license.
>
> NOTES RELATED TO #1-3:
> The SPDX identifier is simply a more concise way to express the same
> intention regarding what license applies to the file as the standard
> license notice, but does so in a reliably, machine-readable way that
> meets the needs of modern software supply chain use and efforts to
> automate detection of license information in order to facilitate more
> complete license information and license compliance. One consideration
> is whether replacing existing license notices with more concise,
> machine-readable expression of the same information could run afoul of
> a strict reading of GPL-2.0, section 1.
> Such a strict reading applied to the scenarios described in #1-3 is
> unconvincing for the following reasons:
> *  Although the license text itself recommends the use of the standard
> license notice, it is not a hard requirement of the license. The
> definitive text, as always, is the full text of the license itself.
> Notably, the license author/steward, the Free Software Foundation
> (FSF), encourages use of the standard header, but more broadly
> recommends clear communication of the license variant chosen for the
> given work as seen in various pages on their site.[1] Furthermore,
> Richard Stallman endorsed the use of the revised SPDX identifiers for
> helping provide clarity as to whether a licensor has chosen the
> license-version-only or any-later-version option.[2]
> *  This project to improve license information in the Linux kernel
> files has been discussed among kernel developers, on kernel mailing
> lists, and documented in public files and documentation beginning in
> mid-20173 to which many kernel copyright holders past and present have
> access and would be likely to see and which has received positive
> response and encouragement.
> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the
> standard license notice, but then also goes on to
> https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest
> one clear and explicit statement such as, “This program is released
> under license FOO”. FAQ questions and https://www.gnu.org/licenses
> /gpl-faq.en.html#NoticeInSourceFile also stress the general need for
> clarity without mandating use of the specific standard license notice.
> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>
> #4   Where the file contains a license notice that clearly states the
> file is licensed under “GPL” with no indication of version number
> and no other license information whatsoever —> ADD SPDX identifier
> for GPL-2.0-or-later
>     Rationale: This is consistent with the text of the license which
> states, “If the Program does not specify a version number of this
> License, you may choose any version ever published by the Free
> Software Foundation.” Because the Linux kernel is well-known to be
> licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it
> within the options given in the license text to choose GPL-2.0-or-
> later in this case. Doing so more easily enables use of such files
> beyond the Linux kernel.

Just FYI,  I am fine with a GPL-2.0-or-later choice for the kernel,
but scancode will report these cases as GPL-1.0-or-later.

> #5   Where the file contains a license notice that: a) refers to the
> COPYING file or another specific file (or references GPL and the
> COPYING or another specific file) with no other information as to the
> specific license whatsoever; and b) the COPYING or other specific file
> can be located and is clearly a copy of GPL-2.0  —> ADD SPDX
> identifier for GPL-2.0-only
>     Rationale: This is similar to #4, but the combination of a clear
> reference to a specific license file and the fact that the Linux
> kernel is clearly intended to be GPL-2.0-only leads to the intent that
> this is also GPL-2.0-only. The COPYING file currently in the kernel is
> at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the
> COPYING file also had Linus expressing GPL-2.0-only: see https://git.k
> ernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?i
> d=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>
> #6   Where a file contains a license notice that is non-standard as
> compared to that stated in the GPL-2.0 license text but in nonetheless
> clear as to GPL-2.0-only or GPL-2.0-or-later and there is other
> license information, and that license information contains the
> following:
>                 #6a  An existing known additional license or exception
> for which there is an SPDX identifier
>                          —> ADD appropriate SPDX license expression
> (use of AND, OR, WITH), where person making change is does not
> represent copyright holders for file
>                          —> REPLACE with appropriate SPDX license
> expression, where person(s) making or signing-off on changes represent
> copyright holders
>                 #6b   An additional license or exception for which
> there is no SPDX identifier as per the existing SPDX License List
> Matching Guidelines:
>                         --  If clearly a different license and use is
> more than one or two files, then submit for addition to SPDX License
> List at http://13.57.134.254/app/submit_new_license/
>                         -- If close to an existing license/exception
> on the SPDX License List such that the SPDX license’s matching
> markup might be extended to accommodate as a match, submit to SPDX
> legal team for review of such.
>                         -- If some mess of a license that is unclear,
> an abomination, contains non-free elements, or otherwise poses some
> kind of challenge, then attempt to contact copyright holders to change
> license with recommendation
>                 #6c   An additional or different disclaimer or
> warranty text:
>                         — Where the copyright holders of the file in
> questions can be contacted, then ask them to remove this and use the
> appropriate SPDX identifier for GPL
>                         —  Where copyright holders of the file in
> question cannot be easily contacted or found, then analyze differences
> between additional disclaimer text and standard disclaimer included in
> GPL, then:
>                                 —> if additional disclaimer text
> adds no additional substantive aspects to the standard GPL disclaimer,
> REPLACE with appropriate SPDX license identifier for GPL-2.0
>                                 —> If additional disclaimer text
> adds additional substantive aspects to the standard GPL disclaimer,
> ADD the appropriate SPDX license identifier for GPL-2.0
> ========
> Please note: while I am a lawyer, I do not represent any kernel
> developers nor any of the people involved in this work. I understand
> that no lawyer could represent the interest of the Linux kernel and
> its many copyright holders in total. We can, however, discuss this in
> a public forum and come up with some consensus as to reasonable
> guidelines and rationale for such.
> I have tried to collect the various thoughts and opinions expressed on
> the mailing list on these topics.
> I’m particularly interested in the following feedback:
> A) This takes a somewhat conservative approach regarding retaining
> some of the license notices and adding SPDX identifiers, rather than
> replacing. I’d like to know from those involved in using scanning
> tools (Thomas, Philippe) if this would be tenable.

Speaking for the scanning tool in use here (i.e. the scancode-toolkit)
having SPDX ids alone or with some extra notice has no impact. The
SPDX id and the license notice will be detected and each detected
texts reported with their own corresponding license expression (which
would happen to be the same and that can later be combined and
simplified in a single expression.)

It would likely not impact checkpatch.pl either since it cares only
about the SPDX identifiers.

BUT If you start to butcher the original notice (such as you remove
the GPL notice part and keep a warranty disclaimer) the detection
results will be butchered accordingly and that standalone disclaimer
will be eventually detected either as a bare disclaimer with no
related license or as a partial detection of an another notice (since
scancode eventually does a multidiff/red line comparison).
The same would likely apply to other license scanners that do not use
a diff, though this could be amplified as regex-based scanners such as
Fossology may get unlucky and miss having a regex for the butchered
text and probabilistic scanners such as Licensee and many others may
see the butchered text going below their false positive threshold and
ignore it entirely.

Therefore my advice would be either to keep a complete and consistent
notice or to keep none e.g. avoid cherry picking parts of a notice as
this will surely result in some license detection but not the one you
would expect: it will likely be inconclusive and require more review.

--
Cordially
Philippe Ombredanne

Re: some ideas on guidelines

[John Sullivan]

Thank you for doing this! It's very helpful to have guidelines like this
to bring everything together. I hope to offer some more feedback, but
wanted to comment now on the description of the FSF's position:

J Lovejoy <opensource@jilayne.com> writes:

> Hi all,
>
> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.  
>
> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency. 
>
> The key points I’ve come up with are as follows. PLEASE NOTE - I have tried to format this so it will read correctly in plain text. When responding, please do not cut out large parts of this as the context will be lost and a different meaning may be implied. (I know this is breaking Greg’s rules, but it’s kind of important to keep the whole context in this case.)  At the bottom of this email, I have identified specific feedback from specific people which would be really helpful. 
>
> ========
> GOAL: The over-arching goal here is to provide clear, concise, and machine-readable license information at the file-level for the Linux kernel by placing SPDX License List short identifiers at the top of each file in order to make it easier for downstream users and distributors to use automated processes and comply with the applicable license terms.
>
> NOTE: The guidance is either to REPLACE the existing license notice with the SPDX license identifier or ADD the SPDX license identifier. The rationale here is that where the license notice is clear, then replacing should be okay as this is essentially upgrading the current notice to something more modern and machine readable. But everywhere else, a conservative approach of adding the SPDX identifiers (and as such, keeping the existing license notice info) means that others can see both. This also avoids the need to create or retain some file with all the removed notices, which seems to be distasteful and untenable based on the threads related to that topic. The SPDX identifier still needs to be accurate, of course. 
>
> TOOLING CONSIDERATION: To make it easier on tooling, putting some kind of START/END notation, as Steve has recommended, thus allowing tooling to ignore what’s enclosed there and just read the SPDX identifier as the definitive license notice. As time goes by, if copyright holders come across these files and want to remove the original notices, then they have the right to do so. 
>
> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
>
> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
>
> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>
> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>
> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>
> NOTES RELATED TO #1-3:
> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
>
> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
> *  Although the license text itself recommends the use of the standard
> license notice, it is not a hard requirement of the license. The
> definitive text, as always, is the full text of the license itself.
> Notably, the license author/steward, the Free Software Foundation
> (FSF), encourages use of the standard header, but more broadly
> recommends clear communication of the license variant chosen for the
> given work as seen in various pages on their site.[1] Furthermore,
> Richard Stallman endorsed the use of the revised SPDX identifiers for
> helping provide clarity as to whether a licensor has chosen the
> license-version-only or any-later-version option.[2]

Hmm. FSF didn't and doesn't blanketly endorse removal of license notices
by non copyright holders. That is a separate question from the FAQs
you're citing, which are about what kind of notice is minimally
acceptable, or recommended, for a new source file or project repository.

In the big picture, we recommend SPDX based on the way it describes its
own use on spdx.org, which also disrecommends removing other people's
notices, and shows SPDX identifiers in use as machine-readable
supplements to human license notices.

The RMS article you link to encourages people to use both: "The way to
avoid these problems is by approving future GPL versions in the license
notice at the outset. Please put on each nontrivial file of the source
release a license notice *of the form shown at the end of the GPL
version you are using*" (emphasis mine). But it also just doesn't
address the question of removing/replacing notices.

I'm just a participant here, trying to offer feedback and help think
through things because Linux is an important example for others and
because I have a working interest in widely adopted best practices to
facilitate the easy, safe distribution of freedom-respecting software.
The specifics of the cases matter, and the copyright holders will make
their decisions about how to handle things; but when it comes to
describing the FSF's position, can you make some edits?

I think the position you're describing is probably right if the question
were "is the result of replacing the notices still at least minimally
acceptable according to the FSF for communicating the license"; but it's
not the answer to the posed question, "One consideration is whether
replacing existing license notices with more concise, machine-readable
expression of the same information could run afoul of a strict reading
of GPL-2.0, section 1."

-john

> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
>
> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>
> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>     Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.
>
> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>     Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>
> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
> 	
> 		#6a  An existing known additional license or exception for which there is an SPDX identifier
> 			 —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
> 			 —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders
>
> 		#6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
> 			--  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
> 			-- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
> 			-- If some mess of a license that is unclear, an abomination, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation 
>
> 		#6c   An additional or different disclaimer or warranty text:
> 			— Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL
> 			—  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
> 				—> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
> 				—> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0
> 	
> ========
>
> Please note: while I am a lawyer, I do not represent any kernel developers nor any of the people involved in this work. I understand that no lawyer could represent the interest of the Linux kernel and its many copyright holders in total. We can, however, discuss this in a public forum and come up with some consensus as to reasonable guidelines and rationale for such.
>
> I have tried to collect the various thoughts and opinions expressed on the mailing list on these topics. 
> I’m particularly interested in the following feedback:
> A) This takes a somewhat conservative approach regarding retaining some of the license notices and adding SPDX identifiers, rather than replacing. I’d like to know from those involved in using scanning tools (Thomas, Philippe) if this would be tenable. 
> B) Related to A, are there examples above noted for ADD, that you would feel comfortable with being REPLACE and if so, explain.
> C) I’m especially interested in Richard, Bradley and John’s view on #1-3 as they seemed to have the most initial concern here.
>
> Finally - don’t shoot the messenger :)
>
>
> Thanks,
> Jilayne
>
>
>
>

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
https://status.fsf.org/johns | https://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<https://my.fsf.org/join>.

Re: some ideas on guidelines

[Richard Fontana]

On Wed, Jun 12, 2019 at 1:25 AM J Lovejoy <opensource@jilayne.com> wrote:
>

> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.

This is sort of a nit but there is no (de facto) standard license
notice (in the GPL text) for the "-only" case. The closest we have to
a standard IMO is the abbreviated version that ends the first sentence
of the notice with "version N of the license."

Richard

Re: some ideas on guidelines

[Richard Fontana]

(Hoping I am responding in a way that conforms sufficiently to
Jilayne's as well as Greg K-H's expectations :)

On Wed, Jun 12, 2019 at 1:25 AM J Lovejoy <opensource@jilayne.com> wrote:
>
> Hi all,
>
> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.
>
> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency.

This is exactly the sort of writeup I was hoping someone would produce
in connection with this effort, so I am pleased to see it. :)


> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
>
> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
>
> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>
> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>
> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>
> NOTES RELATED TO #1-3:
> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
>
> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
> *  Although the license text itself recommends the use of the standard license notice, it is not a hard requirement of the license. The definitive text, as always, is the full text of the license itself. Notably, the license author/steward, the Free Software Foundation (FSF), encourages use of the standard header, but more broadly recommends clear communication of the license variant chosen for the given work as seen in various pages on their site.[1] Furthermore, Richard Stallman endorsed the use of the revised SPDX identifiers for helping provide clarity as to whether a licensor has chosen the license-version-only or any-later-version option.[2]

I don't find this convincing enough as to the basic GPL compliance
objection here, which should not be lost sight of. GPLv2 says:

"You may copy and distribute verbatim copies of the Program's source
code as you receive it, in any medium, provided that you conspicuously
and appropriately publish on each copy an appropriate copyright notice
and disclaimer of warranty; keep intact all the notices that refer to
this License and to the absence of any warranty . . . . "

The license seems to have a "hard requirement" that existing license
notices be "kept intact". So I think a stronger response to this
objection needs to be developed (and the approach this group takes
towards recommending removal or alteration of legal notices should be
influenced by consideration of the "keep intact" requirement of
GPLv2). One thing that just occurred to me is that the nominal
requirement to "conspicuously and appropriately publish on each copy
an appropriate copyright notice and disclaimer of warranty", which I
believe does not give rise to an affirmative obligation to do
*anything* (despite what it seems to say), may nonetheless add
legitimacy to the selective removal or alteration of source file
license notices and warranty disclaimers.

You could also consider mentioning the precedent set by BusyBox in
~2006, though I'm not sure how well documented this is. Bruce Perens
argued, IIRC, that BusyBox could not change GPLv2-or-later notices to
GPLv2-only, citing the "keep intact" requirement (effectively arguing
that a project with conventional license notices could never
distribute GPLv2-or-later code as GPLv2-only), but I believe the FSF
agreed with the position of the BusyBox maintainers at that time, and
a hint of this resolution crept into GPLv3. It just supports the idea
that the "keep intact" requirement shouldn't be read ultra-literally.

> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
>
> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>
> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>     Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.
>
> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>     Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

I'm not sure I agree with this, but one could argue it's not super-important.

I've taken issue with a few cases I've seen where the consensus of
this group is that "GPL-2.0-only" accurately describes the intent of a
license notice that references a copy of GPLv2 outside the context of
the kernel source code. In the notices I'm thinking of, the reference
to the GPLv2 text is sufficiently decoupled from a version-neutral or
version-ambiguous statement about the applicable license that I
believe an "or-later" permission is justifiably read into the notice.

> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
>
>                 #6a  An existing known additional license or exception for which there is an SPDX identifier
>                          —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
>                          —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders
>
>                 #6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
>                         --  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
>                         -- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
>                         -- If some mess of a license that is unclear, an abomination, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation

I found the use of "mess of a license" and "abomination" a little
unnecessarily disturbing there, and it called to my mind Thomas's
strong emotional reaction to the old Red Hat "GPL'd" license notices.
:) I think this guidance should try to be dispassionate.

>                 #6c   An additional or different disclaimer or warranty text:
>                         — Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL

Who are the "copyright holders" though? This could mean:
* The nominal copyright holders (in copyright notices juxaposed with
the license/disclaimer notices)
* The set of all discernible contributors to the file following the
inclusion of the legal notice at issue, including those not reflected
explicitly in copyright notices in the file (and/or their employers at
the time which in most cases would have had ownership interest in
copyright on those contributions from those authors)

I believe a good case could be made that the only copyright holders
you should have to contact are the ones in the first category, but
this may be controversial. In any case I think it ought to be
addressed in these guidelines.

>                         —  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
>                                 —> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
>                                 —> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0

So I agree with this at a high level, but we've seen that this is
potentially challenging in practice (or at least I think so), because
what "additional substantive aspects" are requires (in part) some
degree of legal analysis, or at least one could argue that. For a
simple example, is the addition of "as-is" substantive? Allison argues
no because "as-is" is used in the GPLv2 text itself. I am not so sure.
I have changed my view of this a couple of times. And again let's not
forget the compliance issue here: GPLv2 says you have to keep intact
all notices that refer to the absence of warranty.

Richard

Re: some ideas on guidelines

[J Lovejoy]

HI all,

John , Richard - thanks for the input. Sorry I haven’t had a chance to respond yet - may not have time until later this week, but didn’t want you to think I was ignoring you intentionally! (and am mulling over meaningful replies in the in between moments)

One quick clarification regarding my “abomination” comment - that is born out of my task of looking at the really messy files. You haven’t seen the patches for these yet, as it’s going to take a bit of un-winding to figure out the best route. But, yes, Richard, you are right, I should try to be a bit less emphatic ;) 

Thanks and be back soon,
Jilayne

> On Jun 14, 2019, at 8:25 AM, Richard Fontana <rfontana@redhat.com> wrote:
> 
> (Hoping I am responding in a way that conforms sufficiently to
> Jilayne's as well as Greg K-H's expectations :)
> 
> On Wed, Jun 12, 2019 at 1:25 AM J Lovejoy <opensource@jilayne.com> wrote:
>> 
>> Hi all,
>> 
>> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.
>> 
>> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency.
> 
> This is exactly the sort of writeup I was hoping someone would produce
> in connection with this effort, so I am pleased to see it. :)
> 
> 
>> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
>> 
>> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
>> 
>> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> NOTES RELATED TO #1-3:
>> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
>> 
>> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
>> *  Although the license text itself recommends the use of the standard license notice, it is not a hard requirement of the license. The definitive text, as always, is the full text of the license itself. Notably, the license author/steward, the Free Software Foundation (FSF), encourages use of the standard header, but more broadly recommends clear communication of the license variant chosen for the given work as seen in various pages on their site.[1] Furthermore, Richard Stallman endorsed the use of the revised SPDX identifiers for helping provide clarity as to whether a licensor has chosen the license-version-only or any-later-version option.[2]
> 
> I don't find this convincing enough as to the basic GPL compliance
> objection here, which should not be lost sight of. GPLv2 says:
> 
> "You may copy and distribute verbatim copies of the Program's source
> code as you receive it, in any medium, provided that you conspicuously
> and appropriately publish on each copy an appropriate copyright notice
> and disclaimer of warranty; keep intact all the notices that refer to
> this License and to the absence of any warranty . . . . "
> 
> The license seems to have a "hard requirement" that existing license
> notices be "kept intact". So I think a stronger response to this
> objection needs to be developed (and the approach this group takes
> towards recommending removal or alteration of legal notices should be
> influenced by consideration of the "keep intact" requirement of
> GPLv2). One thing that just occurred to me is that the nominal
> requirement to "conspicuously and appropriately publish on each copy
> an appropriate copyright notice and disclaimer of warranty", which I
> believe does not give rise to an affirmative obligation to do
> *anything* (despite what it seems to say), may nonetheless add
> legitimacy to the selective removal or alteration of source file
> license notices and warranty disclaimers.
> 
> You could also consider mentioning the precedent set by BusyBox in
> ~2006, though I'm not sure how well documented this is. Bruce Perens
> argued, IIRC, that BusyBox could not change GPLv2-or-later notices to
> GPLv2-only, citing the "keep intact" requirement (effectively arguing
> that a project with conventional license notices could never
> distribute GPLv2-or-later code as GPLv2-only), but I believe the FSF
> agreed with the position of the BusyBox maintainers at that time, and
> a hint of this resolution crept into GPLv3. It just supports the idea
> that the "keep intact" requirement shouldn't be read ultra-literally.
> 
>> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
>> 
>> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
>> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>> 
>> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>>    Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.
>> 
>> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>>    Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> 
> I'm not sure I agree with this, but one could argue it's not super-important.
> 
> I've taken issue with a few cases I've seen where the consensus of
> this group is that "GPL-2.0-only" accurately describes the intent of a
> license notice that references a copy of GPLv2 outside the context of
> the kernel source code. In the notices I'm thinking of, the reference
> to the GPLv2 text is sufficiently decoupled from a version-neutral or
> version-ambiguous statement about the applicable license that I
> believe an "or-later" permission is justifiably read into the notice.
> 
>> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
>> 
>>                #6a  An existing known additional license or exception for which there is an SPDX identifier
>>                         —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
>>                         —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders
>> 
>>                #6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
>>                        --  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
>>                        -- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
>>                        -- If some mess of a license that is unclear, an abomination, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation
> 
> I found the use of "mess of a license" and "abomination" a little
> unnecessarily disturbing there, and it called to my mind Thomas's
> strong emotional reaction to the old Red Hat "GPL'd" license notices.
> :) I think this guidance should try to be dispassionate.
> 
>>                #6c   An additional or different disclaimer or warranty text:
>>                        — Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL
> 
> Who are the "copyright holders" though? This could mean:
> * The nominal copyright holders (in copyright notices juxaposed with
> the license/disclaimer notices)
> * The set of all discernible contributors to the file following the
> inclusion of the legal notice at issue, including those not reflected
> explicitly in copyright notices in the file (and/or their employers at
> the time which in most cases would have had ownership interest in
> copyright on those contributions from those authors)
> 
> I believe a good case could be made that the only copyright holders
> you should have to contact are the ones in the first category, but
> this may be controversial. In any case I think it ought to be
> addressed in these guidelines.
> 
>>                        —  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
>>                                —> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
>>                                —> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0
> 
> So I agree with this at a high level, but we've seen that this is
> potentially challenging in practice (or at least I think so), because
> what "additional substantive aspects" are requires (in part) some
> degree of legal analysis, or at least one could argue that. For a
> simple example, is the addition of "as-is" substantive? Allison argues
> no because "as-is" is used in the GPLv2 text itself. I am not so sure.
> I have changed my view of this a couple of times. And again let's not
> forget the compliance issue here: GPLv2 says you have to keep intact
> all notices that refer to the absence of warranty.
> 
> Richard

Re: some ideas on guidelines

[J Lovejoy]

Hi Philppe,

See comments on tooling considerations below:

> On Jun 12, 2019, at 4:26 AM, Philippe Ombredanne <pombredanne@nexb.com> wrote:
> 
> Hi Jilayne:
> 
> On Wed, Jun 12, 2019 at 7:25 AM J Lovejoy <opensource@jilayne.com> wrote:
>> 
>> GOAL: The over-arching goal here is to provide clear, concise, and
>> machine-readable license information at the file-level for the Linux
>> kernel by placing SPDX License List short identifiers at the top of
>> each file in order to make it easier for downstream users and
>> distributors to use automated processes and comply with the applicable
>> license terms.
>> 
>> NOTE: The guidance is either to REPLACE the existing license notice
>> with the SPDX license identifier or ADD the SPDX license identifier.
>> The rationale here is that where the license notice is clear, then
>> replacing should be okay as this is essentially upgrading the current
>> notice to something more modern and machine readable. But everywhere
>> else, a conservative approach of adding the SPDX identifiers (and as
>> such, keeping the existing license notice info) means that others can
>> see both. This also avoids the need to create or retain some file with
>> all the removed notices, which seems to be distasteful and untenable
>> based on the threads related to that topic. The SPDX identifier still
>> needs to be accurate, of course.
>> 
>> TOOLING CONSIDERATION: To make it easier on tooling, putting some kind
>> of START/END notation, as Steve has recommended,
> 
> Having some convention to enclose a notice in some markers would have
> no impact and would not make it easier for scancode: the notice would
> be detected and reported if is enclosed in markers or not. This could
> be leveraged later as a way to speed things up of course, but that's
> minor.
> 
> If tagging notice text boundaries is the route selected for the
> kernel, then it is worth crafting something that is well thought out
> as the kernel ways **will** surely be adopted by other projects.
> 
> FWIW, here are a few examples of using such markers that exist in the
> wild from a quick grep in scancode license notices database:
> 
> - Mozilla: BEGIN LICENSE BLOCK/ END LICENSE BLOCK
> - Apple: @APPLE_LICENSE_HEADER_START@
> @APPLE_LICENSE_HEADER_END@ and some variations
> - Oracle: CDDL HEADER START/END , GPL HEADER START/END, LGPL HEADER
> START/END used with their highly impractical "DO NOT ALTER OR REMOVE
> COPYRIGHT NOTICES OR THIS FILE HEADER."
> - LICENSE_START/LICENSE_END (and variations such as %%%LICENSE_START
> used in some man pages and tools including the kernel)
> - BSDCOPYRIGHTBEGIN, ECOSGPLCOPYRIGHTBEGIN and other variations in eCos.
> - Qt and KDE: QT_BEGIN_LICENSE with variations
> - COPYRIGHTBEGIN/END
> - Begin-Header/End-Header
> - BEGIN LICENSE TEXT/END LICENSE TEXT
> 
>> thus allowing tooling
>> to ignore what’s enclosed there and just read the SPDX identifier as
>> the definitive license notice.
> 
> There is something inconsistent here:
well, it’s not inconsistent, really and it is consistent with the SPDX spec, actually… more below...

> either a custom notice or
> disclaimer is needed and has some legal importance
> or it has none and
> should be removed.

but you are making the wildly optimistic assumption that such determination is black and white, it is not. Reasonable attorneys may disagree as to what is of “legal importance” or not in these cases and ultimately, we don’t decide a judge does.

This is the challenge, as I implicitly note below, of the Linux kernel not having its own lawyer or one point of responsibility.  We are collectively making a decision that impacts lots and lots of Linux users. 

If we had some text that we all generally agreed we didn’t think was substantively adding anything to the standard disclaimer text and thus, just used the GPL-2.0-[only / or-later] tag and didn’t add a new SPDX identifier to represent the non-substantive text - we’d basically be following the advice of the SPDX spec for section 4.6 License Information in File (represented by the stuff found in the file that we left there, but enclosed in some kind of denotation) and section 4.5 Concluded License (represented by the SPDX license identifier)

Don’t get me wrong - the best case scenario for these kinds of things is to have the copyright holder clean it up - but just trying to come up with something for when that’s not feasible that is a bit on the conservative side and accommodates the concerns raised about full-scale removing stuff. 

> If it has some importance and needs to be kept,
> then I cannot "just read the SPDX identifier as the definitive license
> notice" as you wrote, I think I would need to consider both the id and
> extra notice. Or am I missing something?

yes and no. see above :)

> 
>> As time goes by, if copyright holders
>> come across these files and want to remove the original notices, then
>> they have the right to do so.
>> 
>> GUIDANCE: The following is meant to provide some high-level guidance
>> for how to handle common scenarios and triage the approaches to reach
>> the stated goal.
>> The following is not intended to be legal advice. Rather, it is meant
>> to reflect the intention of the participating individuals to improve
>> the quality and machine-readability of the applicable license
>> information in Linux kernel files. The approach described below has
>> been developed with the Linux kernel in mind and might not be
>> appropriate for other projects or communities.
>> 
>> #1   Where a file contains the standard license notice as stated in
>> the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no
>> other license information whatsoever —> then REPLACE the standard
>> license notice with the SPDX identifier for the relevant license.
>> 
>> #2   Where a file contains a non-substantive variation on the standard
>> GPL-2.0 license notice, but still provides clear distinction as to
>> GPL-2.0-only or GPL-or-later consistent with the intent of the
>> standard license notice and no other license information whatsoever
>> —> then REPLACE the standard license notice with the SPDX identifier
>> for the relevant license.
>> 
>> #3   Where a file contains a license notice that is non-standard as
>> compared to that stated in the GPL-2.0 license text but is nonetheless
>> clear as to GPL-2.0-only or GPL-2.0-or-later and no other license
>> information whatsoever —> then REPLACE the standard license notice
>> with the SPDX identifier for the relevant license.
>> 
>> NOTES RELATED TO #1-3:
>> The SPDX identifier is simply a more concise way to express the same
>> intention regarding what license applies to the file as the standard
>> license notice, but does so in a reliably, machine-readable way that
>> meets the needs of modern software supply chain use and efforts to
>> automate detection of license information in order to facilitate more
>> complete license information and license compliance. One consideration
>> is whether replacing existing license notices with more concise,
>> machine-readable expression of the same information could run afoul of
>> a strict reading of GPL-2.0, section 1.
>> Such a strict reading applied to the scenarios described in #1-3 is
>> unconvincing for the following reasons:
>> *  Although the license text itself recommends the use of the standard
>> license notice, it is not a hard requirement of the license. The
>> definitive text, as always, is the full text of the license itself.
>> Notably, the license author/steward, the Free Software Foundation
>> (FSF), encourages use of the standard header, but more broadly
>> recommends clear communication of the license variant chosen for the
>> given work as seen in various pages on their site.[1] Furthermore,
>> Richard Stallman endorsed the use of the revised SPDX identifiers for
>> helping provide clarity as to whether a licensor has chosen the
>> license-version-only or any-later-version option.[2]
>> *  This project to improve license information in the Linux kernel
>> files has been discussed among kernel developers, on kernel mailing
>> lists, and documented in public files and documentation beginning in
>> mid-20173 to which many kernel copyright holders past and present have
>> access and would be likely to see and which has received positive
>> response and encouragement.
>> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the
>> standard license notice, but then also goes on to
>> https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest
>> one clear and explicit statement such as, “This program is released
>> under license FOO”. FAQ questions and https://www.gnu.org/licenses
>> /gpl-faq.en.html#NoticeInSourceFile also stress the general need for
>> clarity without mandating use of the specific standard license notice.
>> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>> 
>> #4   Where the file contains a license notice that clearly states the
>> file is licensed under “GPL” with no indication of version number
>> and no other license information whatsoever —> ADD SPDX identifier
>> for GPL-2.0-or-later
>>    Rationale: This is consistent with the text of the license which
>> states, “If the Program does not specify a version number of this
>> License, you may choose any version ever published by the Free
>> Software Foundation.” Because the Linux kernel is well-known to be
>> licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it
>> within the options given in the license text to choose GPL-2.0-or-
>> later in this case. Doing so more easily enables use of such files
>> beyond the Linux kernel.
> 
> Just FYI,  I am fine with a GPL-2.0-or-later choice for the kernel,
> but scancode will report these cases as GPL-1.0-or-later.

good to know, thanks.  I don’t think that is an issue, agree?

> 
>> #5   Where the file contains a license notice that: a) refers to the
>> COPYING file or another specific file (or references GPL and the
>> COPYING or another specific file) with no other information as to the
>> specific license whatsoever; and b) the COPYING or other specific file
>> can be located and is clearly a copy of GPL-2.0  —> ADD SPDX
>> identifier for GPL-2.0-only
>>    Rationale: This is similar to #4, but the combination of a clear
>> reference to a specific license file and the fact that the Linux
>> kernel is clearly intended to be GPL-2.0-only leads to the intent that
>> this is also GPL-2.0-only. The COPYING file currently in the kernel is
>> at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>> tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the
>> COPYING file also had Linus expressing GPL-2.0-only: see https://git.k
>> ernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?i
>> d=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> 
>> #6   Where a file contains a license notice that is non-standard as
>> compared to that stated in the GPL-2.0 license text but in nonetheless
>> clear as to GPL-2.0-only or GPL-2.0-or-later and there is other
>> license information, and that license information contains the
>> following:
>>                #6a  An existing known additional license or exception
>> for which there is an SPDX identifier
>>                         —> ADD appropriate SPDX license expression
>> (use of AND, OR, WITH), where person making change is does not
>> represent copyright holders for file
>>                         —> REPLACE with appropriate SPDX license
>> expression, where person(s) making or signing-off on changes represent
>> copyright holders
>>                #6b   An additional license or exception for which
>> there is no SPDX identifier as per the existing SPDX License List
>> Matching Guidelines:
>>                        --  If clearly a different license and use is
>> more than one or two files, then submit for addition to SPDX License
>> List at http://13.57.134.254/app/submit_new_license/
>>                        -- If close to an existing license/exception
>> on the SPDX License List such that the SPDX license’s matching
>> markup might be extended to accommodate as a match, submit to SPDX
>> legal team for review of such.
>>                        -- If some mess of a license that is unclear,
>> an abomination, contains non-free elements, or otherwise poses some
>> kind of challenge, then attempt to contact copyright holders to change
>> license with recommendation
>>                #6c   An additional or different disclaimer or
>> warranty text:
>>                        — Where the copyright holders of the file in
>> questions can be contacted, then ask them to remove this and use the
>> appropriate SPDX identifier for GPL
>>                        —  Where copyright holders of the file in
>> question cannot be easily contacted or found, then analyze differences
>> between additional disclaimer text and standard disclaimer included in
>> GPL, then:
>>                                —> if additional disclaimer text
>> adds no additional substantive aspects to the standard GPL disclaimer,
>> REPLACE with appropriate SPDX license identifier for GPL-2.0
>>                                —> If additional disclaimer text
>> adds additional substantive aspects to the standard GPL disclaimer,
>> ADD the appropriate SPDX license identifier for GPL-2.0
>> ========
>> Please note: while I am a lawyer, I do not represent any kernel
>> developers nor any of the people involved in this work. I understand
>> that no lawyer could represent the interest of the Linux kernel and
>> its many copyright holders in total. We can, however, discuss this in
>> a public forum and come up with some consensus as to reasonable
>> guidelines and rationale for such.
>> I have tried to collect the various thoughts and opinions expressed on
>> the mailing list on these topics.
>> I’m particularly interested in the following feedback:
>> A) This takes a somewhat conservative approach regarding retaining
>> some of the license notices and adding SPDX identifiers, rather than
>> replacing. I’d like to know from those involved in using scanning
>> tools (Thomas, Philippe) if this would be tenable.
> 
> Speaking for the scanning tool in use here (i.e. the scancode-toolkit)
> having SPDX ids alone or with some extra notice has no impact. The
> SPDX id and the license notice will be detected and each detected
> texts reported with their own corresponding license expression (which
> would happen to be the same and that can later be combined and
> simplified in a single expression.)
> 
> It would likely not impact checkpatch.pl either since it cares only
> about the SPDX identifiers.
> 
> BUT If you start to butcher the original notice (such as you remove
> the GPL notice part and keep a warranty disclaimer) the detection
> results will be butchered accordingly and that standalone disclaimer
> will be eventually detected either as a bare disclaimer with no
> related license or as a partial detection of an another notice (since
> scancode eventually does a multidiff/red line comparison).

good to know. I don’t think I intended to suggest we’d butcher up the existing notice - I think we either leave it all in, and ADD SPDX identifier or REPLACE it all.  That was what I was trying to delineate here overall.

I think these disclaimers ones are particular tricky. Might be worth trying to settle some of the other threshold issues raised by John and Richard (response to those next and in order!) and then come back to this.

Thanks,
Jilayne

> The same would likely apply to other license scanners that do not use
> a diff, though this could be amplified as regex-based scanners such as
> Fossology may get unlucky and miss having a regex for the butchered
> text and probabilistic scanners such as Licensee and many others may
> see the butchered text going below their false positive threshold and
> ignore it entirely.
> 
> Therefore my advice would be either to keep a complete and consistent
> notice or to keep none e.g. avoid cherry picking parts of a notice as
> this will surely result in some license detection but not the one you
> would expect: it will likely be inconclusive and require more review.
> 
> --
> Cordially
> Philippe Ombredanne

Re: some ideas on guidelines

[J Lovejoy]

> On Jun 12, 2019, at 10:04 AM, John Sullivan <johns@fsf.org> wrote:
> 
> Thank you for doing this! It's very helpful to have guidelines like this
> to bring everything together. I hope to offer some more feedback, but
> wanted to comment now on the description of the FSF's position:

Good and thanks for commenting so!  I figured it’s always easier to start with something and then pick at it and refine it ;)

> 
> J Lovejoy <opensource@jilayne.com> writes:
> 
>> Hi all,
>> 
>> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.  
>> 
>> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency. 
>> 
>> The key points I’ve come up with are as follows. PLEASE NOTE - I have tried to format this so it will read correctly in plain text. When responding, please do not cut out large parts of this as the context will be lost and a different meaning may be implied. (I know this is breaking Greg’s rules, but it’s kind of important to keep the whole context in this case.)  At the bottom of this email, I have identified specific feedback from specific people which would be really helpful. 
>> 
>> ========
>> GOAL: The over-arching goal here is to provide clear, concise, and machine-readable license information at the file-level for the Linux kernel by placing SPDX License List short identifiers at the top of each file in order to make it easier for downstream users and distributors to use automated processes and comply with the applicable license terms.
>> 
>> NOTE: The guidance is either to REPLACE the existing license notice with the SPDX license identifier or ADD the SPDX license identifier. The rationale here is that where the license notice is clear, then replacing should be okay as this is essentially upgrading the current notice to something more modern and machine readable. But everywhere else, a conservative approach of adding the SPDX identifiers (and as such, keeping the existing license notice info) means that others can see both. This also avoids the need to create or retain some file with all the removed notices, which seems to be distasteful and untenable based on the threads related to that topic. The SPDX identifier still needs to be accurate, of course. 
>> 
>> TOOLING CONSIDERATION: To make it easier on tooling, putting some kind of START/END notation, as Steve has recommended, thus allowing tooling to ignore what’s enclosed there and just read the SPDX identifier as the definitive license notice. As time goes by, if copyright holders come across these files and want to remove the original notices, then they have the right to do so. 
>> 
>> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
>> 
>> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
>> 
>> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> NOTES RELATED TO #1-3:
>> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
>> 
>> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
>> *  Although the license text itself recommends the use of the standard
>> license notice, it is not a hard requirement of the license. The
>> definitive text, as always, is the full text of the license itself.
>> Notably, the license author/steward, the Free Software Foundation
>> (FSF), encourages use of the standard header, but more broadly
>> recommends clear communication of the license variant chosen for the
>> given work as seen in various pages on their site.[1] Furthermore,
>> Richard Stallman endorsed the use of the revised SPDX identifiers for
>> helping provide clarity as to whether a licensor has chosen the
>> license-version-only or any-later-version option.[2]
> 
> Hmm. FSF didn't and doesn't blanketly endorse removal of license notices
> by non copyright holders. That is a separate question from the FAQs
> you're citing, which are about what kind of notice is minimally
> acceptable, or recommended, for a new source file or project repository.
> 
> In the big picture, we recommend SPDX based on the way it describes its
> own use on spdx.org, which also disrecommends removing other people's
> notices, and shows SPDX identifiers in use as machine-readable
> supplements to human license notices.

I didn’t mean to imply the FSF was saying *remove* notices from other copyright holders. But what would be tremendously helpful is if the FSF could explicitly say that using the SPDX-License-Identifier tag is just as good (or even better, given tooling of current day?!) than using the recommended license notice in the addendum to the license. I don’t think this is really even controversial - even with GPL-3.0 in 2007, automated tooling was no where near where it is today, not to mention the scale of use of OSS.  The message I got from RMS when we were in the process of changing the SPDX identifiers for the GNU family of licenses and which I think comes out in his article on the topic is: just be clear!

> 
> The RMS article you link to encourages people to use both: "The way to
> avoid these problems is by approving future GPL versions in the license
> notice at the outset. Please put on each nontrivial file of the source
> release a license notice *of the form shown at the end of the GPL
> version you are using*" (emphasis mine). But it also just doesn't
> address the question of removing/replacing notices.

Agreed and I wouldn’t expect the FSF to address that. But the FSF *could* be flexible about how to be clear and recognize that the SPDX-License-Identifier is more machine-friendly given the current reality.

> 
> I'm just a participant here, trying to offer feedback and help think
> through things because Linux is an important example for others and
> because I have a working interest in widely adopted best practices to
> facilitate the easy, safe distribution of freedom-respecting software.
> The specifics of the cases matter, and the copyright holders will make
> their decisions about how to handle things; but when it comes to
> describing the FSF's position, can you make some edits?

Sure! can you agree with the clarifications above? 


> 
> I think the position you're describing is probably right if the question
> were "is the result of replacing the notices still at least minimally
> acceptable according to the FSF for communicating the license"; but it's
> not the answer to the posed question, "One consideration is whether
> replacing existing license notices with more concise, machine-readable
> expression of the same information could run afoul of a strict reading
> of GPL-2.0, section 1.”

Well, one answer to that question *could* be for an addition or expansion of the Community Principles of Enforcement that where people are tying to make things better for license identification, the community enforcers would not bring a non-compliance action where the “non-compliance” is merely replacing an “old” license notice with a newer, clearer one (where the meaning is clear). Just a thought.

I have also realized through all this - the Linux kernel is kind of unique here: it’s old, it has lots o’files, and many many contributors/copyright holders. If I worked for a company that had open source projects under an inbound=outbound model with external contributors and we wanted to upgrade the license notice from, say all the text of the license (for something like BSD-3-Clause) to just the SPDX-License-Identifier, I’d feel pretty comfortable doing that (oh wait, I might have already done that…) but this is just different for a number of reasons and that makes it a bit less comfortable. 

Maybe the good thing about acknowledging this is that ‘what’s good for the kernel’ in terms of methodology is just not going to map on most other projects. In other words, most other projects are not going to have the same challenges we are experiencing here.

Just another thought there!

thanks,
Jilayne

> 
> -john
> 
>> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
>> 
>> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
>> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>> 
>> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>>    Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.
>> 
>> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>>    Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> 
>> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
>> 	
>> 		#6a  An existing known additional license or exception for which there is an SPDX identifier
>> 			 —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
>> 			 —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders
>> 
>> 		#6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
>> 			--  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
>> 			-- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
>> 			-- If some mess of a license that is unclear, an abomination, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation 
>> 
>> 		#6c   An additional or different disclaimer or warranty text:
>> 			— Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL
>> 			—  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
>> 				—> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
>> 				—> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0
>> 	
>> ========
>> 
>> Please note: while I am a lawyer, I do not represent any kernel developers nor any of the people involved in this work. I understand that no lawyer could represent the interest of the Linux kernel and its many copyright holders in total. We can, however, discuss this in a public forum and come up with some consensus as to reasonable guidelines and rationale for such.
>> 
>> I have tried to collect the various thoughts and opinions expressed on the mailing list on these topics. 
>> I’m particularly interested in the following feedback:
>> A) This takes a somewhat conservative approach regarding retaining some of the license notices and adding SPDX identifiers, rather than replacing. I’d like to know from those involved in using scanning tools (Thomas, Philippe) if this would be tenable. 
>> B) Related to A, are there examples above noted for ADD, that you would feel comfortable with being REPLACE and if so, explain.
>> C) I’m especially interested in Richard, Bradley and John’s view on #1-3 as they seemed to have the most initial concern here.
>> 
>> Finally - don’t shoot the messenger :)
>> 
>> 
>> Thanks,
>> Jilayne
>> 
>> 
>> 
>> 
> 
> -- 
> John Sullivan | Executive Director, Free Software Foundation
> GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
> https://status.fsf.org/johns | https://fsf.org/blogs/RSS
> 
> Do you use free software? Donate to join the FSF and support freedom at
> <https://my.fsf.org/join>.

Re: some ideas on guidelines

[J Lovejoy]

and now my belated response to Richard’s comments as well :)

Thanks,
Jilayne

> On Jun 14, 2019, at 8:25 AM, Richard Fontana <rfontana@redhat.com> wrote:
> 
> (Hoping I am responding in a way that conforms sufficiently to
> Jilayne's as well as Greg K-H's expectations :)
> 
> On Wed, Jun 12, 2019 at 1:25 AM J Lovejoy <opensource@jilayne.com> wrote:
>> 
>> Hi all,
>> 
>> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.
>> 
>> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency.
> 
> This is exactly the sort of writeup I was hoping someone would produce
> in connection with this effort, so I am pleased to see it. :)

yeah! glad it’s helpful!

> 
> 
>> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
>> 
>> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
>> 
>> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
>> 
>> NOTES RELATED TO #1-3:
>> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
>> 
>> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
>> *  Although the license text itself recommends the use of the standard license notice, it is not a hard requirement of the license. The definitive text, as always, is the full text of the license itself. Notably, the license author/steward, the Free Software Foundation (FSF), encourages use of the standard header, but more broadly recommends clear communication of the license variant chosen for the given work as seen in various pages on their site.[1] Furthermore, Richard Stallman endorsed the use of the revised SPDX identifiers for helping provide clarity as to whether a licensor has chosen the license-version-only or any-later-version option.[2]
> 
> I don't find this convincing enough as to the basic GPL compliance
> objection here, which should not be lost sight of. GPLv2 says:
> 
> "You may copy and distribute verbatim copies of the Program's source
> code as you receive it, in any medium, provided that you conspicuously
> and appropriately publish on each copy an appropriate copyright notice
> and disclaimer of warranty; keep intact all the notices that refer to
> this License and to the absence of any warranty . . . . "
> 
> The license seems to have a "hard requirement" that existing license
> notices be "kept intact". So I think a stronger response to this
> objection needs to be developed (and the approach this group takes
> towards recommending removal or alteration of legal notices should be
> influenced by consideration of the "keep intact" requirement of
> GPLv2). One thing that just occurred to me is that the nominal
> requirement to "conspicuously and appropriately publish on each copy
> an appropriate copyright notice and disclaimer of warranty", which I
> believe does not give rise to an affirmative obligation to do
> *anything* (despite what it seems to say), may nonetheless add
> legitimacy to the selective removal or alteration of source file
> license notices and warranty disclaimers.

well, yeah, a stronger argument here would be helpful. I just thought that if we could get some explicit support from the FSF  that SPDX identifiers are just as fine to use as the standard header in the license appendix, then that would be one helpful point. Of course, the FSF is not the copyright holder of all GPL code, but they are influential.

At a more practical level, I was trying to think through how an action for non-compliance based on this would play out. Here’s some thoughts on that:
- the license notices are replaced with SPDX identifiers in a bunch of kernel files by various kernel maintainers and other copyright holders
- AcmeCo redistributes the kernel and is in FULL compliance with the kernel licenses
- NastyPlaintiff brings a license non-compliance action against AcmeCo based on the replacement of the license notices, claiming its a violation of the “keep intact” clause. First of all, how is Acme non-compliant - they kept every notice as they found it intact, Acme didn’t remove/replace anything. Then what?  I also would think that a judge wouldn’t be very pleased with such a frivolous suit.
- Now if AcmeCo was non-compliant with GPL in other ways (not providing source code, for example), then the “keep intact” argument is sort of a side show (and see previous point)

Now I’m not a litigator and I know we have a sort of people-can-sue-for-almost-anything, but you have to have a cause of action, and there usually has to be some harm. There’s certainly no harm in improving the state of the license notice. Full-on removing it would be a different scenario and I suspect that part of the license was written with the latter case in mind.

> 
> You could also consider mentioning the precedent set by BusyBox in
> ~2006, though I'm not sure how well documented this is. Bruce Perens
> argued, IIRC, that BusyBox could not change GPLv2-or-later notices to
> GPLv2-only, citing the "keep intact" requirement (effectively arguing
> that a project with conventional license notices could never
> distribute GPLv2-or-later code as GPLv2-only), but I believe the FSF
> agreed with the position of the BusyBox maintainers at that time, and
> a hint of this resolution crept into GPLv3. It just supports the idea
> that the "keep intact" requirement shouldn't be read ultra-literally.

hmmm… not familiar with this and not sure I’m following… but if you think that’s helpful, then would be good to understand better!

> 
>> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
>> 
>> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
>> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>> 
>> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>>    Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.
>> 
>> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>>    Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> 
> I'm not sure I agree with this, but one could argue it's not super-important.
> 
> I've taken issue with a few cases I've seen where the consensus of
> this group is that "GPL-2.0-only" accurately describes the intent of a
> license notice that references a copy of GPLv2 outside the context of
> the kernel source code. In the notices I'm thinking of, the reference
> to the GPLv2 text is sufficiently decoupled from a version-neutral or
> version-ambiguous statement about the applicable license that I
> believe an "or-later" permission is justifiably read into the notice.

And this is the challenge with trying to come up with guidelines… there’s too many, ‘well, it depends’ scenarios. But if I put that much detail into this guideline, then it probably wouldn’t be a guideline, but simply specific advice!  But for this one, maybe we need to look at the various examples and there may be a couple sub-guidelines here.

> 
>> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
>> 
>>                #6a  An existing known additional license or exception for which there is an SPDX identifier
>>                         —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
>>                         —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders
>> 
>>                #6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
>>                        --  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
>>                        -- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
>>                        -- If it is messy, unclear, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation
> 
> I found the use of "mess of a license" and "abomination" a little
> unnecessarily disturbing there, and it called to my mind Thomas's
> strong emotional reaction to the old Red Hat "GPL'd" license notices.
> :) I think this guidance should try to be dispassionate.

I revised the text above :)

> 
>>                #6c   An additional or different disclaimer or warranty text:
>>                        — Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL
> 
> Who are the "copyright holders" though? This could mean:
> * The nominal copyright holders (in copyright notices juxaposed with
> the license/disclaimer notices)
> * The set of all discernible contributors to the file following the
> inclusion of the legal notice at issue, including those not reflected
> explicitly in copyright notices in the file (and/or their employers at
> the time which in most cases would have had ownership interest in
> copyright on those contributions from those authors)

My assumption was the first set you mention + any significant subsequent contributors where such contributions is arguably copyright-able. I make that latter qualification (which is not easy, I know) because having looked at the Credit data for some of the files, there are times where one person wrote a file and then a bunch of people made really minor changes, I have a hard time thinking that one word changes or updating a reference equates to that person having copyright in that file. But, of course, there is no clear cut line on this.

> 
> I believe a good case could be made that the only copyright holders
> you should have to contact are the ones in the first category, but
> this may be controversial. In any case I think it ought to be
> addressed in these guidelines.

I had an inclination in this direction too, but I can’t really explain why. Can you provide a bit more of your thinking here?

> 
>>                        —  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
>>                                —> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
>>                                —> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0
> 
> So I agree with this at a high level, but we've seen that this is
> potentially challenging in practice (or at least I think so), because
> what "additional substantive aspects" are requires (in part) some
> degree of legal analysis, or at least one could argue that. For a
> simple example, is the addition of "as-is" substantive? Allison argues
> no because "as-is" is used in the GPLv2 text itself. I am not so sure.
> I have changed my view of this a couple of times. And again let's not
> forget the compliance issue here: GPLv2 says you have to keep intact
> all notices that refer to the absence of warranty.
> 
> Richard

Re: some ideas on guidelines

[J Lovejoy]

Hi all, 

It’d be great if we could get some more feedback and ultimately consensus here. John, Philippe, and Richard had some responses back in June, to which I then responded to, but no further traffic on this topic. 

There were a few things in there that seem non-controversial (at least in the sense that the comments from the three didn’t at all touch on them) - can I get confirmation on a few of the things as noted below, so we can make some more progress?  I’ve also added one more guideline, #7.

Thanks! (and hope everyone has been having a good summer!)

Cheers, Jilayne

> On Jun 11, 2019, at 11:25 PM, J Lovejoy <opensource@jilayne.com> wrote:
> 
> Hi all,
> 
> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.  
> 
> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency. 
> 
> The key points I’ve come up with are as follows. PLEASE NOTE - I have tried to format this so it will read correctly in plain text. When responding, please do not cut out large parts of this as the context will be lost and a different meaning may be implied. (I know this is breaking Greg’s rules, but it’s kind of important to keep the whole context in this case.)  At the bottom of this email, I have identified specific feedback from specific people which would be really helpful. 
> 
> ========
> GOAL: The over-arching goal here is to provide clear, concise, and machine-readable license information at the file-level for the Linux kernel by placing SPDX License List short identifiers at the top of each file in order to make it easier for downstream users and distributors to use automated processes and comply with the applicable license terms.
> 
> NOTE: The guidance is either to REPLACE the existing license notice with the SPDX license identifier or ADD the SPDX license identifier. The rationale here is that where the license notice is clear, then replacing should be okay as this is essentially upgrading the current notice to something more modern and machine readable. But everywhere else, a conservative approach of adding the SPDX identifiers (and as such, keeping the existing license notice info) means that others can see both. This also avoids the need to create or retain some file with all the removed notices, which seems to be distasteful and untenable based on the threads related to that topic. The SPDX identifier still needs to be accurate, of course. 
> 
> TOOLING CONSIDERATION: To make it easier on tooling, putting some kind of START/END notation, as Steve has recommended, thus allowing tooling to ignore what’s enclosed there and just read the SPDX identifier as the definitive license notice. As time goes by, if copyright holders come across these files and want to remove the original notices, then they have the right to do so. 
> 
> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
> 
> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
> 
> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
> 
> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
> 
> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
> 
> NOTES RELATED TO #1-3:
> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
> 
> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
> *  Although the license text itself recommends the use of the standard license notice, it is not a hard requirement of the license. The definitive text, as always, is the full text of the license itself. Notably, the license author/steward, the Free Software Foundation (FSF), encourages use of the standard header, but more broadly recommends clear communication of the license variant chosen for the given work as seen in various pages on their site.[1] Furthermore, Richard Stallman endorsed the use of the revised SPDX identifiers for helping provide clarity as to whether a licensor has chosen the license-version-only or any-later-version option.[2]
> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
> 
> [1] See https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
> 
> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>    Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.

Please confirm that everyone agrees with this approach, in particular that we would leave the existing license notice in place and simply ADD the SPDX Identifier.

> 
> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>    Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> 
> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
> 	
> 		#6a  An existing known additional license or exception for which there is an SPDX identifier
> 			 —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
> 			 —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders

Please confirm that everyone agrees with this approach, in particular that we would leave the existing license notice in place and simply ADD the SPDX Identifier.

> 
> 		#6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
> 			--  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at http://13.57.134.254/app/submit_new_license/
> 			-- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
> 			-- If some mess of a license that is unclear, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation 
> 
> 		#6c   An additional or different disclaimer or warranty text:
> 			— Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL
> 			—  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
> 				—> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
> 				—> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0
> 	

#7 Where a file contains a license text for a license (nothing related to GPL) that is on the SPDX License List  —> ADD SPDX Identifier for that license (retain license text)

Please confirm that everyone agrees with this approach, in particular that we would leave the existing license in place and simply ADD the SPDX Identifier.


NOTE:  I’m proceeding with the assumption that retaining the existing license notice or license text in particular is ok - we can always remove it later, especially if the copyright holder(s) notice and want to do so themselves. But at least it’s a n incremental approach.



> ========
> 
> Please note: while I am a lawyer, I do not represent any kernel developers nor any of the people involved in this work. I understand that no lawyer could represent the interest of the Linux kernel and its many copyright holders in total. We can, however, discuss this in a public forum and come up with some consensus as to reasonable guidelines and rationale for such.
> 
> I have tried to collect the various thoughts and opinions expressed on the mailing list on these topics. 
> I’m particularly interested in the following feedback:
> A) This takes a somewhat conservative approach regarding retaining some of the license notices and adding SPDX identifiers, rather than replacing. I’d like to know from those involved in using scanning tools (Thomas, Philippe) if this would be tenable. 
> B) Related to A, are there examples above noted for ADD, that you would feel comfortable with being REPLACE and if so, explain.
> C) I’m especially interested in Richard, Bradley and John’s view on #1-3 as they seemed to have the most initial concern here.
> 
> Finally - don’t shoot the messenger :)
> 
> 
> Thanks,
> Jilayne
> 
> 
> 

Re: some ideas on guidelines

[Greg KH]

On Sat, Aug 17, 2019 at 01:55:23PM -0600, J Lovejoy wrote:
> > #4   Where the file contains a license notice that clearly states
> > the file is licensed under “GPL” with no indication of version
> > number and no other license information whatsoever —> ADD SPDX
> > identifier for GPL-2.0-or-later Rationale: This is consistent with
> > the text of the license which states, “If the Program does not
> > specify a version number of this License, you may choose any version
> > ever published by the Free Software Foundation.” Because the Linux
> > kernel is well-known to be licensed under GPL-2.0-only and use of
> > GPL-1.0 is generally sparse, it within the options given in the
> > license text to choose GPL-2.0-or-later in this case. Doing so more
> > easily enables use of such files beyond the Linux kernel.
> 
> Please confirm that everyone agrees with this approach, in particular
> that we would leave the existing license notice in place and simply
> ADD the SPDX Identifier.

Sorry, I missed this one.  No, I do not agree with this as the kernel
has never been "2 or later" for the main license.  "2-only" should be
what is done here as that reflects the license of the kernel as a whole.

Also, I think we caught most of these files already that had this type
of marking, so I don't know if it's even an issue anymore, is it?

And no one except HURD is going to be trying to use Linux files in other
projects :)

thanks,

greg k-h

Re: some ideas on guidelines

[Richard Fontana]

On Sun, Aug 18, 2019 at 1:08 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> And no one except HURD is going to be trying to use Linux files in other
> projects :)

I've actually encountered a few cases over the years where there was
some desire to reuse Linux files, or portions of Linux files anyway,
in non-Linux projects (and not HURD :), in situations where the
presumption that the code was copyrightable and that the applicable
license was GPLv2, or at least GPLv2-only, was problematic. In one of
these cases, it was a GPLv3 project (Samba) that wished to use the
Linux code. They ended up asking Red Hat for a GPLv3-or-later license.
I think both of the non-Samba cases involved some code that was
generally useful in contexts having nothing to do with the kernel.

Granted, though, that's maybe 2-3 cases I am familiar with over a ~10
year period.

Richard

Re: some ideas on guidelines

[Christoph Hellwig]

I know a project that reuses a lot of kernel code (xfsprogs), and we
are perfectly fine with GPLv2 only, and we have a few others that
are pretty similar.

Re: some ideas on guidelines

[Greg KH]

On Sun, Aug 18, 2019 at 06:08:40PM -0400, Richard Fontana wrote:
> On Sun, Aug 18, 2019 at 1:08 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > And no one except HURD is going to be trying to use Linux files in other
> > projects :)
> 
> I've actually encountered a few cases over the years where there was
> some desire to reuse Linux files, or portions of Linux files anyway,
> in non-Linux projects (and not HURD :), in situations where the
> presumption that the code was copyrightable and that the applicable
> license was GPLv2, or at least GPLv2-only, was problematic. In one of
> these cases, it was a GPLv3 project (Samba) that wished to use the
> Linux code. They ended up asking Red Hat for a GPLv3-or-later license.
> I think both of the non-Samba cases involved some code that was
> generally useful in contexts having nothing to do with the kernel.

Great, but then it should be GPLv2 like the original COPYING file says,
and not "or later" like it never said.

That's my point, yes, other projects use kernel files all the time
(Spongebob squarepants video game stole our string handling functions)
but if they want a different license for it, they need to get permission
to change it.

thanks,

greg k-h