4 ms·

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 u

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.

saagarjha 6y ago
Note that there is a specific exception for that case: https://en.wikipedia.org/wiki/GPL_linking_exception https://en.wikipedia.org/wiki/GPL_linking_exception
p0llard 6y ago
> 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.
- dathinab 6y ago
  My last heads up a fiew years ago was: 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.
rbanffy 6y ago
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.
- p0llard 6y ago
  > PostGIS via TCP 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.
  - dathinab 6y ago
    The LGPL linking exception mainly exist because static linking does modify the included binary in the way it links. At least with LTO enabled.
JoshTriplett 6y ago
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.
- p0llard 6y ago
  > 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.
  - JoshTriplett 6y ago
    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.

saagarjha 6y ago

Note that there is a specific exception for that case: https://en.wikipedia.org/wiki/GPL_linking_exception https://en.wikipedia.org/wiki/GPL_linking_exception

p0llard 6y ago

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

dathinab 6y ago
My last heads up a fiew years ago was: 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.

rbanffy 6y ago

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.

p0llard 6y ago
> PostGIS via TCP 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.
- dathinab 6y ago
  The LGPL linking exception mainly exist because static linking does modify the included binary in the way it links. At least with LTO enabled.

JoshTriplett 6y ago

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.

p0llard 6y ago
> 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.
- JoshTriplett 6y ago
  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.