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.