On October 9, a Bitwarden staff member posted in the company’s community forum that, starting with the next release, the Bitwarden apps in the app stores will be the commercially licensed builds. The post says no action is needed and the apps will work exactly as they do today.
That is true as far as it goes. What bothers me is what the change makes possible later.
What is changing
The license files in Bitwarden’s repositories haven’t changed. The code is still on GitHub, and the clients are still GPLv3 by default. What changes is the license on the apps Bitwarden builds and ships itself: the store apps and, according to staff, the downloads on its own Download page.
Staff say two licenses are in play: the GPLv3 and the Bitwarden License, which they call the commercial license. The second one is source-available, and Bitwarden’s own license FAQ says it “does not qualify as an open source license under the OSI definition.” I can’t tell you what terms the store builds will carry, because the next release isn’t out yet. Everything here is based on what Bitwarden has published so far.
Staff also say a lot stays the same: the free plan, every current feature in both versions, and self-hosting. They say the change “affects those who are repackaging and reselling Bitwarden.” I have no evidence that any of that is untrue.
Why Bitwarden can do this
Anyone who contributes code to Bitwarden signs a contributor agreement. In it, you assign to Bitwarden “all right, title, and interest in any copyright in the Contribution.”
That is a common arrangement, and this one dates back to 2020. As I read it, and I’m not a lawyer, Bitwarden owns the contributed code, so it can ship its own builds under any terms it likes while the public GPL copy stays open. Contributors keep a license to use their own code. What they give up is any say in how it is licensed from here on, and I found no promise in the agreement to keep contributions open source.
Where I think it goes wrong
Until now, the line was easy to see. Bitwarden’s FAQ says the commercial license covers features “primarily…designed for use by larger organizations rather than individuals and families.” In the repositories, that means a separate folder, and by my reading it holds things like single sign-on, SCIM provisioning and Secrets Manager.
Now the line is a staff decision. In the same thread, a staff member wrote, “Some future components will be published under the commercial license and will exist only in that build.” New features, they added, “will be evaluated on a case-by-case basis for which license applies to them.” And the store build is the one most people will install.
Bitwarden hasn’t said what will go there, and I’m not claiming it will take anything away. But “case by case” isn’t a limit. It means the line is wherever Bitwarden decides to draw it, and that is a much wider door than a folder and a FAQ. To me, that works against the spirit of open source.
If you want a commercial product, build one
I understand that Bitwarden is protecting its financial interests. A company has every right to. But there is a cleaner way to do it. If Bitwarden wants a commercial product, it can fork its own code into one, with its own name and its own license, and leave the open source project alone. Everyone would know which one they were using and which one they were contributing to.
Today the two share a name, a codebase and a download button, and the boundary between them is a staff decision.
I publish my own tools, DNS Benchmark and Shell Sheet, under the MIT license. Anyone can take them, change them and sell the result. That is the trade open source asks of you: once you share the code, others can use it in ways you wouldn’t choose. Keeping the right to move the line later is a different deal.
At the least, Bitwarden could write its promises into the license. Staff say it remains committed to open source and that “Bitwarden is not going closed-source.” Those are statements, not terms.
What to do if your business uses Bitwarden
Nothing today. The apps work as they did yesterday, and I wouldn’t switch tools over a license alone. But treat this as vendor risk, and spend an hour on it:
- Write down the license. Put it in your software list next to the vendor and the renewal date.
- Read the store-build terms when they appear. They aren’t public until the next release ships.
- Watch for three things. A price change, a current feature moving to a paid plan, and new features that land only in the commercial build.
- Make sure you can leave. Test an export of your vault, and make sure someone besides you knows how. A plain export contains every password, so keep it locked down and delete test copies.
If you self-host, staff say nothing changes for you. They gave the same answer for third-party community servers, like Vaultwarden, an independent server that works with Bitwarden’s apps. Those apps are still the part Bitwarden controls.
When a company wants both the goodwill of open source and the freedom of a commercial product, which one should win when they conflict?
