A derivative work of PostGIS would be a fork or patches to PostGIS (i.e, a set database extensions for geographic/spatial queries). A mapping application that used PostGIS is not a derivative work of PostGIS, in the same way that a C program linked against glibc is not a derivative work of glibc.
At least, that's my layperson's understanding of it.
> in the same way that a C program linked against glibc is not a derivative work of glibc
I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.
Legally people can't decide which form of linkage count as deriving and if the linkage form even matter, but static linking with LTO is most times seen as causing a derivative to be produced.
You're conflating "talking to a server over a socket" with "linking to a library".
The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work. (Another case that doesn't is fork/exec of a separate program.)
The latter, linking a library, is why the distinction between the GPL and LGPL exists. As a general rule, if you link to a GPLed library, you do need to provide your source under a GPL-compatible license. (glibc is LGPLed.)
But people wouldn't use PostGIS by linking to a library, they'd use it by talking to a server.
> The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work.
Could you point me in the direction of a court ruling establishing this general rule? I couldn't find anything after a quick search.
You didn't mention this part of the GPL FAQ (directly after the part you talked about):
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation: what's a "complex internal data structure"? If PostGIS is serialising its (presumably complex) representations of data and sending them over a socket to your program (and vice versa), then does that count?
I think it's also worth noting that "derivative work" is an established legal term; if it comes to a lawsuit, it's probably more likely that the judge will fall back on established precedent on what constitutes a derivative work and enforce the literal terms of the license as opposed to looking at FAQs written by someone who is not a party to the contract.
> I think it's also worth noting that "derivative work" is an established legal term
The last case I could find that substantially attacks the question of what constitutes a "derivative work" in the case of software was in 1994 (!), and I can't find any case that tries to answer it in the case of software libraries (whose only purpose is to be used in larger works). There are tests for determining "derivative work", but a) minor circuit split there and b) they're difficult to apply. In the context of what we're talking about here, it is not an established legal term. In such cases, courts are going to lean more heavily on consensus interpretation.
There's a not-well-understood interplay here between the rights of authors to control derivative works; extending analogies copyrightable and non-copyrightable elements of literary works (well-established) to software (far less so); fair use; and general contract principles (specifically, selling a product confers necessary rights to use it). Our current legal understanding of the situation is almost entirely based on an informal consensus rather than any case law, and there is wide potential for a single oddball case completely wrecking everything... like Google v Oracle.
> Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation
I read that generally as suggesting a mens rea approach: if you're building IPC in such a way as to specifically avoid meeting license obligations, you should be considered in violation. If instead you're using it in a more well-defined and sanctioned API boundary, you're probably okay.
Courts also generally consider things like long-standing precedent and decades of industry practice, as well as estoppel. It's a practice that everyone in an industry has done for decades, which matches the general consensus understanding throughout the FOSS developer community, in addition to being the interpretation of the authors of the license.
As I understand it, the rationale for that FAQ entry was that a blanket statement that communication over a socket never creates a derivative work would allow for things like "what if we built a stub that just moves a shared library out-of-process and copies memory back and forth over a socket", or other similar tricks.
Of course, if Oracle v. Google holds as case law (which we'll find out any month now), then the software world turns upside-down and inside-out, and much of the industry will have cases against each other over "API copyrights"; in that world, I have no idea where this would fall.
A program using PostGIS via TCP is no more a derivative work of PostGIS than a program storing data in its underlying database is derived from PostgreSQL.
I can't imagine the tortuous logic one would need to arrive at a different conclusion.
From a legal perspective I'm unaware of any ruling which establishes a difference between components communicating via TCP and components communicating through function calls at the ABI level (e.g. linked libraries); the latter is apparently enough to constitute a derivative work (see the LGPL/Linking Exception). There are obvious technical differences, but it's not clear that they should be treated any differently from a legal perspective.
At least, that's my layperson's understanding of it.