linux-kernel - Re: linux-next: manual merge of the scsi tree with Linus' tree

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: <1561077341.7970.47.camel@HansenPartnership.com>
Date:   Thu, 20 Jun 2019 17:35:41 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@....de>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Hannes Reinecke <hare@...e.com>
Subject: Re: linux-next: manual merge of the scsi tree with Linus' tree

On Thu, 2019-06-20 at 17:07 -0700, Linus Torvalds wrote:
> On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell <sfr@...b.auug.org.a
> u> wrote:
> > 
> > At what point does it become worth while to do a back merge of
> > v5.2-rc4 (I think the last of the SPDX changes went into there) to
> > take care of all these (rather than Linus having to edit each of
> > these files himself during the merge window)?
> 
> For just trivial conflicts like this that have no code, I really
> would prefer no backmerges.
> 
> That said, I would tend to trust the due diligence that Thomas, Greg
> & co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..

There's two problems.  One is simple terminology: the
Documentation/process/licence-rules.rst say:

GPL-2.0 means GPL 2 only
GPL-2.0+ means GPL 2 or later

I believe RMS made a fuss about this and he finally agreed to 

GPL-2.0-only
GPL-2.0-or-later

It's just the kernel doc hasn't been updated so Christoph did what the
doc says when making the change and Thomas did what we've apparently
agreed to with RMS, hence textual discrepencies.

The other problem is actually substantive: In the libsas code Luben
Tuikov originally specified gpl 2.0 only by dint of stating:

* This file is licensed under GPLv2.

In all the libsas files, but then muddied the water by quoting GPLv2
verbatim (which includes the or later than language).  So for these
files Christoph did the conversion to v2 only SPDX tags and Thomas
converted to v2 or later tags.  Based on somewhat distant recollections
of history, I believe Christoph is right on this one.

James