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
signature.asc
Description: Digital signature
