4 ms·

Vaultwarden is a Rust implementation of the server for Bitwarden, a password manager. It was initially licensed with the GPLv3, and now switched to the AGPLv3.

Vaultwarden is a Rust implementation of the server for Bitwarden, a password manager. It was initially licensed with the GPLv3, and now switched to the AGPLv3. This was done after getting approval from contributors (see linked discussion). As far as I understand it, this new license increases protections for network based services. 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). EDIT: I may be wrong about this according to the replies. From the discussion: > To be clear, this will not effect any (end)user or any self-hosted environment which you share with your family and friends. This will only have an effect on companies or self-hosted environments that build proprietary tools using Vaultwarden code or modify the Vaultwarden code. > This is also more fair towards Bitwarden, since currently the GPLv3 license of Vaultwarden could allow other companies to compete with Bitwarden by modifying the Vaultwarden code and not providing these changes back to the community, which is not something we want.

teraflop 4y ago
> 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.
- demurgos 4y ago
  Oh okay, thank you for the explanation. I'll have to read more about the distinction then.
  - teraflop 4y ago
    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.
- candiddevmike 4y ago
  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.
  - giancarlostoro 4y ago
    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.
  - raggi 4y ago
    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?
    - candiddevmike 4y ago
      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-the-agplv3 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.
- maxloh 4y ago
  > (Otherwise, for instance, all software written in Java would be subject to Java's license agreement.) Java is licensed under GPL.
  - mdaniel 4y ago
    GPLv2 specifically https://github.com/openjdk/jdk/blob/jdk-21%2B9/LICENSE#L3 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 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
    - throwaway2037 4y ago
      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.
  - teraflop 4y ago
    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.
- markkitti 4y ago
  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 https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
maxloh 4y ago
IIRC GPL licensed code could be relicensed to AGPL, without contributors' approval.
- alwayslikethis 4y ago
  No. They are just compatible, in that you can incorporate GPL code in AGPL project and vice versa, with both parts remaining under their respective license.
  - PeterisP 4y ago
    There's really no vice versa - you can combine GPL code with AGPL code, but while both parts remain under their respective license, the resulting combination as a whole then has to follow the AGPL rules ("The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such."), so as soon as you incorporate even a tiny bit of AGPL code in your mostly-GPL project, users have to treat it as an AGPL project.
    - chrismorgan 4y ago
      > as soon as you incorporate even a tiny bit of AGPL code in your mostly-GPL project, users have to treat it as an AGPL project. … or else disentangle the parts, selecting only GPL parts. But yeah, if treating it as a project, AGPL covers it.
  - adastra22 4y ago
    This is incorrect. The mixed projects would become AGPL.
    - goodpoint 4y ago
      No, there is no such thing as software under a license "becoming" something else. When distributing the whole combined work e.g. a compiled file you have to follow the AGPL, naturally. The part under GPL/MIT/BSD is still there. If you were to extract only those source files and distributed them they would be still under GPL/MIT/BSD.

teraflop 4y ago

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

demurgos 4y ago
Oh okay, thank you for the explanation. I'll have to read more about the distinction then.
- teraflop 4y ago
  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.
candiddevmike 4y ago
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.
- giancarlostoro 4y ago
  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.
- raggi 4y ago
  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?
  - candiddevmike 4y ago
    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-the-agplv3 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.
maxloh 4y ago
> (Otherwise, for instance, all software written in Java would be subject to Java's license agreement.) Java is licensed under GPL.
- mdaniel 4y ago
  GPLv2 specifically https://github.com/openjdk/jdk/blob/jdk-21%2B9/LICENSE#L3 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 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
  - throwaway2037 4y ago
    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.
- teraflop 4y ago
  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.
markkitti 4y ago
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 https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

maxloh 4y ago

IIRC GPL licensed code could be relicensed to AGPL, without contributors' approval.

alwayslikethis 4y ago
No. They are just compatible, in that you can incorporate GPL code in AGPL project and vice versa, with both parts remaining under their respective license.
- PeterisP 4y ago
  There's really no vice versa - you can combine GPL code with AGPL code, but while both parts remain under their respective license, the resulting combination as a whole then has to follow the AGPL rules ("The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such."), so as soon as you incorporate even a tiny bit of AGPL code in your mostly-GPL project, users have to treat it as an AGPL project.
  - chrismorgan 4y ago
    > as soon as you incorporate even a tiny bit of AGPL code in your mostly-GPL project, users have to treat it as an AGPL project. … or else disentangle the parts, selecting only GPL parts. But yeah, if treating it as a project, AGPL covers it.
- adastra22 4y ago
  This is incorrect. The mixed projects would become AGPL.
  - goodpoint 4y ago
    No, there is no such thing as software under a license "becoming" something else. When distributing the whole combined work e.g. a compiled file you have to follow the AGPL, naturally. The part under GPL/MIT/BSD is still there. If you were to extract only those source files and distributed them they would be still under GPL/MIT/BSD.