> The license is explicitly outbound GPL-compatible. No GPL-incompatible
> restrictions will survive licensing derived works under the GPL. But
> no one should ever get to the point of having to convert to GPL to
> bypass the provision in question. A business (or its legal advisor)
> contemplating some copyleft-based open core scheme or the like will
> take one look at copyleft-next and decide to use some other copyleft
> license for such a purpose.
Suppose project A decides they are OK with the provision preventing an open core model and decide to use copyleft-next (CN) for their license. What's to stop them from rethinking later, changing the project license to GPL and developing a proprietary version with the open core model?
Yes, the lack of copyright for parts of the code would do that unless they require copyright assignment or a more permissive contributor license, but how is that any different from the situation of CN without the provision?
IOW, I don't see how the provision adds any restrictions on use of the code or project format. It just means if some project does eventually decide to go open core, their further contributions will no longer be compatible with other CN projects, only GPL ones. That seems to hurt only those who use CN "in good faith" as their license.
Posted Feb 21, 2013 14:39 UTC (Thu) by rfontana (subscriber, #52677)
[Link]
> IOW, I don't see how the provision adds any restrictions on use of
> the code or project format.
That's right; it doesn't. It is meant to be a strong disincentive to
use copyleft-next for copyleft/proprietary dual-licensing (by
nullifying its whole basis, which is monopolization of the
proprietization right), and to confine such conduct to other licenses.
> It just means if some project does eventually decide to go open
> core, their further contributions will no longer be compatible with
> other CN projects, only GPL ones. That seems to hurt only those who
> use CN "in good faith" as their license.
That's an interesting argument. The effect of this provision would
(let us assume) be to drive such a project (or to be more precise, the
business or entrepreneur behind it) to other licenses, these days most
likely the GPL or AGPL. So you're arguing that this is just a loss for
a copyleft-next code commons because it will be deprived of some
ability to use this open core code that might otherwise be under
copyleft-next.
First, such open core code will remain available for use by
copyleft-next projects provided it is a 'Separate Work' (outside the
scope of copyleft).
Second, assuming the open core project uses GPLv2/GPLv3/AGPLv3, such
open core code will be usable *inside the scope* of copyleft-next
works, with the theoretical effect being that the larger work will be
under GPLv2 or GPLv3 or some mixture of GPLv3/AGPLv3. This need not
have the effect of taking the *copyleft-next* code out of the
copyleft-next commons, so it doesn't seem like a huge loss. After all,
this nature of code combination occurs precisely because copyleft-next
is designed to be outbound-compatible with the GPL.
So I think your argument reduces to the argument that this provision
would have the effect of keeping the universe of copyleft-next
projects smaller. To me, this is *possible*, but it seems unlikely to
be meaningful unless copyleft-next becomes significantly popular
(which would be great but admittedly is not the case at the moment
:). And if it did become popular, I would see it as all the more
important to have this provision in, to prevent the 'gaming' of
copyleft-next that we've seen with other copyleft licenses.
In short, I'd rather have the copyleft-next universe be smaller and
limited to 'good-faith' projects, with the problematic conduct
confined to existing copyleft licenses like GPL/AGPL, than have the
copyleft-next universe be larger.