|
|
|
|
|
by p0llard
2147 days 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. |
|
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.