Hi. On Sat, Apr 04, 2009 at 10:45:02PM +0800, LI Daobing wrote: > On Sat, Apr 4, 2009 at 22:25, Cristian Greco <cristian.debian@gmail.com> wrote: > > 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. > > > > yes, it is really needed, if you want to run OpenSSL and GPL code in > the same process. On Sat, Apr 04, 2009 at 04:46:32PM +0200, Francesco Poli wrote: > On Sat, 4 Apr 2009 16:25:16 +0200 Cristian Greco wrote: > > 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... Thanks you for all of your comments, then I'll ask upstream to add the exception. I believe deluge (using python-libtorrent) is affected too. Thanks, -- Cristian Greco GPG key ID: 0x0C095825
Attachment:
signature.asc
Description: Digital signature