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

Re: GPL, OpenSSL and Non-Free



On Thu, Dec 30, 2004 at 03:57:48PM +1100, Paul Hampson wrote:
> 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:
> 
> > > 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...)

The libkrb53 package, being MIT KRB5, is distributed under the MIT license.
I'm not aware of any license conflicts related to libkrb53.

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

Well, *I* don't agree with this, and neither does the FSF:
<http://www.fsf.org/licenses/gpl-faq.html#GPLPluginsInNF>.

If the main program links against GPL-incompatible libraries, we can't
distribute it in a form that also uses GPL libraries; this is true whether
you link those GPL libraries into the main program, or try to hide them
behind a plugin interface.

There may be some authors of GPL libraries who don't object to this sort of
plugin use, but as a contributor to GPL software myself, I *do* object, and
I'm increasingly unwilling to grant exceptions for OpenSSL as GNU TLS comes
of age, so I do feel strongly that Debian should not be linking GPL libs
into plugins for GPL-incompatible applications without explicit approval
from the copyright holders of the GPL works.

> If the proposition in my second paragraph is incorrect, then I need
> to verify OpenSSL linkability of:

Hmm, allow me to winnow this list for you:

> libiodbc2 (or unixodbc)

unixodbc is LGPL, no problem.

> libkrb53

MIT license, also ok.

> libcomerr2

MIT license

> libmysqlclient10 or 12 (I believe 12 now has LGPL linkability?)

libmysqlclient10 is LGPL; libmysqlclient12/14 is GPL, but with various
exceptions.  However, I'm not certain that an exception for the OpenSSL
license was included in this, and libmysqclient12 itself recently dropped
OpenSSL support.

> libldap2

The OpenLDAP license, which is BSD-ish and not a problem.  The only reason
libldap2 does not itself link to OpenSSL is because of the problems that
causes for other GPL apps that would use it.

> libpam0g

BSD license, no problem here.

> libgbdm3
> libltdl3
> libpq3
> libsnmp4.2 or 5
> (Where the last two are easy, since they _do_ already.)


Cheers,
-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: