Re: Meta-question on GPL compliance of this activity

[Allison Randal <allison@lohutok.net>]

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