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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_MUTT 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 2C8B2C282CE for ; Wed, 22 May 2019 13:30:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E9D4C21473 for ; Wed, 22 May 2019 13:30:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558531857; bh=c71BwiaT1sNYmC70KRtljMPJ6qc/dtvd9sauyw5660s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=dPiFwzZiV48NG95ITAFCz4Wjec/Ylv21xNm2WrtnK+Ta+/n7VRYL+Olt52yfSD5JJ xzhkP+a2n4Bj5juKodTo3DKl8URzBy4VhKpQjRXp5D/1YuAmquSwl5xbqhnckZlfCj zNbYZRVj1e7MtctsMYqzH/r5i0b31wIJ68g1v05o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729127AbfEVNa4 (ORCPT ); Wed, 22 May 2019 09:30:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:33016 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729126AbfEVNa4 (ORCPT ); Wed, 22 May 2019 09:30:56 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 96B262089E; Wed, 22 May 2019 13:30:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558531856; bh=c71BwiaT1sNYmC70KRtljMPJ6qc/dtvd9sauyw5660s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=etISYcYHjrLRmf3UTvhCvunZ0I9RCobUXZa6+VhSKo6VF8NWyEx14A2pOCq7K96aq oksq3UX4ami0FgYotjofidKedxCLhZ642vY9erEZqcnaDt1FyZTJShR2jmKuZSyPwz U/INtKzUbC7I+TM7WwdrE+8MyeRPBGT+M9L4DxB8= Date: Wed, 22 May 2019 15:30:53 +0200 From: Greg KH To: "Bradley M. Kuhn" Cc: Richard Fontana , linux-spdx@vger.kernel.org Subject: Re: Meta-question on GPL compliance of this activity Message-ID: <20190522133053.GE28920@kroah.com> References: <20190521210833.veltn74dcgic5zmw@ebb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190521210833.veltn74dcgic5zmw@ebb.org> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org On Tue, May 21, 2019 at 02:08:33PM -0700, Bradley M. Kuhn wrote: > Richard, glad to see you on this list! > > 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. Note that we have over 700 instances of how "GPLv2" was described in the kernel tree. We have over 90 thousand different files in the kernel source tree today, with thousands more added every 3 months. There is no way any single file would ever be able to track this type of history. So that's just not going to be possible, or usable, by anyone. Just use git history, we have it, why ignore it? thanks, greg k-h