11 ms·

Re-License Vaultwarden to AGPLv3

129 points by demurgos 4y ago

demurgos 4y ago
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?
- 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.
mdaniel 4y ago
Listed as "Solves https://github.com/dani-garcia/vaultwarden/discussions/2450 https://github.com/dani-garcia/vaultwarden/discussions/2450 " which I guess is just a "discussion" in that they want the contributors to assign copyright
- candiddevmike 4y ago
  The AGPL doesn't necessarily mean folks who create forks of Vaultwarden have to contribute back. They just have to make the source available to users of the service, it doesn't require them to PR their changes to the Vaultwarden repo or make the source available for non-customers (if the service isn't publicly accessible). This may seem like splitting hairs but it's an important distinction.
  - mdaniel 4y ago
    Apologies if my comment came across as passing judgement, since I now have a policy of trying very hard to stay out of discussions about the merits of AGPL. I merely meant that the linked PR says it "solves" an issue, but when I went to the issue the "discussion" was only a "GitHub discussion" and not a discussion Although it is fascinating to see the discussion was opened "May 3, 2022" and this is the first I've heard of the relicense effort
    - candiddevmike 4y ago
      Don't worry about it, my comment was about the GH discussion. They listed "providing back to the community" as one of the reasons for the switch. Sorry!
  - raggi 4y ago
    If we're close to splitting hairs though, users includes everyone who ever hits any of its endpoints. It doesn't matter who has credentials - the license does not discuss "customers" and "non-customers". It says: The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. If someone can reach the server, you agree to give them source for everything involved in that servers operation that is covered under "corresponding source". That includes linked, executed and networked programs that integrate with any custom patches to provide features: 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.
colechristensen 4y ago
AGPL license is a red flag for any software I’d like to use.
- wkat4242 4y ago
  Why? Could you elaborate?
  - alwayslikethis 4y ago
    Some companies (notably Google) have a policy of banning any use of AGPL3 software for use within their networks.
    - josephcsible 4y ago
      That's because Google has backend services that are proprietary and wants to keep them that way, even though that's a bad thing.
      - alwayslikethis 4y ago
        Yeah. Maybe I didn't express it, but I see AGPL as a good weapon against slaveware services and companies.
  - noirscape 4y ago
    Note; I don't work for some big tech company and SaaS companies selling FOSS stuff is a big deal which I don't want to downplay. I'll also point out that when it comes to the GPL, you should view the FSF FAQs with some scepticism, they're dubious at best and wrong at worst. IMO it's bad because the AGPL is more akin to a poison pill license. The few changes it makes to the terms of the GPL change it from affecting copyright permission assignment (you can redistribute & modify, but only on these terms) to becoming an EULA instead (you can use it, but only on these terms). On a pure ideological level, that violates freedom 0 (the freedom to use software however you wish). Further complicating things is that the added clause is a royal mess description-wise. Like... do config files count? Am I supposed to now share my database logins to comply? The AGPL is poorly worded and doesn't address these things and it's an issue because it's a EULA and therefore dictates usage of the software. Adding onto the pile, another issue is just... enforcement? We're talking here about software that is a remote black box; I could easily write a replacement for an AGPL program that spits out the exact same thing and deploy it without needing to pay a damn lick of care to the AGPL. Yet worse, I could also just deploy an AGPL thing and claim I did that. You can't prove it without investigating my servers directly. See the issue? Finally, and this is just in general - it's not a tested license. The GPL is a decently tested legal license and it works. The AGPL has never seen the inside of a courtroom, which means it's very dubious which of the rights it purports to grant will actually hold up when put to the test (and which granted rights turn out to be unenforceable). PS: Also one thing I forgot to mention is that the AGPL demands that network software source code is distributed immediately; ie. Your entire codebase needs to be a quine that can fit in a single HTTP request, which is quite the burden. Most people (including those who release AGPL software) don't do that and don't bother. There's a reason most AGPL "enforcement" is just "be nice" stuff.
Daedren 4y ago
I think it makes sense to do this, mainly because Bitwarden's official server is AGPLv3. This'll help avoid conflict between the two.
- mdaniel 4y ago
  It's Daniel's code (well, I guess and all those contributors, too) and thus can license as they see fit, but the whole idea was to have an alternative implementation. If Bitwarden had heartburn about a lighter-weight GPLv3 implementation existing, they're in for some bad news because there are currently 1200 forks still on the GPLv3 license I doubt very very seriously that there is overlap between the audience who runs Vaultwarden and those who want to start up a company that sells Vaultwarden as its backend to compete with Bitwarden
  - ilyt 4y ago
    > I doubt very very seriously that there is overlap between the audience who runs Vaultwarden and those who want to start up a company that sells Vaultwarden as its backend to compete with Bitwarden Company selling password managment as a service might use the code to give their customers migration path to their service
  - nugget 4y ago
    Now that they are venture funded, Bitwarden will try to restrict competition as much as they can. It's a familiar playbook. I wouldn't be surprised if Bitwarden has applied pressure behind the scenes on Vaultwarden to move in this direction, since the AGPLv3 license will make competition less likely (and VW shortsightedly even says as much). They're learning from Chrome/Chromium and others.
    - Spivak 4y ago
      And it'll be easy too since vaultwarden implements the easy bits but the real value is the high-quality clients on every platform which aren't OSS. Can't be worse than LastPass tho.
chrismorgan 4y ago
jjlin raised some valuable points in https://github.com/dani-garcia/vaultwarden/discussions/2450#discussioncomment-2682483 https://github.com/dani-garcia/vaultwarden/discussions/2450#..., where the initial motivation and reasoning were faulty or incomplete: > While I don't object to changing the license, I think a few things mentioned in the intro are not quite true and should be clarified. > > To be clear, this will not effect any (end)user or any self-hosted environment which you share with your family and friends. > If you make your Vaultwarden instance publicly accessible, then there is a reasonable expectation that anyone could interact with it (if only to load the login page), so if you've modified any of the Vaultwarden backend (e.g., custom templates or graphics that get built into the binary), I believe you would technically be obligated to "prominently offer" the source. In practice, that would probably mean modifying the web vault login page with a link to your source. > > This will only have an effect on companies that build proprietary tools using Vaultwarden code. > As mentioned above, this also affects non-commercial users who have modified 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, which is not something we want. > While this may prevent deep integration of Vaultwarden with a company's other products, they are still perfectly able to provide standalone instances, even with some customizations (as long as they make the modified source available), so I don't think this change would have much effect on most MSPs who offer managed Vaultwarden services. > Overall, AGPL has a limited ability to prevent third-party competition with the original product, as can be seen with Bitwarden's shift towards a non-open-source ("source-available") license for key portions of their software. —⁂— Me, I’m not convinced this change is (a) desirable or (b) worthwhile, for the same reasons as jjlin, but I don’t oppose it either. As a teenager I was generally quite unimpressed by the GPL and deliberately avoided building with some copyleft things where possible, strongly favouring permissive licenses, but now I’m 30 and I’ve definitely come to appreciate the purposes of copyleft licenses a bit more, though I still largely prefer to work with permissive licenses. (I prefer the Blue Oak Model License <https://blueoakcouncil.org/license/1.0.0 https://blueoakcouncil.org/license/1.0.0>; on the licenses’ own merits, BlueOak-1.0.0 is roundly better than the likes of Apache-2.0 and MIT; the only practical imperfection of BlueOak-1.0.0 is that it’s not OSI-approved, largely because—simplifying perhaps past the point of strict accuracy—its authors used to work with OSI and are fed up with broken processes.)
shawnz 4y ago
I'm a big supporter of permissive licenses, but I have to admit this seems like a very responsible and well-thought-out approach to relicensing the project to me.
YPPH 4y ago
The AGPL is an underrated licence. It solves the problem of $bigCorp taking free software, making significant improvements and then renting network access to that improved version without providing their changes to anyone. That's unfair.
- heywoodlh 4y ago
  Doesn't the normal GPL solve this problem as well? I don't have strong opinions for or against AGPL, I'm just not really too sure why the GPL doesn't solve this as well.
  - YPPH 4y ago
    Making software available over a network for interaction does not seem to constitute distributing the software. So, no, it does not cover this situation. https://en.m.wikipedia.org/wiki/Affero_General_Public_License https://en.m.wikipedia.org/wiki/Affero_General_Public_Licens...
    - EMIRELADERO 4y ago
      There could be an argument that the JS frontend that gets sent to the client over the network is part of the software, depending on the project's structure
      - deleted 4y ago
        [deleted]
      - Macha 4y ago
        Yes, but that would only apply to the frontend and derivative works thereof
  - Am4TIfIsER0ppos 4y ago
    If I give you a webpage like this comment box in which you give a command line to run a GPL tool (e.g. ffmpeg built with --enable-gpl) I do not need to give you any source code because I am not distributing that tool. That applies to more complicated interfaces and even if I were to link libavcodec into the web server because I am not distributing the tool.
darthrupert 4y ago
So hmm. If I'm running an AGPLv3 Vaultwarden and then somebody connects to that using the official Bitwarden client, am I responsible of providing the Bitwarden client source code -- or if I cannot do that, I'm technically violating the license?
- planede 4y ago
  How did you arrive to that conclusion? If you are running AGPL3 Vaultwarden then you are only responsible to give source code for Vaultwarden (or just point to the upstream sources, if you did not modify it). Why would you be responsible for code you did not distribute running on a computer of someone else?
geokon 4y ago
is there an AGPL-like license built on top of GPLv2 and not GPLv3? I really like the philosophy behind GPLv2 and the AGPL - both focused on making sure code changes get redistributed. But im not keen on the anti-Tivoization requirments .. i feel its an overstep and i find the linux kernel arguments for v2 convincing
- Macha 4y ago
  There was AGPLv1 by Affero in the pre-GNU days but it is incompatible with GPLv2 software. So it has the similar lack of anti-tivo clause but you can't use GPLv2 dependencies. AGPLv3 software is only able to use GPLv3 dependencies because GPLv3 explicitly says so, otherwise it would be incompatible from the terms of the GPLv3 preventing further restrictions. And for completeness AGPLv2 was basically just a modified version of AGPLv1 that let you upgrade from AGPL licenses published by Affero Inc to those published by the FSF
  - geokon 4y ago
    Oh okay, I think I see the problem. GPLv2 wouldn't allow for something like that b/c it'd be introducing an extra "restriction" (forcing more people to disclose code than plain GPLv2) - while GPLv3 was designed with such an extension in mind. Thanks for taking the time to spell it out :) I somehow always missed this subtlety.
