Re: TODO: GNU TLS - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: TODO: GNU TLS
Date
Msg-id 20061229155035.GB24675@kenobi.snowman.net
Whole thread Raw
In response to Re: TODO: GNU TLS  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: TODO: GNU TLS
List pgsql-hackers
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 29, 2006 at 09:52:08AM -0500, mark@mark.mielke.cc wrote:
> > We're not talking about including GPL code in OpenSSL, though. This is
> > about OpenSSL as the base library. The GPL cannot stipulate that a GPL
> > program may only be linked against GPL libraries, or used on a GPL
> > operating system, on GPL hardware. For example, if GNU coreutils is
> > compiled for HP-UX. This is "linking against" software that is much
> > more restrictive than the OpenSSL license. Is Stephen, or the people
> > whose opinion he is repeating, going to claim that the FSF considers
> > this an illegal distribution of GNU coreutils?
>
> No, because that falls under the "operating system" exception.
> Additionally, "linking against" is no problem. It's *distributing* the
> "linked against" version that gets you in trouble.
>
> The GPL doesn't care about *use*, only about distribution.

Right, if you actually distributed GNU coreutils *and* HP-UX together as
an application, then, yes, that'd be a violation because of the
additional restrictions put on the result by the HP-UX license.  If you
distributed GNU coreutils by itself but compiled to run on HP-UX systems
then that's *not* a violation because the HP-UX code isn't being
distributed as part of the application, even though it's linked against
on the resultant system.

> > The GPL can only require that any product *derived* from the work
> > licensed with the GPL, only be derived from by products which are
> > themselves GPL.
>
> Correct. Additionally it can require that when you *distribute* that
> compiled GPL program (the compiled version being a derived work of the
> source), you provide the source to all the libraries used while running
> it (barring the operating system exception). It couldn't care less what
> licence is used by those libraries, as long as that licence is
> compatable with the requirements the GPL has of the source (which is
> not that the source must be GPL.

Right.

> > I'm not that stunned that this is confusing to people. There is so much
> > invalid information available, and most of us try to stay away from law
> > as much as possible. It can be overwhelming. :-)
>
> The reason this issue is confusing is because it's nobodies fault.

Yeah. :(  Makes it more frustrating when trying to explain it to people
too..  "It's nothing you did, but..."

> PostgreSQL by itself, no problem. Exim by itself, no problem. OpenSSL,
> by itself, no problem. It's only when Debian want's to *distribute* a
> compiled version of Exim linked against libpq while simultaneously
> complying with all the licences.

(and then having libpq linked against OpenSSL)

> Now Exim has granted an exception that gets Debian off the hook, but
> they didn't have to do that.

Right.  If they didn't then it's conceivable that Exim could sue Debian
for violating the GPL license.  Not exactly likely to happen but being
cautious it's best to get their explicit approval rather than playing
the "well, we'll just wait and see if they sue us" game.

> > > Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much
> > > attention, but anyway, just trying to clarify why *in principle* that
> > > Stephen F is talking about a valid *possible* interpretation of the
> > > licensing maze...
> >
> > *nod*
>
> OpenSSL is a very different beast and one of very very few packages
> with this problem. See my other message.

Yup.  Thankfully...  It'd be quite the headache if there were alot of
cases like this. :/
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dead Space Map for vacuum
Next
From: "Florian G. Pflug"
Date:
Subject: Re: [PATCHES] [BUGS] BUG #2846: inconsistent and