Messages in this thread | | | Date | Wed, 25 May 2022 12:44:11 -0700 | From | Luis Chamberlain <> | 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@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
| |