I think the length of this HN discussion is evidence enough that AGPL isn't clear.

In my experience, organizations that use AGPL do so to 1) ward off an active non-paying community with its associated support cost, 2) claim open source to help convince you to buy their software/service, 3) hire skill-vetted programmers, 4) allow third-party security audits, and/or 5) avoid being jaded by someone that can market or host their solution better than they can.

It can also be evidence that HN posters have a poor understanding of GPL licenses. Pretty much all these questions are answered in the FAQ [0]. Your guess is as good as mine as to why people continually post random, uninformed, needlessly conservative takes on them instead of just doing a small amount of reading.

[0]: https://www.gnu.org/licenses/gpl-faq.html

The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only standard described is "like the compiler and the kernel, or like an editor and a shell".

> How do I know whether a particular API usage qualifies as well separated or not?

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.

Sorry but what does "arms length" mean? My software doesn't have arms. Using metaphors full of imagery is cute but essentially meaningless.

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

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

Yep. This is how MySQL/MariaDB work, for example.

What about when running a wasm component in an AGPL host? Can the compiled wasm file be proprietary? They share the same memory space, but the wasm component is not compiled with the host.

Interesting; this sounds to me like linking, but I'd email [email protected] to be sure.

Again, the FAQ says otherwise. #MereAggregation says that this is "normally" the case, but "if the semantics of the communication are intimate enough" two binaries communicating over a socket may still be one program. Whether they are one program is explicitly left as a question for judges to decide.

Here's how that section starts: "An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media.". Are you distributing a lot of apps on CD-ROMs? Have you heard of Linux distributions? Seems like things are fine!

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.

That FAQ covers the GPL, not the AGPL.

If you ctrl-f for AGPL you'll see it's for all of it.

That's the GNU project's interpretation of the license. I don't see how a court couldn't reach a different agreement on what the often discussed "derivative works" section means.

The FAQ also has interesting takes, where depending on the jurisdiction you're in, I'm sure such views would differ:

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)

    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 this essentially 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 derivate work must now be GPL licensed.

I know a lot of this stuff is legally pretty new (though AGPLv3 is almost 17 years old now) and there's not a huge body of case law around it. But--and I'm earnestly asking here--is there case law where courts reach in and modify licenses separate from the authors' explicit intent? It's hard for me to imagine a court doing that, especially with all the reliance interests involved (I use AGPLv3 with the understanding that subclassing requires release, court says no, now my business model is toast).

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

> is there case law where courts reach in and modify licenses separate from the authors' explicit intent

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.

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

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

https://www.gnu.org/licenses/gpl-faq.en.html "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."

I think you can interact with GPL/AGPL and retain your code propietary by:

- Don't modify the AGPL program.

- Run separatly, using docker container, vm etc

- Interact with CLI, REST API, filesystem, database etc

- Keep the AGPL interaction only to your program, non public consumption, minimum the surface of distirbution the code.

- Keep your code non directly interact, such as avoid use node npm dependencies directly, avoid library linking, use api gateway, use thirdparty module.

Github may have it wrong then? Their summary says:

> Permissions of this strongest copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license.

Note the last part: "which include licensed works using a licensed work"

No, GitHub has it exactly right. Ultimately this sort of thing has to be settled in court.

At least in the EU there's some precedent where AGPLv3+ won out, though it was through settlement and not judgement (and it's not super clear how contentious the parties were anyway) [0]

[0]: https://archive.fosdem.org/2021/schedule/event/agplcomplianc...

Yeah I wouldn't rely on their editorializing. It's best to just refer to the FAQ [0], which covers these questions.

[0]: https://www.gnu.org/licenses/gpl-faq.html

"This License explicitly affirms your unlimited permission to run the unmodified Program."

In the Basic permissions of the actual content of the license https://github.com/minio/minio/blob/master/LICENSE

It's not that difficult to parse if you actually read it top to bottom instead of skimming.

You linked a more general FAQ for the GPL. Would you have a more specific quote or link for interactions with AGPL code?

AFAIK, the difference between AGPL is GPL is on what constitutes "distribution"; what constitutes a "derivative" is still the same.

https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html

Thank you!

"In AGPLv3, what counts as 'interacting with [the software] remotely through a computer network?'"

"If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online."

"If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session."

[0]: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...

Thank you!

No it is not clearly spelled out. So I am wondering why you think it is clear. Perhaps you are misunderstanding the problem that is being raised? I’m not sure.

Is it? Doesn't it depend on whether your stack depends on it to function, or if it is standalone that your stack can connect to but doesn't rely on?

Only after people badgered them to remove their claim that anything communicating with Minio gets infected by AGPL immediately. Their compliance page used to claim:

> Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO.

That version has, unfortunately, not been archived at web.archive.org or such.

Some remnants of the old compliance text are still mentioned: https://github.com/minio/operator/issues/2030