rapnie 4y ago
Does someone have pointers to pros and cons to choosing between AGPLv3-only and AGPLv3-or-later variants?
- Macha 4y ago
  It comes down to how much you trust the FSF. If Stallman was finally booted and the new leadership decided to make AGPLv4 which was basically LGPL, you'd have a much more complicated legal battle if you wanted to stop someone using your software under those terms, as you're not arguing intent and reliance and other subjective areas instead of relatively simple copyright infringement. At the same time if you go AGPLv3 only, accept external AGPLv3 only contributions and then FSF releases a AGPLv4 that you feel matches your intent better, then you'd have to do a complicated relicensing process requiring you to get consent from all contributors or rewrite/remove their contributions. The third option is AGPL + CLA but plenty of people are rightfully suspicious of this now many companies have used this to close software moving to source available licenses like SSPL or just flat out proprietary like Emby.
  - gray_-_wolf 4y ago
    There is also an issue of hostile-ish fork. If you release something as (A)GPLv3-or-later, anyone can take it, and extend/change it. However, those changes can be done under (A)GPLv3-only. That would prevent you from incorporating them into your version (unless you also re-license to (A)GPLv3-only), while they still could merge anything you add. In general (A)GPLs care about user freedom, not a developer freedom. So this is not seen as a flaw. I personally prefer using -only variants, since it seems to strike reasonable balance in this regard.
