> Anfang der weitergeleiteten E-Mail: > >> Von: Yavor Doganov <ya...@gnu.org>
>> The problem is the linking. You can't link a GPL'ed application against >> a library under incompatible license, unless it classifies as a "system >> library". You can, if you are not DISTRIBUTING the result of the linking. The linkage occurs at run time, so unless you distribute, say, a core dump, nothing happens – the GNU GPL is not triggered. Furthermore, gajim (GPL) uses (*not* links, this is an additional distinction!) py-openssl via its defined API. It’s an exercise left to the reader to provide an implementation of the py-openssl API which either uses the piece of crap called GnuTLS, or is a dummy implementation. If you call it just the same, gajim would never know the difference. It just would suck more or be unable to use TLS at all (for the dummy implementation). This is a defined API, and the code is never distributed after combining. Please read http://groups.google.com/group/comp.lang.python/msg/29c7588fbecd8289 (again, if you already have) – it’s common FSF FUD (or, perhaps more politely, practice) to _assume_ the result being distributed. Here, it never is, because this is a scripting language, which does not support combining other than at run time anyway. The act of running the programme is not restricted, the GNU GPL says. By the way, even if I strongly believe they are evil, this is the same reason why binary LKMs for the Linux kernel are legal (unless they are bound by the GNU GPL for some other reason, such as being an actual derived work). >> That is precisely the problem. You do that and the combination is >> impossible Note how carefully you omit "to (re)distribute" in this place. >> , which is why[…] >> Please reread the license. Distributors are not allowed to distribute >> Gajim (at least in binary form, for sure) I’d like you to show how a Python “binary” – compiled to .pyc or .pyo files or not – is linked to a C library. Especially statically, as a dynamic linkage is, contrary to popular belief, not covered by the GNU GPL (simply for the reason that everyone can just place a different(ly licenced) or dummy implementation in its place). >> (How such bugs are resolved: 1) the package is relicensed upstream to >> GPL+OpenSSL exception While I do not consider this a bug, the LGPL, if it were not for its insanely huge size, would probably be a viable option. Note that I’m strictly talking for myself, and I am a developer of MirBSD and FreeWRT, not of gajim. >> 2) the package migrates to GnuTLS or NSS Yeah, sometimes I get the impression that “the GNU community” is using this FUD to promote GnuTLS, because it cannot shine through quality. >> 3) the >> openssl support is removed if 1) and 2) are impossible.) Actually, gajim does not use OpenSSL. It is py-openssl which does. >> It is definitely covered by the GPL, as the work you distribute "as a >> whole" Indeed, but mere aggregation does not count. >> should be under the GPL (which in practical terms means that all >> dynamically linked libraries ^^^^^^^^^^^ This is the part where both the FSF and you are wrong. The FSF is wrong in how they interpret the GNU GPL here (please re-read the above linked Usenet posting at this place), and you are wrong since gajim is not linked to OpenSSL at all. By the way, dynamic linkage is much more alike to using a dlopen(3)- style API than to shared linkage, in regard how works are combined at least. >> See for example >> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibilty. Interestingly, here you point out the source of this FUD. >> Note the two distinguished usages "I want to copy code under" and "I >> want to use a library under" Note how it says “use a library”, yet the act of running (using) a programme is not restricted by the GNU GPL? Do you know the most funny part: the GNU project itself has made available the means to prove you wrong. There is a wrapper for GnuTLS exposing the OpenSSL API to other programmes. In recent versions it may be licenced GPLv3+ but that does not matter for this example, especially since it was not always like that. To gajim, this means you get a combined (in memory) work consisting only of GNU LGPL and GPL licenced components. If said wrapper were to not work with py-openssl, again, it would be trivial and is left as an exercise to the reader to add wrappers or stubs for the missing ABIs. In fact, it would be possible to write a DLL (shared object, dylib) which does not link against either at all, but uses dlopen(3)-style APIs to load one at run time, and decides which one to use by avai- lability and/or environment variables. The mere possibility of such a thing (even for GPLv3, since these are not “plugins specifically designed for the programme”) makes your argumentation moot. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt _______________________________________________ Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
