> I think that it means that if your client depends on unique features of the Vaultwarden server, the client also has to use the AGPLv3 license (it's "viral" even through the network).
I'm not aware of any term in the AGPL that requires that. The AGPL says it applies only to modified versions or derivative works of the original codebase, and in general, just using an API -- even if it's unique to that product -- is not enough to make something a derivative work of that product.
(Otherwise, for instance, all software written in Java would be subject to Java's license agreement.)
The AGPL says that all clients interacting with the server through the network must be offered the source code of the server, not that they have to be AGPL themselves.
Of course, if you build your own client that uses code taken from the server, your client must be distributed under AGPL, just as if you did that with the old version, you would have had to use the GPL.
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.
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?
> 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?
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.
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
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 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.
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.
I'm not aware of any term in the AGPL that requires that. The AGPL says it applies only to modified versions or derivative works of the original codebase, and in general, just using an API -- even if it's unique to that product -- is not enough to make something a derivative work of that product.
(Otherwise, for instance, all software written in Java would be subject to Java's license agreement.)
The AGPL says that all clients interacting with the server through the network must be offered the source code of the server, not that they have to be AGPL themselves.
Of course, if you build your own client that uses code taken from the server, your client must be distributed under AGPL, just as if you did that with the old version, you would have had to use the GPL.