The two paragraphs above what you quoted are:
"However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program."
"The difference between this and 'incorporating' the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."
Two programs communicating over a socket aren't incorporated. They're two programs.
I'm not super interested in fielding more thin gotchas based on out of context quotes. There's a big difference between a license that's difficult to understand and a license that somehow summons people from the ether who find endless ways to deliberately misunderstand it.
> Two programs communicating over a socket aren't incorporated. They're two programs.
Aren't they? So, if I want to use a GPL library, all I need to do is write a little wrapper program that does RPC over a socket, and boom, I can use a GPL library in my closed source program? Obviously not.
Yep. This is how MySQL/MariaDB work, for example.
The FAQ also has interesting takes, where depending on the jurisdiction you're in, I'm sure such views would differ:
Q: In an object-oriented language such as Java, if I use a class that is GPLed without modifying, and subclass it, in what way does the GPL affect the larger program? (#OOPLang)
A: Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPLed class.
Thats... a really weird and technically inept take on an issue that is not broadly applicable to all object oriented languges, but going with this argument, I'd argue that "subclassing" essentially constitutes just using an interface (in the general sense, not in the Java sense) to some existing software, so in Minio's case, using their API would constitute a similar usage pattern -> my "derivative" work must now be GPL licensed.> I'd argue that "subclassing" essentially constitutes just using an interface (in the general sense, not in the Java sense) to some existing software, so in Minio's case, using their API would constitute a similar usage pattern -> my "derivative" work must now be GPL licensed.
No, again the difference is incorporation. In order to subclass something you have to incorporate it into your code.
What are you on about? The explicit purpose of a license is that it's users do not have to worry about anyone else's "explicit intent". A license needs to be unambigious about it's terms, else it's just not a good license, hence see the discussion in this thread about the meaning of derivative works.
It may very well be that the FSF/RMS/GNU Project had some intent on it's use when creating the GPL/AGPL v3, but a court in another jurisdiction will not care. I have no idea how to get a hold of the FSF when I'm being sued for license violations in europe and even if so, I doubt a court would care about the FSF's interpretation, given that they're likely not a party to the proceedings.
I'm surprised that people on an US centric site believe that intent in US jurisprudence matters, because in a legal system largely based on precedence, it really does not.
> No, again the difference is incorporation. In order to subclass something you have to incorporate it into your code.
You have to do the same thing in order to use API's. I'm sorry, unless I don't understand something here, this doesn't make sense.
Even the most carefully written license has ambiguity, and that's for two reasons. First, we want to cover situations without exhaustively enumerating and describing them in great detail. Statutes and the Constitution run into this all the time, but no one's like "don't start a business in the US, their Constitution is ambiguous and courts have to clarify and interpret it all the time" because courts (except for this one, I'll admit) do things like take reliance interests into account when adjudicating cases. It works well enough in contract law that we've built the most advanced economy in history, so I wouldn't poo-poo it.
Second, and I'll echo Dijkstra here [0] our languages aren't precise. They're bad at the thing you want them to do. Your argument argues against all contracts and licenses everywhere, even laws themselves.
Finally, (A)GPLv3 don't refer to derivative works. That's a GPLv2 thing.
> I'm surprised that people on an US centric site believe that intent in US jurisprudence matters, because in a legal system largely based on precedence, it really does not.
Again, happy to read any case law you can find on this.
> You have to do the same thing in order to use API's. I'm sorry, unless I don't understand something here, this doesn't make sense.
I'm starting to believe people here don't know what linking and incorporate mean. Linking is using a linker--like ld--to build an executable or library. It's not some abstract idea of linkage. Incorporate means pulling the source code into your own. It's not some abstract idea of building a larger system. You don't pull the source code to Minio into your code to use its API.
0: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...