Re: 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(at)commandprompt(dot)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(at)dunslane(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So where are we at?

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

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

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

* Greg Smith (greg(at)2ndquadrant(dot)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(at)snowman(dot)net> wrote:
> * Greg Smith (greg(at)2ndquadrant(dot)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(at)hagander(dot)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:
>> -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.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)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 20:09, Greg Smith <greg(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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

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.

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 product as GPL

On Fri, 2011-02-11 at 14:59 -0500, Charles(dot)McDevitt(at)emc(dot)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(at)2ndquadrant(dot)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

Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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

* Charles(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)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(at)gmail(dot)com> writes:
> On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)snowman(dot)net> wrote:
> * Charles(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)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(at)svana(dot)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(at)svana(dot)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(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)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(dot)McDevitt(at)emc(dot)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(at)gmail(dot)com [mailto:gsstark(at)gmail(dot)com] On Behalf Of Greg Stark
> Sent: Friday, February 11, 2011 4:03 PM
> On Fri, Feb 11, 2011 at 11:06 PM, <Charles(dot)McDevitt(at)emc(dot)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(dot)McDevitt(at)emc(dot)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(at)gmail(dot)com [mailto:gsstark(at)gmail(dot)com] On Behalf Of Greg Stark
> Sent: Friday, February 11, 2011 4:14 PM
> To: McDevitt, Charles
> Cc: sfrost(at)snowman(dot)net; alvherre(at)commandprompt(dot)com;
> greg(at)2ndquadrant(dot)com; mbanck(at)debian(dot)org; tgl(at)sss(dot)pgh(dot)pa(dot)us;
> andrew(at)dunslane(dot)net; jd(at)commandprompt(dot)com; pgsql-
> hackers(at)postgresql(dot)org
> Subject: Re: Debian readline/libedit breakage
>
> On Sat, Feb 12, 2011 at 12:07 AM, <Charles(dot)McDevitt(at)emc(dot)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 Public License, version 3."

I know it used to be GPLv2, but that isn't true these days.

* Charles(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)com) wrote:
> > * Charles(dot)McDevitt(at)emc(dot)com (Charles(dot)McDevitt(at)emc(dot)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(dot)McDevitt(at)emc(dot)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 Public License, 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(dot)McDevitt(at)emc(dot)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(at)2ndQuadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)2ndquadrant(dot)fr> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)hagander(dot)net> writes:
> On Sat, Feb 12, 2011 at 22:46, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)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(dot)McDevitt(at)emc(dot)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 with Federal 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

Greg Smith <greg(at)2ndquadrant(dot)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(at)2ndquadrant(dot)fr> wrote:
> Greg Smith <greg(at)2ndquadrant(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)debian(dot)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(at)hagander(dot)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(at)bluegap(dot)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(at)bluegap(dot)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(at)bluegap(dot)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(at)hagander(dot)net>:
> On Mon, Feb 14, 2011 at 13:37, Markus Wanner <markus(at)bluegap(dot)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(at)gunduz(dot)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(at)(dot)

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(at)(dot)

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(at)debian(dot)org> wrote:
> thanks Markus for CC'ing me, I'm not on -hackers(at)(dot)
>
> 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(at)2ndQuadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)2ndquadrant(dot)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(at)bfk(dot)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(at)bfk(dot)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(at)debian(dot)org> wrote:
>> thanks Markus for CC'ing me, I'm not on -hackers(at)(dot)
>>
>> 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(at)kaltenbrunner(dot)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(at)kaltenbrunner(dot)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(at)kaltenbrunner(dot)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(at)gmail(dot)com> writes:
> > On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)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(at)gmail(dot)com> writes:
>>> On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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(at)dunslane(dot)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(at)2ndQuadrant(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)mit(dot)edu> writes:
> On Thu, Feb 17, 2011 at 12:07 AM, Greg Smith <greg(at)2ndquadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Smith <greg(at)2ndquadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)snowman(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)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(at)snowman(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> Joshua D. Drake wrote:
> > > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)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(at)mit(dot)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(at)mit(dot)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(at)mit(dot)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(at)momjian(dot)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(at)mit(dot)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(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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(at)mit(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

* Bruce Momjian (bruce(at)momjian(dot)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

On Wed, Feb 16 2011, Tom Lane wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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's a facility not
generally available elsewhere. Releasing it under the GPL and
limiting its use to free programs gives our community a real
boost. At least one application program is free software today
specifically because 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. 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.
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

Jason,

* Jason Earl (jearl(at)notengoamigos(dot)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 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(at)commandprompt(dot)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(at)mit(dot)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(at)hagander(dot)net> wrote:
> On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake <jd(at)commandprompt(dot)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(at)mit(dot)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(at)notengoamigos(dot)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(at)snowman(dot)net> wrote:
> * Greg Stark (gsstark(at)mit(dot)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(at)pgadmin(dot)org> wrote:
> On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake <jd(at)commandprompt(dot)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(at)mit(dot)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(at)hagander(dot)net> wrote:
> On Thu, Feb 17, 2011 at 11:49, Dave Page <dpage(at)pgadmin(dot)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(at)hagander(dot)net> wrote:
> > On Thu, Feb 17, 2011 at 11:49, Dave Page <dpage(at)pgadmin(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

* Bruce Momjian (bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

* Bruce Momjian (bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

* Bruce Momjian (bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)hagander(dot)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(at)svana(dot)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 better support 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(dot)McDevitt(at)emc(dot)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 adding better 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/