Re: openssl vs. GPL question
(copied to debian-legal, where the discussion belongs; next person
please cut debian-mentors)
On 6/4/05, Dafydd Harries <firstname.lastname@example.org> wrote:
> I have a package Alexandria, written in Ruby, which will depend on a
> new library in the next version. This library, ruby-zoom, is an LGPL Ruby
> binding of libyaz. libyaz links to OpenSSL and is, as far as I can tell,
> under a 2-clause BSD licence. Everything fine so far.
> But it seems to me that it will be impossible for Alexandria, which is
> under the GPL, to use ruby-zoom legally as, by doing so, it will be
> linking against OpenSSL, which is under a GPL-incompatible licence. Am I
> right in thinking so?
It is Debian's historical practice, and the FSF's stance, not to
permit this kind of dependency (direct or indirect). I believe
strongly, and have adduced plenty of case law to demonstrate, that the
FSF's GPL FAQ is in error on this point. I would not say, however,
that my opinion represents a debian-legal consensus. See recent
debian-legal threads about Quagga, which is in a similar position.
> My understanding of this issue is based on reading this thread:
> If there is indeed a licence problem here, I can see two main solutions:
> - Try to get libyaz in Debian to link against GnuTLS instead of
> - Get the maintainer of Alexandria to make an exception for linking
> against OpenSSL.
The latter is probably a better choice (at least in the short term),
since the OpenSSL shim for GNU TLS was added to the GPL (not LGPL)
libgnutls-extra. (It's possible that it has since been moved into the
LGPL portion, but I don't think so.) While I don't believe in the
FSF's theories about linking causing "GPL violation" (especially in
the indirect scenario), it's the Debian way to request a clarification
> I notice that the Tellico package, which is GPL, already links against
> libyaz. Is this a licence violation?
No; but there again, it would probably be best to check with upstream
about whether they would mind adding an explicit "OpenSSL exemption".