[Gajim-devel] Licence incompatibility -- GPL and OpenSSL
tg at mirbsd.de
Tue Jan 27 16:32:43 CET 2009
> Anfang der weitergeleiteten E-Mail:
>> Von: Yavor Doganov <yavor at 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
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
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
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
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
>> See for example
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.
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
More information about the Gajim-devel