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/W... 
: 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/msg0... : 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/msg0... : 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/msg0... : 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us