> -----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. > > As a free software hacker *I* value the evolution of copyleft and copyleft-next > does just that. Some may have thought that it may not have been possible to > evolve copyleft and work with an evolved license on Linux, but copyleft-next > shows it is possible. Here in lies the value I see in it. > > 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. There were good reasons that the original BSD dual-licenses were allowed. Those same reasons don't apply here. Each license added to the kernel (even when added as an OR), requires additional legal analysis. Corporate lawyers don't usually rely on the interpretation of novel licenses from external sources. They do it themselves. This means that hundreds of lawyers may find themselves reading and trying to interpret the copyleft-next license. And here's the thing. The copyleft-next license has a number of legal issues that make it problematic. 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. Regards, -- Tim
