> On May 22, 2019, at 8:16 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Wed, 22 May 2019, Greg KH wrote: > > 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. I’m sorry, but this is an unhelpful comment and that I personally take offense to. While I’m 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’t always listen. And, we make mistakes and learn along the way, as Greg said in another thread. 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. > > 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. I think everyone agrees here. > > 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. :) > 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’ll get a better response if we collect similar things and send one (or minimal #) of correspondence, rather than one here, one there, etc. 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’t 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’s GREAT progress - so let’s not lose sight of that either :) For whatever we can’t get copyright holders to clean up, we will look at adding SPDX identifiers for. But it’s not worth doing that first and then having someone clean up the > Thanks, > > tglx > > > >
