Re: Debian readline/libedit breakage

Michael Banck wrote: <blockquote cite="mid:20110211135933.GO26548@nighthawk.chemicalconnection.dyndns.org"
type="cite"><prewrap="">On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote: </pre><blockquote type="cite"><pre
wrap="">Lessnarrow-minded interpretation of GPL requirements, perhaps.
 
(And yes, we have real lawyers on staff considering these issues.)   </pre></blockquote><pre wrap="">
Is their opinion public/can be made public?  This might possibly lead to
a re-evaluation of the situation by Debian. </pre></blockquote><br /> I doubt that.  This is one of those situations
wherethere is an ideological position held by the FSF and Debian that's unlikely to budge, but one that has limited
testingin court.  I believe that RedHat's lawyers have assessed the business risk here and judged it not sufficient to
worryabout.  But their opinion on that isn't going to sway anyone evaluating this primarily on free software
principles.<br/><br /> I had to trace down the history here once before while working on another project that couldn't
linkwith readline; here's a timeline with all the latest fun parts at the end:<br /><br /><a
class="moz-txt-link-freetext"
href="http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL">http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL</a>
: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.<br /><br /><a class="moz-txt-link-freetext"
href="http://www.gnu.org/licenses/gpl-2.0.html">http://www.gnu.org/licenses/gpl-2.0.html</a>: The GPLv2 includes the
followingin section 3:  "However, as a special exception, the source code distributed need not include anything that is
normallydistributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the
operatingsystem on which the executable runs, unless that component itself accompanies the executable."  This provides
somerelief to people building software on their own, but when you're the OS packager it doesn't help because you are
providingthe components and the executables.<br /><br /><a class="moz-txt-link-freetext"
href="http://lists.debian.org/debian-legal/2002/10/msg00113.html">http://lists.debian.org/debian-legal/2002/10/msg00113.html</a>
:Discussion of the exemption made for GPL libraries shipping with an OS, and an early mention of "Debian['s] current
hardlineposition on the GPL+OpenSSL licensing issue"<br /><br /><a class="moz-txt-link-freetext"
href="http://bugs.ntp.org/show_bug.cgi?id=931">http://bugs.ntp.org/show_bug.cgi?id=931</a>: 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
readlineAPI is also a derived work. This hasn't been tested in court yet, so its validity is questionable. However,
thatis their claim."<br /><br /><a class="moz-txt-link-freetext"
href="http://people.gnome.org/~markmc/openssl-and-the-gpl.html">http://people.gnome.org/~markmc/openssl-and-the-gpl.html</a>
:Why OpenSSL is particularly troublesome here.  This describes the now common "OpenSSL exemption" as a suggested
workaroundfor projects who can modify their license terms.<br />  <br /><a class="moz-txt-link-freetext"
href="http://lists.debian.org/debian-legal/2004/05/msg00595.html">http://lists.debian.org/debian-legal/2004/05/msg00595.html</a>
:Example of adding an OpenSSL exemption<br /><br /><a class="moz-txt-link-freetext"
href="http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php">http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php</a>
: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]<br/><br /><a class="moz-txt-link-freetext"
href="http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php">http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php</a>
:More PostgreSQL discussion that predicts a collision with Debian policy is coming.  Concerns about the quality fo the
GnuTLSAPI relative to the feature set provided by OpenSSL are raised too, as impediments toward switch away from
OpenSSL.<br/><br /><a class="moz-txt-link-freetext"
href="http://archives.postgresql.org/pgsql-hackers/2006-12/msg01224.php">http://archives.postgresql.org/pgsql-hackers/2006-12/msg01224.php</a>
:List of GPL applications that use libpq in Debian.<br /><br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857</a>
:Python runs into the readline+OpenSSL issue<br /><br /><a class="moz-txt-link-freetext"
href="http://redmine.ruby-lang.org/issues/show/2982">http://redmine.ruby-lang.org/issues/show/2982</a>: Ruby runs into
thereadline+OpenSSL issue<br /><br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601754">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601754</a>
:PostgreSQL runs into the readline+OpenSSL issue on Debian Lenny.  Note that this bug being open means it's possible
allthese problems in Squeeze are going to get backported to Lenny and break stable server installs all over the world
oneday in our near future.<br /><br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603599">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603599</a>
:Dupe of the bug for 9.0+Squeeze. This is the one that was "fixed" by switching to libedit.<br /><br /> Then we have
thestream of bugs cascading out of that decision:<br /><br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605313">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605313</a>
:Delete key stopped working in psql<br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109</a>
:Cannot input multibyte characters in psql<br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607907">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607907</a>
:Missing readline features<br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442</a>
:Input of non-ASCII characters broken<br /><a class="moz-txt-link-freetext"
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611918">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611918</a>
:psql segfaults in libedit<br /><br /> So where are we at?<br /><br /> -GNU libreadine is certainly never going to add
anOpenSSL exemption<br /> -If the OpenSSL project was going to switch to a reasonable license, they'd have done it
yearsago<br /> -There are many known and serious bugs/limitations in libedit relative to libreadline<br /> -Adding
GnuTLSsupport to PostgreSQL would require solving several code quality issues<br /><br /> Idealogically, I find the
worstoffendor here to be the OpenSSL license.  From a license purity perspective I'd like to see their ridiculous
requirementsbypassed altogether by doing whatever is necessary to get GnuTLS support working.  But pragmatically,
fixingthe bugs and adding features to libedit may be the easier route here.<br /><br /><pre class="moz-signature"
cols="72">--
 
Greg Smith   2ndQuadrant US    <a class="moz-txt-link-abbreviated"
href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>  Baltimore, MD
 
PostgreSQL Training, Services, and 24x7 Support  <a class="moz-txt-link-abbreviated"
href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>

</pre>