Hacker News Reader

Oh okay, thank you for the explanation. I'll have to read more about the distinction then.

No problem. It's not necessarily your fault -- you have to be careful what you read, because a lot of people seem to have very strongly held opinions about the AGPL that are based on hearsay, not on what the license actually says.

Yes, this seems like a common misconception with the AGPL. You can embed AGPL things within your stack and not have to open source the things that interact with it (or the software/scripts that is used to deploy it, another common misconception).

If you're trying to use the AGPL to prevent folks from monetizing your shit or to get them to pay you for using it, you're using the wrong license.

Arguably it discourages anyone who wants to use the back-end code to build something proprietary with your own distinct changes. But you're not wrong, say a cloud hosting provider out of China, they wont care about AGPL they'll do what they have to.

  The "Corresponding Source" for a work in object code form means all
  the source code needed to generate, install, and (for an executable
  work) run the object code and to modify the work, including scripts to
  control those activities.  However, it does not include the work's
  System Libraries, or general-purpose tools or generally available free
  programs which are used unmodified in performing those activities but
  which are not part of the work.  For example, Corresponding Source
  includes interface definition files associated with source files for
  the work, and the source code for shared libraries and dynamically
  linked subprograms that the work is specifically designed to require,
  such as by intimate data communication or control flow between those
  subprograms and other parts of the work.

What is it about the word "deploy" that you used that is materially different from "install" as described in the license text above?

I think you're looking at it too broadly. The AGPL's intent is to extend GPL protection for software available on the network, see the FSF's blog post here: https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t...

> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program

The text you are referencing is present in the GPL too, and it doesn't make GPL code infect adjacent apps.

> It's not like the AGPL infects everything on your network, it's limited to the original source.

Indeed. By the way, the difference between the AGPL and the SSPL is that the SSPL does infect your entire stack and isn't limited to just the original source, which is exactly why the AGPL is free and open-source but the SSPL is neither.

Now consider the "Tivo" target, which is that the scripts and tools required to deploy the code are things they absolutely want to cover.

You didn't answer my question directly though (and nor does the linked article), what is it about deploy in your usage that is materially different from "install" in the text?

Do you disagree that the device case is covered? How do you consider a cloudy type environment different, and by what definition and justification? What if I sell the deployment in a box for on-prem, as well as in hosted VMs? Does that change users rights under the license?

> (Otherwise, for instance, all software written in Java would be subject to Java's license agreement.)

Java is licensed under GPL.

GPLv2 specifically https://github.com/openjdk/jdk/blob/jdk-21%2B9/LICENSE#L3 although Java is the most famous software I know of with the "CLASSPATH exception" https://github.com/openjdk/jdk/blob/jdk-21%2B9/LICENSE#L326 to avoid "linking" the user's compiled artifacts with Oracle's compiled artifacts. I believe there are other projects that make use of that exception, but I couldn't readily find them

I think the history of this exception comes from the Apache Harmony project which was an early, incomplete fully open source implementation of Java core libraries. As I recall, IBM was heavily involved in this project. (Or was it GNU Classpath? I forget.)

And, please remember that Sun Microsystems open-sourced JDK with great difficulty! (There was a mess of proprietary licenses deep within the core library for years that needed to be dug out one by one.) Some very smart lawyers probably thought long and hard about that linking exception. I doubt Oracle likes it, but it is probably impossible to change now.

The point I'm trying to make with that sentence doesn't depend on the exact license. I apologize if I didn't word it clearly enough.

Java is licensed under the GPL, which says any derivative works of a GPL'd work must also be GPL-licensed. But merely using the Java APIs doesn't make your program a derivative work of Java, which is why it's possible to write and distribute non-GPL software in Java.

By the same reasoning, a client library that merely uses Vaultwarden's APIs does not automatically become bound to the terms of Vaultwarden's copyright license. The AGPL states quite clearly, for the avoidance of doubt, that the only acts it restricts are things that would otherwise require the copyright holder's permission.

I am not a lawyer. Anyone interested in what they can or cannot do with AGPL licensed software should probably consult a lawyer.

It may depend on what you mean by use an API. Compiling a program that links AGPL licensed code may incur obligations under the AGPL. Here is a quote from the AGPL FAQ.

> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. https://www.gnu.org/licenses/gpl-faq.html#MereAggregation