On Mon, 6 Mar 2017 00:48:11 +0100 Guilhem Moulin wrote: > First of, apologizes for opening duplicate #856844… I apparently > overlooked this one while browsing though the list of existing bug > reports :-/
No problem... > > On Thu, 30 Jul 2015 at 22:35:17 +0200, Francesco Poli wrote: > > Now, the bad news is that I remembered that the libruby module > > providing SSL support links with libssl. And the OpenSSL license is > > well known to be GPL-incompatible. [...] > > FYI a similar issue (dynamic linking against libssl in the context of > python-pypump) was brought up to debian-legal two years ago: > > https://lists.debian.org/debian-legal/2015/01/msg00020.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740990 > https://github.com/xray7224/PyPump/issues/101 > > “OK. It can't hurt to try - this does seem like a special case.” The > FTP masters didn't reject the GPL-3+'ed (without OpenSSL exception) > code: > > https://tracker.debian.org/media/packages/p/python-pypump/copyright-0.7-1 I am not entirely sure I would be ready to agree with the outcome of the pypump case, but, anyway, the pypump case is not completely analogous to the apt-listbugs (with the https patch) case. As far as pypump is concerned: [...] | the linking is optional, and done by the python-requests library | instead of pypump [...] (quoted from https://bugs.debian.org/740990#65 ) On the other hand, the https patch for apt-listbugs would make the program explicitly default to connecting to an https URL: hence, it would explicitly use the OpenSSL library through the Ruby standard library. > > > An older thread on debian-python mentioning the same problem: > > https://lists.debian.org/debian-python/2011/03/msg00082.html > In my case I am talking about a GPLv3+ package that exists in Debian -- > kupfer > > Where do I draw the line for using/linking against ssl? > > a) Using Python2.6 > b) Unintentionally introducing _ssl or ssl into the imported modules > (import any of urllib, httplib, socket etc!) > c) Unintentionally using ssl (use urllib.urlopen on URL provided by > user -- if it's https we are using openssl) > d) Intentionally using ssl (import ssl and use > httplib.HTTPSConnection and verify certificates) > > Kupfer is today at (c) in the debian archive. It exists in > development version at (d). > > (AFAICT apt-listbugs would be at (b).) [...] I would rather say that the https patch would make apt-listbugs land in between (c) and (d): intentionally use ssl (connecting by default to an https URL). Anyway, please note that I am myself a debian-legal regular and I myself have analyzed the issue in the past: https://lists.debian.org/debian-legal/2011/05/msg00018.html My conclusion is that a Ruby program cannot load both openssl and GPL-licensed libraries, at least if we assume that the FSF's interpretation is correct (this assumption has to be made in order to be on the safe side). Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpzo3AwqHtQD.pgp
Description: PGP signature
