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
Emails mala direta por email Divulgamail
Mais detalhes em: http://www.maladiretaemails.com Emails mala direta e-mails mala direta por e-mails, listas para mala direta divulgação e marketing mala direta, cadastro em site de busca cadastramento em sites de busca, envio em massa divulgação, e-mail divulgação de sites, livre de spam marketing digital por email, divulgação de sites na internet divulgar site. Emails mala direta por email Emails mala direta divulgação, listas para mala direta divulgação e marketing envio anônimo, cadastramento de sites Listas segmentadas e programa para enviar e-mail opt in, enviar emails em massa mala direta, divulgar sites opt in, listas endereços de emails, divulgação de site divulgar sites. direta emails, listas de email e-mails de são paulo, emails segmentados listas para mala direta divulgação e marketing, mala direta são paulo divulgação de sites Visite: http://www.maladiretaemails.com Emails mala direta por email Divulgamail. e-mail segmentados mala direta CADASTROS DE E-MAILS, mala direta via email para divulgação de sites, listas de e-mails programa para enviar email, software publicidade internet enviar mala direta envio de mala direta programa para enviar email. -- 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
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
Curso de Conservação e Restauro de Cerâmica Arqueológica
Curso de Conservação e Restauro de Cerâmica Arqueológica: Limpeza, Consolidação e Colagem Na realidade do Património Arqueológico, aqueles que manuseiam e cuidam dos objectos, não são tanto os Conservadores – restauradores, mas sim os Arqueológos. Conscientes da importância do primeiro contacto com os objectos cerâmicos e da responsabilidade implicada, surge a necessidade de um conhecimento mais profundo sobre o tratamento deste tipo de património. Com o objectivo de colmatar essa necessidade, surge a acção de formação em conservação e restauro de cerâmica arqueológica, específica sobre limpeza, consolidação e colagem. Os conhecimentos desenvolvidos nesta acção, permitirão que o intervir no processo de recuperação do património cerâmico, contribuindo para a sua conservação. Porto - 9 e 16 de Maio Algarve - 23 e 30 de Maio Saiba mais em www.iipatrimonio.org http://www.iipatrimonio.org/ e faça a sua pré inscrição! Telefone 21 096 7349
