linux-kernel - Re: [patch V5 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: <12C856B7-06D5-4D99-8D6E-41F3A679CA17@dilger.ca>
Date:   Mon, 1 Jan 2018 19:35:27 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Philippe Ombredanne <pombredanne@...b.com>,
        Joe Perches <joe@...ches.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>, xfs <linux-xfs@...r.kernel.org>,
        Charlemagne Lasse <charlemagnelasse@...il.com>,
        Carmen Bianca Bakker <carmenbianca@...e.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe
 how to properly identify file licenses

On Dec 29, 2017, at 9:15 PM, Theodore Ts'o <tytso@....edu> wrote:
> 
> On Fri, Dec 29, 2017 at 11:17:54PM +0100, Philippe Ombredanne wrote:
>>> As far as I know, none of the licenses explicitly say
>>> copyright license must be on each file.  Just that the distribution of
>>> source must include the copyright and license statement.  Exactly how
>>> that is done is not explicitly specified.
>> 
>> This is also my take. What is done here is not much different than
>> refactoring duplicated code so it leaves in a single place:
>> 
>> - by "value" at the root in COPYING and in the Documentation.
>> - by "reference" in the code proper as SPDX ids.
>> 
>> Therefore essential and common requirements to include the license
>> text is fulfilled in the kernel.
>> 
>> Note that there are a few offenders that will need to clean up their
>> acts as they came up will both long and "un-removable and
>> un-alterable" crazy legalese blurbs [1] prefix this:
>> 
>> "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER"
>> 
>> These will have to be taken care on a case by case basis. These are
>> pretty stupid and IMHO should have never been allowed to be added to
>> the kernel in the first place and are ugly warts. It could very well
>> be that these are not really GPL-compliant notices FWIW: keeping
>> notices and copyrights is quite different from a restriction of
>> altering things by moving them around which is exactly what is
>> happening with the SPDX-ification here.
>> 
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5
> 
> Lustre is now owned by Intel so I suspect that some throat clearing
> noises in the right direction could easily take care of the issue with
> those files....

To correct this, the copyright on the Lustre code is not owned by Intel.
The copyright on the original Lustre code was transferred from Oracle to
Seagate a few years ago, but the code that Whamcloud->Intel used for their
release (which is what the kernel client is based on) was forked many years
ago from the Oracle version (all under GPL).  There is no single copyright
holder anymore, since there is no copyright assignment for new contributions
and it is copyright by whomever contributed it, as with the kernel itself.

I don't see any issue with leaving those header blocks as-is?

Cheers, Andreas