Comment by p0llard | Hacker News Reader

Comment by p0llard | Hacker News Reader

Parent Full thread

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

> Of course, if Oracle v. Google holds as case law (which we'll find out any month now)

The case won't be heard until Oct 7, and I would think a decision unlikely before January.

"any month now" was very much meant as tongue-in-cheek, yes.

Reply on news.ycombinator.com