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,SPF_HELO_NONE,SPF_PASS 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 01AE4C31E46 for ; Wed, 12 Jun 2019 05:25:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A6F5420896 for ; Wed, 12 Jun 2019 05:25: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="hEtPXRY0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725763AbfFLFZ3 (ORCPT ); Wed, 12 Jun 2019 01:25:29 -0400 Received: from mx1-c1.supremebox.com ([198.23.53.215]:37417 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725681AbfFLFZ3 (ORCPT ); Wed, 12 Jun 2019 01:25:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jilayne.com ; s=default; h=To:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yXOmeS7Nt8z5M3Xf7Wt2YB+1aQA518vHjOy3H5LfD5s=; b=hEtPXRY0Q7IhCU0l0d6zNIxBOw EhSLf3OXlumjwJBQw2o6vP3qRn+VIownfFmVrDhcHoPQHWSJC3yC64/BvHtChnQpxqECxBS5pZwSU YNfHZ2LyXWRcEGELTt9M0UvAlmynrOIbE6CHdzjGTjmDF5PiLz4mp29gIkcj6fJ6rZeI=; Received: from [67.164.173.226] (helo=[10.0.0.12]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1havlG-0007GU-LF for linux-spdx@vger.kernel.org; Wed, 12 Jun 2019 00:25:27 -0500 From: J Lovejoy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: some ideas on guidelines Message-Id: Date: Tue, 11 Jun 2019 23:25:25 -0600 To: linux-spdx@vger.kernel.org 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 Hi all, Sorry to be a bit MIA, been busy with some other things, but still = watching the progress here. =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 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 =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. 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 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 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 =E2=80=94> 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 =E2=80=94> = 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 =E2=80=94> 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, =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 #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. #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 #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 #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 #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 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.=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=99= s view on #1-3 as they seemed to have the most initial concern here. Finally - don=E2=80=99t shoot the messenger :) Thanks, Jilayne