On 5/24/19 1:20 AM, Greg KH wrote: > On Fri, May 24, 2019 at 12:33:22AM -0400, Richard Fontana wrote: >>>> IIUC, Thomas indicated in that thread that he could generate that information >>>> later, but given that we already have consensus on the idea, it seems to me >>>> it would be better if the patches themselves contained the moving of the >>>> notice text from the individual files into the single file, rather than >>>> reconstructing it on the back-end. Richard, what do you think about that? >> >> If I've followed these threads rightly it seems that this may not be a >> practical solution, but I think something like this would be >> preferable. > > It's not practical in any way at all. Again, please realize the size of > our code base. >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 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. Allison
