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=DKIM_SIGNED,DKIM_VALID, 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 D605FC072B5 for ; Fri, 24 May 2019 20:25:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9903320868 for ; Fri, 24 May 2019 20:25:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="dd46Y5I4"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=lohutok.net header.i=@lohutok.net header.b="mebU2bpo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404022AbfEXUZY (ORCPT ); Fri, 24 May 2019 16:25:24 -0400 Received: from pb-smtp21.pobox.com ([173.228.157.53]:51534 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403762AbfEXUZY (ORCPT ); Fri, 24 May 2019 16:25:24 -0400 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 359E07515E for ; Fri, 24 May 2019 16:25:22 -0400 (EDT) (envelope-from allison@lohutok.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:cc :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=lggExdeACmKu 4u2GA/blcnJvu9g=; b=dd46Y5I4W04SUtAvMjS8wgPWDuYxuQtXCzPX/aPUf6oI PW4KPJ0qe05s2bAsRtmuhfRwzJvD7reFiDmKrcxIJkWJR/xEYuO4TPx3nIBbyeL7 Y5J7bszw1nNNyLMzIfOPkr3gedhIOaLKjLJW0tnmKOwdymoQ0ZQw6tC5FBltYAY= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 2D9247515D for ; Fri, 24 May 2019 16:25:22 -0400 (EDT) (envelope-from allison@lohutok.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lohutok.net; h=subject:cc:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=2018-11.pbsmtp; bh=+ulXWWwk5Dcj3pRxXc6XsX7JSCZnUSLwQmK5YGgjYNg=; b=mebU2bpocO2z/MEU2u3RjgTzxquB889ZVTFtwdfR8UGcU7xYU0jzvHEWopsNTqNurGHkLfc7W/MtGfpYZ/xMJfAyfNHunXbWkcazg+1N1qH7BbUVdc57dHA1NCZk49QgDg1qtgFzICLcYendQvM9FPNFtTN7EpgQY07Oe+Fx9YY= Received: from [10.0.0.75] (unknown [24.47.52.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 1790E7515C for ; Fri, 24 May 2019 16:25:19 -0400 (EDT) (envelope-from allison@lohutok.net) Subject: Re: Meta-question on GPL compliance of this activity Cc: linux-spdx@vger.kernel.org References: <20190521210833.veltn74dcgic5zmw@ebb.org> <0995848C-11BE-47B1-86F9-F56D43541246@jilayne.com> <20190524052026.GA28229@kroah.com> From: Allison Randal Message-ID: Date: Fri, 24 May 2019 16:24:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190524052026.GA28229@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0C6D0E02-7E62-11E9-AF2F-8D86F504CC47-44123303!pb-smtp21.pobox.com To: unlisted-recipients:; (no To-header on input) Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org On 5/24/19 1:20 AM, Greg KH wrote: > On Fri, May 24, 2019 at 12:33:22AM -0400, Richard Fontana wrote: >>>> 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? >> >> If I've followed these threads rightly it seems that this may not be a >> practical solution, but I think something like this would be >> preferable. > > It's not practical in any way at all. Again, please realize the size of > our code base. >From what I can tell so far: - everyone agrees that it's fine for the original copyright holder to add an SPDX identifier instead of a messy text license notice and disclaimer - everyone agrees that it's fine for the project to add SPDX identifiers to existing files, with appropriate efforts to match whatever license(s) would have applied to the files anyway - everyone is pretty keen to remove the messy, inconsistent text license notices and disclaimers, not just because they're trivially ugly, but because they're actually a barrier to compliance The lingering question is just how to satisfy the GPL's requirement to "keep intact all the notices that refer to this License and to the absence of any warranty", while avoiding horrible hacks and unmaintainable manual effort. I entirely sympathize with the idea that the git history alone should be sufficient. But, I've dealt with enough lawyers, judges, and users over the years to know that git history doesn't make much sense to people outside our circle of developers, so it's better if whatever we do is discoverable from a web search without any use of git tooling. Out of everything discussed so far, I prefer the options that were: - automatically generated from git history - not checked into git Which seems to leave the options of generating a condensed list of historical notices from the git history and either: - adding the generated file to the release tarball, or - posting the generated file on some kernel.org domain (updated with each release), and linking to it from some sensible doc file in the git repo, possibly: Documentation/process/license-rules.rst In my experience, Kernel teams for Linux distros tend to pull their Kernel source from git rather than the tarballs anyway, so the second method of posting the generated file is probably a more reliable way to get the information passed through to the distros. Posting the generated result outside the release tarball also means we can regenerate it at any time, if we improve the tooling or find errors, instead of being stuck forever with whatever generated file was inserted into each release. Not a strong opinion, just what seems most effective and least horrible to me. Allison