PeterZaitsev 4y ago
I think AGPL is quite poor license choice, it does not really offer protection (ask them why they went from AGPL to SSPL) but introduces friction with compatibility and legal folks in many organizations.
- remram 4y ago
  Does SSPL work in practice with anything? Last I heard you can't run SSPL-licensed software with Linux (you can't re-license Linux as required by SSPL).

129 points by demurgos 4y ago

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

mdaniel 4y ago

Listed as "Solves https://github.com/dani-garcia/vaultwarden/discussions/2450 https://github.com/dani-garcia/vaultwarden/discussions/2450 " which I guess is just a "discussion" in that they want the contributors to assign copyright

candiddevmike 4y ago
The AGPL doesn't necessarily mean folks who create forks of Vaultwarden have to contribute back. They just have to make the source available to users of the service, it doesn't require them to PR their changes to the Vaultwarden repo or make the source available for non-customers (if the service isn't publicly accessible). This may seem like splitting hairs but it's an important distinction.
- mdaniel 4y ago
  Apologies if my comment came across as passing judgement, since I now have a policy of trying very hard to stay out of discussions about the merits of AGPL. I merely meant that the linked PR says it "solves" an issue, but when I went to the issue the "discussion" was only a "GitHub discussion" and not a discussion Although it is fascinating to see the discussion was opened "May 3, 2022" and this is the first I've heard of the relicense effort
  - candiddevmike 4y ago
    Don't worry about it, my comment was about the GH discussion. They listed "providing back to the community" as one of the reasons for the switch. Sorry!
- raggi 4y ago
  If we're close to splitting hairs though, users includes everyone who ever hits any of its endpoints. It doesn't matter who has credentials - the license does not discuss "customers" and "non-customers". It says: The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. If someone can reach the server, you agree to give them source for everything involved in that servers operation that is covered under "corresponding source". That includes linked, executed and networked programs that integrate with any custom patches to provide features: 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.

colechristensen 4y ago

AGPL license is a red flag for any software I’d like to use.

wkat4242 4y ago
Why? Could you elaborate?
- alwayslikethis 4y ago
  Some companies (notably Google) have a policy of banning any use of AGPL3 software for use within their networks.
  - josephcsible 4y ago
    That's because Google has backend services that are proprietary and wants to keep them that way, even though that's a bad thing.
    - alwayslikethis 4y ago
      Yeah. Maybe I didn't express it, but I see AGPL as a good weapon against slaveware services and companies.
- noirscape 4y ago
  Note; I don't work for some big tech company and SaaS companies selling FOSS stuff is a big deal which I don't want to downplay. I'll also point out that when it comes to the GPL, you should view the FSF FAQs with some scepticism, they're dubious at best and wrong at worst. IMO it's bad because the AGPL is more akin to a poison pill license. The few changes it makes to the terms of the GPL change it from affecting copyright permission assignment (you can redistribute & modify, but only on these terms) to becoming an EULA instead (you can use it, but only on these terms). On a pure ideological level, that violates freedom 0 (the freedom to use software however you wish). Further complicating things is that the added clause is a royal mess description-wise. Like... do config files count? Am I supposed to now share my database logins to comply? The AGPL is poorly worded and doesn't address these things and it's an issue because it's a EULA and therefore dictates usage of the software. Adding onto the pile, another issue is just... enforcement? We're talking here about software that is a remote black box; I could easily write a replacement for an AGPL program that spits out the exact same thing and deploy it without needing to pay a damn lick of care to the AGPL. Yet worse, I could also just deploy an AGPL thing and claim I did that. You can't prove it without investigating my servers directly. See the issue? Finally, and this is just in general - it's not a tested license. The GPL is a decently tested legal license and it works. The AGPL has never seen the inside of a courtroom, which means it's very dubious which of the rights it purports to grant will actually hold up when put to the test (and which granted rights turn out to be unenforceable). PS: Also one thing I forgot to mention is that the AGPL demands that network software source code is distributed immediately; ie. Your entire codebase needs to be a quine that can fit in a single HTTP request, which is quite the burden. Most people (including those who release AGPL software) don't do that and don't bother. There's a reason most AGPL "enforcement" is just "be nice" stuff.

Daedren 4y ago

I think it makes sense to do this, mainly because Bitwarden's official server is AGPLv3. This'll help avoid conflict between the two.

mdaniel 4y ago
It's Daniel's code (well, I guess and all those contributors, too) and thus can license as they see fit, but the whole idea was to have an alternative implementation. If Bitwarden had heartburn about a lighter-weight GPLv3 implementation existing, they're in for some bad news because there are currently 1200 forks still on the GPLv3 license I doubt very very seriously that there is overlap between the audience who runs Vaultwarden and those who want to start up a company that sells Vaultwarden as its backend to compete with Bitwarden
- ilyt 4y ago
  > I doubt very very seriously that there is overlap between the audience who runs Vaultwarden and those who want to start up a company that sells Vaultwarden as its backend to compete with Bitwarden Company selling password managment as a service might use the code to give their customers migration path to their service
- nugget 4y ago
  Now that they are venture funded, Bitwarden will try to restrict competition as much as they can. It's a familiar playbook. I wouldn't be surprised if Bitwarden has applied pressure behind the scenes on Vaultwarden to move in this direction, since the AGPLv3 license will make competition less likely (and VW shortsightedly even says as much). They're learning from Chrome/Chromium and others.
  - Spivak 4y ago
    And it'll be easy too since vaultwarden implements the easy bits but the real value is the high-quality clients on every platform which aren't OSS. Can't be worse than LastPass tho.

chrismorgan 4y ago

jjlin raised some valuable points in https://github.com/dani-garcia/vaultwarden/discussions/2450#discussioncomment-2682483 https://github.com/dani-garcia/vaultwarden/discussions/2450#..., where the initial motivation and reasoning were faulty or incomplete: > While I don't object to changing the license, I think a few things mentioned in the intro are not quite true and should be clarified. > > To be clear, this will not effect any (end)user or any self-hosted environment which you share with your family and friends. > If you make your Vaultwarden instance publicly accessible, then there is a reasonable expectation that anyone could interact with it (if only to load the login page), so if you've modified any of the Vaultwarden backend (e.g., custom templates or graphics that get built into the binary), I believe you would technically be obligated to "prominently offer" the source. In practice, that would probably mean modifying the web vault login page with a link to your source. > > This will only have an effect on companies that build proprietary tools using Vaultwarden code. > As mentioned above, this also affects non-commercial users who have modified 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, which is not something we want. > While this may prevent deep integration of Vaultwarden with a company's other products, they are still perfectly able to provide standalone instances, even with some customizations (as long as they make the modified source available), so I don't think this change would have much effect on most MSPs who offer managed Vaultwarden services. > Overall, AGPL has a limited ability to prevent third-party competition with the original product, as can be seen with Bitwarden's shift towards a non-open-source ("source-available") license for key portions of their software. —⁂— Me, I’m not convinced this change is (a) desirable or (b) worthwhile, for the same reasons as jjlin, but I don’t oppose it either. As a teenager I was generally quite unimpressed by the GPL and deliberately avoided building with some copyleft things where possible, strongly favouring permissive licenses, but now I’m 30 and I’ve definitely come to appreciate the purposes of copyleft licenses a bit more, though I still largely prefer to work with permissive licenses. (I prefer the Blue Oak Model License <https://blueoakcouncil.org/license/1.0.0 https://blueoakcouncil.org/license/1.0.0>; on the licenses’ own merits, BlueOak-1.0.0 is roundly better than the likes of Apache-2.0 and MIT; the only practical imperfection of BlueOak-1.0.0 is that it’s not OSI-approved, largely because—simplifying perhaps past the point of strict accuracy—its authors used to work with OSI and are fed up with broken processes.)

shawnz 4y ago

I'm a big supporter of permissive licenses, but I have to admit this seems like a very responsible and well-thought-out approach to relicensing the project to me.

YPPH 4y ago

The AGPL is an underrated licence. It solves the problem of $bigCorp taking free software, making significant improvements and then renting network access to that improved version without providing their changes to anyone. That's unfair.

heywoodlh 4y ago
Doesn't the normal GPL solve this problem as well? I don't have strong opinions for or against AGPL, I'm just not really too sure why the GPL doesn't solve this as well.
- YPPH 4y ago
  Making software available over a network for interaction does not seem to constitute distributing the software. So, no, it does not cover this situation. https://en.m.wikipedia.org/wiki/Affero_General_Public_License https://en.m.wikipedia.org/wiki/Affero_General_Public_Licens...
  - EMIRELADERO 4y ago
    There could be an argument that the JS frontend that gets sent to the client over the network is part of the software, depending on the project's structure
    - deleted 4y ago
      [deleted]
    - Macha 4y ago
      Yes, but that would only apply to the frontend and derivative works thereof
- Am4TIfIsER0ppos 4y ago
  If I give you a webpage like this comment box in which you give a command line to run a GPL tool (e.g. ffmpeg built with --enable-gpl) I do not need to give you any source code because I am not distributing that tool. That applies to more complicated interfaces and even if I were to link libavcodec into the web server because I am not distributing the tool.

darthrupert 4y ago

So hmm. If I'm running an AGPLv3 Vaultwarden and then somebody connects to that using the official Bitwarden client, am I responsible of providing the Bitwarden client source code -- or if I cannot do that, I'm technically violating the license?

planede 4y ago
How did you arrive to that conclusion? If you are running AGPL3 Vaultwarden then you are only responsible to give source code for Vaultwarden (or just point to the upstream sources, if you did not modify it). Why would you be responsible for code you did not distribute running on a computer of someone else?

geokon 4y ago

is there an AGPL-like license built on top of GPLv2 and not GPLv3? I really like the philosophy behind GPLv2 and the AGPL - both focused on making sure code changes get redistributed. But im not keen on the anti-Tivoization requirments .. i feel its an overstep and i find the linux kernel arguments for v2 convincing

Macha 4y ago
There was AGPLv1 by Affero in the pre-GNU days but it is incompatible with GPLv2 software. So it has the similar lack of anti-tivo clause but you can't use GPLv2 dependencies. AGPLv3 software is only able to use GPLv3 dependencies because GPLv3 explicitly says so, otherwise it would be incompatible from the terms of the GPLv3 preventing further restrictions. And for completeness AGPLv2 was basically just a modified version of AGPLv1 that let you upgrade from AGPL licenses published by Affero Inc to those published by the FSF
- geokon 4y ago
  Oh okay, I think I see the problem. GPLv2 wouldn't allow for something like that b/c it'd be introducing an extra "restriction" (forcing more people to disclose code than plain GPLv2) - while GPLv3 was designed with such an extension in mind. Thanks for taking the time to spell it out :) I somehow always missed this subtlety.

