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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 8F5C4C282CE for ; Thu, 23 May 2019 01:19:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3947521019 for ; Thu, 23 May 2019 01:19:54 +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="l8OBq9Qn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728050AbfEWBTy (ORCPT ); Wed, 22 May 2019 21:19:54 -0400 Received: from mx2-c1.supremebox.com ([198.23.53.234]:56649 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727305AbfEWBTx (ORCPT ); Wed, 22 May 2019 21:19:53 -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=eon199XA1MEI9Yv3jLTWsU4h48ATY6siv4ztvv6ZQYs=; b=l8OBq9QniORZEVFF9fq1ptJred fnomMixXttyVHjpT9zmh9AsEr9jQJMS4dtOSoean6P6spydtJiw3yteyWp6/znk2HHzSbGynZ3O+G W9Xe70Sf6YjzHZjoTJnph4LsUjGnjCJ+99YhAB+M2BALC2gVa/zYAjhR48dG4HW7u7dk=; Received: from [67.164.173.226] (helo=[10.0.0.21]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1hTcOe-0009ol-LL; Thu, 23 May 2019 01:19:52 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Meta-question on GPL compliance of this activity From: J Lovejoy In-Reply-To: <871s0qyz3z.fsf@wjsullivan.net> Date: Wed, 22 May 2019 19:19:51 -0600 Cc: linux-spdx@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D762992-918F-4901-8355-F258DAAB88EA@jilayne.com> References: <20190521210833.veltn74dcgic5zmw@ebb.org> <0995848C-11BE-47B1-86F9-F56D43541246@jilayne.com> <871s0qyz3z.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 May 22, 2019, at 3:10 PM, John Sullivan wrote: >=20 > J Lovejoy writes: >=20 >> Richard,=20 >>=20 >> As you raised this concern and yet I=E2=80=99m noticing you continue = to review >> the patches and sign off, am I correct to assume that you don=E2=80=99t= think >> this is a big concern? >>=20 >=20 > I was late to subscribe and am just catching up on the conversation > here, so apologies if I missed earlier explanation, but I remember > discussing this issue a while back on either -legal or -general (I'll > look when I have a few more moments). On https://spdx.org/ids-how it > currently says: >=20 >> When a license defines a recommended notice to attach to files under >> that license (sometimes called a "standard header"), the SPDX project >> recommends that the standard header be included in the files, in >> addition to an SPDX ID. >=20 >> Additionally, when a file already contains a standard header or other >> license notice, the SPDX project recommends that those existing = notices >> should not be removed. The SPDX ID is recommended to be used to >> supplement, not replace, existing notices in files. >=20 >> Like copyright notices, existing license texts and notices should be >> retained, not replaced =E2=80=90 especially a third party's license = notices. >=20 > - John,=20 that text is from the SPDX website and is very generalized, conservative = and non-contextual. The reality we live in today is that people are = choosing to use the SPDX identifiers in their files instead of the full = license text (for MIT) or the standard license notice (for Apache-2.0 or = GPL), etc. - this is good because SPDX identifiers are more concise and = easier for tooling to parse. Even when there is a standard license = header recommended, like the GPL has done, it doesn=E2=80=99t get = faithfully reproduced which causes headaches for tooling to parse even = when the intent is clear. This is what Thomas is dealing with and you = can see the many examples of this on the many other emails on this list.=20= =20 The question Richard was posing (if I may paraphrase) if someone would = have a viable argument for non-compliance with section 1 just for = replacing a messy, but clear (in terms of what license variant applies) = with an SPDX identifier. Considering that Stallman encouraged the use of = the SPDX identifiers we adopted based on his concern for lack of = clarity, I can hardly think that the FSF is now going to go back on that = sentiment? Thanks, Jilayne=