> -----Original Message----- > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > Tim! > > On Wed, May 25 2022 at 19:05, Bird, Tim wrote: > >> From: Luis Chamberlain <mcgrof@xxxxxxxxxxxxx> On Behalf Of Luis Chamberlain > >> 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. > > No! Sorry for the delayed response. I was on vacation over memorial day weekend (holiday in the US.) I think that the option to reject a contribution based on its license should be available to the community, using criteria beyond those that Luis has mentioned (and that you mention below). I could create a license that was GPL-2.0-only compatible, and use it to cover a new contribution to the Linux kernel (in dual-license format), in order to get exposure for the license or to promote it. We could use the SPDX identifier "Tims-license-0.1". I think it would be fair for the community to reject a contribution based on those license circumstances, even though it met all the criteria you mention. I don't think that the Linux kernel should be used for license promotion, but if it is, then it should be used to promote GPL-v2-only. > > > There were good reasons that the original BSD dual-licenses were > > allowed. Those same reasons don't apply here. > > That's just wrong. The reason why dual licensing is allowed is to share > code across licesce preferences. The very same reason applies here. I was talking about why dual licensing was originally introduced, which was a situation different from what went on in 2016, when the copyleft-next dual license was discussed. Dual-licensing in the Linux kernel was originally introduced because code was being taken from BSD and placed into Linux (under GPL v2), often by someone other than the original author. This created a bit of hard feelings between the BSD community and the Linux community. So dual-licensing was introduced so that derivative works (created by Linux developers) of BSD code could flow back into the BSD project. This was code that existed before being introduced into Linux, and there was no notion of using the kernel to promote the BSD license. I have a problem with the statement: "The reason why dual licensing is allowed is to share code across license preferences. The very same reason applies here." I'm concerned about license proliferation, and that statement has no limiting principle. Although you do raise some limiting principles below, I don't think they are adequate. I don't think it should be the mission of the kernel to allow shared code across [any and all] license preferences. Just by way of example, I would hesitate to support the adoption into the kernel of any license that had an "or later" provision. That's true, even on the other side of an "OR" clause. Also, my preference would be to limit new licenses to OSI-approved licenses, which have already had extensive vetting. > > > 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. > > It's none of our problems that corporate lawyers are obviously unable to > act, cooperate and to agree on something. That's an over-generalization. > > The license in question is around since 2016 and the kernel carries > code under that license since 2017. > > So what the hell are you complaining 5 years after the fact? The whole > point here is to convert this to SPDX identifiers. I missed the original discussion, and the license was limited in application. I agree that my complaint is late, but this conversion to SPDX adds the license text to LICENSES, which IMHO makes this license stand out more than it has previously, and possibly provides an implied endorsement. I think it's a good thing to convert from the current language to an SPDX identifier. And that I'm late to the party with complaints about this particular license. But I'd rather not encourage developers to use this license going forward. > > Aside of that I'm impressed by your chutzpah to make up an argument on > corporate lawyer costs. Burden on corporate lawyers (and, dare I say, OSPO people like myself who deal in license training at our respective companies) has been a consideration in past discussions of contributions. The 2016 LKML thread about the original submission included discussion about the amount of "lawyer ink" required for different licensing constructs and development scenarios. For example, see https://lore.kernel.org/lkml/20170518221205.gcfs2t4ihlpx5kj6@xxxxxxxxx/#t > > Do you realize how much costs the very same crowd of corporate lawyers "very same crowd"? > created by ill advising their employees to put corporate defined > boiler plate into every other kernel source code file or by not > advising them at all and let them add random crap? I think we're talking about different sets of lawyers, so the rest of the complaint about some lawyers and the costs they've imposed on the kernel community I think is unrelated. > > Do you realize that the costs to cleanup this mess have been mostly > covered by community members with the help from a _very_ small subset > of corporate lawyers? > > Do you realize that it's hilarious that your so costly corporate > lawyers only need to react now that we are trying to convert licensing > information to SPDX 5 years after the fact? The fact that the conversion being discussed *now* may not yield an identical licensing situation seems to warrant some legal discussion. I assume Luis is on-board with the change in licensing situation due to the conversion, but I have yet to see the final patches. > > Do you realize that the SPDX cleanup effort is reducing the costs for > everyone including _all_ of the corporate lawyers you are so concerned > of? Yes. I'm supportive of using SPDX in the kernel, as are all the lawyers I work with. > > Sure, complaining about your individual corporate costs is way simpler > than: > > - contributing to community efforts to reduce those costs > > - acknowledging that the community efforts even without contribution > or your particular organization are reducing those costs > > Try again. Try what again? Communicating a preference on license proliferation? That's what this message is. > > > 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. > > And here is the thing: > > Whether you consider it to be a good license or not, does not matter > in this context. > > The license _IS_ GPLv2 compatible which is even understandable for > mere mortals, i.e. non lawyers. That's the only relevant point for > including code under this license into the kernel. I disagree. There are other relevant points if the kernel is being used to promote a license. I have made all my contributions to the Linux kernel (meager though they are) under GPL-v2-only. I think straying from this should be rare and well-justified. > > Your way-back machine argument is beyond hilarious. Guess what the > folks who try to cleanup the corporate lawyers induced mess in the > kernel rely on? But that's absolutely not applicable to this > problem. Why? > > The kernel has very strict rules for licensing today. Any valid > SPDX tag in a source file has to be accompanied with a > corresponding machine readable license file. > > This license file is version controlled and if there is a > dependency on any other license in the context then the > dependency is also available in the git history. > > So no, you do not need Internet archive for this at all simply > because if the kernel git history vanishes from the planet > then this particular licensing problem is the least of your > worries. I said that the textual terms of copyleft-next require the Internet archive to interpret. That's completely independent of what version control system you use to track the license and its application to the kernel. Linux kernel git logs are not going to tell you what the OSI and FSF-approved licenses were in 2016. > > Maybe it's about time to move your corporate lawyers, who are > caught in their own past sins, to the reality of today. *My* corporate lawyers and their "past sins"? I think you're taking actions by some lawyers and overgeneralizing them. It is not unheard-of to consider the cost in legal overhead in licensing considerations in the kernel. I believe Luis is working on an independent patch that isolates the SPDX conversion from the changes to the testing module code. As such, I'll give feedback on new patches going forward. Regards, -- Tim
