Hello,
Le samedi 18 mai 2013 à 23:21 -0400, Richard Fontana a écrit :
I hope the issue I am trying to address is now clear from the
referenced cinder-rtstool example, which as noted had quite an effect
on me.
What we have, in a Python context, is a file, with an Apache License
2.0 notice, that says 'import rtslib', and the file uses functions
from rtslib (AGPLv3-licensed). The project that was distributing
cinder-rtstool was not also distributing rtslib. I express no view
(here) on the (A)GPL analysis of this situation, copyleft-next being a
different license. I think it is interesting, however, that some
believed that it was a foregone conclusion that cinder-rtstool was
"really AGPL", in a context where this was understood to be perceived
as a *bad* thing. The effect is the continued, yet inconsistent,
marginalization of strong-copyleft-licensed code. That
marginalization, and some of its roots, are motivations for the
copyleft-next project itself.
As a data point, I'd like to mention that copyleft licenses are really
unpopular in the Python world. As a Python developer myself, if I want a
library of mine to get some use, I will choose a MIT-like license. (*)
I'm not sure exactly which triggered such unpopularity but there are
certainly several reasons.
One reason, slightly silly but which I think is quite widespread these
days, is that being liberal is "cool" (I think you could call it the
Github mindset).
But another reason is that there doesn't seem to be an appropriate
copyleft license for Python libraries. This is exemplified in the
following discussion where Twisted, a popular library, decided (long
ago) that they would switch from LGPL to MIT-like:
http://twistedmatrix.com/pipermail/twisted-python/2004-May/007944.html
(*) for an application of course I would use the GPL; but interestingly
the Python ecosystem is composed of libraries much more than
applications
While I did not say this even as recently as FOSDEM 2013, because it
wasn't really clear to me then, I think that strong copyleft as a
legal theory needs to be weakened in order to escape this threat of
marginalization.
Definitely agreed. It doesn't help that the FSF chose to marginalize the
LGPL.
I have come up with one approach. If you are writing a Python
library
foo and you put it under copyleft-next, and you want me to use your
library, you ought to have the burden of making clear that the moment
I merely distribute a file that says 'import foo' my file is ipso
facto "really copyleft-next". If you did not bother to do this, I
ought to be free to rely on an assumption you intended something
'weaker'.
Do note that "using a library" in the Python world can go very far,
perhaps as far as monkeypatching the library in order to fix some
undesired behaviour. The license (or its attached FAQ) has to be clear
that such uses don't entail propagation of copyleft to the application
as a whole.
Regards
Antoine.