Regarding the "nullification in case of proprietary dual licensing" clause (a developer's perspective)
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.
On Wed, Jul 28, 2021, at 7:59 AM, Ciprian Craciun wrote:
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).
Why would you be locked-out of your code?
Any kind of proprietary licensing of copyleft-next code effectively turns copyleft-next into a permissive license for everyone using that copyleft-next licensed project. Obviously you as the copyright-holder don't need a license to use or sell your own code.
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,
The entire purpose of the clause is to eliminate that "edge on competitors".
If you use copyleft-next on code which you also offer as a proprietary license -- then copyleft-next becomes permissive to ensure everyone who legally obtained that code licensed under copyleft-next can compete with you by making their version also proprietary.
-- Kuno.
On Wed, Jul 28, 2021 at 4:59 PM Kuno Woudt kuno@frob.nl wrote:
Why would you be locked-out of your code?
Any kind of proprietary licensing of copyleft-next code effectively turns copyleft-next into a permissive license for everyone using that copyleft-next licensed project. Obviously you as the copyright-holder don't need a license to use or sell your own code.
Indeed, it's not like I'm unable to use my own code, however I can't still use it in the way I've described (i.e. as a minor part of a proprietary product) and still keep it available as copyleft-next open-source.
In essence at that point, I would be better off just switching (for future releases) from copyleft-next to the GPL family.
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,
The entire purpose of the clause is to eliminate that "edge on competitors".
If you use copyleft-next on code which you also offer as a proprietary license -- then copyleft-next becomes permissive to ensure everyone who legally obtained that code licensed under copyleft-next can compete with you by making their version also proprietary.
But this "edge off on competitors" makes sense for whole products not for smaller parts as in my example with a company that would open source under copyleft-next only an algorithm (or something else) that is non essential to the whole product.
Thus my suggestion to allow relicensing under proprietary terms if the relicensed work isn't "the whole product". (I know this is hard to word in such a way that is enforceable from a legal point of view, but at least this route could be explored.)
Ciprian.
If you want to mix proprietary software with free software then copyleft is not your answer. Permissive licenses such as Apache 2.0/BSD/MIT is what you are looking for.
A note about your algorithm example; Algorithms as the ideas per se are not protected by copyright. Meaning, even if you publish your algorithm under a proprietary license; That doesn't stop anyone else from writing a white paper in plain English or in mathematical notation about what the algorithm is supposed to do, then someone else can reimplement that algorithm under any license of their choice.
On Wed, Jul 28, 2021 at 5:53 PM Solomon B solomonb9@outlook.com wrote:
If you want to mix proprietary software with free software then copyleft is not your answer. Permissive licenses such as Apache 2.0/BSD/MIT is what you are looking for.
It might be nice to have a "mission statement" from the copyleft-next authors regarding what is their overall goal with this license?
I find it (thought of it) as a more utilitarian form of GPL, with more focus on usability than on doctrine...
Now about the statement regarding the mix of copyleft-next with proprietary licenses, I think this puts copyleft-next into a lonely corner of open-source licenses... Because in the end (like with many things today) a power of a license comes from its user-base, and unfortunately a user-base can't be built only upon "pure" open-source projects, mainly because there is no funding in that niche.
A note about your algorithm example; Algorithms as the ideas per se are not protected by copyright. Meaning, even if you publish your algorithm under a proprietary license; That doesn't stop anyone else from writing a white paper in plain English or in mathematical notation about what the algorithm is supposed to do, then someone else can reimplement that algorithm under any license of their choice.
I agree in principle, that ideas can't / shouldn't be licensed / patented; however there is a distinction between a "specification" (what an algorithm is in the end) and it's "implementation" (the software embodiment of the idea).
Take for example one of the new cryptographic hashes (that don't yet have native CPU support like SHA): even though the algorithm is public domain, a naive implementation (that is easy to implement in portable C or another language) might be quite inefficient, however someone could implement it in fine-tuned assembly to achieve quite a few orders of magnitude better performance. Thus although the algorithm is public, the implementation could be licensed under proprietary terms.
However, getting back to my example, the algorithm is just a placeholder for some generic useful library that is not where the value of the product lies.
Ciprian.
Copyleft emerged to protect the rights of users of the software against proprietary software shackles. Proprietary software is focused on making money first, while copylefted free software such as the GNU project focuses on the user's rights to freely use, modify, redistribute the software and funding is a secondary question. The objectives of Copyleft and Proprietary licensing could not be further from each other; So trying to mix Copyleft with proprietary is not supported by either strategies. I too fail to see the policy end goal behind copyleft-next. It seems more like the product of experimenting with licensing ideas just because it's cool.
On Thu, Jul 29, 2021, at 11:02 AM, Solomon B wrote:
Copyleft emerged to protect the rights of users of the software against proprietary software shackles. Proprietary software is focused on making money first, while copylefted free software such as the GNU project focuses on the user's rights to freely use, modify, redistribute the software and funding is a secondary question. The objectives of Copyleft and Proprietary licensing could not be further from each other; So trying to mix Copyleft with proprietary is not supported by either strategies. I too fail to see the policy end goal behind copyleft-next.
The purpose of the nullification clause as I understand it is to remove the competitive advantage the copyright holder has with the GPL family of licenses. By removing the incentive for proprietary dual licensing, presumably any copyleft-next licensed code is less likely to end up being dual licensed.
This is a response to companies trying to have their cake and eat it to by pretending to be open source by using the AGPL, while their main focus is on selling proprietary licenses.
To some extent I think AWS has proven that the AGPL is not in itself enough protection for businesses trying to use that model, with companies like MongoDB and Elastic moving to source-available proprietary licenses.
Given that trend, perhaps the clause isn't as important nowadays as it was when written.
-- Kuno.
In my personal point of view I have no issue against proprietary dual licensing with GPL. I would have an issue if the software was originally developed and funded by the community then later was proprietarized by a company which happens with permissively licensed community projects. But in the case where a company develops a software from scratch and is the sole owner of it, I have no comment about their competitive practices by offering a GPL version alongside the usual proprietary version.
There is one problematic case that often arises and that is when community developers decide to submit the changes back, and they do not want their community effort to become proprietary software. My solution is simple. Fork it. Make a community fork where copyrights are held by the community. It's that simple.
Whether I think that the nullification clause of copyleft-next replaces the the need of the previously mentioned forking solution; My answer is no. Because the nullification clause falls back to permissive, and permissive means anyone can make a proprietary version of the software, while a community fork would be under copyleft instead which means that no one can make a proprietary version of the community funded effort.
In defense of proprietary dual licensing with copyleft.
I want to live in a world where proprietary licensing doesn’t exist, so I will not be defending the that, instead I will focus on the benefit to free software.
Proprietary software when published under a copyleft license such as GPL, is in fact published as free software which can be used by free software projects. Being banned from using a copyleft license, either will push towards the proliferation of copyleft licenses that aren’t and probably couldn’t be compatible with at least the license that they have been banned from; or will drive this dual licensing scheme out of business and proprietary software will continue being proprietary without the free option, in which case the loss is to free software.
Forcing proprietary software vendors to stop offering a free version licensed under copyleft, is akin to forcing service providers such as github.com to cease providing free services for free software projects; because the motivation behind the business model is similar; free for open source, and paid for commercial.
I my conclusion, I do not find being hostile to the proprietary world - by banning them from using copyleft as a dual licensing scheme - actually beneficial to the cause of the free software movement, nor do I find it a necessity.
copyleft-next@lists.fedorahosted.org
-
Ciprian Craciun -
Kuno Woudt -
Solomon B