Bitwarden moves its store apps to a commercial license while the GPLv3 build stays on GitHub
On October 9, 2026, Bitwarden announced that the apps it publishes to app stores will switch to the commercially licensed build, while the GPLv3 build stays on GitHub. For self-hosters, nothing changes today — but the word 'current' in 'all current features' deserves a careful second read.
October 9, 2026. RyanL, a Bitwarden team member, announces on the community forum that the apps published to the various stores will switch, starting with the next release, to the commercially licensed builds. GPLv3. The open-source version, meanwhile, “continues to be updated and published on GitHub.” No action required. The apps “will work exactly as they do today.” Why it matters: Bitwarden is not closing anything, but it is drawing a new line between two versions of the same code — and for self-hosters, that is a line to watch closely.
What changes, and what does not
Until now, the stores (App Store, Play Store, browser extensions) distributed Bitwarden’s GPLv3 build. Going forward, at build time for a new release, Bitwarden produces two versions and publishes both on GitHub: a commercial one and a GPLv3 one. The commercial builds are the ones that will go to the stores and to the direct-download page.
The reassuring part for the average user: nothing changes in the visible code. The announcement insists — and an edit repeats it — that the store clients are “built directly from 100% publicly auditable code on GitHub,” that “nothing has been made closed source,” and that the code remains readable, auditable and contributable. The nuance fits in one sentence: the license applying to that code changes, not the code itself.
The stated reason is logistical. Bitwarden has had a commercial license for some time, focused on enterprise features — the announcement points to the FedRAMP and Privileged Controls programs as examples. Until now, an enterprise customer who wanted those features had to fetch the commercial version from GitHub. Shipping the commercial build on the stores lets everyone get “the features they pay for (or don’t pay for)” from the same place.
One distinction the announcement leaves implicit is worth making explicit: Bitwarden also maintains an official self-hosted server, often deployed as Bitwarden Unified, separate from Vaultwarden. The announced switch touches neither of them — it concerns only the clients. That is good news for the self-hoster, but it says nothing about the server’s future licensing choices, which deserve to be watched separately.
In concrete terms, a GPLv3 purist’s life changes in one specific way: on every release, they must fetch the app from GitHub releases rather than letting the store auto-update, and they must accept that paid features placed under the commercial license will silently be absent. That is a real operational cost for a minority of users — and a non-event for everyone else. The asymmetry is the point: Bitwarden can move the boundary because almost nobody is on the wrong side of it today, which is exactly why the trajectory, not the snapshot, deserves attention.
“All current features”: the devil is in the adjective
That is the phrase the community seized on — Ethan Sholly of selfh.st first among them: “all current features are available in both versions.” The word “current” does the heavy lifting. Asked about future differences, RyanL clarified: “some future components will be published under the commercial license and will exist only in that build,” and “newly developed features will be evaluated on a case-by-case basis.”
In other words, the two builds are identical today, but they will diverge. The underlying question — raised by a community member — remains open: will those future features excluded from the GPLv3 build still be open source? The announcement gives no firm answer. This is the classic open-core mechanism: a free core and a commercial periphery that gradually narrows.
What does not change, by contrast, is stated unambiguously: self-hosting is unaffected, the code can still be forked (including the commercially licensed code), and the free plan “is here to stay permanently.” The licensing change only concerns those who resell Bitwarden.
Vaultwarden and the self-hosting question
For the self-hoster, the crucial point is to understand what is affected — and what is not. The license switch concerns the clients Bitwarden distributes on the stores: the browser extension, the mobile apps and the desktop app. The self-hosted server is not touched by this announcement, and Vaultwarden users — the very popular compatible reimplementation — will see no change in how their vault behaves.
Still, the signal is real. Bitwarden was already dual-licensing the server — a commercial Bitwarden license alongside GPLv3 — but the clients had remained entirely GPLv3 until now. Extending the mechanism to the store apps moves the open-core boundary one notch further, toward the periphery users touch every day.
The precedent matters. The ecosystem has already watched Redis adopt a restrictive license, Elasticsearch switch to the SSPL, and Terraform move to the BSL before OpenTofu was born. Each time, the core stayed readable, and the community responded by measuring what remained genuinely free. Bitwarden is careful, this time, to state plainly that “nothing has been made closed source” — but it is the trajectory, more than the moment, that counts.
For the vigilant self-hoster, three signals are worth watching. First, the GitHub release notes: the first feature that appears only in the commercial build will mark the real start of the divergence. Second, the answer to the still-open question — will those future features remain readable in the source code? Third, the fate of the GPLv3 build itself: as long as it is published with every release, the promise that “everything stays open source” holds; the day its cadence slows, it will be time to reconsider. None of these signals is red today. But a license is a statement of intent, and reading it closely is how you stay ahead.
Two builds, two audiences
| GPLv3 build (GitHub) | Commercial build (stores) | |
|---|---|---|
| Distribution | GitHub releases, side-loaded | Stores and download page |
| Source code | Public and auditable | Public and auditable (same repo) |
| Current features | All | All |
| Future features | Per license, case by case | All, including commercial |
| Intended audience | Open-source purists | Standard and enterprise users |
The practical consequence for a strict GPLv3 user: they will have to side-load the app from GitHub on every update, and will give up paid features placed under the commercial license. For everyone else, the switch is transparent.
Verdict
The recommendation is easy to state, but it depends on your profile. If you install Bitwarden from the stores, you have nothing to do: the build changes license, not behavior, and your vault works identically. If you are a GPLv3 purist, prepare now to side-load the GitHub releases manually, and accept that future paid features will escape you. If you self-host a compatible server such as Vaultwarden, watch the rate of divergence between the two builds: nothing breaks today, but this is one more signal — after Dockhand and its BSL rolling window — that the line between the free core and the commercial periphery keeps moving, project after project. The one thing not to do is assume a license is a consequence-free formality: it is what ultimately decides what you will still be able to self-host. The cheapest diligence is to watch the first release notes after the switch.