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=-1.0 required=3.0 tests=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 4B507C18E7D for ; Wed, 22 May 2019 09:40:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1CC61208C3 for ; Wed, 22 May 2019 09:40:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728638AbfEVJkM (ORCPT ); Wed, 22 May 2019 05:40:12 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35839 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728615AbfEVJkM (ORCPT ); Wed, 22 May 2019 05:40:12 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hTNjD-00006L-C6; Wed, 22 May 2019 11:40:07 +0200 Date: Wed, 22 May 2019 11:40:07 +0200 (CEST) From: Thomas Gleixner To: "Bradley M. Kuhn" cc: Richard Fontana , linux-spdx@vger.kernel.org Subject: Re: Meta-question on GPL compliance of this activity In-Reply-To: <20190521210833.veltn74dcgic5zmw@ebb.org> Message-ID: References: <20190521210833.veltn74dcgic5zmw@ebb.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org On Tue, 21 May 2019, Bradley M. Kuhn wrote: > 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. > > 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. > > 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: > > Filenames: a.c, b.c, c.c contained this notice: > NOTICE > which was replaced with SPDX_IDENTIFIER on DATE. > > 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. The only issue with that are the filenames. They tend to change by renames, moves etc. And we know from other stuff (e.g. Documentation) that nobody ever cares about updating these things. > 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? > > 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? It's not too late to do that. Though, can we please avoid having all the explicit patterns and use one 'normalized' pattern instead, i.e. something more readable than the normalized pattern which we use in the changelog right now. The point is that if I just take a single patch which matches 100 files with the normalized pattern, then I'd end up with at least 50 variants due to formatting (comment style, line breaks, whitespace, ...), which is not really helpful either. Thinking about the volatile nature of filenames, we could be smart about that and provide a generator for that 'documentation'. Git allows me to follow the renames and moves and extract the exact point where the boilerplate/reference was replaced. That way the information can be retrieved on demand and does not get subject to bitrot. Arguably the information is still in place, right? Thanks, tglx