Re: Debian readline/libedit breakage

Michael Banck wrote:
> On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote:
>
>> Less narrow-minded interpretation of GPL requirements, perhaps.
>> (And yes, we have real lawyers on staff considering these issues.)
>>
>
> Is their opinion public/can be made public? This might possibly lead to
> a re-evaluation of the situation by Debian.
>

I doubt that. This is one of those situations where there is an
ideological position held by the FSF and Debian that's unlikely to
budge, but one that has limited testing in court. I believe that
RedHat's lawyers have assessed the business risk here and judged it not
sufficient to worry about. But their opinion on that isn't going to
sway anyone evaluating this primarily on free software principles.

I had to trace down the history here once before while working on
another project that couldn't link with readline; here's a timeline with
all the latest fun parts at the end:

http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL
: Early discussion with RMS about why linking with readline requires
code using it be GPL, and why "the user did the linking" and "I wrapped
it" aren't escape routes.

http://www.gnu.org/licenses/gpl-2.0.html : The GPLv2 includes the
following in section 3: "However, as a special exception, the source
code distributed need not include anything that is normally distributed
(in either source or binary form) with the major components (compiler,
kernel, and so on) of the operating system on which the executable runs,
unless that component itself accompanies the executable." This provides
some relief to people building software on their own, but when you're
the OS packager it doesn't help because you are providing the components
and the executables.

http://lists.debian.org/debian-legal/2002/10/msg00113.html : Discussion
of the exemption made for GPL libraries shipping with an OS, and an
early mention of "Debian['s] current hardline position on the
GPL+OpenSSL licensing issue"

http://bugs.ntp.org/show_bug.cgi?id=931 : ntp runs into readline
concerns. Pull quote: "What is less clear is the claim that the FSF
makes that any program written to even *use* the readline API is also a
derived work. This hasn't been tested in court yet, so its validity is
questionable. However, that is their claim."

http://people.gnome.org/~markmc/openssl-and-the-gpl.html : Why OpenSSL
is particularly troublesome here. This describes the now common
"OpenSSL exemption" as a suggested workaround for projects who can
modify their license terms.

http://lists.debian.org/debian-legal/2004/05/msg00595.html : Example of
adding an OpenSSL exemption

http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php : A
patch adding GnuTLS support is submitted to PostgreSQL. It's rejected
mainly because the code is so large/obtrusive. TODO item "Consider
GnuTLS if OpenSSL license becomes a problem" added. [Hint: it's now
become a problem]

http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php : More
PostgreSQL discussion that predicts a collision with Debian policy is
coming. Concerns about the quality fo the GnuTLS API relative to the
feature set provided by OpenSSL are raised too, as impediments toward
switch away from OpenSSL.

http://archives.postgresql.org/pgsql-hackers/2006-12/msg01224.php : List
of GPL applications that use libpq in Debian.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857 : Python runs
into the readline+OpenSSL issue

http://redmine.ruby-lang.org/issues/show/2982 : Ruby runs into the
readline+OpenSSL issue

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601754 : PostgreSQL
runs into the readline+OpenSSL issue on Debian Lenny. Note that this
bug being open means it's possible all these problems in Squeeze are
going to get backported to Lenny and break stable server installs all
over the world one day in our near future.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603599 : Dupe of the
bug for 9.0+Squeeze. This is the one that was "fixed" by switching to
libedit.

Then we have the stream of bugs cascading out of that decision:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605313 : Delete key
stopped working in psql
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 : Cannot input
multibyte characters in psql
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607907 : Missing
readline features
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442 : Input of
non-ASCII characters broken
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611918 : psql segfaults
in libedit

So where are we at?

-GNU libreadine is certainly never going to add an OpenSSL exemption
-If the OpenSSL project was going to switch to a reasonable license,
they'd have done it years ago
-There are many known and serious bugs/limitations in libedit relative
to libreadline
-Adding GnuTLS support to PostgreSQL would require solving several code
quality issues

Idealogically, I find the worst offendor here to be the OpenSSL
license. From a license purity perspective I'd like to see their
ridiculous requirements bypassed altogether by doing whatever is
necessary to get GnuTLS support working. But pragmatically, fixing the
bugs and adding features to libedit may be the easier route here.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us