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

[Luis Chamberlain <mcgrof@kernel.org>]

On Wed, May 25, 2022 at 07:05:31PM +0000, Bird, Tim wrote:
> > -----Original Message-----
> > From: Luis Chamberlain <mcgrof@infradead.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