rapnie 4y ago

Does someone have pointers to pros and cons to choosing between AGPLv3-only and AGPLv3-or-later variants?

Macha 4y ago
It comes down to how much you trust the FSF. If Stallman was finally booted and the new leadership decided to make AGPLv4 which was basically LGPL, you'd have a much more complicated legal battle if you wanted to stop someone using your software under those terms, as you're not arguing intent and reliance and other subjective areas instead of relatively simple copyright infringement. At the same time if you go AGPLv3 only, accept external AGPLv3 only contributions and then FSF releases a AGPLv4 that you feel matches your intent better, then you'd have to do a complicated relicensing process requiring you to get consent from all contributors or rewrite/remove their contributions. The third option is AGPL + CLA but plenty of people are rightfully suspicious of this now many companies have used this to close software moving to source available licenses like SSPL or just flat out proprietary like Emby.
- gray_-_wolf 4y ago
  There is also an issue of hostile-ish fork. If you release something as (A)GPLv3-or-later, anyone can take it, and extend/change it. However, those changes can be done under (A)GPLv3-only. That would prevent you from incorporating them into your version (unless you also re-license to (A)GPLv3-only), while they still could merge anything you add. In general (A)GPLs care about user freedom, not a developer freedom. So this is not seen as a flaw. I personally prefer using -only variants, since it seems to strike reasonable balance in this regard.

PeterZaitsev 4y ago

I think AGPL is quite poor license choice, it does not really offer protection (ask them why they went from AGPL to SSPL) but introduces friction with compatibility and legal folks in many organizations.

remram 4y ago
Does SSPL work in practice with anything? Last I heard you can't run SSPL-licensed software with Linux (you can't re-license Linux as required by SSPL).