Re: [OT] MySQL is bad, but THIS bad? - Mailing list pgsql-hackers

On Fri, May 19, 2006 at 07:04:47PM -0400, Bruce Momjian wrote:
> > libreadline is not a problem because you can distribute postgresql
> > compiled with readline and comply with all licences involved
> > simultaneously. It doesn't work with openssl because the licence
> > requires things that are incompatable with the GPL.
>
> My question is whether psql using libreadline.so has to be GPL, meaning
> the psql source has to be included in a binary distribution.

IANAL, but yes. Or any other of the methods allowed, like providing a
written voucher valid for at least three years. People who feel they
need to keep the source to psql secret should link against libeditline
instead.

The way I understand it, the GPL affects programs in two main ways:

1. A program which is GPL'd must, when distributed, be able to provide
all source used to build it under terms compatable with the GPL.

2. A program which includes a GPL'd header file while building, must,
when distributed, provide its own source and the library under GPL
compatable terms, but not necessariliy the source of anything else
needed to build it. This is why it's OK that psql links against openssl
and readline.

These are obviously only relevent when distributing precompiled
binaries. If you are only distributing source, none of the above
applies to you.

There's a third method that some people claim, but I don't buy. This
where a program using an interface of a GPL'd library somehow become a
derived work of said library. That's just way whacked out.

You may ofcourse disagree with any of the above, and hey, if you have a
lawyer to back you up, who am I to argue?

As for why you don't solve the problem by distributing a libpq not
compiled against OpenSSL, well, that's a different question. Back when
SSL was considered an arms exports by the US, having both SSL and
non-SSL versions was common (and a big PITA). When that disappeared,
the main reason for the split went away and people started compiling
SSL by default. This solved the problem for 99% of programs.

However, one tiny subset remains problematic:
- A library implements SSL, but only using OpenSSL
- The library doesn't use the GPL, or doesn't have an OpenSSL exception
clause.
- A GPL'd program uses this library, without an OpenSSL exception
clause.

In this subset of a subset of a subset of programs, it's a problem.
Many libraries that implement SSL provide an alternative to OpenSSL,
many programs using such libraries have exception clauses so that
there's just a handful of programs and libraries that are problematic.

As long as there's a possibility that the situation can change (either
every GPL program using postgresql gains an exception clause, or
postgresql might someday support some other library) it will probably
stay this way.

If the the postgresql core decides that OpenSSL will be the only SSL
ever supported, no matter what, well, the split distribution may yet
happen. In the meantime, we have status quo.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.