On Sat, 4 Apr 2009 16:25:16 +0200 Cristian Greco wrote: > On Sat, Apr 04, 2009 at 05:47:15PM +0800, LI Daobing wrote: > > On Sat, Apr 4, 2009 at 17:43, Cristian Greco <cristian.debian@gmail.com> wrote: > > > 1) What to do in this case? Should all clients based on libtorrent-rasterbar > > > and licensed under the GPL add an exception even if they don't directly use the > > > OpenSSL library? > > > > > libtorrent-rasterbar should provide two packages, one is > > libtorrent-rasterbar-openssl (with openssl enabled), another is > > libtorrent-rasterbar (with openssl disabled), just like libcurl3 and > > libcurl3-gnutls. > > This is not what I was looking for (and this solution wouldn't be useful, as > all existing clients actually require encryption to be enabled). My question is > if it is really needed for all clients licensed under the GPL to add an > exception even if they don't directly use the OpenSSL library. > This could be a problem, eventually. Sorry, but I am not following you here. If a GPL'ed client actually requires encryption to be enabled in libtorrent-rasterbar, then how can you claim that this client does *not* use OpenSSL (which is the library that provides encryption capabilities to libtorrent-rasterbar)? According to the FSF linking legal theory (which we usually assume valid, even though still untested in court, in order to be on the safe side), adding one or two or n levels of indirectness makes no difference from a legal point of view... Disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgprWv9ehBjm7.pgp
Description: PGP signature