| Message ID | 20210707184310.3624761-1-mcgrof@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | LICENSES: add and use copyleft-next-0.3.1 | expand |
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. Why do we need a random weirdo license in the kernel tree? Is there any benefit? If so it needs to be clearly spelled out.
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? 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. It is directly testing GPL-v2-only code, so the attempt to dual license it makes no sense to me. How could anyone take that code and do anything with it under the copyleft-next license only? And where would that happen? 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. 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. thanks, greg k-h
[ Full Disclosure: I've written parts of copyleft-next, have been involved with the initiative basically since its inception, and obviously I like the license a lot. Take my comments with the recommend dose NaCl granules those facts require. ] Greg KH wrote: > 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? There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in Linux. Many corporate copyright holders have well documented strong reasons for wanting that. (Those policy goals and the analysis behind them, I find problematic and sometimes outright wrong, but nonetheless it's their right to license their copyrights that way, and the license *is* GPLv2-only compatible, as is Luis'!). I assume that you're not asking those companies to relicense to pure GPLv2-only. While those companies perhaps faced early resistance when they began their dual-licensing-in-upstream endeavor, it was ultimately accepted and that opens the door, IMO, to accepting any form of GPL-compatible dual-licensing upstream. There is no cogent argument that I can see that says “(GPLv2-only|{2,3}-Clause-BSD) is so special that it should be grandfathered in over other forms of dual licensing”. (Ironically, IIRC, (then acting on behalf of Qualcomm/Atheros, Luis — the person proposing the (GPLv2-only|copyleft-next) dual-licensing *now* was a champion of upstreaming (GPLv2-only|{2,3}-Clause-BSD) code years ago before it was a wide and common practice.) > 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. It is directly > testing GPL-v2-only code, so the attempt to dual license it makes no sense > to me. How could anyone take that code and do anything with it under the > copyleft-next license only? And where would that happen? But, it's a valid compatible license, so there is no harm. And, see below, regarding policy reasons … > 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, Consider me to be the first to advise that! I realize it's a tough thing to do, but every great adventure to solve a big problem starts with a first step! I further realize it's a non-starter, but please don't say again no one has advised you such! BTW, the only reason I didn't advise it because I know a top-level license change away from straight, no-exceptions/no-additional-permissions GPLv2-only is a non-starter for the Linux community. (Great, BTW, that you've stuck so firmly to your steadfast plan on this!) Greg continued: > 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. Relatedly, Christoph asked (footnote mine): >> Why do we need a random weirdo [0] license in the kernel tree? Is there >> any benefit? To be frank, we in the copyleft-next community were very excited to learn that such dual-licensed code had been added to upstream Linux, back when it was many years ago. It's a vote of confidence from a well-known developer who really is excited about our policy goals. FOSS licensing isn't just about simplicity and cleanliness. Like budgets, which seem dry topics on surface, they are actual moral documents that make a statement about the philosophy and aspirations for software freedom by the licensor. Of course, we all know it's completely symbolic to dual license (GPLv2-only|copyleft-next), just like it's purely symbolic to dual license (GPLv2-only|2-Clause-BSD) upstream [1]. But it makes a statement that I think is a good one. Finally, while GPLv2-only compatibility has been a mainstay so far in copyleft-next drafting, it's not clear to me that we can keep that compatibility forever and reach copyleft-next's policy goals. There's been no discussion of this yet, but it's certainly in the realm of possibility. If GPLv2-incompatibility ultimately happens in future copyleft-next versions, having dual-licensed code out there will be a huge help as it will assure that code can forever be used both on GPLv2-only and copyleft-next sides of future single-license-project equations. Thanks for listening; of course it's the sole prerogative for the copyright holder to decide whether to change the license of their code or not, and I hope that they don't bow to pressure, just as Qualcomm wouldn't bow to pressure if you started asking them to stop dual licensing all their upstream Linux code under BSD licenses. [0] BTW, Christoph, I remember when I started in FOSS in the early 1990s, everyone called the GPL a “random weirdo license”. The incumbent always seems not as random and weirdo as the challenger. [1] There is the argument that 2-Clause-BSD has fewer requirements than GPLv2-only; however, that's not an argument to release the code *upstream* that way, it's an argument to release a separate version under 2-Clause-BSD. -- Bradley M. Kuhn - he/him Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Thu, Jul 08, 2021 at 07:59:13AM -0700, Bradley M. Kuhn wrote: > Greg KH wrote: > > 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? > > There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in > Linux. Many corporate copyright holders have well documented strong reasons > for wanting that. (Those policy goals and the analysis behind them, I find > problematic and sometimes outright wrong, but nonetheless it's their right to > license their copyrights that way, and the license *is* GPLv2-only > compatible, as is Luis'!). > > I assume that you're not asking those companies to relicense to pure > GPLv2-only. On the contrary, I have stated in public many times to companies that try to add dual-licensed new kernel code that they should only do so if they provide a really good reason, and pushed back on them numerous times. See the mailing list archives for details if you care. So yes, I am asking them, this is not anything new. Let's keep it simple please, and not add new licenses for no real good reason if at all possible. thanks, greg k-h
On Thu, 2021-07-08 at 17:32 +0200, Greg KH wrote: > On Thu, Jul 08, 2021 at 07:59:13AM -0700, Bradley M. Kuhn wrote: > > Greg KH wrote: > > > 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? > > > > There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in > > Linux. Many corporate copyright holders have well documented strong reasons > > for wanting that. (Those policy goals and the analysis behind them, I find > > problematic and sometimes outright wrong, but nonetheless it's their right to > > license their copyrights that way, and the license *is* GPLv2-only > > compatible, as is Luis'!). > > > > I assume that you're not asking those companies to relicense to pure > > GPLv2-only. > > On the contrary, I have stated in public many times to companies that > try to add dual-licensed new kernel code that they should only do so if > they provide a really good reason, and pushed back on them numerous > times. See the mailing list archives for details if you care. > > So yes, I am asking them, this is not anything new. > > Let's keep it simple please, and not add new licenses for no real good > reason if at all possible. You can ask but it's the submitter's choice to license their code however they desire.
> -----Original Message----- > From: Bradley M. Kuhn <bkuhn@ebb.org> > > [ Full Disclosure: I've written parts of copyleft-next, have been involved > with the initiative basically since its inception, and obviously I like the > license a lot. Take my comments with the recommend dose NaCl granules > those facts require. ] > > Greg KH wrote: > > 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? > > There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in > Linux. Many corporate copyright holders have well documented strong reasons > for wanting that. (Those policy goals and the analysis behind them, I find > problematic and sometimes outright wrong, but nonetheless it's their right to > license their copyrights that way, and the license *is* GPLv2-only > compatible, as is Luis'!). > > I assume that you're not asking those companies to relicense to pure > GPLv2-only. While those companies perhaps faced early resistance when they > began their dual-licensing-in-upstream endeavor, it was ultimately accepted > and that opens the door, IMO, to accepting any form of GPL-compatible > dual-licensing upstream. There is no cogent argument that I can see that > says “(GPLv2-only|{2,3}-Clause-BSD) is so special that it should be > grandfathered in over other forms of dual licensing”. > > (Ironically, IIRC, (then acting on behalf of Qualcomm/Atheros, Luis — the > person proposing the (GPLv2-only|copyleft-next) dual-licensing *now* was a > champion of upstreaming (GPLv2-only|{2,3}-Clause-BSD) code years ago before > it was a wide and common practice.) > > > 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. It is directly > > testing GPL-v2-only code, so the attempt to dual license it makes no sense > > to me. How could anyone take that code and do anything with it under the > > copyleft-next license only? And where would that happen? > > But, it's a valid compatible license, so there is no harm. And, see below, > regarding policy reasons … > > > 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, > > Consider me to be the first to advise that! I realize it's a tough thing to > do, but every great adventure to solve a big problem starts with a first > step! I further realize it's a non-starter, but please don't say again no > one has advised you such! > > BTW, the only reason I didn't advise it because I know a top-level license > change away from straight, no-exceptions/no-additional-permissions GPLv2-only > is a non-starter for the Linux community. (Great, BTW, that you've stuck so > firmly to your steadfast plan on this!) > > Greg continued: > > 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. > Relatedly, Christoph asked (footnote mine): > >> Why do we need a random weirdo [0] license in the kernel tree? Is there > >> any benefit? > > To be frank, we in the copyleft-next community were very excited to learn > that such dual-licensed code had been added to upstream Linux, back when it > was many years ago. It's a vote of confidence from a well-known developer > who really is excited about our policy goals. FOSS licensing isn't just > about simplicity and cleanliness. Like budgets, which seem dry topics on > surface, they are actual moral documents that make a statement about the > philosophy and aspirations for software freedom by the licensor. Of course, > we all know it's completely symbolic to dual license > (GPLv2-only|copyleft-next), just like it's purely symbolic to dual license > (GPLv2-only|2-Clause-BSD) upstream [1]. It's not at all purely symbolic to dual license (GPLv2-only|2-Clause-BSD). That dual-licensing has allowed the interchange of a lot of code between the BSD Unixes and Linux, that otherwise would not have happened. It's very much in the spirit of Linus' tit-for-tat compact to allow the BSD Unixes to benefit from improvements made to code that originated there and made it's way to Linux. -- Tim > But it makes a statement that I > think is a good one. > > Finally, while GPLv2-only compatibility has been a mainstay so far in > copyleft-next drafting, it's not clear to me that we can keep that > compatibility forever and reach copyleft-next's policy goals. There's been > no discussion of this yet, but it's certainly in the realm of possibility. > If GPLv2-incompatibility ultimately happens in future copyleft-next versions, > having dual-licensed code out there will be a huge help as it will assure > that code can forever be used both on GPLv2-only and copyleft-next sides of > future single-license-project equations. > > Thanks for listening; of course it's the sole prerogative for the copyright > holder to decide whether to change the license of their code or not, and I > hope that they don't bow to pressure, just as Qualcomm wouldn't bow to > pressure if you started asking them to stop dual licensing all their upstream > Linux code under BSD licenses. > > [0] BTW, Christoph, I remember when I started in FOSS in the early 1990s, > everyone called the GPL a “random weirdo license”. The incumbent always > seems not as random and weirdo as the challenger. > > [1] There is the argument that 2-Clause-BSD has fewer requirements than > GPLv2-only; however, that's not an argument to release the code > *upstream* that way, it's an argument to release a separate version under > 2-Clause-BSD. > > -- > Bradley M. Kuhn - he/him > > Pls. support the charity where I work, Software Freedom Conservancy: > https://sfconservancy.org/supporter/
Greg KH wrote: > Let's keep it simple please, and not add new licenses for no real good > reason if at all possible. I've stated a number of real good reasons to keep copyleft-next as a dual-licensing option; they seem to have not been refuted here. Indeed, this point is quite salient: Joe Perches wrote: >>> You can ask but it's the submitter's choice to license their code however >>> they desire. … to which I'd add, as long as the license is GPLv2-only-compatible, which of course (GPLv2-only|copyleft-next) is. Rest is admittedly a bit OT: Greg also noted: > I have stated in public many times to companies that try to add > dual-licensed new kernel code that they should only do so if they provide a > really good reason We can agree to disagree on the differences in how company vs. individual requests and their "good reasons" are handled/prioritized; I think we'd both agree it's actually moot anyway. While it's an important topic, I apologize for raising that as it was off-topic to the issue at hand. On that off-topic point, Tim Bird added: >> It's not at all purely symbolic to dual license (GPLv2-only|2-Clause-BSD). >> That dual-licensing has allowed the interchange of a lot of code between >> the BSD Unixes and Linux, that otherwise would not have happened. This is a good point, but the same argument is of course valid for copyleft-next-licensed projects. While there are currently fewer than those than BSD-ish projects, I don't think Linux should stand on ceremony of “your project must be this tall to ride this ride” and share code with us … and then there are the aspirational arguments that I made in my prior email. -- Bradley M. Kuhn - he/him Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/
On Thu, Jul 08, 2021 at 06:14:46AM +0200, Christoph Hellwig 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. > > Why do we need a random weirdo license in the kernel tree? Its already present in the kernel. This patch just adds the respective SPDX license tag so we can remove the boiler plate. > Is there > any benefit? If so it needs to be clearly spelled out. The benefits are described in the first patch, I hope that's clear enough. Let me know if its not! Luis
On Thu, 8 Jul 2021 10:52:54 -0700 "Bradley M. Kuhn" <bkuhn@ebb.org> wrote: > Joe Perches wrote: > >>> You can ask but it's the submitter's choice to license their code however > >>> they desire. > > … to which I'd add, as long as the license is GPLv2-only-compatible, which of > course (GPLv2-only|copyleft-next) is. I agree with Joe on this, but I have to ask; What happens when someone makes a change to this file? The default kernel license is GPL-v2. Does this change automatically become the same as the file itself, or is the new change under the dual license? I've made changes to code that had a dual license that wasn't GPL compatible, and the company involved asked me to sign off on the other license (which I did). -- Steve
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
On Thu, Jul 08, 2021 at 03:01:58PM -0400, Steven Rostedt wrote: > On Thu, 8 Jul 2021 10:52:54 -0700 > "Bradley M. Kuhn" <bkuhn@ebb.org> wrote: > > > Joe Perches wrote: > > >>> You can ask but it's the submitter's choice to license their code however > > >>> they desire. > > > > … to which I'd add, as long as the license is GPLv2-only-compatible, which of > > course (GPLv2-only|copyleft-next) is. > > I agree with Joe on this, but I have to ask; What happens when someone > makes a change to this file? The default kernel license is GPL-v2. Does this > change automatically become the same as the file itself, or is the new > change under the dual license? > > I've made changes to code that had a dual license that wasn't GPL > compatible, and the company involved asked me to sign off on the other > license (which I did). The Signed-off-by tag implies you are making a contribution under the same license as the license file states. The more people are aware of this fact, the better, and its then why we made DCO a public thing and now other projects embrace it. Luis
On Thu, 8 Jul 2021 12:37:46 -0700 Luis Chamberlain <mcgrof@kernel.org> wrote: > The Signed-off-by tag implies you are making a contribution under the > same license as the license file states. The more people are aware of > this fact, the better, and its then why we made DCO a public thing and > now other projects embrace it. Ah, I forgot it was "per-file" and not "per-project". That's the difference. -- Steve