[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPL, OpenSSL and Non-Free

On Wed, Dec 29, 2004 at 09:37:23PM -0600, Steve Langasek wrote:
> On Wed, Dec 29, 2004 at 04:47:06PM -0800, Don Armstrong wrote:
> > On Thu, 30 Dec 2004, Paul Hampson wrote:
> > > As I understand it, the issue is that anything in the Debian
> > > archive is considered to be distributed with Debian, and so
> > > the GPL's exception for libraries that come with the OS
> > > doesn't apply since the application also comes with the OS.
> > > (In GPL's terms, the OS comes with the application)

> > Just for completeness, here's the clause in question:

> >      However, as a special exception, the source code distributed need
> >      not include anything that is normally distributed (in either
> >      source or binary form) with the major components (compiler,
> >      kernel, and so on) of the operating system on which the
> >      executable runs, unless that component itself accompanies the
> >      executable. (GNU GPL ???3)

> > > However, non-free is not part of Debian (as per the social contract)
> > > so it would be OK to put GPL'd programs that depend on OpenSSL into
> > > non-free?

> > Unfortunatly, it is not clear that openssl is normally distributed
> > with the other components, as we do not require that people actually
> > install openssl.

> > Moreover, if we did claim that it did, the fact that they are both on
> > the same mirror (in the typical case) leads to the conclusion that
> > openssl accompanies an executable in non-free. [This becomes a "the
> > result is not distributable" instead of a "the result is not DFSG
> > free".]

> > In the end, your best bet is to either 1) get the exception from the
> > FreeRadius upstream or 2) port FreeRadius to gnutls. Working around
> > the problem using non-free really isn't going to work.

> This permission would have to come from more than just FreeRadius
> upstream, as it links in a number of other libraries including some that
> are distributed under the GPL.

That is true for the built-in SNMP support. However, for the plugins,
the major issues are rlm_eap_tls and rlm_sql_postgresql. rlm_eap_tls
links only to glibc and OpenSSL, and postgresql to glibc, OpenSSL,
postgresql's libpq3 and krb5 and related (to my utter surprise!).
(This of course means than I have to check if krb5 is GPL'd and gives
OpenSSL linking permission, or I have to work out why it links against
krb5 and if I can prevent this. But that's a different barrel of
monkeys. Interestingly, depkg-shlibdeps _didn't_ put libkrb53 in the
Depends field...)

In a discussion I came across while searching debian-legal to see if
I was having a non-new idea, it seemed to be agreed that if the main
program links to OpenSSL, but the plugins can't access it via any
kind of API, then that is not a conflict with the GPL. (Discussion from
July 2004, I think. I can find it in the archives if anyone wants)

The idea being if the plugin didn't care if OpenSSL was used or not
to perform a task it requested of the main program, then there was
no GPL conflict.

That would mean that the main program can link against libsnmp, but
only with the permission of the copyright holders of the main program
itself. (And libradius, which is technically seperate and LGPL'd, but
is as good as part of the main program for this dicussion)

To my mind, that also means that if the GPL'd plugin uses OpenSSL but
doesn't provide access to it for the rest of the program, you'd only need
the permission of the author of that plugin to link against OpenSSL.
eg. rlm_sql_postgresql which transitively links OpenSSL via libpq3.

In the case of rlm_eap_tls, I guess you'd also need the permission of the
authors of rlm_eap_ttls and rlm_eap_peap which link directly and
specifically against rlm_eap_tls (rather than dlopening it and using the
standard API as the main program does with plugins) for TLS services.
Maybe you still wouldn't need their permission, but I doubt the authors
of that code would be harder to find and/or bring around than
rlm_eap_tls itself.

If the proposition in my second paragraph is incorrect, then I need
to verify OpenSSL linkability of:
libiodbc2 (or unixodbc)
libmysqlclient10 or 12 (I believe 12 now has LGPL linkability?)
libsnmp4.2 or 5
(Where the last two are easy, since they _do_ already.)

(I'm not asking someone to go do this for me, I'm happy to do it
myself. I just took the opportunity to make this list for my later
consumption. ^_^)

Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.

Attachment: signature.asc
Description: Digital signature

Reply to: