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

Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation

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


 New location for my website! Update your bookmarks!
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4

Attachment: pgpIsEkFno3ls.pgp
Description: PGP signature

Reply to: