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=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,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 C2A6FC07542 for ; Sat, 25 May 2019 16:56:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 96255216FD for ; Sat, 25 May 2019 16:56:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558803406; bh=E/1DXm4qstH5PRehJv7CrY4qSYHll8aMpHbgI/82ET8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=bMEzzZPLnz6GtdoquRyinRC5jWhePqyJySWsEokbggoWS8F8RmugsXYTuJTEV28gj oTMSbPS8DT6NINaKzYtIyHbc2Sq6rABltnrXlgt5PvJYLE4ZdEsUCIO3WCbj3LeUTv 3YrC3wPzq7+t9IaLN290JJq6DbTAVCWvMb2srjRo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727127AbfEYQ4q (ORCPT ); Sat, 25 May 2019 12:56:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:48028 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727028AbfEYQ4q (ORCPT ); Sat, 25 May 2019 12:56:46 -0400 Received: from localhost (unknown [62.129.28.50]) (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 0E88E20879; Sat, 25 May 2019 16:56:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558803405; bh=E/1DXm4qstH5PRehJv7CrY4qSYHll8aMpHbgI/82ET8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t43/gPTebkxj7U+5ZO9JUEMUOZZ0V8dzm/E9wu+azIj1hamjZQ+Ym4lLqK0b1s348 hlwVf27y1lhBHp85g1rbNVjtplH50YjIEDCDueVtqux/Jf9EK5sqYJIwD11smeF3nS A9o09kj7AscFMFFjVC81/VNuYFQlJbRoRR9LIlbY= Date: Sat, 25 May 2019 18:56:43 +0200 From: Greg KH To: Allison Randal Cc: linux-spdx@vger.kernel.org Subject: Re: Meta-question on GPL compliance of this activity Message-ID: <20190525165643.GA13394@kroah.com> References: <20190521210833.veltn74dcgic5zmw@ebb.org> <0995848C-11BE-47B1-86F9-F56D43541246@jilayne.com> <20190524052026.GA28229@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, May 24, 2019 at 04:24:25PM -0400, Allison Randal wrote: > 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 As the person who generates the release tarballs these days, this is going to be tough. It's an automated process that generates it directly from the git tree itself so that anyone else can also do the same thing and verify that what we released is identical to what the git tree has. Reproducable builds are good to have :) If I have to have the servers run some other script that magically injects it into the tarball, that's going to be a big problem as it makes verification of the tarball _much_ more difficult :( > - 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 We can do this, again, if it is something that is actually workable. Again, remember we have over 65 thousand files in the kernel source tree. Any single file that tries to reference them all, in any form, is going to be unworkable. As a simple experiment, has anyone tried to run something like 'reuse' on the kernel source tree today and seen what the output is? Good luck with that :) thanks, greg k-h > 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. Why would a distro kernel package suck in a random file off of the web that could change at any point in time and isn't obviously related to the kernel tree itself (i.e. part of it?) And wouldn't they really need to post their _OWN_ file as everyone who ships a kernel changes it in some way (for good reasons.) So individuals would need to be able to generate their own file somehow. Anyway, I'm trying to say that a "single file" is going to be a major pain in the rear with almost no benefit that I can see. Again, has anyone demanded such a thing from any other project that has switched to only SPDX tags (like uboot?) thanks, greg k-h