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@xxxxxxxxxxx> 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>.
