linux-kernel - Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license

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: <Yo6HC9BfkCo3MBbH@bombadil.infradead.org>
Date:   Wed, 25 May 2022 12:44:11 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     "Bird, Tim" <Tim.Bird@...y.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Richard Fontana <fontana@...rpeleven.org>,
        "tj@...nel.org" <tj@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "bvanassche@....org" <bvanassche@....org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "joe@...ches.com" <joe@...ches.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "linux-spdx@...r.kernel.org" <linux-spdx@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Goldwyn Rodrigues <rgoldwyn@...e.com>,
        Kuno Woudt <kuno@...b.nl>,
        "copyleft-next@...ts.fedorahosted.org" 
        <copyleft-next@...ts.fedorahosted.org>,
        Ciaran Farrell <Ciaran.Farrell@...e.com>,
        Christopher De Nicolo <Christopher.DeNicolo@...e.com>,
        Christoph Hellwig <hch@....de>,
        Jonathan Corbet <corbet@....net>,
        Thorsten Leemhuis <linux@...mhuis.info>
Subject: Re: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license

On Wed, May 25, 2022 at 07:05:31PM +0000, Bird, Tim wrote:
> > -----Original Message-----
> > From: Luis Chamberlain <mcgrof@...radead.org> On Behalf Of Luis Chamberlain
> > 
> > On Wed, May 25, 2022 at 05:05:54PM +0000, Bird, Tim wrote:
> > > I know it's being submitted as an OR, but I question
> > > the value of introducing another license into the kernel's licensing mix.
> > 
> > I agree that we want to keep the number of licenses as small as
> > possible but we cannot really dictate which dual licensing options a
> > submitter selects unless the license is GPL-2.0-only incompatible,
> > which copyleft-next is not.
> 
> Um, yes we can dictate that. 

The statement about us not being able to dictate which dual licensing
options a submitter selects does not actually come from me, Thomas noted
this [0].

[0] https://lkml.kernel.org/r/87fsl1iqg0.ffs@tglx

> There were good reasons that the original
> BSD dual-licenses were allowed.

I helped spearhead some of that effort.

> Those same reasons don't apply here.

Correct, and I noted my own reasoning for now dual licensing with
copyleft-next, which you seem to be disregarding?

> Each license added to the kernel (even when added as an OR), requires
> additional legal analysis.

And I noted in my cover letter that copyleft-next-0.3.1 has been found to be
to be GPLv2 compatible by three attorneys at SUSE and Redhat [1], but
to err on the side of caution we simply recommend to always use the "OR"
language for this license [2].

[1] https://lore.kernel.org/lkml/20170516232702.GL17314@wotan.suse.de/
[2] https://lkml.kernel.org/r/1495234558.7848.122.camel@linux.intel.com

> And here's the thing.
> The copyleft-next license has a number of legal issues that make it problematic.

You say number of legal issues.

> Not the least of which are that some of its terms are dependent on external
> situations that can change over time, in a matter that is uncontrolled by either
> the licensor or the licensee.  In order to determine what terms are effective, you
> have to know when the license was granted, and what the FSF and OSI approved
> licenses were at various points in time.  You literally have to use the Internet
> Archive wayback machine, and do a bunch of research, to interpret the license terms.
> It is not, as currently constructed, a good license, due to this lack of legal clarity.

But the above seems to indicate one technical pain point in so far as
two sections:

4. Condition Against Further Restrictions; Inbound License Compatibility
7. Nullification of Copyleft/Proprietary Dual Licensing

If you are going to offer to pay for an alternative proprietary
licensing, I'm sure you can do the work.

And if in so far as clause 4 is concerned, yeah I think wayback machine
is a sensible solution. Good idea, seems like we have that covered since
1999 [3].

[3] https://web.archive.org/web/*/https://opensource.org/licenses

  Luis