Thread: Debian readline/libedit breakage
Hello, Per: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 It seems we may have a problem to consider. As far as I know, we are the only major platform that supports libedit but our default is readline. Unfortunately readline is not compatible with OpenSSL (apparently?) licensing. This seems that it may be a problem for us considering the pre-package builds we do. What does everyone think? Should we work on getting libedit up to snuff? JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, Feb 10, 2011 at 2:34 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > Hello, > > Per: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 > > It seems we may have a problem to consider. As far as I know, we are the > only major platform that supports libedit but our default is readline. > Unfortunately readline is not compatible with OpenSSL (apparently?) > licensing. > > This seems that it may be a problem for us considering the pre-package > builds we do. > > What does everyone think? Should we work on getting libedit up to snuff? I have to admit, this change in debian packaging -- which I have noticed, and not a little -- makes my hands angry. I considered looking into the problem, but were I doing it, I would have considered teaching psql to support NSS or GnuTLS as totally viable alternatives to this problem, as to keep readline. -- fdr
On 02/10/2011 05:34 PM, Joshua D. Drake wrote: > Hello, > > Per: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 > > It seems we may have a problem to consider. As far as I know, we are the > only major platform that supports libedit but our default is readline. > Unfortunately readline is not compatible with OpenSSL (apparently?) > licensing. > > This seems that it may be a problem for us considering the pre-package > builds we do. > > What does everyone think? Should we work on getting libedit up to snuff? I'll be happy if you do, but why haven't I haven't noticed, say, RedHat taking this line? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I'll be happy if you do, but why haven't I haven't noticed, say, RedHat
> taking this line?
Less narrow-minded interpretation of GPL requirements, perhaps.
(And yes, we have real lawyers on staff considering these issues.)
libedit is a long way from being ready to replace readline,
much as one could wish it otherwise. If Debian want to shoot
themselves in the foot like that, we can't stop them, but neither
should we be devoting our project resources to fixing libedit.
(I have seen some noise recently on the Fedora lists about putting
work into libedit, so maybe something good will come of that.
I'm just not ready to define it as my/our problem.)
regards, tom lane
Excerpts from Joshua D. Drake's message of jue feb 10 19:34:31 -0300 2011: > Hello, > > Per: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 O, the joy of having people mess up with legal stuff that nobody cares about creating endless work for everyone. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
* Daniel Farina (drfarina@acm.org) wrote:
> I have to admit, this change in debian packaging -- which I have
> noticed, and not a little -- makes my hands angry. I considered
> looking into the problem, but were I doing it, I would have considered
> teaching psql to support NSS or GnuTLS as totally viable alternatives
> to this problem, as to keep readline.
Supporting GnuTLS would be really nice.. That's how we addressed the
same issue w/ OpenLDAP (I was involved in that as a Debian
co-maintainer). GnuTLS has limitations too, but in the end, I find
those more palatable (and the GnuTLS maintainer is certainly willing to
work on improving it) than dropping readline. :/
THanks,
Stephen
On 02/10/2011 06:36 PM, Stephen Frost wrote: > * Daniel Farina (drfarina@acm.org) wrote: >> I have to admit, this change in debian packaging -- which I have >> noticed, and not a little -- makes my hands angry. I considered >> looking into the problem, but were I doing it, I would have considered >> teaching psql to support NSS or GnuTLS as totally viable alternatives >> to this problem, as to keep readline. > Supporting GnuTLS would be really nice.. That's how we addressed the > same issue w/ OpenLDAP (I was involved in that as a Debian > co-maintainer). GnuTLS has limitations too, but in the end, I find > those more palatable (and the GnuTLS maintainer is certainly willing to > work on improving it) than dropping readline. :/ > Strikes me as a lot of work to buy nothing much. cheers andrew
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. > If Debian want to shoot themselves in the foot like that, we can't > stop them BTW, that change has been merged into Ubuntu and will be (as of now) in the next Ubuntu release. Michael
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>
* Greg Smith (greg@2ndquadrant.com) wrote:
> -GNU libreadine is certainly never going to add an OpenSSL exemption
I really wish they would, that's just them being obnoxious- it's already
LGPL, after all..
> -If the OpenSSL project was going to switch to a reasonable license,
> they'd have done it years ago
aiui, the problem here is actually a former OpenSSL hacker who has no
interest (and, in fact, a positive interest against) in changing the
OpenSSL licensing. Most of the current OpenSSL hackers don't have an
issue with the change (again, aiui).
> -There are many known and serious bugs/limitations in libedit
> relative to libreadline
Yes, which makes it suck. :(
> -Adding GnuTLS support to PostgreSQL would require solving several
> code quality issues
I'm curious about this, but I don't know that I've got time to dive into
it and solve it. :/
> 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.
That suprises me.. There are a ton of tools which work with GnuTLS
today, and hearing that it's got serious issues isn't good. :/
Thanks,
Stephen
On Fri, Feb 11, 2011 at 19:13, Stephen Frost <sfrost@snowman.net> wrote: > * Greg Smith (greg@2ndquadrant.com) wrote: >> -Adding GnuTLS support to PostgreSQL would require solving several >> code quality issues > > I'm curious about this, but I don't know that I've got time to dive into > it and solve it. :/ Yeah, I'm curious about that one as well. A lot has happened since this was last investigated, I believe. We may also have a problem in that libpq exposes OpenSSL structs, though. We actually return it as a void *, to make it possible to change, but there's no API in libpq to tell you what it is... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
* Magnus Hagander (magnus@hagander.net) wrote: > We may also have a problem in that libpq exposes OpenSSL structs, > though. We actually return it as a void *, to make it possible to > change, but there's no API in libpq to tell you what it is... Ugh, yeah, that probably wasn't the best decision in the world.. :( Stephen
On Fri, 2011-02-11 at 14:59 +0100, 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 certainly hope so. Although, what I question is... Did Debian seek legal advice? Debian does have a corporation of which I am a director for. Software in the Public Interest. I don't recall a legal request coming through from the DPL? > > > If Debian want to shoot themselves in the foot like that, we can't > > stop them > > BTW, that change has been merged into Ubuntu and will be (as of now) in > the next Ubuntu release. Yeah see, that is something that raises my red-alert bells. As popular as Debian is, the "user" population is squarely in Ubuntu world and that has some serious public implications as a whole. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Stephen Frost wrote:<br /><blockquote cite="mid:20110211181327.GS4116@tamriel.snowman.net" type="cite"><blockquote type="cite"><prewrap="">-Adding GnuTLS support to PostgreSQL would require solving several code quality issues </pre></blockquote><pre wrap=""> I'm curious about this, but I don't know that I've got time to dive into it and solve it. :/ </pre></blockquote><br /> Note that the past discussion was on the difficulty of matching the existingOpenSSL API using GnuTLS, which is apparently difficult to do. I wasn't trying to suggest there were issues specificiallywith GnuTLS's code quality. It's more that the APIs are just different enough that it's not trivial to do aswap--which is surprising given how many people have seemingly needed to do exactly this conversion. You'd think there'dbe a simple "OpenSSL-like" interface available for GnuTLS by now or something.<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> "PostgreSQL 9.0 High Performance": <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/books">http://www.2ndQuadrant.com/books</a> </pre>
On Fri, Feb 11, 2011 at 20:09, Greg Smith <greg@2ndquadrant.com> wrote: > Stephen Frost wrote: > > -Adding GnuTLS support to PostgreSQL would require solving several > code quality issues > > > I'm curious about this, but I don't know that I've got time to dive into > it and solve it. :/ > > > Note that the past discussion was on the difficulty of matching the existing > OpenSSL API using GnuTLS, which is apparently difficult to do. I wasn't > trying to suggest there were issues specificially with GnuTLS's code > quality. It's more that the APIs are just different enough that it's not > trivial to do a swap--which is surprising given how many people have > seemingly needed to do exactly this conversion. You'd think there'd be a > simple "OpenSSL-like" interface available for GnuTLS by now or something. There is one, but it's not complete - it will work for simple users, though, AFAIK. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, Feb 11, 2011 at 2:09 PM, Greg Smith <greg@2ndquadrant.com> wrote: > Note that the past discussion was on the difficulty of matching the existing > OpenSSL API using GnuTLS, which is apparently difficult to do. I believe that the OpenSSL API is "make some function calls, and if it works, then you're using it right; if not, copy some source code from the examples and use the undocumented APIs that appear there to fix whatever problem you're having." At least, that's been my approach. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Greg Smith's message of vie feb 11 14:51:17 -0300 2011: > 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 Why do we have to involve the whole of PostgreSQL? Since the only piece that links to libreadline is psql, perhaps we could fix this by having only psql optionally use GnuTLS. (I don't know if you can make an OpenSSL server talk to a GnuTLS client -- are these things supposed to be interoperable?) -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Fri, Feb 11, 2011 at 11:49 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Why do we have to involve the whole of PostgreSQL? Since the only piece > that links to libreadline is psql, perhaps we could fix this by having > only psql optionally use GnuTLS. (I don't know if you can make an > OpenSSL server talk to a GnuTLS client -- are these things supposed to > be interoperable?) I agree with this: barring shockingly convenient engineering details, my plan was to just evaluate the option of doing this for the psql client. -- fdr
On Fri, 2011-02-11 at 14:59 -0500, Charles.McDevitt@emc.com wrote: > If psql uses libreadline and libgnutls, does that mean psql will be distributed under the GPL in the future? Or Dual-licensed? libgnutls is libgpl, not GPL, so this is not a problem. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Greg,
* Greg Smith (greg@2ndquadrant.com) wrote:
> Note that the past discussion was on the difficulty of matching the
> existing OpenSSL API using GnuTLS, which is apparently difficult to
> do.
Oh, yes, that's more a reflection on the crappy API that OpenSSL has
than on anything else, in my view...
> I wasn't trying to suggest there were issues specificially with
> GnuTLS's code quality.
Ah, I'm glad to hear that.
> You'd think there'd be a simple "OpenSSL-like" interface available
> for GnuTLS by now or something.
There is, but it was written by Steve Langasek (as I recall...) for when
this was done for OpenLDAP and was licensed under the GPL (and, yes, I
did bitch at him about this... Didn't help. :/).
I'm not sure if that compatability layer would work (in terms of being
acceptable by core) for PG in any case tho.
Thanks,
Stephen
Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 compliance is essential to many Federal users. GnuTLS doesn't qualify.
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Why do we have to involve the whole of PostgreSQL? Since the only piece
> that links to libreadline is psql, perhaps we could fix this by having
> only psql optionally use GnuTLS.
We have code that exists in both psql and the backend (cf src/port/)
so I'm not sure this really will satisfy the more rabid GPL partisans.
And this whole discussion is about satisfying the most rabid of them,
remember. I don't really think that anything other than "relicense all
of Postgres as GPL" will make them happy.
regards, tom lane
On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Why do we have to involve the whole of PostgreSQL? Since the only piece >> that links to libreadline is psql, perhaps we could fix this by having >> only psql optionally use GnuTLS. > > We have code that exists in both psql and the backend (cf src/port/) > so I'm not sure this really will satisfy the more rabid GPL partisans. > And this whole discussion is about satisfying the most rabid of them, > remember. I don't really think that anything other than "relicense all > of Postgres as GPL" will make them happy. Which, by the way, *no one* has the authority to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
If psql uses libreadline and libgnutls, does that mean psql will be distributed under the GPL in the future? Or Dual-licensed? If I read the readline license right, applications that link to it must be GPL. That's why we (EMC/Greenplum) switch to libedit, even though readline is nicer... We didn't want to ship part of our productas GPL
* Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote:
> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 compliance is essential to many Federal
users.
Essential? That's a bit much. Yes, it shows up on a FISMA review as an
open action item, but it's a risk that can both be accepted and
mitigated. I also thought FIPS-140 version required API changes..
> GnuTLS doesn't qualify.
That should be "doesn't currently"..
Thanks,
Stephen
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We have code that exists in both psql and the backend (cf src/port/)
>> so I'm not sure this really will satisfy the more rabid GPL partisans.
>> And this whole discussion is about satisfying the most rabid of them,
>> remember. �I don't really think that anything other than "relicense all
>> of Postgres as GPL" will make them happy.
> Which, by the way, *no one* has the authority to do.
Right. So the long term solution in my mind is to migrate away from
readline and towards libedit. I'm just not sufficiently worried about
this to put any of my own cycles into making libedit good enough.
regards, tom lane
Tom,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> We have code that exists in both psql and the backend (cf src/port/)
> so I'm not sure this really will satisfy the more rabid GPL partisans.
We're talking Debian, who, yes, are a bit pickier when it comes to
trying to actually follow the licneses they release, but they're also
technically competent. I expect the answer would depend on if the
backend process links against both readline and openssl or not.
> And this whole discussion is about satisfying the most rabid of them,
> remember. I don't really think that anything other than "relicense all
> of Postgres as GPL" will make them happy.
Of course, relicensing it under the GPL wouldn't actually help this
situation, at all, nor has anyone brought it up that I'm aware of..
Thanks,
Stephen
On Fri, Feb 11, 2011 at 12:25 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote: >> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 compliance is essential to many Federal users. > > Essential? That's a bit much. Yes, it shows up on a FISMA review as an > open action item, but it's a risk that can both be accepted and > mitigated. I also thought FIPS-140 version required API changes.. > >> GnuTLS doesn't qualify. > > That should be "doesn't currently".. Not being a SSL aficionado by any means, but what about NSS? That's pretty mature, and could be another viable option. -- fdr
On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote: > Note that the past discussion was on the difficulty of matching the > existing OpenSSL API using GnuTLS, which is apparently difficult to do. > I wasn't trying to suggest there were issues specificially with GnuTLS's > code quality. It's more that the APIs are just different enough that > it's not trivial to do a swap--which is surprising given how many people > have seemingly needed to do exactly this conversion. You'd think > there'd be a simple "OpenSSL-like" interface available for GnuTLS by now > or something. I spent some time a while back making PostgreSQL work with GnuTLS. The actual SSL bit is trivial. The GnuTLS interface actually made sense whereas the OpenSSL one is opaque (at least, I've never seen any structure in it). The GnuTLS interface was designed in the modern era and it shows. The problems are primarily that psql exposes in various ways that it uses OpenSSL and does it in ways that are hard to support backward compatably. So for GnuTLS support you need to handle all those bits too. For example, the patch as presented introduced a passthrough mode that allowed applications to read/write over the SSL connection without actually knowing the underlying library. It had to fix psql to use this info. It had to provide ways for applications to determine the info they needed about the SSL, since it wouldn't beable to just grab the OpenSSL handle. All this made the patch large, which caused it to be rejected. I found that odd since the bulk of the patch was the renaming of two files, which makes for huge diffs while the changes where minimal. I beleive git is smarter about renames which means the diff may magically become much smaller just by using git, yay! Supporting GnuTLS for that backend was just icing, but trivial once the frontend was done. It can be left out. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
On Fri, Feb 11, 2011 at 5:22 PM, Martijn van Oosterhout <kleptog@svana.org> wrote: > On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote: >> Note that the past discussion was on the difficulty of matching the >> existing OpenSSL API using GnuTLS, which is apparently difficult to do. >> I wasn't trying to suggest there were issues specificially with GnuTLS's >> code quality. It's more that the APIs are just different enough that >> it's not trivial to do a swap--which is surprising given how many people >> have seemingly needed to do exactly this conversion. You'd think >> there'd be a simple "OpenSSL-like" interface available for GnuTLS by now >> or something. > > I spent some time a while back making PostgreSQL work with GnuTLS. The > actual SSL bit is trivial. The GnuTLS interface actually made sense > whereas the OpenSSL one is opaque (at least, I've never seen any > structure in it). The GnuTLS interface was designed in the modern era > and it shows. > > The problems are primarily that psql exposes in various ways that it > uses OpenSSL and does it in ways that are hard to support backward > compatably. So for GnuTLS support you need to handle all those bits > too. > > For example, the patch as presented introduced a passthrough mode that > allowed applications to read/write over the SSL connection without > actually knowing the underlying library. It had to fix psql to use this > info. It had to provide ways for applications to determine the info > they needed about the SSL, since it wouldn't beable to just grab the > OpenSSL handle. > > All this made the patch large, which caused it to be rejected. I found > that odd since the bulk of the patch was the renaming of two files, > which makes for huge diffs while the changes where minimal. I beleive > git is smarter about renames which means the diff may magically become > much smaller just by using git, yay! > > Supporting GnuTLS for that backend was just icing, but trivial once the > frontend was done. It can be left out. We should probably revisit this for 9.2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
> * Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote: > > Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 > compliance is essential to many Federal users. > > Essential? That's a bit much. Yes, it shows up on a FISMA review as an > open action item, but it's a risk that can both be accepted and > mitigated. I also thought FIPS-140 version required API changes.. > > > GnuTLS doesn't qualify. > > That should be "doesn't currently".. > Doesn't currently? Does that mean you know of a project to get FIPS certification for it? I don't. The current OpenSSL has a version that is (the only source-code-level FIPS-140 certification ever). And yes, it is API compatible with the non-FIPS one. It just doesn't support some of the algorithms that the other does. The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL. Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this).
On Fri, Feb 11, 2011 at 11:06 PM, <Charles.McDevitt@emc.com> wrote: > The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL. > Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this). This is just libelous FUD. There's absolutely no reason postgres would have to be GPL'd to satisfy any library license. In fact doing so would make the problem worse, not better since then the license on Postgres itself would (allegedly) conflict with the OpenSSL license. There's no question that the resulting binary when linked with readline is covered by the GPL including shipping source code etc. This is non-controversial and the original intent of licensing readline under the GPL. This isn't the same question as GIMP plugins or code using GMP which are themselves functionally dependent on the GPL'd code and some claim are therefore derivative works. I don't think anyone would claim that Postges is a derivative work of readline. The only question here is whether the OpenSSL license imposes requirements which cannot be met at the same time as the GPL requirements. The rest of Postgres itself doesn't conflict but if you're distributing a binary then you're covered by all the licenses of the code you include and depend on (the last part is somewhat controversial but irrelevant to this topic since OpenSSL headers are already included). So if the OpenSSL license imposes restrictions that the GPL bars then the resulting binary is not distributable. I suspect RedHat may have determined that the OpenSSL license requirements are not in fact mutually exclusive with the GPL either because they're not enforceable at all in the US anyways or because the way they read them they can be satisfied without violating the GPL. It's also possible they just decided it's unlikely the OpenSSL people would ever sue or the damages would be negligable. Of course this is all speculation. -- greg
-----Original Message----- > From: gsstark@gmail.com [mailto:gsstark@gmail.com] On Behalf Of Greg Stark > Sent: Friday, February 11, 2011 4:03 PM > On Fri, Feb 11, 2011 at 11:06 PM, <Charles.McDevitt@emc.com> wrote: > > The GNU people will never be 100% satisfied by anything you do to psql, other > than making it GPL. > > Readline is specifically licensed in a way to try to force this (but many disagree > with their ability to force this). > > This is just libelous FUD. There's absolutely no reason postgres would > have to be GPL'd to satisfy any library license. Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional requirements.
On Sat, Feb 12, 2011 at 12:07 AM, <Charles.McDevitt@emc.com> wrote: >> This is just libelous FUD. There's absolutely no reason postgres would >> have to be GPL'd to satisfy any library license. > > Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional requirements. No -- greg
> -----Original Message----- > From: gsstark@gmail.com [mailto:gsstark@gmail.com] On Behalf Of Greg Stark > Sent: Friday, February 11, 2011 4:14 PM > To: McDevitt, Charles > Cc: sfrost@snowman.net; alvherre@commandprompt.com; > greg@2ndquadrant.com; mbanck@debian.org; tgl@sss.pgh.pa.us; > andrew@dunslane.net; jd@commandprompt.com; pgsql- > hackers@postgresql.org > Subject: Re: Debian readline/libedit breakage > > On Sat, Feb 12, 2011 at 12:07 AM, <Charles.McDevitt@emc.com> wrote: > >> This is just libelous FUD. There's absolutely no reason postgres would > >> have to be GPL'd to satisfy any library license. > > > > Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional > requirements. > > No What? From the GNU Readline home page: "Readline is free software, distributed under the terms of the GNU General PublicLicense, version 3." I know it used to be GPLv2, but that isn't true these days.
* Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote:
> > * Charles.McDevitt@emc.com (Charles.McDevitt@emc.com) wrote:
> > > GnuTLS doesn't qualify.
> >
> > That should be "doesn't currently"..
> >
>
> Doesn't currently? Does that mean you know of a project to get FIPS certification for it? I don't.
"doesn't qualify" would imply that it's incapable of attaining FIPS
certification. I didn't make that claim, you did. Is there some reason
that GnuTLS is incapable of attaining FIPS certification that you know
of? Also, this is a very Debian-specific thread and quite a few other
Debian packages use GnuTLS instead of OpenSSL. I do not expect
PostgreSQL to drop support for OpenSSL, ever.
> The current OpenSSL has a version that is (the only source-code-level FIPS-140 certification ever).
Yes, I'm aware, I didn't dispute that.
> And yes, it is API compatible with the non-FIPS one. It just doesn't support some of the algorithms that the other
does.
When I looked into addressing this for our C&A'd systems it wasn't at
all clear that it was trivial to move from non-FIPS OpenSSL to
FIPS-compliant OpenSSL. Perhaps that's changed but, sadly, there's a
heck of a lot more encryption out there than just what OpenSSL will give
you (the Linux kernel being a primary example, but also the MIT Kerberos
libraries). Yes, it means you have to address that FISMA control, but
that's not an insurmountable problem and is, really, a reality for
anyone running a serious Linux-based environment, in my experience.
What I don't think people appreciate or realize is that there's a lot of
other encryption happening in their systems beyond what OpenSSL does.
> The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL.
> Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this).
This doesn't deserve a response.
Thanks,
Stephen
On Sat, Feb 12, 2011 at 12:15 AM, <Charles.McDevitt@emc.com> wrote: >> > Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional >> requirements. >> >> No > > What? From the GNU Readline home page: "Readline is free software, distributed under the terms of the GNU General PublicLicense, version 3." > > I know it used to be GPLv2, but that isn't true these days. There's nothing in the GPLv3 which changes things in this case. -- greg
Charles.McDevitt@emc.com wrote: > The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL. > Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this). > The "GNU people" are perfectly content with the license of PostgreSQL. They are unhappy with the license terms of OpenSSL, which is fair because they are ridiculous. Eric Young and the rest of the contributors produced a useful piece of software, and made it considerly less valuable to the world due to the ego trip terms: http://www.openssl.org/source/license.html -- the worst specific problem is the requirement to acknowledge OpenSSL use in advertising of projects that use it. The PostgreSQL community has had similar issues with popular software commonly used on top of PostgreSQL, that happened to use a non-standard license with unique terms. It would be both hypocritical and incorrect to now blame the GNU projects for taking a similar stand on this one. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
Tom Lane <tgl@sss.pgh.pa.us> writes: > Less narrow-minded interpretation of GPL requirements, perhaps. > (And yes, we have real lawyers on staff considering these issues.) If we really believe that the debian interpretation of the licence issue here is moot, surely the easiest action is to offer a debian package repository hosted in the postgresql.org infrastructure. That would also allow us to maintain all our currently supported versions and choose to consider reaching EOL of one of them where it's still included in a stable debian releases. Debian folks can't do that and as a result they will only ship one major version at a time, which certainly is a shame. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> Less narrow-minded interpretation of GPL requirements, perhaps. >> (And yes, we have real lawyers on staff considering these issues.) > > If we really believe that the debian interpretation of the licence issue > here is moot, surely the easiest action is to offer a debian package > repository hosted in the postgresql.org infrastructure. > > That would also allow us to maintain all our currently supported > versions and choose to consider reaching EOL of one of them where it's > still included in a stable debian releases. Debian folks can't do that > and as a result they will only ship one major version at a time, which > certainly is a shame. Yeah, I've been thinking about that before, for other reasons. It's fallen down so far on the fact that our current packager (Martin) isn't too interested in doing it, and he's been the one with the cycles and experience... Are you volunteering? ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes: > On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: >> If we really believe that the debian interpretation of the licence issue >> here is moot, surely the easiest action is to offer a debian package >> repository hosted in the postgresql.org infrastructure. >> > Are you volunteering? ;) I would, yes. I would benefit from that in more than one place, and of course we would have to ship extensions packages for all supported major versions too, which is something I've been working on for debian. See http://packages.debian.org/squeeze/postgresql-server-dev-all Now, what I think I would do about the core package is a quite simple backport of them, using Martin's excellent work. Do we want our own QA on them? If yes, I think I would need some help here, maybe with some build farm support for running from our debian packages rather than from either CVS or git. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
> Charles.McDevitt@emc.com wrote: > > The GNU people will never be 100% satisfied by anything you do to psql, other > than making it GPL. > > Readline is specifically licensed in a way to try to force this (but many disagree > with their ability to force this). > > > > The "GNU people" are perfectly content with the license of PostgreSQL. > They are unhappy with the license terms of OpenSSL, which is fair > because they are ridiculous. Eric Young and the rest of the > contributors produced a useful piece of software, and made it considerly > less valuable to the world due to the ego trip terms: > http://www.openssl.org/source/license.html -- the worst specific problem > is the requirement to acknowledge OpenSSL use in advertising of projects > that use it. > > The PostgreSQL community has had similar issues with popular software > commonly used on top of PostgreSQL, that happened to use a non-standard > license with unique terms. It would be both hypocritical and incorrect > to now blame the GNU projects for taking a similar stand on this one. You are correct... I overreacted, after having run into problems in the past with GPL (vs LGPL) issues. My apologies to all for adding stupid distracting comments to this thread. It would be wonderful if the OpenSSL people would compromise on this, but I suppose that isn't possible. I'd love to see libedit get better, and would like to see that solution, because OpenSSL's FIPS compliance really helps withFederal customers, but I realize that involves a lot of effort. I hope if the PostgreSQL project goes down the path of switching to GnuTLS, OpenSSL remains an option (for the server side).
Dimitri Fontaine wrote:
> Now, what I think I would do about the core package is a quite simple
> backport of them, using Martin's excellent work. Do we want our own QA
> on them? If yes, I think I would need some help here, maybe with some
> build farm support for running from our debian packages rather than from
> either CVS or git.
>
What the RPM packaging does is run this (approximately):
pushd src/test/regress make all make MAX_CONNECTIONS=5 check
Something similar might be sufficient for QA on the Debian packaging
too. The overhead of the buildfarm makes sense if you want to rebuild
after every single commit. It may be overkill to go through that just
for testing .deb packaging, which realistically you're only going to
want to do after each point release.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Greg Smith <greg@2ndquadrant.com> writes: > What the RPM packaging does is run this (approximately): Well building the debian package also run make check. My question is if that's enough QA here for us? The other side of things if that we will need to provide for a debian repository with support for at least lenny and squeeze and sid, and i386 and amd64. Maybe some more. We will need some build environments here. Anybody thinking we should somehow include ubuntu in the mix? If yes, which versions? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Sun, Feb 13, 2011 at 12:09, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Greg Smith <greg@2ndquadrant.com> writes: >> What the RPM packaging does is run this (approximately): > > Well building the debian package also run make check. My question is if > that's enough QA here for us? Don't the RPM building guys (Hi, Devrim!) also run the tests on an installed version of the RPMs? Should be easy enough to automate something like that, no? Though there obviously has to be some point where to stop - should we test both install and upgrade? > The other side of things if that we will need to provide for a debian > repository with support for at least lenny and squeeze and sid, and i386 > and amd64. Maybe some more. We will need some build environments here. I think i386 and amd64 are enough, really. We could add more later if necessary, but i don't think we need to. I assume this can be easily virtualized - e.g. having one VM for each version and just boot it up, update all dependencis, build, and shut down? in fact, shouldn't there be tools around already that do this automated? > Anybody thinking we should somehow include ubuntu in the mix? If yes, > which versions? Yes, since according to a comment somewhere the same issue will bubble into ubuntu soon. At this point, definitely 8.04 and 10.04, and probably 10.10. If things can be easily automated, it would be great if we could do *all* supported ubuntu, but doing LTS and the latest one or two non-LTS releases. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes: > I think i386 and amd64 are enough, really. We could add more later if > necessary, but i don't think we need to. Ok. > I assume this can be easily virtualized - e.g. having one VM for each > version and just boot it up, update all dependencis, build, and shut > down? in fact, shouldn't there be tools around already that do this > automated? Yes, see pbuilder. You prepare a debootstrap environment (that's a tar.gz with a bare minimum debian installation in that you can chroot to to build package) and pbuilder will apt-get build-dep then debuild for you then copy the resulting debs out of the chroot and remove it. You can even build i386 packages from an amd64 OS, I'm doing that nowadays for the emacs-snapshot package for ubuntu. I'm building from the debian package someone else is doing. >> Anybody thinking we should somehow include ubuntu in the mix? If yes, >> which versions? > > Yes, since according to a comment somewhere the same issue will bubble > into ubuntu soon. At this point, definitely 8.04 and 10.04, and > probably 10.10. If things can be easily automated, it would be great > if we could do *all* supported ubuntu, but doing LTS and the latest > one or two non-LTS releases. Well, that needs I guess either several ubuntu VM or pbuilder support for ubuntu debootstraps, will check about that. -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Sun, Feb 13, 2011 at 12:56:03PM +0100, Dimitri Fontaine wrote: > Magnus Hagander <magnus@hagander.net> writes: > > Yes, since according to a comment somewhere the same issue will > > bubble > > into ubuntu soon. At this point, definitely 8.04 and 10.04, and > > probably 10.10. If things can be easily automated, it would be great > > if we could do *all* supported ubuntu, but doing LTS and the latest > > one or two non-LTS releases. > > Well, that needs I guess either several ubuntu VM or pbuilder support > for ubuntu debootstraps, will check about that. As pbuilder just runs debootstrap on --create and (Debian) debootstrap supports the Ubuntu releases, this is not an issue. Michael
Michael Banck <mbanck@debian.org> writes: > As pbuilder just runs debootstrap on --create and (Debian) debootstrap > supports the Ubuntu releases, this is not an issue. Great. It seems that a single amd64 build VM would allow us to build all those binary packages for i386 and amd64, for several debian and ubuntu releases. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri, On 02/12/2011 11:18 PM, Dimitri Fontaine wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Are you volunteering? ;) Once upon a time, I started such an approach, see packages.bluegap.ch. However, I didn't upgrade these packages for quite some time, because I didn't need them anymore for my day job. I received at least two mails thanking me for this service. (And judging from the server logs, I'm afraid they still use that unmaintained repository). > Now, what I think I would do about the core package is a quite simple > backport of them, using Martin's excellent work. Yeah, I've mostly run into Debian specific compatibility issues (like newer debhelper versions and stuff like that). Another major annoyance might be that (IIRC) postgresql-common has the knowledge about which Postgres versions are supported. So you don't ever want the Debian package to override the one you are providing. However, that means you either need to always be ahead of the Debian repo (version wise) or you need to rename that package (to something that's easier to your ears, like postgres-common *ducks*) > Do we want our own QA > on them? If yes, I think I would need some help here, maybe with some > build farm support for running from our debian packages rather than from > either CVS or git. I once had an issue with an upgrade. Testing that sucks big time, because the number of combinations grows exponentially, and I didn't see any good way to automate that kind of testing. But yeah, as long as Debian itself doesn't provide at least the newest few major versions still supported upstream, it would certainly make sense for the Postgres project to provide its own Debian / Ubuntu repositories. Regards Markus Wanner
Markus Wanner <markus@bluegap.ch> writes: > Once upon a time, I started such an approach, see packages.bluegap.ch. > However, I didn't upgrade these packages for quite some time, because I > didn't need them anymore for my day job. I received at least two mails > thanking me for this service. (And judging from the server logs, I'm > afraid they still use that unmaintained repository). Hey, wanna join the fun? That'd be awesome :) >> Now, what I think I would do about the core package is a quite simple >> backport of them, using Martin's excellent work. > > Yeah, I've mostly run into Debian specific compatibility issues (like > newer debhelper versions and stuff like that). > > Another major annoyance might be that (IIRC) postgresql-common has the > knowledge about which Postgres versions are supported. So you don't > ever want the Debian package to override the one you are providing. > However, that means you either need to always be ahead of the Debian > repo (version wise) or you need to rename that package (to something > that's easier to your ears, like postgres-common *ducks*) Well in fact if you install a PostgreSQL version that is not officially supported in the debian release you're working with, then the script /usr/share/postgresql-common/supported-versions will output it too. > But yeah, as long as Debian itself doesn't provide at least the newest > few major versions still supported upstream, it would certainly make > sense for the Postgres project to provide its own Debian / Ubuntu > repositories. +1 That's a big service to offer to our users. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 02/14/2011 10:23 AM, Dimitri Fontaine wrote: > Hey, wanna join the fun? That'd be awesome :) Sure, I'll try to help. Don't be surprised if that's not too often, though. I currently cannot promise to provide packaging in any kind of timely fashion. :-( > Well in fact if you install a PostgreSQL version that is not officially > supported in the debian release you're working with, then the script > /usr/share/postgresql-common/supported-versions will output it too. That's pretty much what I meant. I tried to avoid that warning by providing a newer version of the postgresql-common package. However, that approach doesn't work well with upgrades from Debian (because then you get the warning back). Another thing I tried was adding support for release candidates. The ability to distribute these as Debian packages could help getting them more tested. However, the "rc" in the version identifier isn't currently appreciated by the perl scripts provided. Anyway, that's probably not top priority. Where do we start? How would you like to organize this? (Martin used to have a git branch per distribution and per major version. That quickly gives you lots of branches and lots of only slightly different code bases to work on. Patching (or cherry picking) back and forth turned out to be quite a mess. Ideally I'd envision some kind of template system to build all of the variations. That would make the minor differences obvious). Markus
2011/2/14 Markus Wanner <markus@bluegap.ch>: > On 02/14/2011 10:23 AM, Dimitri Fontaine wrote: >> Hey, wanna join the fun? That'd be awesome :) > > Sure, I'll try to help. Don't be surprised if that's not too often, > though. I currently cannot promise to provide packaging in any kind of > timely fashion. :-( > >> Well in fact if you install a PostgreSQL version that is not officially >> supported in the debian release you're working with, then the script >> /usr/share/postgresql-common/supported-versions will output it too. > > That's pretty much what I meant. I tried to avoid that warning by > providing a newer version of the postgresql-common package. However, > that approach doesn't work well with upgrades from Debian (because then > you get the warning back). one way might be to suggest apt-preferences here, I believe. > > Another thing I tried was adding support for release candidates. The > ability to distribute these as Debian packages could help getting them > more tested. However, the "rc" in the version identifier isn't > currently appreciated by the perl scripts provided. Anyway, that's > probably not top priority. > > Where do we start? How would you like to organize this? First, we must have an agreement here. Is debian.postgresql.org to host and distribute the debian packages (and the ubuntu's) linked with readline and openSSL something that we want and assume ? So far, it looks like. Before pushing more efforts here, I would like people who not agree to stand up. Other options exists like a 3rd party website, but this is not my favorite solution. > > (Martin used to have a git branch per distribution and per major > version. That quickly gives you lots of branches and lots of only > slightly different code bases to work on. Patching (or cherry picking) > back and forth turned out to be quite a mess. Ideally I'd envision some > kind of template system to build all of the variations. That would make > the minor differences obvious). -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Cédric, thanks for taking a step back and bringing in the bigger picture. On 02/14/2011 11:57 AM, Cédric Villemain wrote: > one way might be to suggest apt-preferences here, I believe. Agreed, might be the cleanest way from a technical POV. > Is debian.postgresql.org to host and distribute the debian packages > (and the ubuntu's) linked with readline and openSSL something that we > want and assume ? Magnus confirmed on IRC, that they'd be willing to host such a repository. > So far, it looks like. Before pushing more efforts here, I would like > people who not agree to stand up. Other options exists like a 3rd > party website, but this is not my favorite solution. Well, I consider providing packages for more major versions in parallel a good service anyway. (So this probably deserves its own thread). But yes, to solve the OPs issue with such a custom repository, we'd need to be prepared to be responsible for providing a Postgres binary that links to readline and OpenSSL at the same time. Are we? Regards Markus Wanner
Hi, On 02/10/2011 11:34 PM, Joshua D. Drake wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 > > It seems we may have a problem to consider. As far as I know, we are the > only major platform that supports libedit but our default is readline. > Unfortunately readline is not compatible with OpenSSL (apparently?) > licensing. Anybody realized that this Debian bug (and several others) got closed in the mean time (Sunday)? According to the changelog [1], Martin Pitt (which I'm CC'ing here, as he might not be aware of this thread, yet) worked around this issue by pre-loading readline via LD_PRELOAD for psql. Personally, I'm a bit suspicious about that solution (technically as well as from a licensing perspective), but it's probably the simplest way to let only psql link against readline. Regards Markus Wanner [1]: Changelog for postgresql-common on Debian: http://packages.debian.org/changelogs/pool/main/p/postgresql-common/current/changelog
On Mon, Feb 14, 2011 at 13:37, Markus Wanner <markus@bluegap.ch> wrote: > Hi, > > On 02/10/2011 11:34 PM, Joshua D. Drake wrote: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 >> >> It seems we may have a problem to consider. As far as I know, we are the >> only major platform that supports libedit but our default is readline. >> Unfortunately readline is not compatible with OpenSSL (apparently?) >> licensing. > > Anybody realized that this Debian bug (and several others) got closed in > the mean time (Sunday)? According to the changelog [1], Martin Pitt > (which I'm CC'ing here, as he might not be aware of this thread, yet) > worked around this issue by pre-loading readline via LD_PRELOAD for psql. > > Personally, I'm a bit suspicious about that solution (technically as > well as from a licensing perspective), but it's probably the simplest > way to let only psql link against readline. That is a rather ugly workaround, but if it works and actually fixes the license considerations, then it's at least better than nothing at all. Not sure it's a reason not to have our own packaging (mainly because we could provide the version compatibility mix), but it would certainly reduce the urgency. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
2011/2/14 Magnus Hagander <magnus@hagander.net>: > On Mon, Feb 14, 2011 at 13:37, Markus Wanner <markus@bluegap.ch> wrote: >> Hi, >> >> On 02/10/2011 11:34 PM, Joshua D. Drake wrote: >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 >>> >>> It seems we may have a problem to consider. As far as I know, we are the >>> only major platform that supports libedit but our default is readline. >>> Unfortunately readline is not compatible with OpenSSL (apparently?) >>> licensing. >> >> Anybody realized that this Debian bug (and several others) got closed in >> the mean time (Sunday)? According to the changelog [1], Martin Pitt >> (which I'm CC'ing here, as he might not be aware of this thread, yet) >> worked around this issue by pre-loading readline via LD_PRELOAD for psql. >> >> Personally, I'm a bit suspicious about that solution (technically as >> well as from a licensing perspective), but it's probably the simplest >> way to let only psql link against readline. > > That is a rather ugly workaround, but if it works and actually fixes > the license considerations, then it's at least better than nothing at > all. Yes! > > Not sure it's a reason not to have our own packaging (mainly because > we could provide the version compatibility mix), but it would > certainly reduce the urgency. I agree. "Consider providing debian packages at debian.postgresql.org" Do we push that on the TODO list ? I believe it can come promptly after the extension stuff is done :) -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote: > "Consider providing debian packages at debian.postgresql.org" apt.postgresql.org, please. :) -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
2011/2/14 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote: >> "Consider providing debian packages at debian.postgresql.org" > > apt.postgresql.org, please. :) sure !!! -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Hello all, thanks Markus for CC'ing me, I'm not on -hackers@. Markus Wanner [2011-02-14 13:37 +0100]: > On 02/10/2011 11:34 PM, Joshua D. Drake wrote: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 Note that the recent discussions happened on bug 608442, in particular http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442#30 and the following comments. > Personally, I'm a bit suspicious about that solution (technically as > well as from a licensing perspective), [...] For the record, so am I (see comment 30 in the link above), as it uses the very same ld.so in both cases. However, Andreas Barth pointed out that with LD_PRELOAD it's guaranteed that we do not "import" any code from the libreadline header files, which guarantees that psql doesn't become something that can be considered a "derived work". Technically, this is a bit fragile, of course, as there might be some subtle ABI differences which lead to crashes. However, the preloading workaround already makes the situation so much better than before, so IMHO it's better than the previous status quo. I don't really like this situation, and personally I'd rather move back to libreadline until OpenSSL or readline or PostgreSQL threatens Debian with a legal case for license violation (I daresay that the chances of this happening are very close to zero..). But oh well.. Thanks, and sorry for all the madness this created! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin, On 02/14/2011 02:08 PM, Martin Pitt wrote: > thanks Markus for CC'ing me, I'm not on -hackers@. Sure. > Note that the recent discussions happened on bug 608442, in particular > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442#30 Thanks for this pointer. > Markus Wanner [2011-02-14 13:37 +0100]: >> Personally, I'm a bit suspicious about that solution (technically as >> well as from a licensing perspective), [...] > > For the record, so am I (see comment 30 in the link above) That's good to hear. ;-) > as it uses > the very same ld.so in both cases. However, Andreas Barth pointed out > that with LD_PRELOAD it's guaranteed that we do not "import" any code > from the libreadline header files, which guarantees that psql doesn't > become something that can be considered a "derived work". Hm.. interesting reasoning. But yes, there is something to it. It's not really the linking that matters, it seems. > Technically, this is a bit fragile, of course, as there might be some > subtle ABI differences which lead to crashes. However, the preloading > workaround already makes the situation so much better than before, so > IMHO it's better than the previous status quo. Absolutely, thanks for taking care. Regards Markus Wanner
On Mon, Feb 14, 2011 at 3:08 PM, Martin Pitt <mpitt@debian.org> wrote: > thanks Markus for CC'ing me, I'm not on -hackers@. > > Markus Wanner [2011-02-14 13:37 +0100]: >> On 02/10/2011 11:34 PM, Joshua D. Drake wrote: >> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 > > Note that the recent discussions happened on bug 608442, in particular > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442#30 > > and the following comments. > >> Personally, I'm a bit suspicious about that solution (technically as >> well as from a licensing perspective), [...] > > For the record, so am I (see comment 30 in the link above), as it uses > the very same ld.so in both cases. However, Andreas Barth pointed out > that with LD_PRELOAD it's guaranteed that we do not "import" any code > from the libreadline header files, which guarantees that psql doesn't > become something that can be considered a "derived work". > > Technically, this is a bit fragile, of course, as there might be some > subtle ABI differences which lead to crashes. However, the preloading > workaround already makes the situation so much better than before, so > IMHO it's better than the previous status quo. > > I don't really like this situation, and personally I'd rather move > back to libreadline until OpenSSL or readline or PostgreSQL threatens > Debian with a legal case for license violation (I daresay that the > chances of this happening are very close to zero..). But oh well.. I think it would be better to revert to readline and make note that conversion depends on libedit's readiness for unicode. I doubt anybody in Debian is that gung-ho to veto current state... Informing libedit about relevant problem would be good too. I don't see any bugs about that in Debian's bugtracker, did you send them to upstream? It's not like problems with openssl license is any sort of recent news. Solving it with preload hacks feels sleazy, as the non-preloaded state is unusable for most of the world... Also, I know admins who have /usr/lib/.../bin in their PATH to get access to all admin tools. So the preload hack would not work for them. -- marko
Markus Wanner wrote: > Anybody realized that this Debian bug (and several others) got closed in > the mean time (Sunday)? According to the changelog [1], Martin Pitt > (which I'm CC'ing here, as he might not be aware of this thread, yet) > worked around this issue by pre-loading readline via LD_PRELOAD for psql. > > Personally, I'm a bit suspicious about that solution (technically as > well as from a licensing perspective), but it's probably the simplest > way to let only psql link against readline. > This originated in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442 , and from what I'm reading there it sounds like Martin is inserting this as a workaround but it hasn't passed through Debian Legal yet. I would expect them to reject this as unacceptable. Dynamic linking via LD_PRELOAD is still linking, even if it happens at runtime. I commend Martin for buying some time here by doing that, but this doesn't change the urgency to come up with an alternate solution much to me. As I see it, that change could be reverted at any time via pushback from legal. As far as working around this by releasing our own packages goes, that's useful, but I'd also characterize that as only a workaround rather than a real solution. OpenSSL is open-source, but it's not "free software" via that standards of the FSF, which I feel is a completely reasonable position given the license. When you depend on a software stack built from unambiguously free software, having components that aren't you've wedged in there and are dependent on is never a good idea. I won't consider this truly resolved until GnuTLS support for PostgreSQL is in core. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
On Fri, Feb 11, 2011 at 1:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I'll be happy if you do, but why haven't I haven't noticed, say, RedHat >> taking this line? > > Less narrow-minded interpretation of GPL requirements, perhaps. > (And yes, we have real lawyers on staff considering these issues.) FYI, seems Fedora has been actively trying to move away from OpenSSL for some time now: https://fedoraproject.org/wiki/CryptoConsolidationEval https://fedoraproject.org/wiki/FedoraCryptoConsolidation Main arguments are FIPS and single-cert-store, but in the evaluation of NSS vs. OpenSSL I think license issues have at least some impact. -- marko
On 02/14/2011 08:27 AM, Greg Smith wrote: > Markus Wanner wrote: >> Anybody realized that this Debian bug (and several others) got closed in >> the mean time (Sunday)? According to the changelog [1], Martin Pitt >> (which I'm CC'ing here, as he might not be aware of this thread, yet) >> worked around this issue by pre-loading readline via LD_PRELOAD for >> psql. >> >> Personally, I'm a bit suspicious about that solution (technically as >> well as from a licensing perspective), but it's probably the simplest >> way to let only psql link against readline. > > This originated in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442 , and from > what I'm reading there it sounds like Martin is inserting this as a > workaround but it hasn't passed through Debian Legal yet. I would > expect them to reject this as unacceptable. Dynamic linking via > LD_PRELOAD is still linking, even if it happens at runtime. I commend > Martin for buying some time here by doing that, but this doesn't > change the urgency to come up with an alternate solution much to me. > As I see it, that change could be reverted at any time via pushback > from legal. > > As far as working around this by releasing our own packages goes, > that's useful, but I'd also characterize that as only a workaround > rather than a real solution. OpenSSL is open-source, but it's not > "free software" via that standards of the FSF, which I feel is a > completely reasonable position given the license. When you depend on > a software stack built from unambiguously free software, having > components that aren't you've wedged in there and are dependent on is > never a good idea. I won't consider this truly resolved until GnuTLS > support for PostgreSQL is in core. Given the links Marko just posted, maybe NSS would be a better bet. Apparently they also have some sort of compatibility library too. I agree that the LD_PRELOAD trick seems absurd, and unlikely to be acceptable to FSF types. cheers andrew
* Stephen Frost: > * Greg Smith (greg@2ndquadrant.com) wrote: >> -GNU libreadine is certainly never going to add an OpenSSL exemption > > I really wish they would, that's just them being obnoxious- it's already > LGPL, after all.. Source? I've only seen GPLed copies. We wouldn't face this issue with LGPL code. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
* Florian Weimer (fweimer@bfk.de) wrote: > Source? I've only seen GPLed copies. We wouldn't face this issue > with LGPL code. Yeah, Greg corrected me on this already. So we have both FSF folks *and* OpenSSL people being foolish. Sigh. Stephen
On 02/14/2011 02:26 PM, Marko Kreen wrote: > On Mon, Feb 14, 2011 at 3:08 PM, Martin Pitt<mpitt@debian.org> wrote: >> thanks Markus for CC'ing me, I'm not on -hackers@. >> >> Markus Wanner [2011-02-14 13:37 +0100]: >>> On 02/10/2011 11:34 PM, Joshua D. Drake wrote: >>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 >> >> Note that the recent discussions happened on bug 608442, in particular >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442#30 >> >> and the following comments. >> >>> Personally, I'm a bit suspicious about that solution (technically as >>> well as from a licensing perspective), [...] >> >> For the record, so am I (see comment 30 in the link above), as it uses >> the very same ld.so in both cases. However, Andreas Barth pointed out >> that with LD_PRELOAD it's guaranteed that we do not "import" any code >> from the libreadline header files, which guarantees that psql doesn't >> become something that can be considered a "derived work". >> >> Technically, this is a bit fragile, of course, as there might be some >> subtle ABI differences which lead to crashes. However, the preloading >> workaround already makes the situation so much better than before, so >> IMHO it's better than the previous status quo. >> >> I don't really like this situation, and personally I'd rather move >> back to libreadline until OpenSSL or readline or PostgreSQL threatens >> Debian with a legal case for license violation (I daresay that the >> chances of this happening are very close to zero..). But oh well.. > > I think it would be better to revert to readline and make note > that conversion depends on libedit's readiness for unicode. > I doubt anybody in Debian is that gung-ho to veto current state... > > Informing libedit about relevant problem would > be good too. I don't see any bugs about that in Debian's > bugtracker, did you send them to upstream? from what I can see upstream libedit actually has utf8 support for a while now (as well as some other fixes) but the debian libedit version (and also the one of other distributions) is way too old for that so maybe most of the issues would be mood if debian updated to a newer libedit version... Stefan
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > from what I can see upstream libedit actually has utf8 support for a while > now (as well as some other fixes) but the debian libedit version (and also > the one of other distributions) is way too old for that so maybe most of the > issues would be mood if debian updated to a newer libedit version... There's utf8 support and then there's utf8 support. last I saw libedit didn't actually stop you from using utf8 and things kind of worked, but none of the editing commands understand what the multibyte characters were or understood what column position you were in so you could easily end up deleting half a character or with the insertion point in the middle of a character. -- greg
On 02/15/2011 12:37 PM, Greg Stark wrote: > On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: >> from what I can see upstream libedit actually has utf8 support for a while >> now (as well as some other fixes) but the debian libedit version (and also >> the one of other distributions) is way too old for that so maybe most of the >> issues would be mood if debian updated to a newer libedit version... > > There's utf8 support and then there's utf8 support. last I saw libedit > didn't actually stop you from using utf8 and things kind of worked, > but none of the editing commands understand what the multibyte > characters were or understood what column position you were in so you > could easily end up deleting half a character or with the insertion > point in the middle of a character. well I have not actually tested - I was just reading the changelog on http://www.thrysoee.dk/editline/ which claims UTF8 "support" (whatever that means) in the current code drop. Stefan
--On 15. Februar 2011 18:52:04 +0100 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > well I have not actually tested - I was just reading the changelog on > http://www.thrysoee.dk/editline/ which claims UTF8 "support" (whatever > that means) in the current code drop. I tested it....--enable-wc doesn't work as you might expect. As Greg already said, it will bother you with a strange behavior when deleting characters (e.g. it removes half of your prompt) and at least on my mac i still wasn't able to enter multibyte characters like german umlauts. -- Thanks Bernd
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> We have code that exists in both psql and the backend (cf src/port/) > >> so I'm not sure this really will satisfy the more rabid GPL partisans. > >> And this whole discussion is about satisfying the most rabid of them, > >> remember. �I don't really think that anything other than "relicense all > >> of Postgres as GPL" will make them happy. > > > Which, by the way, *no one* has the authority to do. > > Right. So the long term solution in my mind is to migrate away from > readline and towards libedit. I'm just not sufficiently worried about > this to put any of my own cycles into making libedit good enough. Agreed. If we can create a database, someone can get libedit to work 100%! There is no excuse for this not being done, seeing that libreadline has been (viral) GPL forever and has changed APIs regularly and broken things for us. Even going with GNUTLS does not help us with that. Can someone take ownership of this, get involved with the libedit folks, get Debian to use their fixes, and solve this problem for us? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 02/16/2011 12:29 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Robert Haas<robertmhaas@gmail.com> writes: >>> On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>>> We have code that exists in both psql and the backend (cf src/port/) >>>> so I'm not sure this really will satisfy the more rabid GPL partisans. >>>> And this whole discussion is about satisfying the most rabid of them, >>>> remember. �I don't really think that anything other than "relicense all >>>> of Postgres as GPL" will make them happy. >>> Which, by the way, *no one* has the authority to do. >> Right. So the long term solution in my mind is to migrate away from >> readline and towards libedit. I'm just not sufficiently worried about >> this to put any of my own cycles into making libedit good enough. > Agreed. If we can create a database, someone can get libedit to work > 100%! There is no excuse for this not being done, seeing that > libreadline has been (viral) GPL forever and has changed APIs regularly > and broken things for us. Even going with GNUTLS does not help us with > that. > > Can someone take ownership of this, get involved with the libedit folks, > get Debian to use their fixes, and solve this problem for us? You're assuming a fact not in evidence, namely the existence of an identifiable group of "libedit folks". Last time I looked there was no such group. I'm not greatly in favor of encouraging people to spend lots of time on this. If they have cycles to spend I'd rather they spent them on Postgres features, rather than a project we'd probably end up owning forever. (And we shouldn't assume that GnuTLS is the right replacement for OpenSSL either, BTW). cheers andrew
On Wed, 2011-02-16 at 12:29 -0500, Bruce Momjian wrote: > Tom Lane wrote: > Can someone take ownership of this, get involved with the libedit folks, > get Debian to use their fixes, and solve this problem for us? That is a lot easier said that done. To be frank, I thought it was something that I would put CMD to task with because it would help not only Pg but the much wider community as well. However, the project is not small and I don't want CMD being solely responsible for something that will generate exactly 0 dollars. It is hard enough that we make well over 98% of our dollars not working on PostgreSQL but instead working with it. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On mån, 2011-02-14 at 15:01 +0200, Devrim GÜNDÜZ wrote: > On Mon, 2011-02-14 at 13:52 +0100, Cédric Villemain wrote: > > "Consider providing debian packages at debian.postgresql.org" > > apt.postgresql.org, please. :) APT is not necessarily tied to Debian, nor is a Debian package repository necessarily tied to APT.
Andrew Dunstan <andrew@dunslane.net> writes: > On 02/16/2011 12:29 PM, Bruce Momjian wrote: >> Can someone take ownership of this, get involved with the libedit folks, >> get Debian to use their fixes, and solve this problem for us? > You're assuming a fact not in evidence, namely the existence of an > identifiable group of "libedit folks". Last time I looked there was no > such group. FWIW, we are not the only people who are unhappy with the readline license situation. There has been muttering on the Fedora lists about trying to push libedit to the point where it'd be a usable drop-in replacement, even as recently as last week: http://lists.fedoraproject.org/pipermail/devel/2011-February/148473.html I'm not sure how much manpower is likely to emerge from that quarter, but it seems at least possible that something will get done without us having to do it. In the meantime, if there's anybody here who feels their talents are more suited to fixing libedit than to hacking Postgres, I encourage them to do so. But I don't think it's this project's charter to fix that problem. regards, tom lane
Andrew Dunstan wrote: > You're assuming a fact not in evidence, namely the existence of an > identifiable group of "libedit folks". Last time I looked there was no > such group. There appear to be two people working periodically on the upstream NetBSD libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date And a third who periodically packages that at http://www.thrysoee.dk/editline/ Those are the group as far as I can tell. It's not encouraging that the Debian issue with libedit+UTF8 has been documented for almost year a now: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579729 > (And we shouldn't assume that GnuTLS is the right replacement for > OpenSSL either, BTW). The idea of using NSS instead is an interesting one. Looking at http://en.wikipedia.org/w/index.php?title=Comparison_of_TLS_Implementations it does seem to match the basic feature set of OpenSSL. And the nss_compat_ossl compatibility layer might be useful: http://fedoraproject.org/wiki/Nss_compat_ossl I find it hard to get excited about working to replace the software that has a reasonable license here (readline) rather than trying to eliminate dependence on the one with an unreasonable license (OpenSSL). -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith <greg@2ndquadrant.com> wrote: > There appear to be two people working periodically on the upstream NetBSD libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date > > And a third who periodically packages that at http://www.thrysoee.dk/editline/ I'm really confused between libedit and libeditline. They both appear to be in Debian and I think they both trace their lineage to the original BSD library. Was one the NetBSD maintained one and the other the "upstream"? > I find it hard to get excited about working to replace the software that has > a reasonable license here (readline) rather than trying to eliminate > dependence on the one with an unreasonable license (OpenSSL). Personally I find there are plenty of technical reasons to run screaming from OpenSSL anyways. -- greg
On Thu, 2011-02-17 at 00:28 +0000, Greg Stark wrote: > On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith <greg@2ndquadrant.com> wrote: > > > There appear to be two people working periodically on the upstream NetBSD libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date > > > > And a third who periodically packages that at http://www.thrysoee.dk/editline/ > > I'm really confused between libedit and libeditline. They both appear > to be in Debian and I think they both trace their lineage to the > original BSD library. Was one the NetBSD maintained one and the other > the "upstream"? > > > I find it hard to get excited about working to replace the software that has > > a reasonable license here (readline) rather than trying to eliminate > > dependence on the one with an unreasonable license (OpenSSL). > > Personally I find there are plenty of technical reasons to run > screaming from OpenSSL anyways. > Maybe we really should consider moving to NSS insread? http://www.mozilla.org/projects/security/pki/nss/ If it solves the license problem, it is well supported etc.. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Greg Smith <greg@2ndquadrant.com> writes:
> I find it hard to get excited about working to replace the software that
> has a reasonable license here (readline) rather than trying to eliminate
> dependence on the one with an unreasonable license (OpenSSL).
Hm?
The trouble with readline is that it's GPL, not LGPL, and the former is
actually *not* a reasonable license for a library. At least not for one
that isn't trying to be viral. There's room for argument about whether
dynamic linking exempts applications from the scope of the license, but
in the end it would be cleanest from a licensing standpoint if we
weren't using readline. The OpenSSL license is BSD-with-advertising,
which is obnoxious in some respects but it isn't trying to force other
people to change the license on their code.
In particular, getting rid of use of OpenSSL would not be sufficient
to satisfy the most rabid GPL partisans that we were in compliance.
Whereas, if we get rid of readline, it no longer matters whether we
depend on OpenSSL.
regards, tom lane
Greg Stark <gsstark@mit.edu> writes: > On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith <greg@2ndquadrant.com> wrote: >> There appear to be two people working periodically on the upstream NetBSD libedit: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date >> >> And a third who periodically packages that at http://www.thrysoee.dk/editline/ > I'm really confused between libedit and libeditline. They both appear > to be in Debian and I think they both trace their lineage to the > original BSD library. Was one the NetBSD maintained one and the other > the "upstream"? The one in Fedora/RHEL and the one in Mac OSX both definitely consider NetBSD to be the active upstream. Dunno where Debian's other version comes from. regards, tom lane
On Thu, Feb 17, 2011 at 2:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Smith <greg@2ndquadrant.com> writes: >> I find it hard to get excited about working to replace the software that >> has a reasonable license here (readline) rather than trying to eliminate >> dependence on the one with an unreasonable license (OpenSSL). > > Hm? > > The trouble with readline is that it's GPL, not LGPL, and the former is > actually *not* a reasonable license for a library. At least not for one > that isn't trying to be viral. There's room for argument about whether > dynamic linking exempts applications from the scope of the license, but > in the end it would be cleanest from a licensing standpoint if we > weren't using readline. Using libedit would fix the problem for 'psql', but ... > The OpenSSL license is BSD-with-advertising, > which is obnoxious in some respects but it isn't trying to force other > people to change the license on their code. ... you are forgetting all the GPL apps that link with libpq. They either need to use non-SSL libpq or add OpenSSL exception to their license (to have 100% feel-good licensing). Just pointing out that OpenSSL does not smell like roses... -- marko
On Thu, Feb 17, 2011 at 12:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In particular, getting rid of use of OpenSSL would not be sufficient > to satisfy the most rabid GPL partisans that we were in compliance. Huh? In what way would we not be in compliance? Or rather, what part of the GPL would we be unable to comply with for distributing binaries? I think what you're getting at is that distributing source which can optionally link against GPL code might itself be a derivative work of the GPL code and need to be distributed under the GPL even if it's not built against it. I think that's just a straw man though, even the most ardent GPL partisan isn't going to claim that the Postgres source is a derivative work of readline because it has the option to link against readline for additional incidental functionality. To give context the case where this comes up are things like Gimp plugins *which are useless with thout the GIMP*. They're entirely dependent on the Gimp for their functionality. Claiming they're derivative works of the Gimp is a lot easier than claiming that Postgres is a derivative work of readline. A more borderline case was programs based on GMP. However even there it's hard to picture a useful program which needs GMP being able to do anything useful without GMP. Even then just providing a (much poorer) alternative implementation makes the case fall apart. > Whereas, if we get rid of readline, it no longer matters whether we > depend on OpenSSL. Not really, people still need to abide by the OpenSSL license rules which make our product less useful and less flexible. People might want to include Postgres in a product which uses other GPL'd code or which they don't want to alter their advertising. -- greg
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> In particular, getting rid of use of OpenSSL would not be sufficient
> to satisfy the most rabid GPL partisans that we were in compliance.
I've never heard anyone argue that position, don't believe anyone would,
and certainly don't agree with it.
> Whereas, if we get rid of readline, it no longer matters whether we
> depend on OpenSSL.
I agree w/ the other responses to this, in particular from Stark, but I
just wanted to point out that we're much more likely to come across
other GPL-licensed things that we want to support linking against (and
who might link against us..) than OpenSSL-type-licensed things..
Thanks,
Stephen
On Wed, 2011-02-16 at 20:53 -0500, Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > In particular, getting rid of use of OpenSSL would not be sufficient > > to satisfy the most rabid GPL partisans that we were in compliance. > > I've never heard anyone argue that position, don't believe anyone would, > and certainly don't agree with it. Yeah I am not sure I can buy Tom's argument here. The GPL is fairly clear and is compatible with the BSD/Postgres license. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, Feb 17, 2011 at 1:53 AM, Stephen Frost <sfrost@snowman.net> wrote:
> I agree w/ the other responses to this, in particular from Stark, but I
> just wanted to point out that we're much more likely to come across
> other GPL-licensed things that we want to support linking against (and
> who might link against us..) than OpenSSL-type-licensed things..
Well for what it's worth we want to support both. At least the project
philosophy has been that commercial derivatives are expected and
acceptable so things like EDB's products, or Greenplums, or for that
matter Pokertracker's all include other proprietary source that of
course has restrictive licenses ("OpenSSL-type-licensed" except even
*more* restrictive).
--
greg
Joshua D. Drake wrote: > On Wed, 2011-02-16 at 20:53 -0500, Stephen Frost wrote: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > > In particular, getting rid of use of OpenSSL would not be sufficient > > > to satisfy the most rabid GPL partisans that we were in compliance. > > > > I've never heard anyone argue that position, don't believe anyone would, > > and certainly don't agree with it. > > Yeah I am not sure I can buy Tom's argument here. The GPL is fairly > clear and is compatible with the BSD/Postgres license. Compatible if you want the result to be GPL, yes. I hardly see that as desirable. I am unclear what is being said above. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Greg Stark wrote: > On Thu, Feb 17, 2011 at 12:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > In particular, getting rid of use of OpenSSL would not be sufficient > > to satisfy the most rabid GPL partisans that we were in compliance. > > Huh? > > In what way would we not be in compliance? Or rather, what part of the > GPL would we be unable to comply with for distributing binaries? > > > I think what you're getting at is that distributing source which can > optionally link against GPL code might itself be a derivative work of > the GPL code and need to be distributed under the GPL even if it's not > built against it. I think that's just a straw man though, even the > most ardent GPL partisan isn't going to claim that the Postgres source > is a derivative work of readline because it has the option to link > against readline for additional incidental functionality. > > To give context the case where this comes up are things like Gimp > plugins *which are useless with thout the GIMP*. They're entirely > dependent on the Gimp for their functionality. Claiming they're > derivative works of the Gimp is a lot easier than claiming that > Postgres is a derivative work of readline. A more borderline case was > programs based on GMP. However even there it's hard to picture a > useful program which needs GMP being able to do anything useful > without GMP. Even then just providing a (much poorer) alternative > implementation makes the case fall apart. You are right that our source code is not require the GPL because it can use libreadline, but I am worried about people producing binaries that do link (dynamically?) against libreadline, which is GPL. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Greg Stark wrote:
> On Thu, Feb 17, 2011 at 1:53 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > I agree w/ the other responses to this, in particular from Stark, but I
> > just wanted to point out that we're much more likely to come across
> > other GPL-licensed things that we want to support linking against (and
> > who might link against us..) than OpenSSL-type-licensed things..
>
> Well for what it's worth we want to support both. At least the project
> philosophy has been that commercial derivatives are expected and
> acceptable so things like EDB's products, or Greenplums, or for that
> matter Pokertracker's all include other proprietary source that of
> course has restrictive licenses ("OpenSSL-type-licensed" except even
> *more* restrictive).
That might not be possible of libreadline makes psql require a GPL
license.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
* Bruce Momjian (bruce@momjian.us) wrote:
> Joshua D. Drake wrote:
> > > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > > > In particular, getting rid of use of OpenSSL would not be sufficient
> > > > to satisfy the most rabid GPL partisans that we were in compliance.
> > >
> > > I've never heard anyone argue that position, don't believe anyone would,
> > > and certainly don't agree with it.
> >
> > Yeah I am not sure I can buy Tom's argument here. The GPL is fairly
> > clear and is compatible with the BSD/Postgres license.
>
> Compatible if you want the result to be GPL, yes. I hardly see that as
> desirable. I am unclear what is being said above.
The comment regarding compliance, to me anyway, came across as meaning
that community PG wouldn't be compliant with the GPL if it linked with
libreadline and not with OpenSSL. Perhaps I misunderstood.
If the concern is that EDB's (or anyone else's) modified PG is linked
and distributed with libreadline, then yes, there is room to be
concerned about the GPL and I'd recommend they not do that. Of course,
I'd also recommend they not link with OpenSSL either, given the
advertising clause in that license. Thankfully, there's a clear option
for dealing with libreadline- distribute libedit and let users
LD_PRELOAD (or maybe distribute a community/OSS psql, if it's
unmodified..). There isn't an option for dealing with the OpenSSL
problem currently. :(
Thanks
Stephen
On Thu, Feb 17, 2011 at 3:16 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> Well for what it's worth we want to support both. At least the project
>> philosophy has been that commercial derivatives are expected and
>> acceptable so things like EDB's products, or Greenplums, or for that
>> matter Pokertracker's all include other proprietary source that of
>> course has restrictive licenses ("OpenSSL-type-licensed" except even
>> *more* restrictive).
>
> That might not be possible of libreadline makes psql require a GPL
> license.
>
There's a lot of confusion in this thread between the license terms
that Postgres source is distributed under and the license terms that
apply to distributing the resulting binary build. It shouldn't be
surprising that if you build Postgres to use other software that the
resulting binaries are covered by the union of all the licenses of
that code including both Postgres and any libraries you build with.
readline is an optional configure option. If we didn't have readline
support today and someone suggested adding a configure option to
support it wouldn't follow that having that option makes it any harder
to support non-GPL'd binary packages than if the configure option
wasn't there. Either way you can't distribute a binary with readline
in it unless you can follow the readline license.
Perhaps we should make configure print a warning for each
non-Postgres-license software it's being configured to use with a
pointer to the license for the configured. That might make it more
obvious to people that while Postges is licensed under a given
license, they might be configuring their build to depend on other code
under other licenses.
--
greg
* Greg Stark (gsstark@mit.edu) wrote:
> Well for what it's worth we want to support both. At least the project
> philosophy has been that commercial derivatives are expected and
> acceptable so things like EDB's products, or Greenplums, or for that
> matter Pokertracker's all include other proprietary source that of
> course has restrictive licenses ("OpenSSL-type-licensed" except even
> *more* restrictive).
This is a bit backwards, I think.. What you're suggesting is that, some
day, we might want community/BSD-licensed PG to link against
commercially licensed products from EDB for basic functionality (eg:
encryption)?
I agree that we want to reduce and eliminate, to the extent possible,
our dependence on GPL or OpenSSL-type-licensed libraries. It's
unfortunate that there isn't a good non-GPL option for libreadline, but
I'm not sure what EDB or anyone else would expect the PG community to
do regarding that. Should PG remove support for libreadline? Should
the PG community make libedit a good BSD-licensed alternative to
libreadline? Neither of those really make sense to me.
Thanks,
Stephen
* Greg Stark (gsstark@mit.edu) wrote:
> Perhaps we should make configure print a warning for each
> non-Postgres-license software it's being configured to use with a
> pointer to the license for the configured. That might make it more
> obvious to people that while Postges is licensed under a given
> license, they might be configuring their build to depend on other code
> under other licenses.
apt-cache depends postgresql-9.0 |\grep 'Depends: ' |\cut -f4 -d' ' |\sed -e 's:^:/usr/share/doc/:' -e
's:$:/copyright:'|\xargs cat |\wc -l
2364
Not too much to read. :)
Thanks,
Stephen
Stephen Frost wrote:
-- Start of PGP signed section.
> * Greg Stark (gsstark@mit.edu) wrote:
> > Well for what it's worth we want to support both. At least the project
> > philosophy has been that commercial derivatives are expected and
> > acceptable so things like EDB's products, or Greenplums, or for that
> > matter Pokertracker's all include other proprietary source that of
> > course has restrictive licenses ("OpenSSL-type-licensed" except even
> > *more* restrictive).
>
> This is a bit backwards, I think.. What you're suggesting is that, some
> day, we might want community/BSD-licensed PG to link against
> commercially licensed products from EDB for basic functionality (eg:
> encryption)?
>
> I agree that we want to reduce and eliminate, to the extent possible,
> our dependence on GPL or OpenSSL-type-licensed libraries. It's
> unfortunate that there isn't a good non-GPL option for libreadline, but
> I'm not sure what EDB or anyone else would expect the PG community to
> do regarding that. Should PG remove support for libreadline? Should
> the PG community make libedit a good BSD-licensed alternative to
> libreadline? Neither of those really make sense to me.
What are our click-installers doing now?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Greg Stark (gsstark@mit.edu) wrote:
> > > Well for what it's worth we want to support both. At least the project
> > > philosophy has been that commercial derivatives are expected and
> > > acceptable so things like EDB's products, or Greenplums, or for that
> > > matter Pokertracker's all include other proprietary source that of
> > > course has restrictive licenses ("OpenSSL-type-licensed" except even
> > > *more* restrictive).
> >
> > This is a bit backwards, I think.. What you're suggesting is that, some
> > day, we might want community/BSD-licensed PG to link against
> > commercially licensed products from EDB for basic functionality (eg:
> > encryption)?
> >
> > I agree that we want to reduce and eliminate, to the extent possible,
> > our dependence on GPL or OpenSSL-type-licensed libraries. It's
> > unfortunate that there isn't a good non-GPL option for libreadline, but
> > I'm not sure what EDB or anyone else would expect the PG community to
> > do regarding that. Should PG remove support for libreadline? Should
> > the PG community make libedit a good BSD-licensed alternative to
> > libreadline? Neither of those really make sense to me.
>
> What are our click-installers doing now?
Probably readline but does it matter? We distribute the source to the
click installers.
JD
>
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> In particular, getting rid of use of OpenSSL would not be sufficient
>> to satisfy the most rabid GPL partisans that we were in compliance.
> I've never heard anyone argue that position, don't believe anyone would,
> and certainly don't agree with it.
[ shrug ... ] Check the Postgres archives, from back around 2000 if
memory serves.
regards, tom lane
Joshua D. Drake wrote:
> On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
> > Stephen Frost wrote:
> > -- Start of PGP signed section.
> > > * Greg Stark (gsstark@mit.edu) wrote:
> > > > Well for what it's worth we want to support both. At least the project
> > > > philosophy has been that commercial derivatives are expected and
> > > > acceptable so things like EDB's products, or Greenplums, or for that
> > > > matter Pokertracker's all include other proprietary source that of
> > > > course has restrictive licenses ("OpenSSL-type-licensed" except even
> > > > *more* restrictive).
> > >
> > > This is a bit backwards, I think.. What you're suggesting is that, some
> > > day, we might want community/BSD-licensed PG to link against
> > > commercially licensed products from EDB for basic functionality (eg:
> > > encryption)?
> > >
> > > I agree that we want to reduce and eliminate, to the extent possible,
> > > our dependence on GPL or OpenSSL-type-licensed libraries. It's
> > > unfortunate that there isn't a good non-GPL option for libreadline, but
> > > I'm not sure what EDB or anyone else would expect the PG community to
> > > do regarding that. Should PG remove support for libreadline? Should
> > > the PG community make libedit a good BSD-licensed alternative to
> > > libreadline? Neither of those really make sense to me.
> >
> > What are our click-installers doing now?
>
> Probably readline but does it matter? We distribute the source to the
> click installers.
Well, there is what the community is risking, and there is what the
packagers are risking. Ideally we would make the job easier for the
packagers too, though we don't have to.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
* Bruce Momjian (bruce@momjian.us) wrote: > Joshua D. Drake wrote: > > Probably readline but does it matter? We distribute the source to the > > click installers. > > Well, there is what the community is risking, and there is what the > packagers are risking. Ideally we would make the job easier for the > packagers too, though we don't have to. I'm really mystified by this. If the source is available for the installers, what's the risk that you're worried about..? For the community or the packagers? Stephen
Jason,
* Jason Earl (jearl@notengoamigos.org) wrote:
> Or he could just read this essay from the FSF website:
Which is all about the GPL's "can't be *more* restrictive"
requirement. That doesn't apply in this case, sorry. Reading back
through the thread from December of 2000, I see the same was pointed
out then.
The BSD license clearly does not add any restrictions on distribution
that the GPL itself doesn't have (indeed, it's the other way around- the
GPL adds a bunch of additional restrictions), hence, there's no reason
to be concerned wrt community PG.
Would RMS like it to be GPL'd? Sure, of course he does, but that
doesn't mean he can use readline to somehow make us relicense it. If we
were releasing PG under a *more* restrictive license than the GPL, it'd
be different (which was the whole issue with ncftp, for those who read
the 2000 thread..). In *that* case, we'd have to make the source
available under a license which *didn't* impose any requirements beyond
what the GPL imposed, but we're already doing that!
> At least one application program is free software today
> specifically because that was necessary for using Readline.
Note that they say *free software* here- that doesn't mean it has to be
GPL, but that the source has to be available to the user without
additional restrictions on it. Here's the relevant quote from the GPL:
------------------
You may not impose any further restrictions on the recipients' exercise
of the rights granted herein.
------------------
(Section 6)
> IANAL, but it is hard to recommend relying on a reading of the GPL that
> is inconsistent with the folks that wrote the license.
What you're argueing isn't actually a position the GPL folks hold
though and seems to be built based on *no* reading of the GPL itself and
just an interpretation of how FSF has applied the GPL to other
situations which are drastically different from ours. :(
I'd like to see where someone from FSF, Debian, or anywhere else, where
they've actually even *asked* us to relicense PG under the GPL.
Thanks,
Stephen
On Wed, Feb 16 2011, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: >> * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>> In particular, getting rid of use of OpenSSL would not be sufficient >>> to satisfy the most rabid GPL partisans that we were in compliance. > >> I've never heard anyone argue that position, don't believe anyone would, >> and certainly don't agree with it. > > [ shrug ... ] Check the Postgres archives, from back around 2000 if > memory serves. > > regards, tom lane Or he could just read this essay from the FSF website: http://www.gnu.org/philosophy/why-not-lgpl.html It basically tries to persuade developers to create GPLed libraries in cases where the library provides services that are not available in proprietary libraries. The idea is to *force* developers to use the GPL if they want to use the library. Here's a relevant quote that actually uses readline as an example: However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that'sa facility not generally available elsewhere. Releasing it under the GPL and limiting its use to freeprograms gives our community a real boost. At least one application program is free software today specificallybecause that was necessary for using Readline. If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software,they will provide a range of useful modules to serve as building blocks in new free programs. Thiswill be a significant advantage for further free software development, and some projects will decide to makesoftware free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way. IANAL, but it is hard to recommend relying on a reading of the GPL that is inconsistent with the folks that wrote the license. Jason
On 02/10/2011 11:34 PM, Joshua D. Drake wrote: > Hello, > > Per: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 > > It seems we may have a problem to consider. As far as I know, we are the > only major platform that supports libedit but our default is readline. > Unfortunately readline is not compatible with OpenSSL (apparently?) > licensing. > > This seems that it may be a problem for us considering the pre-package > builds we do. > > What does everyone think? Should we work on getting libedit up to snuff? > > JD on lwn.net there's a nice summary about this debate you can read it at (*): http://lwn.net/SubscriberLink/428111/36b6b26832f4309d/ Andrea
On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
>> Stephen Frost wrote:
>> -- Start of PGP signed section.
>> > * Greg Stark (gsstark@mit.edu) wrote:
>> > > Well for what it's worth we want to support both. At least the project
>> > > philosophy has been that commercial derivatives are expected and
>> > > acceptable so things like EDB's products, or Greenplums, or for that
>> > > matter Pokertracker's all include other proprietary source that of
>> > > course has restrictive licenses ("OpenSSL-type-licensed" except even
>> > > *more* restrictive).
>> >
>> > This is a bit backwards, I think.. What you're suggesting is that, some
>> > day, we might want community/BSD-licensed PG to link against
>> > commercially licensed products from EDB for basic functionality (eg:
>> > encryption)?
>> >
>> > I agree that we want to reduce and eliminate, to the extent possible,
>> > our dependence on GPL or OpenSSL-type-licensed libraries. It's
>> > unfortunate that there isn't a good non-GPL option for libreadline, but
>> > I'm not sure what EDB or anyone else would expect the PG community to
>> > do regarding that. Should PG remove support for libreadline? Should
>> > the PG community make libedit a good BSD-licensed alternative to
>> > libreadline? Neither of those really make sense to me.
>>
>> What are our click-installers doing now?
>
> Probably readline but does it matter? We distribute the source to the
> click installers.
Actually, we don't. We used to, but we don't at this point.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake <jd@commandprompt.com> wrote:
>> On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
>>> Stephen Frost wrote:
>>> -- Start of PGP signed section.
>>> > * Greg Stark (gsstark@mit.edu) wrote:
>>> > > Well for what it's worth we want to support both. At least the project
>>> > > philosophy has been that commercial derivatives are expected and
>>> > > acceptable so things like EDB's products, or Greenplums, or for that
>>> > > matter Pokertracker's all include other proprietary source that of
>>> > > course has restrictive licenses ("OpenSSL-type-licensed" except even
>>> > > *more* restrictive).
>>> >
>>> > This is a bit backwards, I think.. What you're suggesting is that, some
>>> > day, we might want community/BSD-licensed PG to link against
>>> > commercially licensed products from EDB for basic functionality (eg:
>>> > encryption)?
>>> >
>>> > I agree that we want to reduce and eliminate, to the extent possible,
>>> > our dependence on GPL or OpenSSL-type-licensed libraries. It's
>>> > unfortunate that there isn't a good non-GPL option for libreadline, but
>>> > I'm not sure what EDB or anyone else would expect the PG community to
>>> > do regarding that. Should PG remove support for libreadline? Should
>>> > the PG community make libedit a good BSD-licensed alternative to
>>> > libreadline? Neither of those really make sense to me.
>>>
>>> What are our click-installers doing now?
>>
>> Probably readline but does it matter? We distribute the source to the
>> click installers.
>
> Actually, we don't. We used to, but we don't at this point.
Depends on your definition of "distribute" (and what part you are
specifically referring to). There's no tarball, but the installer
sources are on git.postgresql.org.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Feb 17, 2011 at 4:50 AM, Jason Earl <jearl@notengoamigos.org> wrote: > This will be a significant advantage for > further free software development, and some projects will decide > to make software free in order to use these libraries. You've misread this paragraph. Postgres is already free (except for the OpenSSL restrictions). Even by these people's definitions you don't need to use the GPL to be free. -- greg
On Thu, Feb 17, 2011 at 3:39 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Greg Stark (gsstark@mit.edu) wrote:
>> Well for what it's worth we want to support both. At least the project
>> philosophy has been that commercial derivatives are expected and
>> acceptable so things like EDB's products, or Greenplums, or for that
>> matter Pokertracker's all include other proprietary source that of
>> course has restrictive licenses ("OpenSSL-type-licensed" except even
>> *more* restrictive).
>
> This is a bit backwards, I think.. What you're suggesting is that, some
> day, we might want community/BSD-licensed PG to link against
> commercially licensed products from EDB for basic functionality (eg:
> encryption)?
>
No. Firstly we're not talking about linking -- linking is just a
technical step and the law is much fuzzier and general than that. When
you build a binary it's a "derivative work" of all the components that
went into building that binary whether they were linked in or not.
This includes the macros in the header files that were used, the
parser code from bison, etc.
Secondly I'm not talking about how what software is in the community
licensed PG. We have always said in the past that we want Postgres to
be usable by other people to embed in their commercially licensed
software and that means that the license has to allow not just
redistributing Postgres but redistributing it under more restrictive
licenses.
--
greg
On Thu, Feb 17, 2011 at 11:49, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake <jd@commandprompt.com> wrote:
>>> On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
>>>> Stephen Frost wrote:
>>>> -- Start of PGP signed section.
>>>> > * Greg Stark (gsstark@mit.edu) wrote:
>>>> > > Well for what it's worth we want to support both. At least the project
>>>> > > philosophy has been that commercial derivatives are expected and
>>>> > > acceptable so things like EDB's products, or Greenplums, or for that
>>>> > > matter Pokertracker's all include other proprietary source that of
>>>> > > course has restrictive licenses ("OpenSSL-type-licensed" except even
>>>> > > *more* restrictive).
>>>> >
>>>> > This is a bit backwards, I think.. What you're suggesting is that, some
>>>> > day, we might want community/BSD-licensed PG to link against
>>>> > commercially licensed products from EDB for basic functionality (eg:
>>>> > encryption)?
>>>> >
>>>> > I agree that we want to reduce and eliminate, to the extent possible,
>>>> > our dependence on GPL or OpenSSL-type-licensed libraries. It's
>>>> > unfortunate that there isn't a good non-GPL option for libreadline, but
>>>> > I'm not sure what EDB or anyone else would expect the PG community to
>>>> > do regarding that. Should PG remove support for libreadline? Should
>>>> > the PG community make libedit a good BSD-licensed alternative to
>>>> > libreadline? Neither of those really make sense to me.
>>>>
>>>> What are our click-installers doing now?
>>>
>>> Probably readline but does it matter? We distribute the source to the
>>> click installers.
>>
>> Actually, we don't. We used to, but we don't at this point.
>
> Depends on your definition of "distribute" (and what part you are
> specifically referring to). There's no tarball, but the installer
> sources are on git.postgresql.org.
Oh, my bad - they're back. I was referring to our discussion a couple
of weeks back (I think), when you said that was too much work :-P
My apologies.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Feb 17, 2011 at 11:49, Dave Page <dpage@pgadmin.org> wrote: >> Depends on your definition of "distribute" (and what part you are >> specifically referring to). There's no tarball, but the installer >> sources are on git.postgresql.org. > > Oh, my bad - they're back. I was referring to our discussion a couple > of weeks back (I think), when you said that was too much work :-P For the record, it wasn't keeping the PG installer source code public that was too much work, it was cleaning out some of the unrelated code from other installers. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave Page wrote: > On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander <magnus@hagander.net> wrote: > > On Thu, Feb 17, 2011 at 11:49, Dave Page <dpage@pgadmin.org> wrote: > >> Depends on your definition of "distribute" (and what part you are > >> specifically referring to). There's no tarball, but the installer > >> sources are on git.postgresql.org. > > > > Oh, my bad - they're back. I was referring to our discussion a couple > > of weeks back (I think), when you said that was too much work :-P > > For the record, it wasn't keeping the PG installer source code public > that was too much work, it was cleaning out some of the unrelated code > from other installers. Well, we are going down a slippery slope if we think the click-through installers are OK to use readline and distribute because we supply the source for the installers --- that then requires anyone using the binaries (or libraries) in those installers to also supply the source code, e.g. GPL. :-( I am not saying they have to, but falling back to the "oh we give source code for the click-through installers" is not a position we can fall back on without affecting our users. Also, I think part of the problem for Debian is that they distribute readline and Postgres because they are the operating system vendor. I don't think the "use the OS library if already present" interpretation of the GPL really thought about that case. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > Joshua D. Drake wrote: > > > Probably readline but does it matter? We distribute the source to the > > > click installers. > > > > Well, there is what the community is risking, and there is what the > > packagers are risking. Ideally we would make the job easier for the > > packagers too, though we don't have to. > > I'm really mystified by this. If the source is available for the > installers, what's the risk that you're worried about..? For the > community or the packagers? I just posted on this. The risk is to people using the packages --- the packages themselves include the source as an option, so they are fine, but everyone using those packages would also be required to distribute source, which is a restriction we have avoided in the past. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
* Bruce Momjian (bruce@momjian.us) wrote:
> Well, we are going down a slippery slope if we think the click-through
> installers are OK to use readline and distribute because we supply the
> source for the installers --- that then requires anyone using the
> binaries (or libraries) in those installers to also supply the source
> code, e.g. GPL.
If they build binaries which include the GPL'd readline, then there's a
(potential) issue, sure. I'm not sure what system you're looking at,
but readline isn't linked in by libpq today and I can't imagine it ever
being linked to it.
If they're using the binaries which the community provides, I really
don't believe there's any issue. It's possible someone would ask for
the source code for that psql binary, but that shouldn't/wouldn't be
hard for them to produce for the community psql.
If they're building their own binaries of psql which they've modified
*and* have linked in with readline, then they've put themselves into a
position where FSF or someone could complain. I'd recommend they not do
that, so as to avoid the issue.
> :-( I am not saying they have to, but falling back to
> the "oh we give source code for the click-through installers" is not a
> position we can fall back on without affecting our users.
I really don't follow the logic here. Are you suggesting that people
take psql and *embed* it into their own binaries?
If there's really that much concern over it, presumably the installers
could be built w/o readline support.
That'd probably be more comfortable for me anyway, since then psql on
Windows would behave like every other Windows app. ;) (j/k..)
> Also, I think part of the problem for Debian is that they distribute
> readline and Postgres because they are the operating system vendor. I
> don't think the "use the OS library if already present" interpretation
> of the GPL really thought about that case.
I don't think this really plays into this whole thing at all, but my
understanding is that Debian intentionally doesn't use that clause
because it's vague.
Thanks,
Stephen
* Bruce Momjian (bruce@momjian.us) wrote:
> I just posted on this. The risk is to people using the packages --- the
> packages themselves include the source as an option, so they are fine,
> but everyone using those packages would also be required to distribute
> source, which is a restriction we have avoided in the past.
I think you may want to reread the GPL on this. They're not actually
required to distribute source *with* the binaries (hell, Debian
doesn't..) as long as they are willing to produce it if asked. And
that's the source for the binaries which actually depend on the GPL'd
code, eg, the community-built psql binary that you're talking about
here.. They don't have to provide source for everything on the CD or
something (again, Debian has a "non-free" section also..).
Thanks,
Stephen
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > Well, we are going down a slippery slope if we think the click-through > > installers are OK to use readline and distribute because we supply the > > source for the installers --- that then requires anyone using the > > binaries (or libraries) in those installers to also supply the source > > code, e.g. GPL. > > If they build binaries which include the GPL'd readline, then there's a > (potential) issue, sure. I'm not sure what system you're looking at, > but readline isn't linked in by libpq today and I can't imagine it ever > being linked to it. It is true that readline is not linked to libpq, but that muddies the waters. Notice that Dave said the source to Postgres is distributed, not that psql source is distributed, meaning he didn't make the distinction between psql and the complete source, and most users aren't going to understand that distinction. > If they're using the binaries which the community provides, I really > don't believe there's any issue. It's possible someone would ask for > the source code for that psql binary, but that shouldn't/wouldn't be > hard for them to produce for the community psql. > > If they're building their own binaries of psql which they've modified > *and* have linked in with readline, then they've put themselves into a > position where FSF or someone could complain. I'd recommend they not do > that, so as to avoid the issue. True. I just hate to have anything in a packaged distribution that has any GPL requirement, even if it is a binary that no one can link to. Call me paranoid, but I see it as marketing confusion for us. > > :-( I am not saying they have to, but falling back to > > the "oh we give source code for the click-through installers" is not a > > position we can fall back on without affecting our users. > > I really don't follow the logic here. Are you suggesting that people > take psql and *embed* it into their own binaries? > > If there's really that much concern over it, presumably the installers > could be built w/o readline support. > > That'd probably be more comfortable for me anyway, since then psql on > Windows would behave like every other Windows app. ;) (j/k..) psql used to use the native Windows line editing ability --- has that changed? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > I just posted on this. The risk is to people using the packages --- the > > packages themselves include the source as an option, so they are fine, > > but everyone using those packages would also be required to distribute > > source, which is a restriction we have avoided in the past. > > I think you may want to reread the GPL on this. They're not actually > required to distribute source *with* the binaries (hell, Debian > doesn't..) as long as they are willing to produce it if asked. And > that's the source for the binaries which actually depend on the GPL'd > code, eg, the community-built psql binary that you're talking about > here.. They don't have to provide source for everything on the CD or > something (again, Debian has a "non-free" section also..). Yes, I understand very well the source does not have to be with the binary. I am trying to avoid that non-BSD-licensed section in our installers. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
* Bruce Momjian (bruce@momjian.us) wrote:
> psql used to use the native Windows line editing ability --- has that
> changed?
*that* I couldn't tell you..
Thanks,
Stephen
On 02/17/2011 11:22 AM, Bruce Momjian wrote: > psql used to use the native Windows line editing ability --- has that > changed? When did it? Ad what "native" windows line editing ability are you referring to? cheers andrew
Andrew Dunstan wrote: > > > On 02/17/2011 11:22 AM, Bruce Momjian wrote: > > psql used to use the native Windows line editing ability --- has that > > changed? > > > When did it? Ad what "native" windows line editing ability are you > referring to? There is native Windows editing like arrows, etc and history, though the history is not kept between sessions. If windows is now using readline, then odds are we are shipping libreadline to make that happen, and we are then linking using a supplied GPL library (and we don't have the OS-installed exception). I hope I am wrong. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 02/17/2011 11:44 AM, Bruce Momjian wrote: > Andrew Dunstan wrote: >> >> On 02/17/2011 11:22 AM, Bruce Momjian wrote: >>> psql used to use the native Windows line editing ability --- has that >>> changed? >> >> When did it? Ad what "native" windows line editing ability are you >> referring to? > There is native Windows editing like arrows, etc and history, though the > history is not kept between sessions. If windows is now using readline, > then odds are we are shipping libreadline to make that happen, and we > are then linking using a supplied GPL library (and we don't have the > OS-installed exception). I hope I am wrong. Readline has always been disabled on Windows builds AFAIK. Just look at the buildfarm traces. Here's an example from <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouth&dt=2011-02-17%2015%3A30%3A03&stg=configure> configure: WARNING: *** Readline does not work on MinGW --- disabling It's not used in MSVC either, IIRC. cheers andrew
Andrew Dunstan wrote: > > > On 02/17/2011 11:44 AM, Bruce Momjian wrote: > > Andrew Dunstan wrote: > >> > >> On 02/17/2011 11:22 AM, Bruce Momjian wrote: > >>> psql used to use the native Windows line editing ability --- has that > >>> changed? > >> > >> When did it? Ad what "native" windows line editing ability are you > >> referring to? > > There is native Windows editing like arrows, etc and history, though the > > history is not kept between sessions. If windows is now using readline, > > then odds are we are shipping libreadline to make that happen, and we > > are then linking using a supplied GPL library (and we don't have the > > OS-installed exception). I hope I am wrong. > > > Readline has always been disabled on Windows builds AFAIK. Just look at > the buildfarm traces. Here's an example from > <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouth&dt=2011-02-17%2015%3A30%3A03&stg=configure> > > configure: WARNING: *** Readline does not work on MinGW --- disabling > > > It's not used in MSVC either, IIRC. OK, I was only responding to Stephen Frost who said psql did not behave like other Windows apps. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 02/17/2011 11:58 AM, Bruce Momjian wrote: > Andrew Dunstan wrote: >> >> On 02/17/2011 11:44 AM, Bruce Momjian wrote: >>> Andrew Dunstan wrote: >>>> On 02/17/2011 11:22 AM, Bruce Momjian wrote: >>>>> psql used to use the native Windows line editing ability --- has that >>>>> changed? >>>> When did it? Ad what "native" windows line editing ability are you >>>> referring to? >>> There is native Windows editing like arrows, etc and history, though the >>> history is not kept between sessions. If windows is now using readline, >>> then odds are we are shipping libreadline to make that happen, and we >>> are then linking using a supplied GPL library (and we don't have the >>> OS-installed exception). I hope I am wrong. >> >> Readline has always been disabled on Windows builds AFAIK. Just look at >> the buildfarm traces. Here's an example from >> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouth&dt=2011-02-17%2015%3A30%3A03&stg=configure> >> >> configure: WARNING: *** Readline does not work on MinGW --- disabling >> >> >> It's not used in MSVC either, IIRC. > > OK, I was only responding to Stephen Frost who said psql did not behave > like other Windows apps. I think both of you have possibly been under a misapprehension. All this discussion about the Windows installers is entirely irrelevant to this thread, ISTM, since there is no readline use in them. FWIW, the only interactively usable version of psql for windows I know of is the one that runs under Cygwin. It can be build with readline and works as expected. cheers andrew
Andrew Dunstan wrote: > > > On 02/17/2011 11:58 AM, Bruce Momjian wrote: > > Andrew Dunstan wrote: > >> > >> On 02/17/2011 11:44 AM, Bruce Momjian wrote: > >>> Andrew Dunstan wrote: > >>>> On 02/17/2011 11:22 AM, Bruce Momjian wrote: > >>>>> psql used to use the native Windows line editing ability --- has that > >>>>> changed? > >>>> When did it? Ad what "native" windows line editing ability are you > >>>> referring to? > >>> There is native Windows editing like arrows, etc and history, though the > >>> history is not kept between sessions. If windows is now using readline, > >>> then odds are we are shipping libreadline to make that happen, and we > >>> are then linking using a supplied GPL library (and we don't have the > >>> OS-installed exception). I hope I am wrong. > >> > >> Readline has always been disabled on Windows builds AFAIK. Just look at > >> the buildfarm traces. Here's an example from > >> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouth&dt=2011-02-17%2015%3A30%3A03&stg=configure> > >> > >> configure: WARNING: *** Readline does not work on MinGW --- disabling > >> > >> > >> It's not used in MSVC either, IIRC. > > > > OK, I was only responding to Stephen Frost who said psql did not behave > > like other Windows apps. > > I think both of you have possibly been under a misapprehension. All this > discussion about the Windows installers is entirely irrelevant to this > thread, ISTM, since there is no readline use in them. OK, that's what I thought. > FWIW, the only interactively usable version of psql for windows I know > of is the one that runs under Cygwin. It can be build with readline and > works as expected. Uh, don't we have a psql built via MSVC? Doesn't it work interactively? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
* Bruce Momjian (bruce@momjian.us) wrote:
> OK, I was only responding to Stephen Frost who said psql did not behave
> like other Windows apps.
I don't actually run psql or PG on Windows at all, I just presumed it
did since you were bringing up concerns about it in the Windows
installers. Ah well, sorry for the confusion. :)
Thanks,
Stephen
On 02/17/2011 12:13 PM, Bruce Momjian wrote: > >> FWIW, the only interactively usable version of psql for windows I know >> of is the one that runs under Cygwin. It can be build with readline and >> works as expected. > Uh, don't we have a psql built via MSVC? Doesn't it work interactively? Not if you want readline. And in my book that's a requirement of a psql that's usable interactively. It's pretty horrible to use without it. cheers andrew
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > I just posted on this. The risk is to people using the packages --- the > > packages themselves include the source as an option, so they are fine, > > but everyone using those packages would also be required to distribute > > source, which is a restriction we have avoided in the past. > > I think you may want to reread the GPL on this. They're not actually > required to distribute source *with* the binaries (hell, Debian > doesn't..) as long as they are willing to produce it if asked. And > that's the source for the binaries which actually depend on the GPL'd > code, eg, the community-built psql binary that you're talking about > here.. They don't have to provide source for everything on the CD or > something (again, Debian has a "non-free" section also..). In summary, our click-through installers and hopefully other packaged versions of Postgres don't distribute libreadline and rely on the OS-supplied version, which is a FSF exception. As I mentioned, distributing the installer source doesn't exempt others from having to GPL when they add to it (again, kind of rare because you can't link something to psql, but anyway, it is mostly perception). Debian distributes both Postgres and libreadline, so my guess is they don't think they can use that exception and therefore have a problem. And, again, libedit is not as hard as many of the problems we have solved. Since we have grown strong, I would love to see us reaching out to those satellite communities and helping them solve some of their problems, though, as people pointed out, in a way that does not take energy away from Postgres development. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Andrew Dunstan wrote: > > > On 02/17/2011 12:13 PM, Bruce Momjian wrote: > > > >> FWIW, the only interactively usable version of psql for windows I know > >> of is the one that runs under Cygwin. It can be build with readline and > >> works as expected. > > Uh, don't we have a psql built via MSVC? Doesn't it work interactively? > > > Not if you want readline. And in my book that's a requirement of a psql > that's usable interactively. It's pretty horrible to use without it. Well, as horrible as other Windows apps. I will leave others to decide if that is usable. ;-) I am unclear if we would ship readline support on Windows even if we didn't have a license issue (no OS readline version on Windows). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, 2011-02-17 at 10:49 +0000, Dave Page wrote: > On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander <magnus@hagander.net> wrote: > >> Probably readline but does it matter? We distribute the source to the > >> click installers. > > > > Actually, we don't. We used to, but we don't at this point. > > Depends on your definition of "distribute" (and what part you are > specifically referring to). There's no tarball, but the installer > sources are on git.postgresql.org. Right, and that qualifies. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 02/17/2011 12:34 PM, Bruce Momjian wrote: > Andrew Dunstan wrote: >> >> On 02/17/2011 12:13 PM, Bruce Momjian wrote: >>>> FWIW, the only interactively usable version of psql for windows I know >>>> of is the one that runs under Cygwin. It can be build with readline and >>>> works as expected. >>> Uh, don't we have a psql built via MSVC? Doesn't it work interactively? >> >> Not if you want readline. And in my book that's a requirement of a psql >> that's usable interactively. It's pretty horrible to use without it. > Well, as horrible as other Windows apps. I will leave others to decide > if that is usable. ;-) I am unclear if we would ship readline support > on Windows even if we didn't have a license issue (no OS readline > version on Windows). > Windows developers almost universally work from GUIs and not using console apps (and that's true of many Unix developers also, particularly those who can't recall a time when X-Windows wasn't almost universally available). Microsoft has de-emphasized console apps for 15 years. So the only people who are likely to be interested in using an enhanced psql on Windows are old Unix-heads like you and me. It's not worth a lot of effort, IMNSHO. cheers andrew
On Wed, Feb 16, 2011 at 04:33:19PM -0800, Joshua D. Drake wrote: > Maybe we really should consider moving to NSS insread? > > http://www.mozilla.org/projects/security/pki/nss/ > > If it solves the license problem, it is well supported etc.. For the record, which library you choose only matters for a fairly small (and easy) part of the patch. Changing libpq to be SSL library agnostic is more work. For the people who aren't following, the issue is there are libraries out there that use libpq to setup the connection to the postgres server (so handing all authentication, et al) and then stealing the FD and implementing the rest of the protocol themselves. This is supported. Where it goes wonky is that this also has to work when the connection is via SSL. So libpq provides a function to return (via a void*) a pointer to the OpenSSL structure so that can be used to communicate with the server. As you can imagine, unless the library you use is *binary* compatable with OpenSSL, you're kinda stuck. The idea I suggested way back was to introduce a passthrough mode which would hide all the connection details within libpq, simplifying the code on both sides. Then after a few releases you could remove the old code and change the SSL library at leasure. I guess the painless option however is no longer available. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
> On 02/17/2011 12:34 PM, Bruce Momjian wrote: > > Andrew Dunstan wrote: > >> > >> On 02/17/2011 12:13 PM, Bruce Momjian wrote: > >>>> FWIW, the only interactively usable version of psql for windows I know > >>>> of is the one that runs under Cygwin. It can be build with readline and > >>>> works as expected. > >>> Uh, don't we have a psql built via MSVC? Doesn't it work interactively? > >> > >> Not if you want readline. And in my book that's a requirement of a psql > >> that's usable interactively. It's pretty horrible to use without it. > > Well, as horrible as other Windows apps. I will leave others to decide > > if that is usable. ;-) I am unclear if we would ship readline support > > on Windows even if we didn't have a license issue (no OS readline > > version on Windows). > > > > Windows developers almost universally work from GUIs and not using > console apps (and that's true of many Unix developers also, particularly > those who can't recall a time when X-Windows wasn't almost universally > available). Microsoft has de-emphasized console apps for 15 years. So > the only people who are likely to be interested in using an enhanced > psql on Windows are old Unix-heads like you and me. It's not worth a lot > of effort, IMNSHO. > > cheers > > andrew > I think this is wrong... There are plenty of people who use the command line in Windows, and Microsoft has been adding bettersupport for this, including PowerShell and interfaces to every administrative operation from command line scripts. Psql on Windows is ugly... Readline does (supposedly) run on Windows, but no one has done the work to get it to happen. One of the problems with libedit is that it does not support Windows, as far as I know. I don't know of a good solution, given the license for readline. But it would sure be nice.
On Fri, Feb 18, 2011 at 02:01, <Charles.McDevitt@emc.com> wrote: >> On 02/17/2011 12:34 PM, Bruce Momjian wrote: >> > Andrew Dunstan wrote: >> >> >> >> On 02/17/2011 12:13 PM, Bruce Momjian wrote: >> >>>> FWIW, the only interactively usable version of psql for windows I know >> >>>> of is the one that runs under Cygwin. It can be build with readline and >> >>>> works as expected. >> >>> Uh, don't we have a psql built via MSVC? Doesn't it work interactively? >> >> >> >> Not if you want readline. And in my book that's a requirement of a psql >> >> that's usable interactively. It's pretty horrible to use without it. >> > Well, as horrible as other Windows apps. I will leave others to decide >> > if that is usable. ;-) I am unclear if we would ship readline support >> > on Windows even if we didn't have a license issue (no OS readline >> > version on Windows). >> > >> >> Windows developers almost universally work from GUIs and not using >> console apps (and that's true of many Unix developers also, particularly >> those who can't recall a time when X-Windows wasn't almost universally >> available). Microsoft has de-emphasized console apps for 15 years. So >> the only people who are likely to be interested in using an enhanced >> psql on Windows are old Unix-heads like you and me. It's not worth a lot >> of effort, IMNSHO. >> >> cheers >> >> andrew >> > > I think this is wrong... There are plenty of people who use the command line in Windows, and Microsoft has been addingbetter support for this, including PowerShell and interfaces to every administrative operation from command line scripts. While I haven't used the latest version of powershell, my experience has always been that the focus has really been on scripts and not necessarily the interactive experience. > Psql on Windows is ugly... Readline does (supposedly) run on Windows, but no one has done the work to get it to happen. Readline does not run on Windows, if you want to use any interesting keys. Such as the alt or alt-gr keys. Basically, readline for windows doesn't work outside of english locales... For example, you can't access any of the backslash commands in many locales, which makes psql a lot less useful... IIRC I even brought this up with the readline folks, and they simply don't give a **** about woe32 as they call it, so there should be no faith in that ever getting fixed. Granted, I haven't checked if they actually fixed it in the past couple of years, but there seemed to be zero interest before that a least. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 02/17/2011 04:09 PM, Martijn van Oosterhout wrote: > On Wed, Feb 16, 2011 at 04:33:19PM -0800, Joshua D. Drake wrote: >> Maybe we really should consider moving to NSS insread? >> >> http://www.mozilla.org/projects/security/pki/nss/ >> >> If it solves the license problem, it is well supported etc.. > For the record, which library you choose only matters for a fairly > small (and easy) part of the patch. Changing libpq to be SSL library > agnostic is more work. > > For the people who aren't following, the issue is there are libraries > out there that use libpq to setup the connection to the postgres server > (so handing all authentication, et al) and then stealing the FD and > implementing the rest of the protocol themselves. > > This is supported. Where it goes wonky is that this also has to work > when the connection is via SSL. So libpq provides a function to return > (via a void*) a pointer to the OpenSSL structure so that can be used to > communicate with the server. Ugh. Maybe not the best design decision we've ever made. > As you can imagine, unless the library you use is *binary* compatable > with OpenSSL, you're kinda stuck. The idea I suggested way back was to > introduce a passthrough mode which would hide all the connection > details within libpq, simplifying the code on both sides. Then after a > few releases you could remove the old code and change the SSL library > at leasure. > > I guess the painless option however is no longer available. > Could we provide an abstraction layer over whatever SSL library is in use with things like read/write/poll? Maybe that's what you had in mind for the passthrough mode. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 02/17/2011 04:09 PM, Martijn van Oosterhout wrote:
>> This is supported. Where it goes wonky is that this also has to work
>> when the connection is via SSL. So libpq provides a function to return
>> (via a void*) a pointer to the OpenSSL structure so that can be used to
>> communicate with the server.
> Ugh. Maybe not the best design decision we've ever made.
libpq-fe.h is pretty clear on this matter:
/* Get the OpenSSL structure associated with a connection. Returns NULL for* unencrypted connections or if any other
TLSlibrary is in use. */
extern void *PQgetssl(PGconn *conn);
We are under no compulsion to emulate OpenSSL if we switch to another
library. The design intent is that we'd provide a separate function
(PQgetnss?) and callers that know how to use that library would call
that function. If they don't, it's not our problem.
regards, tom lane
On Fri, Feb 18, 2011 at 16:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 02/17/2011 04:09 PM, Martijn van Oosterhout wrote: >>> This is supported. Where it goes wonky is that this also has to work >>> when the connection is via SSL. So libpq provides a function to return >>> (via a void*) a pointer to the OpenSSL structure so that can be used to >>> communicate with the server. > >> Ugh. Maybe not the best design decision we've ever made. > > libpq-fe.h is pretty clear on this matter: > > /* Get the OpenSSL structure associated with a connection. Returns NULL for > * unencrypted connections or if any other TLS library is in use. */ > extern void *PQgetssl(PGconn *conn); > > We are under no compulsion to emulate OpenSSL if we switch to another > library. The design intent is that we'd provide a separate function > (PQgetnss?) and callers that know how to use that library would call > that function. If they don't, it's not our problem. Yeah, the only issue there is that it should perhaps have been called PQgetopenssl(). We did that right for PQinitOpenSSL(). But then not for PQinitSSL(). So we aren't exactly consistent.. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > On 02/17/2011 04:09 PM, Martijn van Oosterhout wrote: > >> This is supported. Where it goes wonky is that this also has to work > >> when the connection is via SSL. So libpq provides a function to return > >> (via a void*) a pointer to the OpenSSL structure so that can be used to > >> communicate with the server. > > > Ugh. Maybe not the best design decision we've ever made. > > libpq-fe.h is pretty clear on this matter: > > /* Get the OpenSSL structure associated with a connection. Returns NULL for > * unencrypted connections or if any other TLS library is in use. */ > extern void *PQgetssl(PGconn *conn); > > We are under no compulsion to emulate OpenSSL if we switch to another > library. The design intent is that we'd provide a separate function > (PQgetnss?) and callers that know how to use that library would call > that function. If they don't, it's not our problem. Who uses this? ODBC? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Feb 18, 2011 at 02:35:42PM -0500, Bruce Momjian wrote: > > /* Get the OpenSSL structure associated with a connection. Returns NULL for > > * unencrypted connections or if any other TLS library is in use. */ > > extern void *PQgetssl(PGconn *conn); > > > > We are under no compulsion to emulate OpenSSL if we switch to another > > library. The design intent is that we'd provide a separate function > > (PQgetnss?) and callers that know how to use that library would call > > that function. If they don't, it's not our problem. > > Who uses this? ODBC? There's a few users, that I can find anyway. psql is one. It uses this to get information about the connection, pgadmin does it also for a similar reasons I guess. Adding a seperate function for each SSL library seems odd. It would mean that psql would need the headers to every possible SSL library because it (in theory) doesn't know which library might be used at runtime. ODBC uses it as well. It really uses it for communication. As far as Google Code Search can it's the only one that does. But if the intention is to do it by adding new functions, we can and let the ODBC guys sort it out (ERROR: Using incompatable SSL connection). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
On Sat, Feb 19, 2011 at 07:42:20PM +0100, Martijn van Oosterhout wrote: > ODBC uses it as well. It really uses it for communication. As far as > Google Code Search can it's the only one that does. > > But if the intention is to do it by adding new functions, we can and > let the ODBC guys sort it out (ERROR: Using incompatable SSL > connection). Actually, it would just break. There is currently no way to distinguish between no-SSL and not-OpenSSL, so ODBC would use PQgetssl() to determine the SSL status, get NULL and assume there is no SSL active, and subsequently break when trying to communicate via the sockets. Frankly I think that this "solution" doesn't meet the usual high standards of this project... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
On 02/19/2011 01:42 PM, Martijn van Oosterhout wrote: > On Fri, Feb 18, 2011 at 02:35:42PM -0500, Bruce Momjian wrote: >>> /* Get the OpenSSL structure associated with a connection. Returns NULL for >>> * unencrypted connections or if any other TLS library is in use. */ >>> extern void *PQgetssl(PGconn *conn); >>> >>> We are under no compulsion to emulate OpenSSL if we switch to another >>> library. The design intent is that we'd provide a separate function >>> (PQgetnss?) and callers that know how to use that library would call >>> that function. If they don't, it's not our problem. >> Who uses this? ODBC? > There's a few users, that I can find anyway. psql is one. It uses this > to get information about the connection, pgadmin does it also for a > similar reasons I guess. > > Adding a seperate function for each SSL library seems odd. It would > mean that psql would need the headers to every possible SSL library > because it (in theory) doesn't know which library might be used at > runtime. I don't see why. If you plug in a libpq that was compiled against, say, NSS under a psql that's expecting OpenSSL you'll get a null back instead of a pointer to an SSL object, but then that would be a silly thing to do. > ODBC uses it as well. It really uses it for communication. As far as > Google Code Search can it's the only one that does. > > But if the intention is to do it by adding new functions, we can and > let the ODBC guys sort it out (ERROR: Using incompatable SSL > connection). > > Yeah. It might make sense to have a library function that tells the client what SSL library is being used. cheers andrew
On Fri, Feb 18, 2011 at 10:42:20AM -0500, Andrew Dunstan wrote:
> Could we provide an abstraction layer over whatever SSL library is in
> use with things like read/write/poll? Maybe that's what you had in mind
> for the passthrough mode.
The suggested interface was as follows. It basically exposes the
read/write interface that libpq itself uses. Whether its enough for all
uses I don't know, but it was extensible.
From the patch:
+ /* Get data about current TLS connection */
+ extern PGresult *PQgettlsinfo(PGconn *conn);
+ /* Tell libpq whether it needs to initialize OpenSSL */ extern void PQinitSSL(int do_init);
+ /* Tell libpq we're taking over the connection. After this, no normal
+ * queries may be sent anymore. When finished you may close the connection */
+ typedef PostgresPollingStatusType (*pq_read_func)( PGconn *conn, void *buf, int *len);
+ typedef PostgresPollingStatusType (*pq_write_func)( PGconn *conn, const void *buf, int *len);
+ typedef int (*pq_pending_func)( PGconn *conn );
+
+ typedef struct {
+ int len; /* Length of this structure, so users may determine if the
+ info they require is there. For backward compatability,
+ new members can only be added to the end. */
+ pq_read_func read;
+ pq_write_func write;
+ pq_pending_func pending;
+
+ /* char *ssllibname; Need not yet demonstrated. */
+ /* void *sslptr; */
+ } PQpassthrough;
+
+ /* The pointer returned in state must be freed with PQfreemem() */
+ extern int PQsetPassthrough(PGconn *conn, PQpassthrough **state );
+
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle
On lör, 2011-02-19 at 13:55 -0500, Andrew Dunstan wrote: > If you plug in a libpq that was compiled against, say, > NSS under a psql that's expecting OpenSSL you'll get a null back > instead of a pointer to an SSL object, but then that would be a silly > thing to do. Not so silly if you consider partial upgrades.