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
