linux-kernel - Re: [patch 1/7] 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: <CAOFm3uFANvJa0yxiKPcR7KER22951+uO8-qez+hKRY9PzzNskw@mail.gmail.com>
Date:   Fri, 17 Nov 2017 08:37:28 +0100
From:   Philippe Ombredanne <pombredanne@...b.com>
To:     Jonas Oberg <jonas@...e.org>
Cc:     Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Andrew Morton <akpm@...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>,
        Joe Perches <joe@...ches.com>, xfs <linux-xfs@...r.kernel.org>,
        Kate Stewart <kstewart@...uxfoundation.org>
Subject: Re: [patch 1/7] Documentation: Add license-rules.rst to describe how
 to properly identify file licenses

On Thu, Nov 16, 2017 at 4:15 PM, Jonas Oberg <jonas@...e.org> wrote:
> Hi,
>
>> One other thing that occurred to me is that documentation files, too,
>> are copyrightable and should have license identifiers.
>
> Would it make sense to take an incremental approach to this? Get the
> source code and identifiers worked on by Thomas et al through first, then
> think about and fix up potential other issues, like the top level COPYING
> file, or documentation :-)

I could not agree more... code first!
FWIW I scanned the whole docs with scancode as part of this exercise.
They are rather ... messy license-wise, but even though I got through
it eventually they also generally less critical license-wise IMHO.

You can see some details of these scans in [1] though they are not
100% up to date: I did not post every intermediate scans and review
there as things are moving at a fast pace.

There are probably more pressing things to fix such as discrepancies
between a MODULE_LICENSE and the licensing of a file when they do not
match.

Here [2] the top level comment is a plain GPL-2.0 "only" while the
MODULE_LICENSE  is a GPL-2.0+ "or later"  (based on the plain "GPL"
definition in module.h [3] and this is just  one of many examples of this
weirdness.

Or fix the non-standard redefinition of the MODULE_LICENSE macro as
DRIVER_LICENSE as in [2]  and found elsewhere with
grep -r . -e "DRIVER_LICENSE"

These break the otherwise nicely grepable MODULE_LICENSE macros
with this kind of warty redirection I stumbled upon while reviewing kernel
license scans:

#define DRIVER_LICENSE "GPL"
[...]
MODULE_LICENSE(DRIVER_LICENSE);

[1] https://github.com/pombredanne/linux-kernel-scans/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/alpha/kernel/srm_env.c?h=v4.14#n13
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?h=v4.14#n174
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/gma500/psb_drv.h?h=v4.14#n39
-- 
Cordially
Philippe Ombredanne