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: