From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23679C43613 for ; Mon, 24 Jun 2019 01:48:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB47A2063F for ; Mon, 24 Jun 2019 01:48:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=jilayne.com header.i=@jilayne.com header.b="BeXKO+jC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726331AbfFXBs3 (ORCPT ); Sun, 23 Jun 2019 21:48:29 -0400 Received: from mx2-c1.supremebox.com ([198.23.53.234]:50875 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726323AbfFXBs3 (ORCPT ); Sun, 23 Jun 2019 21:48:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jilayne.com ; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=KsgDprgOhTZSULuKtf/1G8YSIBvAYNnsdAkcTkbrzlY=; b=BeXKO+jC72W/KYU/AYNXspdZmS BrlpxRs+rqFMvYwzOd2aelqvDXGhi1vxFJ7s/9Sn1YZq6cfFu3RHSCuJ4QJ1EZaPGqeSsBh2AlSxN Kp7Xmluw6bI7rWs3X/cerd1MGRyw43oUuyuFaCfd6zVq9d6Qm2k6AQ8cAfGH/wJOOoUE=; Received: from [166.137.104.218] (helo=[172.20.10.4]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1hfDMw-0007pg-24; Sun, 23 Jun 2019 21:02:04 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: some ideas on guidelines From: J Lovejoy In-Reply-To: <87muimpz7r.fsf@wjsullivan.net> Date: Sun, 23 Jun 2019 19:01:59 -0600 Cc: linux-spdx@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87muimpz7r.fsf@wjsullivan.net> To: John Sullivan X-Mailer: Apple Mail (2.3445.104.11) X-Sender-Ident-agJab5osgicCis: opensource@jilayne.com Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org > On Jun 12, 2019, at 10:04 AM, John Sullivan wrote: >=20 > 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=E2=80=99s always easier = to start with something and then pick at it and refine it ;) >=20 > J Lovejoy writes: >=20 >> Hi all, >>=20 >> Sorry to be a bit MIA, been busy with some other things, but still = watching the progress here. =20 >>=20 >> I have been thinking a lot about some of the patterns discussed here = and various issues logged for =E2=80=9Cfurther 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.=20 >>=20 >> The key points I=E2=80=99ve 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=E2=80=99s rules, but it=E2=80=99s 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.=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D >> 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. >>=20 >> 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.=20 >>=20 >> 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=E2=80=99s 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.=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> #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 =E2=80=94> then REPLACE the = standard license notice with the SPDX identifier for the relevant = license. >>=20 >> #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 =E2=80= =94> then REPLACE the standard license notice with the SPDX identifier = for the relevant license. >>=20 >> #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 =E2=80=94> then REPLACE the standard license = notice with the SPDX identifier for the relevant license. >>=20 >> 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. >>=20 >> 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] >=20 > 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. >=20 > 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=E2=80=99t 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=E2=80=99t 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! >=20 > 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=E2=80=99t 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. >=20 > 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?=20 >=20 > 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.=E2=80=9D 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 = =E2=80=9Cnon-compliance=E2=80=9D is merely replacing an =E2=80=9Cold=E2=80= =9D 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=E2=80=99s old, it has lots o=E2=80=99files, and many = many contributors/copyright holders. If I worked for a company that had = open source projects under an inbound=3Doutbound 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=E2=80=99d feel pretty comfortable doing that = (oh wait, I might have already done that=E2=80=A6) but this is just = different for a number of reasons and that makes it a bit less = comfortable.=20 Maybe the good thing about acknowledging this is that =E2=80=98what=E2=80=99= s good for the kernel=E2=80=99 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 >=20 > -john >=20 >> * 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. >>=20 >> [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, =E2=80=9CThis program is released = under license FOO=E2=80=9D. 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 >>=20 >> #4 Where the file contains a license notice that clearly states the = file is licensed under =E2=80=9CGPL=E2=80=9D with no indication of = version number and no other license information whatsoever =E2=80=94> = ADD SPDX identifier for GPL-2.0-or-later >> Rationale: This is consistent with the text of the license which = states, =E2=80=9CIf the Program does not specify a version number of = this License, you may choose any version ever published by the Free = Software Foundation.=E2=80=9D 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. >>=20 >> #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 =E2=80=94> 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/CO= PYING, 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=3D1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 >>=20 >> #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: >> =09 >> #6a An existing known additional license or exception = for which there is an SPDX identifier >> =E2=80=94> ADD appropriate SPDX license = expression (use of AND, OR, WITH), where person making change is does = not represent copyright holders for file >> =E2=80=94> REPLACE with appropriate SPDX = license expression, where person(s) making or signing-off on changes = represent copyright holders >>=20 >> #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=E2=80=99s 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=20 >>=20 >> #6c An additional or different disclaimer or warranty = text: >> =E2=80=94 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 >> =E2=80=94 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: >> =E2=80=94> if additional disclaimer text = adds no additional substantive aspects to the standard GPL disclaimer, = REPLACE with appropriate SPDX license identifier for GPL-2.0 >> =E2=80=94> If additional disclaimer text = adds additional substantive aspects to the standard GPL disclaimer, ADD = the appropriate SPDX license identifier for GPL-2.0 >> =09 >> =3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 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. >>=20 >> I have tried to collect the various thoughts and opinions expressed = on the mailing list on these topics.=20 >> I=E2=80=99m 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=E2=80=99d like to know from those involved in using = scanning tools (Thomas, Philippe) if this would be tenable.=20 >> 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=E2=80=99m especially interested in Richard, Bradley and John=E2=80= =99s view on #1-3 as they seemed to have the most initial concern here. >>=20 >> Finally - don=E2=80=99t shoot the messenger :) >>=20 >>=20 >> Thanks, >> Jilayne >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > 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 >=20 > Do you use free software? Donate to join the FSF and support freedom = at > .