Re: [PATCH][RFC] module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity
From: Alan Cox
Date: Wed Jan 30 2019 - 16:06:13 EST
On Wed, 30 Jan 2019 15:31:20 +1030
Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> Thanks taking on such a thankless task Thomas,
>
> Might have been overzealous in assuming a verionless GPL string meant
> "or later" (I'm happy for that for my own code, FWIW). My memory is
> fuzzy, but I don't think anyone cared at the time.
Versionless always meant 'or later' outside of the tags. It's the default
version of the licence. (Whether v2 only has any meaning beyond intent is
another debate that I guess some year a lawyer will have to figure out).
I think the description change makes sense given the ambiguity and the
fact we now have SPDX headers. (IANAL etc)
> > 2) The dual licensed strings became ill defined as well because following
> > the "GPL" vs. "GPL v2" distinction all dual licensed (or additional
The dual ones were IMHO a mistake. They should just have used GPL and
additional rights. Either you have GPL rights (and it's ok to use in the
kernel) or you don't (and it's proprietary and the rest is down to
derivative works).
We don't actually care whether its dual licensed BSD, or whether it
merely grants you an additional right to cheap pizza.
> > As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
> > conflicting with the actual license in the source code (either SPDX or
> > license boilerplate/reference). A comparison between the scan of the
The SPDX tag isn't correctly capable of expressing the licence anyway. If
you have functions in a file and two of them are GPL v2+ and someone
added a GPLv2 only one and updated the header there isn't a valid SPDX tag
for it because I can still use the GPLv2+ bits with GPLv3.
This is nothing new - the headers on the files provided no more data on
that and took up lots more space 8) We've simply never tracked licence
data by line.
Alan