On Wed, May 25, 2022 at 07:05:31PM +0000, Bird, Tim wrote: > > -----Original Message----- > > From: Luis Chamberlain <mcgrof@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx/ [2] https://lkml.kernel.org/r/1495234558.7848.122.camel@xxxxxxxxxxxxxxx > 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
