Hello all,
I am currently facing a licensing issue due to libruby, openssl and its
GPL-incompatibility.
As some of you already know, I am the current maintainer of
apt-listbugs [1].
I received a patch from a kind user (Michael Gold) that makes
apt-listbugs use HTTPS instead of HTTP to communicate with the Debian
BTS SOAP interface. This means that the default URL passed to the
ruby-soap4r library becomes
"https://bugs.debian.org:443/cgi-bin/soap.cgi"; instead of
"http://bugs.debian.org:80/cgi-bin/soap.cgi";. The user may anyway
modify this URL with appropriate configuration and/or command-line
options.
The patch works and (after some modifications) would be ready to be
accepted, except that it may cause a license incompatibility issue!
I realized this while working on the patch itself: I remembered that
libruby supports SSL thanks to an extension which is linked with libssl
(openssl).
Basically, what seems to happen is that ruby-soap4r loads 'net/https',
when the use of SSL is requested. And libruby loads 'openssl', when
'net/https' is loaded.
Now, the OpenSSL license is well-known to be GPL-incompatible.
On the other hand, apt-listbugs is GPL-licensed and loads a number of
GPL-licensed Ruby libraries.
As far as I understand it, this means that a version of apt-listbugs
which uses SSL would be undistributable in Debian.
This issue was explored a while ago on debian-legal and I was the one
who replied [2] with my own analysis (!).
[1] https://packages.debian.org/sid/apt-listbugs
[2] https://lists.debian.org/debian-legal/2011/05/msg00018.html
Now, why am I writing to debian-ruby?
I am seeking your help to see what can be done on the libruby front in
order to solve this issue for apt-listbugs and other Ruby applications
or libraries with similar needs.
Adding an OpenSSL linking exception to the GPL license of apt-listbugs
is not an option, since it would require to also have it added to the
other GPL-licensed libraries used by apt-listbugs.
As a consequence, I can think of the following possible strategies to
address this issue:
A) persuade the OpenSSL copyright holders to switch to a sane 3-clause
BSD license (which is GPL-compatible)
B) modify libruby to link with a GPL-compatible SSL/TLS implementation
(such as libgnutls or libnss or anything else fit for the purpose),
so that SSL/TLS is supported without loading GPL-incompatible
libraries
Strategy A would solve a longstanding issue once and for all and would
greatly benefit the whole Free Software community, but is known to be
close to impossible. It has been probably attempted countless times in
some 15 years and hasn't yet succeeded.
Would strategy B be feasible?
What do you think?
--
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
Attachment:
pgpVt4t9Yeqhi.pgp
Description: PGP signature