On Fri, May 24, 2019 at 4:25 PM Allison Randal <allison@xxxxxxxxxxx> wrote: > From what I can tell so far: > > - everyone agrees that it's fine for the original copyright holder to > add an SPDX identifier instead of a messy text license notice and disclaimer > > - everyone agrees that it's fine for the project to add SPDX identifiers > to existing files, with appropriate efforts to match whatever license(s) > would have applied to the files anyway > > - everyone is pretty keen to remove the messy, inconsistent text license > notices and disclaimers, not just because they're trivially ugly, but > because they're actually a barrier to compliance Not to sidetrack discussion but I don't see how they're a barrier to *true* compliance specifically for Linux. If you have the complete corresponding source code for the Linux kernel, and you just assume (as some of us do) it's licensed under GPLv2 and provide the source code and chances are you'll be in compliance. And most noncompliant Linux distributors are noncompliant because they aren't distributing the source code (and thus they have nothing to run scanning tools on or whatever). Nevertheless I see a more general (beyond the Linux kernel) benefit to adoption of legal notices in source code that can more easily be understood by tools, and GPL-licensed projects in particular pose a challenge to changing practices around source code license notices. Which is partly why I am interested in and helping out a bit with this work. I know full well that "compliance" is being redefined by some companies to mean "tabulating and cataloging detailed information about licenses and copyrights covering open source software, preferably in Excel spreadsheets", but I refuse to join in that redefinition. > The lingering question is just how to satisfy the GPL's requirement to > "keep intact all the notices that refer to this License and to the > absence of any warranty", while avoiding horrible hacks and > unmaintainable manual effort. > > I entirely sympathize with the idea that the git history alone should be > sufficient. But, I've dealt with enough lawyers, judges, and users over > the years to know that git history doesn't make much sense to people > outside our circle of developers, so it's better if whatever we do is > discoverable from a web search without any use of git tooling. > > Out of everything discussed so far, I prefer the options that were: > > - automatically generated from git history > > - not checked into git > > 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 > > - 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 > > 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. Posting the generated > result outside the release tarball also means we can regenerate it at > any time, if we improve the tooling or find errors, instead of being > stuck forever with whatever generated file was inserted into each release. > > Not a strong opinion, just what seems most effective and least horrible > to me. Sounds like a good suggestion. Perhaps alternatively or in addition, a good faith effort can be undertaken to attempt to get licensor (more specifically, nominal-copyright-holder) consent for these changes. It doesn't have to be perfect or rushed. Was this idea considered but abandoned? Not long ago Thomas asked me about a number of source files with Red Hat copyrights, such as the ones that said "GPL'd" which seemed particularly to irk him :) It seems like at this point you are all giving up on the idea of checking with nominal copyright holders ... out of frustration or impatience I guess? Richard
