Gajim-devel January 2009

gajim-devel@gajim.org

6 participants
4 discussions

Licence incompatibility -- GPL and OpenSSL
by Yavor Doganov 02 Feb '09

02 Feb '09

[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.

3 9

Re: [Gajim-devel] Licence incompatibility -- GPL and OpenSSL
by Thorsten Glaser 27 Jan '09

27 Jan '09

> Anfang der weitergeleiteten E-Mail: > >> Von: Yavor Doganov <yavor(a)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

2 1

group windows by contacts groups
by Serge Matveenko 15 Jan '09

15 Jan '09

Hello! I've add several lines to the gajim code to allow grouping of the tabs to windows by contact groups. Here is the patch for gajim-0.11.4 for sources from Ubuntu Hardy repo. -- Serge Matveenko mailto:serge@matveenko.ru http://serge.matveenko.ru/

3 11

Detecting and caching LaTeX support
by Brendan Taylor 08 Jan '09

08 Jan '09

Why don't we detect LaTeX support at startup and cache? I don't have dvipng installed and every time I get a message with a $$foo$$ I get Error executing "dvipng -bg rgb 1.0 1.0 1.0 -T tight -D 108 /tmp/gajimtex_23.dvi -o /tmp/gajimtex_23.png": [Errno 2] No such file or directory printed to my chat window. If nobody has any objections I'll move the detection code that we've got for the features window so that it always executes and gets cached.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Gajim-devel January 2009