linux-kernel - Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOFm3uHoTGeS3V8bZUAsGVrPPfxHi7FU1etyfrFnCx3U+LDx4Q@mail.gmail.com>
Date:   Sun, 26 Nov 2017 00:41:16 +0100
From:   Philippe Ombredanne <pombredanne@...b.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Mauro Carvalho Chehab <mchehab@...pensource.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@....de>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Rob Herring <rob.herring@...aro.org>,
        Jonas Oberg <jonas@...e.org>, Joe Perches <joe@...ches.com>,
        xfs <linux-xfs@...r.kernel.org>,
        Charlemagne Lasse <charlemagnelasse@...il.com>,
        Carmen Bianca Bakker <carmenbianca@...e.org>
Subject: Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe
 how to properly identify file licenses

Pavel:

On Sat, Nov 25, 2017 at 7:51 PM, Pavel Machek <pavel@....cz> wrote:
> On Fri 2017-11-17 15:06:39, Mauro Carvalho Chehab wrote:
>> Hi Thomas,
>>
>> Em Fri, 17 Nov 2017 11:00:33 +0100 (CET)
>> Thomas Gleixner <tglx@...utronix.de> escreveu:
>>
>> > Subject: Documentation: Add license-rules.rst to describe how to properly identify file licenses
>> > From: Thomas Gleixner <tglx@...utronix.de>
>> > Date: Fri, 10 Nov 2017 09:30:00 +0100
>> >
>> > Add a file to the Documentation directory to describe how file licenses
>> > should be described in all kernel files, using the SPDX identifier, as well
>> > as where all licenses should be in the kernel source tree for people to
>> > refer to (LICENSES/).
>> >
>> > Thanks to Kate, Greg and Jonathan for review and editing and Jonas for the
>> > suggestions concerning the meta tags in the licenses files.
>> >
>> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>>
>> The document itself looks good, but I think it should also mention
>> what would be the expected values for the MODULE_LICENSE() macro and
>> how each license would be mapped into it.
>>
>> Right now, include/linux/module.h says:
>>
>> /*
>>  * The following license idents are currently accepted as indicating free
>>  * software modules
>>  *
>>  *    "GPL"                           [GNU Public License v2 or later]
>
> Hmm. AFAICT Greg translated GPL as GPL v1 or later. That seemed
> wrong... and now it seems even more wrong.

While this may come out as weird or wrong, this is neither wrong nor
"more wrong" when you dive in the details:

1. the meaning of a bare "GPL" in MODULE_LICENSE is well defined in
module.h as "GPL 2.0 or later" so there is no ambiguity there. It
would have been best to align this with SPDX, but this would break
instantly so many out of tree kernel modules and module loading tools
that expect these hard coded values and conventions that it is not
worth changing it IMHO.

2. the meaning of a bare "GPL" as a the only license notice is also
well defined in the GPL 2.0 text itself  in section 9 [1] and means
any version of the GPL that therefore can be made clear as GPL-1.0 or
later, i.e. GPL-1.+:
" If the Program does not specify a version number of this License,
you may choose any version ever published by the Free Software
Foundation. "

Therefore I do not think Greg did any translation and got anything
wrong but used exactly the convention in 2.

For instance when the only license notice in a file was a terse and
unclear: "Copyright (c) Jane Doe, GPL" or "Copyright (c) John Doe,
GPL'ed" then the resulting SPDX license id applied was  "GPL-1.0+"

I personally think this is unfortunate that we have warts like this:
it could have been the intent of author, or an oversight, or the
author may have meant 2.0.... we can only guess! What is clear is that
in these cases and short of any other indication, "GPL-1.0+" is the
precise meaning that "GPL" or "GPL'ed" has in a notice outside of the
MODULE_LICENSE macro.

Note that no MODULE_LICENSE macro was harmed in the process.... though
having SPDX ids makes quite visible some discrepancies as you noticed
such as when:
- a MODULE_LICENSE is "GPL"  and the top level license is "GPL 2.0
only": here the MODULE_LICENSE would need to be fixed to "GPL v2"
- or MODULE_LICENSE is "GPL v2" and the top level license is "GPL 2.0
or later": here the MODULE_LICENSE would need to be fixed to "GPL"

These will need to be fixed over time and this is made easier with the
clarity brought by the SPDX id. My take there is that the best
approach is likely:

1. the top level license notice should take precedence over the
MODULE_LICENSE and MODULE_LICENSE should be updated accordingly
2. you might want an ack or a review from the original author in these
weird cases of mismatch

[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section9
-- 
Cordially
Philippe Ombredanne