Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 04, 2009 at 12:00:56PM +0800, LI Daobing wrote: On Sat, Apr 4, 2009 at 05:06, Cristian Greco cristian.deb...@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 signature.asc Description: Digital signature
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 4, 2009 at 17:43, Cristian Greco cristian.deb...@gmail.com 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.deb...@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? 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. 2) Why doesn't lintian complain about the exception if the source code contains GPL + another different license (this is the case with qbittorrent)? I don't know. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.deb...@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, cu Adrian -- 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 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
Cristian Greco cristian.deb...@gmail.com writes: 2) Why doesn't lintian complain about the exception if the source code contains GPL + another different license (this is the case with qbittorrent)? Until we have an agreed machine-parseable ‘debian/copyright’ format, and until that file is correctly populated with the actual copyright information, Lintian will be unable to reliably detect such problems mechanically. -- \ “Better not take a dog on the space shuttle, because if he | `\ sticks his head out when you're coming home his face might burn | _o__)up.” —Jack Handey | Ben Finney pgpucSlUEFgl4.pgp Description: PGP signature
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
Hi. On Sat, Apr 04, 2009 at 01:06:49PM +0300, Adrian Bunk wrote: On Sat, Apr 04, 2009 at 11:43:53AM +0200, Cristian Greco wrote: 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. On Sat, Apr 04, 2009 at 10:09:01PM +1100, Ben Finney wrote: Cristian Greco cristian.deb...@gmail.com writes: 2) Why doesn't lintian complain about the exception if the source code contains GPL + another different license (this is the case with qbittorrent)? Until we have an agreed machine-parseable ‘debian/copyright’ format, and until that file is correctly populated with the actual copyright information, Lintian will be unable to reliably detect such problems mechanically. I see your point here, and I already know that lintian is just a support tool. Agreed on that, but this was a secondary remark, I'm still concerned about my first question: On Sat, Apr 04, 2009 at 05:47:15PM +0800, LI Daobing wrote: On Sat, Apr 4, 2009 at 17:43, Cristian Greco cristian.deb...@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. Thanks, -- Cristian Greco GPG key ID: 0x0C095825 signature.asc Description: Digital signature
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 4, 2009 at 22:25, Cristian Greco cristian.deb...@gmail.com wrote: On Sat, Apr 4, 2009 at 17:43, Cristian Greco cristian.deb...@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. yes, it is really needed, if you want to run OpenSSL and GPL code in the same process. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.deb...@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 pgp1ygYU62lV9.pgp Description: PGP signature
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
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.deb...@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 signature.asc Description: Digital signature
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
[ CCing debian-legal for comments ] On Fri, Apr 03, 2009 at 10:37:49PM +0300, Adrian Bunk wrote: On Fri, Apr 03, 2009 at 01:35:30AM +0200, Cristian Greco wrote: On Thu, Apr 02, 2009 at 08:27:19PM +0300, Adrian Bunk wrote: $ ldd /usr/bin/qbittorrent | grep ssl libssl.so.0.9.8 = /usr/lib/libssl.so.0.9.8 (0x7fd73085a000) $ /usr/share/doc/qbittorrent/copyright states that much of the code is GPL-licenced. I didn't find any statement that all copyright holders of GPL'ed code in tracker have given extra permission to link with OpenSSL. See also question 28 at http://people.debian.org/~bap/dfsg-faq Hi Adrian, first of all thanks for your report. qbittorrent does not use directly the OpenSSL library, as you can see looking at the source code and the symbols table of the (unstripped) executable file. It is linked against two libraries using libssl (libtorrent-rasterbar and libcurl), and there are some symbols from boost::asio related to 'ssl'. And by the way, even if the majority of the C++ code in qbittorrent is released under the GPL, the debian/copyright file includes a mix of files with different licenses (LGPL, BSD, MIT), so that lintian does not complain about linking against libssl. Any suggestion? 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. Thanks, -- Cristian Greco GPG key ID: 0x0C095825 signature.asc Description: Digital signature
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 4, 2009 at 05:06, Cristian Greco cristian.deb...@gmail.com wrote: [ CCing debian-legal for comments ] On Fri, Apr 03, 2009 at 10:37:49PM +0300, Adrian Bunk wrote: On Fri, Apr 03, 2009 at 01:35:30AM +0200, Cristian Greco wrote: On Thu, Apr 02, 2009 at 08:27:19PM +0300, Adrian Bunk wrote: $ ldd /usr/bin/qbittorrent | grep ssl libssl.so.0.9.8 = /usr/lib/libssl.so.0.9.8 (0x7fd73085a000) $ /usr/share/doc/qbittorrent/copyright states that much of the code is GPL-licenced. I didn't find any statement that all copyright holders of GPL'ed code in tracker have given extra permission to link with OpenSSL. See also question 28 at http://people.debian.org/~bap/dfsg-faq Hi Adrian, first of all thanks for your report. qbittorrent does not use directly the OpenSSL library, as you can see looking at the source code and the symbols table of the (unstripped) executable file. It is linked against two libraries using libssl (libtorrent-rasterbar and libcurl), and there are some symbols from boost::asio related to 'ssl'. And by the way, even if the majority of the C++ code in qbittorrent is released under the GPL, the debian/copyright file includes a mix of files with different licenses (LGPL, BSD, MIT), so that lintian does not complain about linking against libssl. Any suggestion? 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. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
