* Bruce Momjian (bruce@momjian.us) wrote:
> Well, we are going down a slippery slope if we think the click-through
> installers are OK to use readline and distribute because we supply the
> source for the installers --- that then requires anyone using the
> binaries (or libraries) in those installers to also supply the source
> code, e.g. GPL.
If they build binaries which include the GPL'd readline, then there's a
(potential) issue, sure. I'm not sure what system you're looking at,
but readline isn't linked in by libpq today and I can't imagine it ever
being linked to it.
If they're using the binaries which the community provides, I really
don't believe there's any issue. It's possible someone would ask for
the source code for that psql binary, but that shouldn't/wouldn't be
hard for them to produce for the community psql.
If they're building their own binaries of psql which they've modified
*and* have linked in with readline, then they've put themselves into a
position where FSF or someone could complain. I'd recommend they not do
that, so as to avoid the issue.
> :-( I am not saying they have to, but falling back to
> the "oh we give source code for the click-through installers" is not a
> position we can fall back on without affecting our users.
I really don't follow the logic here. Are you suggesting that people
take psql and *embed* it into their own binaries?
If there's really that much concern over it, presumably the installers
could be built w/o readline support.
That'd probably be more comfortable for me anyway, since then psql on
Windows would behave like every other Windows app. ;) (j/k..)
> Also, I think part of the problem for Debian is that they distribute
> readline and Postgres because they are the operating system vendor. I
> don't think the "use the OS library if already present" interpretation
> of the GPL really thought about that case.
I don't think this really plays into this whole thing at all, but my
understanding is that Debian intentionally doesn't use that clause
because it's vague.
Thanks,
Stephen