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: 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? 2) Why doesn't lintian complain about the exception if the source code contains GPL + another different license (this is the case with qbittorrent)? Thanks, -- Cristian Greco GPG key ID: 0x0C095825
Attachment:
signature.asc
Description: Digital signature