> On Jun 12, 2019, at 10:04 AM, John Sullivan <johns@xxxxxxx> 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@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. 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>.
