Published version update in app stores
community.bitwarden.com
Hello everyone! Starting in the next release, the Bitwarden apps published to the various stores will be the commercially licensed builds. No action is needed, and the apps will work exactly as they do today. Bitwarden remains committed to open source security and transparency The GPLv3 OSS licensed version continues to be updated and published on GitHub All current features are available in both versions License details are on GitHub Bitwarden remains committed to a robust, free forever plan...

RyanL Bitwarden Employee

Hello everyone!

Starting in the next release, the Bitwarden apps published to the various stores will be the commercially licensed builds. No action is needed, and the apps will work exactly as they do today.

Bitwarden remains committed to open source security and transparency
The GPLv3 OSS licensed version continues to be updated and published on GitHub
All current features are available in both versions
License details are on GitHub
Bitwarden remains committed to a robust, free forever plan for everyone

If you have any questions, please ask them in this thread. Thanks all!

EDIT:

Bitwarden is not going closed-source
You can still fork Bitwarden
No change to self-hosting, the licensing change affects those who are repackaging and reselling Bitwarden
The free plan is here to stay permanently
  • lemmyvore@feddit.nlEnglish
    192·
    18 hours ago

    Vaultwarden (and all the client apps) depend on Bitwarden for the API spec. If Bitwarden introduces closed features in the API that Vaultwarden can’t/won’t implement, but the client apps do, it will split the spec. They can also introduce API license keys, which would render Vaultwarden mostly irrelevant.

    The only way for Vaultwarden to remain relevant going forward is to own it and split ways from Bitwarden. This would in turn mean that the FOSS client apps have to decide which to support. But I think the ecosystem is going to fragment eventually anyway, so the sooner every app decides which way they want to go, the better.

        • nibbler@discuss.tchncs.deEnglish
          3·
          8 hours ago

          History shows this will happen. Or do you have any counter example?

          Mariadb, libreoffice and most recently OpenCourant

          • Natanox@discuss.tchncs.deEnglish
            2·
            7 hours ago

            Not arguing against it of course, just dislike when people make forking (and establishing a whole new standard) sound like not that big of a deal.

            • nibbler@discuss.tchncs.deEnglish
              11·
              7 hours ago

              well, the first step of forking is clicking a button or execting a “git clone” command. thats trivial. publishing to android is a bit of work, but very one-time.

              keeping up with development is a different story - but many foss projects thrive with support from whoever needs to have something fixed.

              • Natanox@discuss.tchncs.deEnglish
                1·
                7 hours ago

                You’ll also have to convince other maintainers to adopt the new API in this case, otherwise it’s pointless. Vaultwarden is only the server, you’d at least require one third-party client (e.g. Keyguard) to add and maintain the Vaultwarden API and probably also someone to fork the browser plugins. This whole issue is quite involved.

                • nibbler@discuss.tchncs.deEnglish
                  2·
                  7 hours ago

                  I highly doubt future compatibility. Things will diverge. I care about having a good hostable password manager. I don’t care about the name of the client or if it’s compatible with some closed source shit.

        • ryannathans@aussie.zoneEnglish
          78·
          13 hours ago

          When presented a hypothetical between the commenter suggesting it be

          A) forked now

          And me suggesting

          B) forking when there is a problem

          You elect C) the commenter does the work?

          Brilliant contribution