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=-5.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D0DAFC282CE for ; Wed, 22 May 2019 16:33:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E6A52081C for ; Wed, 22 May 2019 16:33:07 +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="fOy0Ngxw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730051AbfEVQdH (ORCPT ); Wed, 22 May 2019 12:33:07 -0400 Received: from mx2-c1.supremebox.com ([198.23.53.234]:34529 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729874AbfEVQdH (ORCPT ); Wed, 22 May 2019 12:33:07 -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=T+pN7mtrEnj2X2wgRpCjRbIcAIqok+4kJh54fMnQOWY=; b=fOy0NgxwSSXKgc/zrjV52wVI8T MmBmebAPKZhSONvl4PMhzJSZ9M/jPLutcUDpAD4GdJqIrbjHwINbgo5HRm2bswoqOcsreDKe3MlKw CZBVAnPcZCjeM9JeMA5xfVHVseTypS5ihbTT88clRrt1H0Q0stb74+LQCOvB9eGKq1Sg=; Received: from [67.164.173.226] (helo=[10.0.0.176]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1hTUAr-0001ot-5i; Wed, 22 May 2019 16:33:05 +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: Date: Wed, 22 May 2019 10:33:04 -0600 Cc: Greg KH , Richard Fontana , linux-spdx@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <86651BE5-1F89-445C-ABDA-FDBFBF177409@jilayne.com> References: <20190522132744.GD28920@kroah.com> To: Thomas Gleixner 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 > On May 22, 2019, at 8:16 AM, Thomas Gleixner = wrote: >=20 > On Wed, 22 May 2019, Greg KH wrote: >=20 > And there is precedence: >=20 > = https://github.com/u-boot/u-boot/commit/cb3761ea995ca2699db19f54e7c5f7e463= 381459 >=20 > plus a few dozen of similar commits which converted the u-boot tree = into a > SPDX clean state. They had a simpler task as the number of crude = licenses > was smaller, but they had to fight odd cases as well. AFAIK nobody = went > berserk on the u-boot folks and they did that 6 years ago... >=20 >> Note, we can trivially change back any such file if someone objects = in >> the future as well. Remember, we have the whole history of "the = world" >> at our fingertips here, nothing we do is ever immutable. >=20 > I just hacked up a trivial script. >=20 > # spdxhist.py kernel/delayacct.c >=20 > SPDX identifier added with: > commit 7170066ecd289cd8560695b6f86ba8dc723b6505 > Author: Thomas Gleixner > Date: Sun May 19 15:51:55 2019 +0200 >=20 > // SPDX-License-Identifier: GPL-2.0-or-later >=20 > Lines removed: >=20 > * > * This program is free software; you can redistribute it and/or = modify > * it under the terms of the GNU General Public License as published = by > * the Free Software Foundation; either version 2 of the License, or > * (at your option) any later version. > * > * This program is distributed in the hope that it would be useful, = but > * WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See > * the GNU General Public License for more details. >=20 > Now for a file where we just added one (had no license ref at all): >=20 > # spdxhist.py kernel/irq/chip.c=20 >=20 > SPDX identifier added with > commit 52a65ff5603e685e9b19c2e108b3f0826dc7a86b > Author: Thomas Gleixner > Date: Sun May 19 15:51:55 2019 +0200 >=20 > // SPDX-License-Identifier: GPL-2.0 >=20 > So we can expose that information with tooling or generate even full > documentation for the whole kernel tree at any given time. >=20 > Picking some random other one: >=20 > # spdxhist.py drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c >=20 > SPDX identifier added with > commit 4c450f056cae111a48bb33c3ddb33296a206faad > Author: Jonathan Gray > Date: Mon Oct 15 15:45:49 2018 +1100 >=20 > // SPDX-License-Identifier: MIT >=20 > Lines removed: >=20 > // SPDX-License-Identifier: GPL-2.0 >=20 > So fixups happen when people notice and it's not the end of the world. >=20 > We rather spend some time on tooling to find out the exact point of = change > and deal with it after the fact rather than trying to solve all = theoretical > lawyerese issues upfront. You know exactly that this won't ever be > possible. >=20 > TBH, we are talking about cleaning up this mess for at least a decade = and > the lawyers while promising to help just came up with new fancy = licenses or > did not prevent their engineers from creating these zombies which just > cause headache. I=E2=80=99m sorry, but this is an unhelpful comment and that I = personally take offense to. While I=E2=80=99m sure you have had bad = experience with lawyers in the course of this project (and others) - I = have my own set of war stories as well and have often been vocal about = criticizing my fellow lawyers (in the vain hope I might actually make a = difference), placing blame is just unhelpful. Please understand that, for example off the top of my head, ONE (open = source) lawyer in a company with hundreds (or thousands?) of software = developers/engineers cannot control what those engineers do in terms of = licensing information - We can give the best advice and document best = practices until we are blue in the face and people (aka our clients) = still won=E2=80=99t always listen. And, we make mistakes and learn along the way, as Greg said in another = thread.=20 We are in this together and we all feel the pain of this mess in our = given roles, which is why we can all come together here and try to fix = it as best we can, which includes, us lawyers making sure we have = covered any potential risks as best we can as well.=20 >=20 > We need a pragmatic approach and I'm surely aware that there might be > dragons lurking, but we spent a lot of time on thinking about a sane > approach and with the review process we are able to filter out the > problematic cases upfront and then we just need to find a way to deal = with > them in a sensible way. >=20 > Just leaving them around is not a solution as explained already in = that > other thread. I think everyone agrees here.=20 >=20 > We need quick help from the SPDX/lawyer camp to handle these cases = proper, > unless the copyright holders are willing to remove the magic = disclaimers > and modifications. Surely the latter would be the preferred solution, = but > that's nothing engineers can solve. That's something we happily = delegate to > a lawyer to lawyer conversation. :) >=20 in terms of efficiency of process on this: my thinking is that we are = bound to have files that need cleaning up (for one reason or another) = from the same copyright holders, as well as files that have similar = patterns of cleaning up. When it comes to reaching out to people to get = them to help clean stuff up, I think we=E2=80=99ll get a better response = if we collect similar things and send one (or minimal #) of = correspondence, rather than one here, one there, etc.=20 And, yes, we may not be able to get the copyright holders to help in all = cases where it would be ideal for a number of reasons (can=E2=80=99t = find them, too many people, etc) - but I think we all agree that is = ideal and the first point to try for the messy files. There seems to be = plenty of low-hanging fruit to work on in the meantime and that=E2=80=99s = GREAT progress - so let=E2=80=99s not lose sight of that either :) For whatever we can=E2=80=99t get copyright holders to clean up, we will = look at adding SPDX identifiers for. But it=E2=80=99s not worth doing = that first and then having someone clean up the=20 > Thanks, >=20 > tglx >=20 >=20 >=20 >=20