On Thu, Jul 08, 2021 at 08:22:26AM +0200, Greg KH wrote: > On Wed, Jul 07, 2021 at 11:43:08AM -0700, Luis Chamberlain wrote: > > This adds the copyleft-next-0.3.1 SPDX tag and replaces existing > > boilerplate with the tag. > > > > Luis Chamberlain (2): > > LICENSES: Add the copyleft-next-0.3.1 license > > testing: use the copyleft-next-0.3.1 SPDX tag > > > > LICENSES/dual/copyleft-next-0.3.1 | 237 +++++++++++++++++++++++ > > lib/test_kmod.c | 12 +- > > lib/test_sysctl.c | 12 +- > > tools/testing/selftests/kmod/kmod.sh | 13 +- > > tools/testing/selftests/sysctl/sysctl.sh | 12 +- > > As we only have 4 usages of this license in the tree, we have the > opportunity to actually remove it and keep the list of licenses that we > use in the kernel source smaller. > > Any chance you wish to just change the license of these files, given > that you are the only one that has tried to use it for kernel code? Since it is a "relatively" new license (2012, used in Linux since 2017) obviously not many people would have used it, but one cannot assume it is not because one does not want, but rather one is not aware. I myself have used the license for all new projects, and the agreement I reached with SUSE was I'd be using this license when I can for my own projects and contributions. I'm not a zealot though, and I also take care for proper considerations for such a large project such as Linux. It is why I had the license vetted by attorneys at SUSE in 2017, and also drew up a public discussion over its possible use on Linux. My goal then, in so far as Linux is concerned, is to use it for selftests as a safe place, which won't grow folks weary or concerned. And then let things evolve from there. Of all the items listed on patch #1 for which I prefer using copyleft-next the most important one for me is an explicit patent grant. Although GPL applies to Linux I do feel very strongly about propagation of more projects with such type of licenses and I feel we should be happy to help such projects grow by allowing cross polination. > As a follow-up to this, I do not want to see your "test_sysfs.c" module > as a dual-licensed file, as that makes no sense whatsoever. You can ignore the patch then, its a selftest driver, not a core sysfs change. I believe it should be up to the selftest maintainer? The changes I am making to sysfs are explicitly under GPLv2, and has nothing to do with copyleft-next. I am using dual licensing with copyleft-next only for selftests for now. I have support from SUSE to use this license. > It is > directly testing GPL-v2-only code, so the attempt to dual license it > makes no sense to me. So what? I can have BSD licensed code testing GPLv2 code. In fact folks out there use proprietary licensed code to test GPLv2 code as well. I don't see your the rationale here. > How could anyone take that code and do anything > with it under the copyleft-next license only? And where would that > happen? That's up to the users. In my case I am heavily involved with doing automation of testing and so *I care* as I am building automation of testing for all things kernel. My project kdevops, will soon be relicensed to copyleft-next. My personal development goal is I will embrace copyleft-next for anything new I write, and only use GPLv2 or another license when I am required to do so. I believe I am being reasonable also in using this only for sefltests for now as discussions and awareness of the license grows. > I understand the appeal of copyleft-next in that it resolves many of the > "grey" areas around gplv2, but given that no one is rushing to advise us > to relicense all of the kernel with this thing, there is no need to > encourage the spread of it given the added complexity and confusion that > adding another license to our mix can only cause. "Need" is subjective. I feel strongly about a need to have explicit patent grants propagating in our community. So the more we can do this outside of Linux and allow code from Linux to be used in such projects the better. The license is one of the only few licenses (if not only?) which is GPLv2 compatible and also has an clear patent grant. I have reasons to believe, we as a community face serious challenges if we don't grow our collection of code with explicit patent grants. And so any new project I create will have such licenses. It is simply my preference, and if I can contribute code to Linux in a "safe place" to slowly build traction of it, then fantastic. > So please, no, I don't want to see new licenses added to the tree, if > anything we should be trimming them down to be less as it makes things > simpler and more obvious. Too late. Dual GPLv2 / copyleft-next code was added in 2017 and I had a clear community discussion over it. I take caution and care about this. I do feel this discussion is worth having and hence my contributions in 2017 and now adding the respective SPDX license tag. Luis
