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.
