Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
Am 27.01.2009 um 14:29 schrieb Yavor Doganov: [I submitted this as a Trac ticket, but got Submission rejected due to potential spam or similar.] I believe Gajim is currently not distributable, as even an optional dependency on python-openssl requires the license of Gajim to have the (in)famous OpenSSL exception. Although PyOpenSSL is under LGPL, it is merely a wrapper and the interpreted program (Gajim) is effectively linked with the library (libssl) through the python extension (PyOpenSSL). http://www.gnu.org/licenses/license-list.html#OpenSSL http://www.gnome.org/~markmc/openssl-and-the-gpl.html http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat (The questions from the GPL FAQ are not about this specific problem, but the explanations give answers to that as well.) Probably an easier alternative to relicensing would be to use python-gnutls, the GnuTLS bindings. We do not ship with py-OpenSSL. We do not include any of the code from py-OpenSSL. We do not ship with OpenSSL. We do not include any code from OpenSSL. I don't see where we are violating any license. OpenSSL is loaded at runtime, but GPL doesn't cover which code is allowed to be run in memory, it only covers distribution rights. So GPL doesn't forbid to mix GPL and non-GPL code in RAM, as long as you don't distribute the result (e.g. a core dump). Therefore I fail to see the problem. d8289 Additionally, GPL explicitely allows mere aggregation, so even our Windows binaries are no See also: http://groups.google.com/group/comp.lang.python/msg/ 29c7588fbecproblem, as OpenSSL is a separate DLL which is loaded at runtime. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht ___ Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
Am 27.01.2009 um 14:48 schrieb Jonathan Schleifer: d8289 Additionally, GPL explicitely allows mere aggregation, so even our Windows binaries are no See also: http://groups.google.com/group/comp.lang.python/msg/ 29c7588fbecproblem, as OpenSSL is a separate DLL which is loaded at runtime. Sorry, I broke the link. Here's the fixed one: http://groups.google.com/group/comp.lang.python/msg/29c7588fbecd8289. The See also: and the link are in the middle of the sentence, sorry for pasting it wrong :/. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht ___ Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
On Tue, Jan 27, 2009 at 02:48:45PM +0100, Jonathan Schleifer wrote: We do not ship with py-OpenSSL. We do not include any of the code from py-OpenSSL. I never said you did. I don't see where we are violating any license. You are violating your own license, the GPL. OpenSSL is loaded at runtime, but GPL doesn't cover which code is allowed to be run in memory, Please. All libraries you link against should be under a GPL-compatible license. The fact that you link with libssl via a python wrapper does not alleviate that. Additionally, GPL explicitely allows mere aggregation, so even our Windows binaries are no This is not about mere aggregation at all. http://groups.google.com/group/comp.lang.python/msg/29c7588fbecproblem, as OpenSSL is a separate DLL which is loaded at runtime. The link doesn't work for me, but the situation on POSIX systems is the same -- when you do import OpenSSL.SSL and then use OpenSSL facilities, they don't come from PyOpenSSL's independent SSL implementation (as there isn't any), they come from libssl. So the .so is loaded at runtime as well. ___ Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
Am 27.01.2009 um 14:56 schrieb Yavor Doganov: On Tue, Jan 27, 2009 at 02:48:45PM +0100, Jonathan Schleifer wrote: We do not ship with py-OpenSSL. We do not include any of the code from py-OpenSSL. I never said you did. Then I fail to see the problem. I don't see where we are violating any license. You are violating your own license, the GPL. I am where? Where do we distribute something that includes non-GPL code? Neither our source, nor our binaries include non-GPL code. OpenSSL is loaded at runtime, but GPL doesn't cover which code is allowed to be run in memory, Please. All libraries you link against should be under a GPL- compatible license. The fact that you link with libssl via a python wrapper does not alleviate that. We only combine our code with OpenSSL's code in memory. This is perfectly legal, as the GPL only covers _DISTRIBUTION_. It's a license about _DISTRIBUTION_, _NOT_ about usage. That's why it's a _DISTRIBUTION_ license and not an EULA. Additionally, GPL explicitely allows mere aggregation, so even our Windows binaries are no This is not about mere aggregation at all. It is, because all we do with the Windows binaries is have the OpenSSL DLLs included, which are loaded at runtime. So we do _NOT_ distribute any combined work. It is combined in memory. This is not covered by the GPL at all. Because GPL allows mere aggregation, it is allowed to include non-GPL'd stuff in the distribution set. http://groups.google.com/group/comp.lang.python/msg/29c7588fbecproblem , as OpenSSL is a separate DLL which is loaded at runtime. The link doesn't work for me Yup, I broke it on pasting, see my second mail. but the situation on POSIX systems is the same -- when you do import OpenSSL.SSL and then use OpenSSL facilities, they don't come from PyOpenSSL's independent SSL implementation (as there isn't any), they come from libssl. So the .so is loaded at runtime as well. Right, it is loaded at runtime. So the combined work is created at _RUNTIME_, and _NOT_ at distribution. This isn't covered by the GPL at all. It doesn't say a single word that it's forbidden to combine GPL'd and non-GPL'd code in RAM. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht ___ Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
Yavor Doganov wrote: On Tue, Jan 27, 2009 at 02:48:45PM +0100, Jonathan Schleifer wrote: OpenSSL is loaded at runtime, but GPL doesn't cover which code is allowed to be run in memory, Please. All libraries you link against should be under a GPL-compatible license. The fact that you link with libssl via a python wrapper does not alleviate that. We are not linked against anything as in a C program, there is no mention to OpenSSL.so in our compiled binaries. We don't use openssl.so, python-openssl do. And I don't see why Gajim debian package cannot depend on another package in debian which is not in non-free. If openssl and python-openssl are in debian it means they have an opensource license, an I wrong? -- Yann ___ Gajim-devel mailing list Gajim-devel@gajim.org http://lists.gajim.org/cgi-bin/listinfo/gajim-devel
Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
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
