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 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 498BDC282CE for ; Wed, 22 May 2019 16:14:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1142B20881 for ; Wed, 22 May 2019 16:14:05 +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="atZkcReH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729642AbfEVQOE (ORCPT ); Wed, 22 May 2019 12:14:04 -0400 Received: from mx2-c1.supremebox.com ([198.23.53.234]:54159 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728466AbfEVQOE (ORCPT ); Wed, 22 May 2019 12:14:04 -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=kVKZaT468DP9iaFgrzkn6q5yWRk3jb+v5onmJhaHNQU=; b=atZkcReHgJoUtJO7+b1dT1Xcss jYt04j2P1ot9kr5i2laEH3Pwf+Clsu00b3Q8CxJuCrjhXtwtVt9D3cw/QP2AJg+ePo5b4R311b+Om 93cPJyoMkBvF9fljJXJ7udE79etnHCZ/4/pHQgmYPccv+XxnYalM7w+kdL7NJfzhMsHk=; Received: from [67.164.173.226] (helo=[10.0.0.176]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1hTTsP-000Anm-Qg; Wed, 22 May 2019 16:14:02 +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: <20190521210833.veltn74dcgic5zmw@ebb.org> Date: Wed, 22 May 2019 10:14:00 -0600 Cc: Richard Fontana , linux-spdx@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <0995848C-11BE-47B1-86F9-F56D43541246@jilayne.com> References: <20190521210833.veltn74dcgic5zmw@ebb.org> To: "Bradley M. Kuhn" 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 Richard,=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? thanks, Jilayne > On May 21, 2019, at 3:08 PM, Bradley M. Kuhn wrote: >=20 > Richard, glad to see you on this list! >=20 > Richard Fontana wrote: >> I have recently heard the argument that replacing a more or less = standard >> old-school GNU license notice, or any sort of nonstandard pre-SPDX >> alternative human-oriented notice, with an SPDX license identifier = string, >> without explicit permission from the copyright holder, complies with = this >> condition, because in substance the SPDX string embodies equivalent >> licensing information (and has benefits of its own over the = old-school >> notice). However, more conservative interpreters of GPLv2, including = some >> copyright holders, might argue otherwise. >=20 > I think we do have to worry about more conservative interpreters, esp. = given > that copyright holders are not giving their consent for these notice = changes. >=20 > There was consensus at the meeting in Barcelona that moving all the = notices > to a single file to live inside the Linux tree "somewhere" with = entries like: >=20 > Filenames: a.c, b.c, c.c contained this notice: > NOTICE > which was replaced with SPDX_IDENTIFIER on DATE. >=20 > and that such was a fine and acceptable way to address even the most > disagreeable and litigious conservative interpreters, and that such > was a necessary step to avoid compliance infractions on this issue. >=20 > Related to this, Allison noted on May 8th on this list: >>> Are you [Thomas] automatically logging which files were modified by = each >>> pattern match, for the legally conservative hack we talked about, >>> preserving a historical record of altered license notices in a doc = file? >=20 > IIUC, Thomas indicated in that thread that he could generate that = information > later, but given that we already have consensus on the idea, it seems = to me > it would be better if the patches themselves contained the moving of = the > notice text from the individual files into the single file, rather = than > reconstructing it on the back-end. Richard, what do you think about = that? >=20 > -- > Bradley M. Kuhn >=20 > Pls. support the charity where I work, Software Freedom Conservancy: > https://sfconservancy.org/supporter/