copyleft-next July 2021

copyleft-next@lists.fedorahosted.org

8 participants
11 discussions

OSI submission
by Richard Fontana 25 May '22

25 May '22

Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval? I had given a little thought to the idea in the past, but while I was on the OSI board (2013-2019) I considered it to be inappropriate. Richard

10 10

Regarding the "nullification in case of proprietary dual licensing" clause (a developer's perspective)
by Ciprian Craciun 01 Aug '21

01 Aug '21

I have been following the copyleft-next mailing list for quite a while (since perhaps 2013), and I've pondered on using it for my own projects, especially since it is simpler than the GPL family, and it is a lot friendlier to integrations with other non copyleft-next compatible licenses but still OSI / FSF approved. There are two (possibly three) issues I have with copyleft-next as compared to the GPL family (which I use for my own work): (a) the nullification in case of proprietary dual licensing clause; (that I'll tackle in this email;) (b) the licensing sunset clause (to a somewhat lesser extent); (c) the lack of network effect like in the case of AGPL (to an even lesser extent); However my main issue is with the nullification in case of proprietary dual licensing clause. I understand the broader issue, where one company builds a nice open-source product and after it becomes popular they start to either lock new features behind a proprietary version (like MySQL does, or countless other "large" projects), or they relicense under an AGPL-like or proprietary license (like has been done by Oracle with BerkeleyDB, Elastic Search, MongoDB, etc.) Unfortunately I don't think such a clause would actually stop such behavior because it puts in public domain only old versions of the software, and given the quality of today's software, that would be obsolete (if not outright a security risk) in no more than a couple of months. Moreover I think the main enabler of such behavior is the copyright assignment agreements that I think should be fought against by the various open-source foundations (without the copyright assignment, they couldn't have switched to a new license). But this is not the main reason I don't find the nullification clause attractive, but another more pragmatic one... I'll take my personal use-case: I'm what I would call a "hobbyist" open-source developer, in the sense that I've open-sourced quite a lot of experimental tools and projects that have zero users (basically abandonware); thus at the moment I have zero returns (in monetary terms) from my work, and thus close to zero probability (and incentive) to someday sell my projects as proprietary products. As such I could easily use copyleft-next as a license without any issue. (In fact in all my licensing notices I do say that although I release that code under mostly LGPL/GPL/AGPL, I am always open to relicensing it under any other open-source license if any user has this requirement for whatever purposes). However most of what I do is at least as a response to a particular current or perceived need, and thus I do keep an (hopeful) eye open to somehow benefit (in monetary terms) from my effort. How I envisage such a situation? Simple, I assume I'll be able to incorporate my code in some for-pay project without requiring that project to become open-source or me licensing my code under something like MIT/BSD just for this purpose. Thus if my code is a library, which I usually release under LGPL, I can just link against it without any issues, or if it's GPL/AGPL (depending on the case) I can always relicense it to my customer. (All this assumes I have no contributed patches, which at the moment stands.) As seen, my presumed "business model" isn't a bait-and-switch one, but merely "using" my code to sustain future development. (As a matter of fact, I've seen quite a few small prototype-like open-source projects lately that explicitly state they are provided open-source "as is" for the benefit of the users, and are not interested in patches due to lack of time and effort in handling them.) Now, if I were to use copyleft-next, and the (unlikely) opportunity of using it in a commercial way would arise, I would be basically locked-out of my own code, and thus would force me to start from scratch (which basically means any improvement I could have made to the open source project would be voided). As such, at the moment, I can't choose to use copyleft-next due to this (close to zero) perceived risk. In the end, and assuming that the spirit of this clause is to fight bait-and-switch behavior, I think the nullification clause could be changed in a couple of ways: * like other clauses make it optional; (just like the network services clause is in the master version;) * rewrite it, or include an exception, that would allow one to use such covered work only as a "non-almost-everything" part of another product; (for example take the example of an SQL DB engine, say I release a transactional key-value storage engine under copyleft-next, I could use it in my proprietary SQL DB engine because the SQL engine does much more than just being a key-value store wrapper;) And if my above use-case didn't convince, then how about this other plausible use-case: say a company has developed an algorithm (say image compression, etc.) that was included in some proprietary software; then said company wants to open-source only that algorithm, but under a copyleft license to still keep it's edge on competitors, but still benefiting the open-source community; in that case it couldn't use copyleft-next as the license because (given it is still selling it as part of a proprietary product) the nullification clause would apply, basically putting it in public domain. Furthermore the license isn't clear about the ordering of events; for example would the nullification clause apply in the following case? Said company had the proprietary algorithm that it sold as part of a product, but now it makes it available under copyleft-next license and stops selling that proprietary product (including support for it which would require new proprietary builds). Would the nullification clause apply? Granted both copyleft-next v0.3.1 and the master one use the present term "if I offer" or "if I distribute", thus it would imply not. However as hinted, that company would not be able to still keep supporting the proprietary product because it would imply offering under a proprietary license the covered work after they've released it under copyleft-next. Hopefully I've made my case against the nullification clause. Ciprian.

3 8

Isn't the copyleft sunset a disadvantage to free software
by Solomon B 29 Jul '21

29 Jul '21

To quote section 8 of copyleft-next-0.3.1: ` 8. Copyleft Sunset The conditions in sections 3 through 5 no longer apply once fifteen years have elapsed from the date of My first Distribution of My Work under this License. ' I feel that addressing copyright obsolescence should be follow whatever the copyright law says - which is currently 120 years or the author's lifetime plus 70 years - because the issue I am seeing with the "Copyleft Sunset" clause is that it puts free software as a disadvantage in comparison to non-free software. As a free software maximalist I want all software in the world to never be proprietary including the old software that I wrote ages ago and nobody uses anymore, I want that too to remain free forever and after.

4 5

=?utf-8?q?=5Bcopyleft-next=5D?=(Request for) clarifications regarding the sunset clause
by Ciprian Craciun 28 Jul '21

28 Jul '21

In relation to the other thread discussing the subject of sunset clause, I've re-read the clause in question and personally (as a developer) I am even more confused about how it should be properly applied. Quoting (from v0.3.1): << The conditions in sections 3 through 5 no longer apply once fifteen years have elapsed from the date of My first Distribution of My Work under this License. >> (Although the current master has almost the same words, its clause coverage is different, most notably including the proprietary dual license clause.) I have problems understanding the following items: * the fact that it applies 15 years since my **first** distribution; this implies that if one is maintaining a work for more than 15 years, basically after that point one is doing public domain work, which reduces ones incentive to keep contributing, given that now distributors (and competitors) can just take any new enhancements for free and not contribute anything back; * in the "master" version of the license, the sunset clause also applies to the "proprietary dual licensing" clause, meaning that after 15 years, the original author can now re-license both the original work and any later derived works, thus completely side-stepping the original license; (it seems that this doesn't hold for v0.3.1, which doesn't sunset the proprietary dual licensing clause;) * who is the "my" in that clause? according to the definition in v0.3.1 (which is missing from the master), "my" is the original author of the "my work"; however in the context of open-source software development there are many authors that submit patches, which under the definitions of the license (at least v0.3.1) are actually "distributors" that "distribute" "derived works"; so in the end this clause applies only to the original author, i.e. the first open source contributor (i.e. "my"), and not to later contributors? if so how does this clause apply to a project with many authors throughout the time? * how does this clause apply in the case of patches? in v0.3.1 section 6 (licensing for upstream contributions) it is stated that a patch becomes in fact "my work", and thus the contributor becomes in his turn "my"; thus taking that patch as a "my work" in itself, the sunset clause applies to this contributor 15 years after he made his first contribution to a project, but only for versions of that project that come after that patch; Based on my observations above, in the context of an open-source project, the sunset clause would apply to the latest version of a project only when the youngest developer has already been involved for 15 years in the project. And any new contributor to that project would prolong the 15 years deadline, which in essence, for popular projects would mean that the sunset clause would never actually apply in practice. I've tried searching the mailing list archives, and found a similar topic in the thread `Copyleft Sunset` from February 2018, where Janson made the following two interpretations: * that in the sunset clause "my work" actually implies the original author's work and any other derived works; (I don't make such an interpretation, since my question regarding patches;) * that 15 years are counted since the first distribution of "my work" but then it applies to all future versions that "my" am releasing; (I am also making this interpretation;) However reading that thread, especially Janson's suggestion of including the word "version" in the sunset clause, now I too wonder if the "my work" actually means "a particular version of my project", or to the whole project continuously morphing? I.e. are we putting in public domain only works that are 15 years old, or any versions of a project that has more than 15 years of existence? As a conclusion, I think at least in the context of open-source projects with many authors, the sunset clause doesn't quite work in the current form (or at least it's unclear how it is to be applied). I think it makes a lot of sense for a company that releases software as source code snapshots with no other contributors and no public history (i.e. there is only one "my" entity, a clear "my work" that is the current release, and perhaps only patches with a copyright assignment that are not seen by the public). However I have a hard time wrapping my head around how this clause would apply to a GitHub project with thousands of commits and hundreds of contributors. (I.e. what is an original "my work" combined with a patch that is another "my work"? Is it just an "derived work", or given that it can be a base for other patches, becomes in itself a "my work"?) In the end I think I agree with Solomon and Jason observation, made in the last thread about "sunset a disadvantage to free software", that perhaps open-source work should always remain open-source (i.e. not public-domain). Or perhaps, a different approach to the sunset clause would be to replace the public domain with any "OSI-Approved and FSF-Free" (as is the case of the inbound license compatibility) thus allowing the re-licensing by users after 15 years. Thanks, Ciprian.

2 1

Solution for prop relicensing
by sidhant＠tuta.io 24 Jul '21

24 Jul '21

Re-Licensing waiver clause "If the licensor excersices any rights as a copyright holder to Re-License his contributions orignally licensed under this license(other than he could have without actually being a copyright holder) then their work is deemed to be released under Public Domain." Is there a problem with this approach?

1 0

Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
by Luis Chamberlain 08 Jul '21

08 Jul '21

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(a)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

1 0

Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
by Luis Chamberlain 08 Jul '21

08 Jul '21

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

1 0

Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
by Luis Chamberlain 08 Jul '21

08 Jul '21

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

1 0

Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
by Bradley M. Kuhn 08 Jul '21

08 Jul '21

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/

1 0

Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1
by Bradley M. Kuhn 08 Jul '21

08 Jul '21

[ 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/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next July 2021