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) libkrb53 libcomerr2 libmysqlclient10 or 12 (I believe 12 now has LGPL linkability?) libldap2 libgbdm3 libltdl3 libpam0g libpq3 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) Paul.Hampson@Anu.edu.au "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