Re: Meta-question on GPL compliance of this activity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 22 May 2019, Greg KH wrote:
> On Tue, May 21, 2019 at 01:58:04PM -0400, Richard Fontana wrote:
> > I was at the LLW event in Barcelona last month but unfortunately did
> > not attend the workshop relating to this activity, so I apologize if
> > this is something that has already been considered.
> > 
> > GPLv2 section 1 says: "You may copy and distribute verbatim copies of
> > the Program's source code as you receive it, in any medium, provided
> > that you conspicuously and appropriately publish on each copy an
> > appropriate copyright notice and disclaimer of warranty; keep intact
> > all the notices that refer to this License and to the absence of any
> > warranty; and give any other recipients of the Program a copy of this
> > License along with the Program."
> > 
> > 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.
> 
> Wonderful, let's debate that with any copyright holder who argues
> otherwise.  Right now, we have all companies and developers who have
> seen these lines removed in their files, agree with the removal of the
> text.  If there are any objections, we will gladly leave their files
> alone.

And there is precedence:

 https://github.com/u-boot/u-boot/commit/cb3761ea995ca2699db19f54e7c5f7e463381459

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...

> 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.

I just hacked up a trivial script.

  # spdxhist.py kernel/delayacct.c

  SPDX identifier added with:
  commit 7170066ecd289cd8560695b6f86ba8dc723b6505
  Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  Date:   Sun May 19 15:51:55 2019 +0200

  // SPDX-License-Identifier: GPL-2.0-or-later

  Lines removed:

  *
  * 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.

Now for a file where we just added one (had no license ref at all):

  # spdxhist.py kernel/irq/chip.c 

  SPDX identifier added with
  commit 52a65ff5603e685e9b19c2e108b3f0826dc7a86b
  Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  Date:   Sun May 19 15:51:55 2019 +0200

  // SPDX-License-Identifier: GPL-2.0

So we can expose that information with tooling or generate even full
documentation for the whole kernel tree at any given time.

Picking some random other one:

  # spdxhist.py drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c

  SPDX identifier added with
  commit 4c450f056cae111a48bb33c3ddb33296a206faad
  Author: Jonathan Gray <jsg@xxxxxxxxx>
  Date:   Mon Oct 15 15:45:49 2018 +1100

  // SPDX-License-Identifier: MIT

  Lines removed:

  // SPDX-License-Identifier: GPL-2.0

So fixups happen when people notice and it's not the end of the world.

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.

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.

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.

Just leaving them around is not a solution as explained already in that
other thread.

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. :)

Thanks,

	tglx







[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux