Re: Debian readline/libedit breakage - Mailing list pgsql-hackers
From | Greg Smith |
---|---|
Subject | Re: Debian readline/libedit breakage |
Date | |
Msg-id | 4D557715.4060509@2ndquadrant.com Whole thread Raw |
In response to | Re: Debian readline/libedit breakage (Michael Banck <mbanck@debian.org>) |
Responses |
Re: Debian readline/libedit breakage
Re: Debian readline/libedit breakage |
List | pgsql-hackers |
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>
pgsql-hackers by date: