PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 22:06 UTC (Wed) by fuhchee (guest, #40059)
Parent article: PostgreSQL, OpenSSL, and the GPL

This LD_PRELOAD hack reminds one of the confusion associated with that
"derived work" term. While the FSF unofficially advises an expansive
definition ("anything that links"), here LD_PRELOAD can allow completely
decoupled distribution of the two pieces of code without any plausible
license-cross-infection claim. That in turn puts that expansive
definition into some doubt.

to post comments

Again: "derived work" is meaningless here.

Posted Feb 18, 2011 6:07 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

While the FSF unofficially advises an expansive definition ("anything that links"), here LD_PRELOAD can allow completely decoupled distribution of the two pieces of code without any plausible license-cross-infection claim.

Yes, of course. Unless you'll include such script in your distribution and make it available by default. You see, GPL is pretty expansive: if forces you to distribute everything derived from GPLed sources to be distributed under GPL terms. Including whole distributions! But there are couple of exceptions: system libraries ("unless that component itself accompanies the executable") and "mere aggregation". Now, of course libedit-linked postgresql is not infringing. But what about distribution which forces usage of readline injected in postgresql client? This very much a grey area. If it's unconditionally injects the readline then it can probably viewed as a clever way to circumvent the GPL requirement. But if it's configurable and user can select one of two choices... then it's more like mere aggregation - but only court can say for sure... and two different courts may decide differently too.

We can argue till we blue in face but because law is squishy there are no resolution till actual court proceeding will occur. We can only estimate probabilities of different outcomes, really.

Again: "derived work" is meaningless here.

Posted Feb 18, 2011 15:14 UTC (Fri) by fuhchee (guest, #40059) [Link] (2 responses)

"You see, GPL is pretty expansive: if forces you to distribute everything derived from GPLed sources to be distributed under GPL terms."

No, that is not the "expansiveness" what I was referring to. It was that the FSF has taught people to think of *linkage* as being an obvious example of *derivation*, despite e.g. Sega v. Accolade.

Sorry, but this is quite different...

Posted Feb 18, 2011 16:28 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Sigh. Sega never distributed anything from Accolade. Accolade never distributed anything from Sega.

There are no doubt that if distribution does not include readline library but includes openssl library you are allowed to link your product with both [system] openssl and [non-system] readline: the whole thing which you are distibuting is most probably not derived (like in Sega v. Accolade case) and, in fact, GPL contains explicit permission for such a case.

Now, if you distribute the single package on a CD which includes both openlssl and readline then there are no doubts that this combination is compilation of both works! You don't even need any linkage for it to be compilation - and while compilations have some additional rules you still need permissions from all authors. GPL gives you two choices: either the whole compilation is distributed under GPL or you can combine totally unrelated things to form it ("mere aggregation" clause).

Sega v. Accolade will be relevant in cases like nVidia driver: where some piece is distributed under GPL, another piece under proprietary license but they are never combined to form the single compilation (except by the end user who has a right to do this and more as long as he does not distribute the result).

So... Close but no cigar.

P.S. It's interesting to note that by your reasoning you actually can include LGPLed (and even GPLed) libraries in distribution and as long is interfaces are not too rich (== don't include tons of non-trivial inlined functions) third-party developers will be allowed to use them. Again: as long as these third-party developments don't come pre-installed. This interpretation may even be correct, but it's not relevant to Debian case.

Sorry, but this is quite different...

Posted Feb 24, 2011 4:16 UTC (Thu) by jjs (guest, #10315) [Link]

GPL2 Para 2:
n addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

You can include anthing you wnat in the compilation, to include proprietary software.