[Gajim-devel] Licence incompatibility -- GPL and OpenSSL

[Yavor Doganov]

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 at 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*.

> >> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibilty.
> 
> 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.