[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.
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
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
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.
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
On Tue, Jan 27, 2009 at 03:08:57PM +0100, Jonathan Schleifer wrote:
I never said you did.
Then I fail to see the problem.
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".
We only combine our code with OpenSSL's code in memory.
That is precisely the problem. You do that and the combination is impossible, which is why wget, gnubiff, exim and tons of other GPL'ed packages have this exception.
See also http://en.wikipedia.org/wiki/Openssl#Licensing -- this is widely known problem. That's one of the reasons GnuTLS exists.
This is perfectly legal, as the GPL only covers _DISTRIBUTION_.
Please reread the license. Distributors are not allowed to distribute Gajim (at least in binary form, for sure), as it is not complying to its own license. Several distros care about this (like Debian and Fedora), others assume OpenSSL is a "system library", and others simply ignore the problem like most licensing issues.
Only a very small portion of the bugs reported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443451 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497837 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367024 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358246 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508292
(How such bugs are resolved: 1) the package is relicensed upstream to GPL+OpenSSL exception; 2) the package migrates to GnuTLS or NSS; 3) the openssl support is removed if 1) and 2) are impossible.)
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.
It is definitely covered by the GPL, as the work you distribute "as a whole" should be under the GPL (which in practical terms means that all dynamically linked libraries must be licensed under a GPL-compatible license).
See for example http://www.gnu.org/licenses/gpl-faq.html#AllCompatibilty.
Note the two distinguished usages "I want to copy code under" and "I want to use a library under" and read their explanations above the table. You are basically arguing that to comply with the GPL, you only must make sure to include GPL-compatible code in the tarball. That's only one of the things you have to do.
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 Leboulanger wrote:
We are not linked against anything as in a C program,
Correct, you are in fact linking against C libraries (for the Gajim C modules), but not in this case. The GPL is not exclusively for C programs and is not void for interpreted programs. The mechanism via which you use a certain facility provided by a library is important -- for example, if PyOpenSSL was not calling OpenSSL functions but simply invoking external `openssl ...' processes there would be no problem.
But I feel I have to ellaborate, as based on the public and private messages I received there seems to be a gross misunderstandig.
What my initial message was about: I believe that by using python-openssl you don't explicitly grant permission to every distributor to distribute Gajim (modified or not). It is not a question about Gajim being non-free (nonsense, since both Gajim and all of its possible dependencies are free) or the FSF concerned about this case (again nonsense, the FSF has no control whatsoever under Gajim).
It is about violating the license you have chosen, because you can't lawfully distribute something under two contradicting licenses. Well, theoretically you can distribute sources, as the Gajim Team is a copyright holder, but no one else can. Here come into play the distros and miniscule miniature people like me, who provide unofficial (binary and source) packages.
It is a matter of judgement: to ignore the isssue until some trouble happens or to be safe. It is a matter of doing the right thing, so everyone is safe and assumes the act of distribution is explicitly allowed by the copyright holders of the program.
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?
In a (hypothetical) world where all free software licenses are compatible, you can. This world does not exist and is unlikely to become reality any time soon. Every package (GPL'ed or not) should take this into account. There is a list of GPL-incompatible licenses at http://gnu.org/licenses/license-list.html but it is far from complete. You could also explore the minimal portion of bugs I gave referrences to. Packages with incompatible licenses can co-exist in a system like Debian, when they have no relationship.
As licensing@fsf.org replied (I leave to Yann to propagate their response, although I can do it too, if it is a problem), I need to know (as a distributor) what your decision is. Will you poll the copyright holders for relicensing with the OpenSSL exception? Will you switch to python-gnutls? Or...?
Yavor Doganov wrote:
As licensing@fsf.org replied (I leave to Yann to propagate their response, although I can do it too, if it is a problem), I need to know (as a distributor) what your decision is. Will you poll the copyright holders for relicensing with the OpenSSL exception? Will you switch to python-gnutls? Or...?
The only reply I got from fsf is an unofficial answer from a non-lawyer. I can forward it, but I don't know which value it has.
Could you explain me why pyopenssl is GPL?
We don't know yet what we'll do as we don't have all answers.
At Fri, 30 Jan 2009 07:24:52 +0100, Yann Leboulanger wrote:
The only reply I got from fsf is an unofficial answer from a non-lawyer.
That's the only reply you'll get unless you hire a lawyer. "This is not a legal advice" is a standard disclaimer given even by lawyers, see http://en.wikipedia.org/wiki/TINLA.
Could you explain me why pyopenssl is GPL?
It is LGPL AFAIK.
-
Jonathan Schleifer -
Yann Leboulanger -
Yavor Doganov