Anfang der weitergeleiteten E-Mail:
Von: Yavor Doganov yavor@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.
- 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.
- 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
Thorsten Glaser wrote:
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.
TTBOMK the actual linkage against shared libraries always happens at run time.
Furthermore, gajim (GPL) uses (*not* links, this is an additional distinction!) py-openssl via its defined API.
Yes, this is the only point that is debatable. I've spent some time thinking about this. Whether you use the library directly, or via a wrapper (like for example NSImage and NSImageBitMapRep in GNUstep GUI), the result is the same: the application is actually using the facilities provided by the (C) library, just like a GNUstep image viewer uses libpng/libjpeg/libtiff/libgif under the hood (via libgnustep-gui).
which either uses the piece of crap called GnuTLS,
I'd suggest that you refrain from insults. Did I say anything (good or bad) about OpenSSL or NSS? No, I did not, because the software quality is completely irrelevant.
If you call it just the same, gajim would never know the difference.
Right.
This is a defined API, and the code is never distributed after combining.
It is a defined API, but the functionality it provides does not come out of the air. It is the functionality delivered by the OpenSSL library. In a similar fashion, PyGTK does not invent GTK for Python applications. It wraps the existing GTK+ library.
Please read http://groups.google.com/group/comp.lang.python/msg/29c7588fbecd8289 (again, if you already have) – it’s common FSF FUD
Yes, I did. Nothing new on the horizon; some people think that the FSF linking theory is fundamentally wrong, and the interpretation of their own licenses is broken beyond repair.
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.
This requires thought, I agree. The answers to the FAQs in my initial message clearly indicate that there is no fundamental difference if the language does not support what we call "classic" linking for C/C++/Objective-C.
I'll ask licensing@fsf.org for clarification.
The act of running the programme is not restricted, the GNU GPL says.
Yes. The problem is that distributors (such as major GNU distros, who generally accept the FSF interpretation and other unimportant distributors such as me by maintaining unofficial Gajim package for gNewSense) do not have license to distribute in the case where the GPL application uses GPL-incompatible libraries.
That's why such distributors don't put their head in the sand and try to solve the problem somehow; they want to be on solid legal ground -- and there's nothing wrong with that.
Like Mark McLoughlin says:
,---- | The conclusion I draw from all this is that if want to use OpenSSL | with a GPL program you should consider whether an OpenSSL exemption to | the license is viable - i.e. do all the copyright holders for the | affected code agree? Failing that, you could distribute the GPL | program using OpenSSL but you are effectively trusting that the | copyright holders for that program don't care. A much safer option is | to use either the GNU TLS or Mozilla NSS library. `----
the LGPL, if it were not for its insanely huge size, would probably be a viable option.
I don't think so. It will allow proprietary Gajim plugins, which is not a good thing.
Actually, gajim does not use OpenSSL. It is py-openssl which does.
Yes. If PyOpenSSL provided its own SSL implementation, there would be no problem. I don't think that wrapping OpenSSL through a pythonic API solves the license incompatibility problem.
This is the part where both the FSF and you are wrong.
I can't swear that I'm entirely right, and I'm not absolutely sure about FSF's statement *in this particular case*.
Interestingly, here you point out the source of this FUD.
This "FUD" was discussed for years among the free software community and lots of lawyers/legal experts, including legal departments in large software companies. It is effectively enforced by major distributors like Debian, where you maintain your mksh package and Gajim's main author maintains the gajim package.
Note how it says “use a library”, yet the act of running (using) a programme is not restricted by the GNU GPL?
When you don't distribute, yes. When you distribute, you must comply with the license the copyright holder granted you.
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.
No. The (incomplete) OpenSSL compatibility API in libgnutls-extra is written from scratch, imitating the original OpenSSL API (but *not* the implementation). If libgnutls-extra functions called libssl functions, the only way to distribute it would be GPL+OpenSSL exception (because it would link against libssl), which is pointless as OpenSSL is already available and GPL app developers already have to solve this problem.
-
Thorsten Glaser -
Yavor Doganov