[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

[ lintian maintainer added to Cc ]

On Sat, Apr 04, 2009 at 11:43:53AM +0200, Cristian Greco wrote:
> On Sat, Apr 04, 2009 at 12:00:56PM +0800, LI Daobing wrote:
> > On Sat, Apr 4, 2009 at 05:06, Cristian Greco <cristian.debian@gmail.com> wrote:
> > > [ CCing debian-legal for comments ]
> > >
> > > On Fri, Apr 03, 2009 at 10:37:49PM +0300, Adrian Bunk wrote:
> > >> The libcurl case might be easy to resolve, but I don't know anything
> > >> about the libtorrent-rasterbar.
> > >>
> > >> It might be required that you get all copyright holders to agree on a
> > >> licence exception.
> > >
> > > The point is that qbittorrent doesn't directly link against libssl and the
> > > source code doesn't really use that library. Is it really necessary to add the
> > > exception?
> > >
> > > I'm not sure if the executable linking is caused by libtorrent-rasterbar (BSD
> > > code linked against libssl) or some other required libraries/headers. In the
> > > former case, if linking is caused by the torrent library, all of its clients
> > > should add such exception.
> > >
> > > My thought is that qbittorrent shouldn't be affected by this problem because it
> > > doesn't really link against libssl. And BTW, the source code includes licenses
> > > such as LGPL, BSD and MIT, so it shouldn't need the exception anyway.
> > >
> > I think it need an exception.
> > 
> > GPL licensed code and OpenSSL licensed code should not run in the same process.
> I can confirm that linking against libssl is caused by libtorrent-rasterbar,
> which is compiled with encryption support and causes inclusion of some OpenSSL
> headers.
> I'm wondering:
> 2) Why doesn't lintian complain about the exception if the source code contains
> GPL + another different license (this is the case with qbittorrent)?

First of all, please try to understand the differences between the 
following completely different cases:
- program with different licences, that effectively mean the whole 
  program is licenced under one specific licence (e.g. combining BSD and 
  GPL licenced code results in the program being GPL licenced)
- package contains different programs under different licences
- dual-licenced code

Why lintian doesn't find these cases:
- Catching some of the simpler cases is not too hard.
  Handling all details of existing open source licencing would be
  very hard.
- As far as I understand the code in lintian, it only parses the 
  dependency information of the package. That would have worked
  for indirect dependencies 10 years ago when dependencies were created 
  using ldd, but indirect dependencies cannot be found this way today.

But lintian is anyway just a tool to find some errors, it can never be 
used to prove that a package is correct.

> Thanks,



       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply to: