Re: [OT] MySQL is bad, but THIS bad?

> 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.

This is not technically true. If you incorporate GPL code that is
publically available and unchanged, you needn't provide the 3rd party
packages.

>
> 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.

This is sort of a disputable position, and RMS himself isn't clear. If the
header files are simply definitions and declarations, then no GPL material
is actually included in a binary. However, inline functions and macros may
constitute code.

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

> 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.

There is no supporting argument for that, however, RMS supporting writings
indicate that he defines "derived" as being in the same process space.

>
> 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?

I have talked to too many lawyers, sigh, aout this stuff.

>
> 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.
>