Bitwarden's Dual License Move: 823 Commercial Files, 52 Hidden Bundle Files, and the 95 Routes the Open-Source Build Never Ships

On October 9, 2026, a Bitwarden staff account posted a five-line notice on the company’s community forum: “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.” It is the kind of announcement that reads like housekeeping. It is not. Within a day the thread had 52 posts and 40,121 views, and Hacker News had taken it to 338 points and 244 comments, most of them framing it as the opening move of a rug pull.

The interesting part is not the announcement. It is that the thing the announcement describes has been shipping for a while, and you can measure it.

I pulled the two self-hosted web artifacts Bitwarden published on 2026-09-30 — eleven days before the notice — unpacked them, diffed every file, and compared every string literal in every non-sourcemap JavaScript bundle. The commercial artifact already contains features the open-source artifact does not. Meanwhile the repository’s licence files have a commit history three entries long, the newest from 2016 apart from a 2022 directory preparation and a 2025 typo fix. Bitwarden did not relicense its code. It changed which build it hands to app stores, and the asymmetry between its two builds is older and wider than the announcement admits.

The short version

What the licence actually says, in full

Bitwarden’s client repositories have been dual-licensed for years, and the arrangement is spelled out in an 820-byte LICENSE.txt:

Source code in this repository is covered by one of two licenses: (i) the GNU General Public License (GPL) v3.0 (ii) the Bitwarden License v1.0. The default license throughout the repository is GPL v3.0 unless the header specifies another license. Bitwarden Licensed code is found only in the /bitwarden_license directory.

The second licence is titled “BITWARDEN LICENSE AGREEMENT Version 1, 4 September 2020”. Its operative clause is short and, for anyone who intends to run a commercial build, unexpectedly narrow:

2.1 Commercial Module License. Subject to Your compliance with this Agreement, Bitwarden hereby grants to You a limited, non-exclusive, non-transferable, royalty-free license to use the Commercial Modules for the sole purposes of internal development and internal testing, and only in a non-production environment.

Section 2.3 then forbids selling, renting, leasing, distributing, sublicensing, loaning or otherwise transferring the Commercial Modules, removing trademarks, or “use [of] the Commercial Modules to create a competing product or service”. Section 3.1 says the agreement “will automatically terminate upon notice from Bitwarden”. Section 5.7 handles U.S. Government restricted rights, and 5.8 provides injunctive relief for breaches of Section 2.

Read that as a whole and the shape of the move becomes legible. The Bitwarden License is a commercial redistribution control, not an end-user licence. It is designed so that nobody can take Bitwarden’s pre-built binaries and their enterprise modules and sell them. What it does not contain is any clause granting the free end user a right to run those modules in production. The staff reassurance that store builds “will work exactly as they do today” is a statement about behaviour, not about legal permission.

A forum participant named DenBesten caught the same ambiguity within hours: “The statement, apps published to the various stores will be the commercially licensed builds sounds to me like License_Bitwarden.txt will replace Terms of Service… I don’t think either of these are what you mean, but it is how it reads to me.” No clarification followed that addressed the licence text itself.

The measurement: two artifacts, one release, 52 files apart

GitHub’s release API gives you both bundles from the same tag. I downloaded them and did the arithmetic.

At the file level: 52 files exist only in the commercial zip, 35 exist only in the open-source zip (renamed bundles whose content hashes changed), and 3 files exist in both with different content. One of the commercial-only files is a licence notice for Chart.js v4.5.1 — a charting library, which tells you something about what kind of screens the open build does not have.

File counts are crude, though, because minified bundles get renamed on every build. So I compared the string literals instead: parse every quoted ASCII string of 6–70 characters out of every non-sourcemap .js file in both zips and take the set difference.

• 25,973 distinct strings in the commercial build vs 24,103 in the open-source build
• 2,164 strings appear only in the commercial build
• 294 strings appear only in the open-source build

That asymmetry is the finding. The commercial bundle is a superset in substance, not a rebuild with different hashes. And among the 2,164, the routes are unambiguous — 95 path-like strings exist only in the commercial build:

(Forty-three bitwarden.com/help/... URLs in total appear only in the commercial bundle.)

It is worth being careful about what this does and does not prove. String presence in a minified bundle is a good proxy for shipped capability and a poor proxy for reachable UI — a route string can exist in dead code. What it establishes beyond argument is that the two artifacts are not the same program. Anyone running the open-source self-hosted web vault in September 2026 did not have the code paths for Secrets Manager, Key Connector, provider setup, item trash, risk-insights dashboards or those 11 SAML and 10 SIEM integrations in their bundle at all.

Those are, by coincidence or not, precisely the features enterprises pay for. The word doing the heavy lifting in “all current features are available in both versions” is current, as one forum participant put it — and the artifact diff shows the boundary was already drawn before the announcement, on a case-by-case basis, exactly as staff now say future features will be decided.

Who is actually affected

The announcement’s stated scope is one sentence: “the licensing change affects those who are repackaging and reselling Bitwarden.” The other staff statements describe something wider. Both are quoted below because they cannot both be narrow.

Two things in that table deserve emphasis. First, the fourth row is the only place where the licence does something crisp: if you redistribute the commercial modules, you are outside the grant, full stop. Second, the announcement never says which store builds, and staff initially had to go and find out — the reply to “Will the Portable Desktop App link on Bitwarden’s Download Page download a build that is commercially licensed or OSS licensed?” was “That’s a great question. I’ll work to get that information,” followed by an edit: “The download page will also direct link to the commercial license.”

As of 2026-10-11, that promise is not visible. I loaded bitwarden.com/download/ in a real headless browser, scrolled it, and searched both the rendered text and the full HTML: zero occurrences of “license”, “GPL” or “commercial”. The page still advertises the free plan and a “free forever” commitment. Whatever else is true, the disclosure the company said it would add had not landed two days later. That is a small thing that matters disproportionately for a security product: the user’s only reliable signal about which licence governs the binary in their hand is a forum thread.

The escape hatches, and how many people actually use them

Every licence-change story produces a list of alternative channels. Three are commonly proposed for Bitwarden. Two of them do not exist in the form people assume.

F-Droid. There is no Bitwarden client on F-Droid. The canonical package path returns HTTP 404, and a search of the F-Droid index for “bitwarden” returns SelfPrivacy, PassVault, AIPOS Password Manager, Monica F-Droid and Anywherelan — none of them Bitwarden. The official Android app lives in the Play Store and, for the source-committed, in bitwarden/android (9,466 stars, GPL-3.0). If you want a store-free Android client, you are compiling it.

Source tarballs. The browser release publishes browser-source-2026.9.3.zip. Its download count on GitHub: 44, against 488 for the Chrome distribution zip. Building from source is technically available and empirically unpopular — the same pattern I measured in the Cloudflare/Deno analysis, where the escape hatch nobody walks through is the most reliable finding in the data.

The open-source self-hosted bundle. Here the numbers are almost a tie: 158 downloads for web-2026.9.1-selfhosted-open-source.zip versus 135 for the commercial one. The GPLv3 path is alive. It is three percent smaller, missing 52 files, and — per the route diff — missing the enterprise half of the web vault.

Meanwhile the direct-download channel dwarfs the store channel in raw volume on GitHub’s counters: the Windows installer .exe shows 114,497 downloads, the universal macOS .dmg 72,017, the portable build 19,099, the .deb 8,357, the AppImage 1,741 — while the Microsoft Store .appx assets sit at 222, 96 and 46. Interpretation requires care (auto-updaters hit release assets, and Store installs don’t touch GitHub), but one thing is clear from staff’s own edit: the download-page binaries are going commercial too. The channel with the largest measured usage is the one losing the open build, not the one keeping it.

Twenty-six weeks of context that make the timing legible

None of the above explains why now. The public record around Bitwarden in 2026 does.

• February 2026 — Longtime CEO Michael Crandell moves to an advisory role, unannounced; you would only know from LinkedIn. His replacement, Michael Sullivan, previously led Acquia and Insightsoftware, and his profile leads with M&A experience “including direct experience with leading PE firms”.
• March 2026 — The Premium price roughly doubles, announced inside a feature announcement rather than as a pricing change, with existing customers notified about two weeks before renewal; a commenter in this week’s Hacker News thread quotes their own invoice moving from $10/year to $19.80/year.
• Mid-April 2026 — “Always free” disappears from the personal password-manager page.
• 4 May 2026 — The company’s internal values acronym changes from Gratitude, Responsibility, Inclusion, Transparency to Gratitude, Responsibility, Innovation, Trust.
• October 9, 2026 — Store and download-page builds become commercially licensed.

Against that arc, the announcement’s own language is more revealing than any critic’s reading of it. Asked what features might end up commercial-only, staff answered: “It’ll be evaluated on a case-by-case basis, but you’ll see some new products released soon — including a government version of Bitwarden — where having this license will give Bitwarden the legal protection it needs.” That is a coherent business rationale. It is also, plainly, a statement that the plan extends beyond repackagers.

The company also did something rare in these situations: it agreed, publicly, with a criticism. A user proposed shipping both builds to the stores so people could choose, and warned that forcing the commercial one invites “bad press”. Staff replied, “This is a pretty good idea! I know it’ll basically double the deployment team’s workload, but I’ll take this back to leadership as a recommendation.” As of this writing there is no follow-up on that thread.

The steelman, and what would settle it

It is tempting to read every licence change as hostility. It usually isn’t that simple, and the honest version of this story includes the case for it.

Bitwarden has been repackaged and resold for years by parties that contribute nothing upstream. A security product that wants government business needs contract language, indemnification and liability boundaries that GPLv3 explicitly disclaims — the Bitwarden License’s §4 disclaims warranties and §5.7 addresses government restricted rights for exactly that reason. And the commercial modules themselves — SSO, SCIM, Secrets Manager — are the ones enterprises pay for; the same features sat under /bitwarden_license in the public repository long before this week, readable and auditable by anyone. “Source available with a commercial-use restriction” is not “closed source”, and conflating the two makes the criticism easier to dismiss than it deserves.

So the disagreement is not about the licence. It is about selection: which features land in which build, decided by whom, disclosed how. That is testable, and the test is cheap. Here is the checklist I would apply to the next release.

Evidence that the open build is genuinely maintained and co-equal

1. The next release still publishes -selfhosted-open-source.zip, and its non-sourcemap byte count keeps growing rather than freezing.
2. The route/string diff between the two zips does not expand to include personal-vault features. The current diff is enterprise-shaped: SSO, SCIM, Secrets Manager, provider console. If /trash were the only anomaly and tomorrow /vault or autofill joins it, that is a different story.
3. The GPLv3 repository keeps receiving feature commits, and kspearrin (7,187 commits, 32.3% of the top-100 total) — the founder, still CTO — stays in the commit log.
4. The store publication becomes a choice: two builds, two names, as the community proposed.

Evidence that the concern was correct

1. Core personal-vault capability moves behind the commercial build.
2. The open-source self-hosted artifact stops being published, or its version line stalls while the commercial line advances.
3. Client-server protocol changes break third-party servers. This has happened before: the web client broke Vaultwarden compatibility at least once, tracked in dani-garcia/vaultwarden issue #7607. Protocol drift is the soft power in this situation; nobody has to announce it.
4. The GPLv3 repositories are relicensed to a source-available licence (BUSL/SSPL), which was the Redis, Elastic and Terraform pattern that Hacker News commenters reached for immediately. One commenter in the thread, who said he was at Redis during its first licence change, described asking leadership to keep the core BSD and split instead.

Both columns are cheap to check on any release. The second column’s fourth item is the one to watch hardest, because it is the point at which “you can still fork it” stops being true — and “you can still fork it” was the staff answer to the rug-pull question.

How to check your own build in five minutes

Everything in this article is reproducible without special access. If you run Bitwarden anywhere, these are the checks worth automating.

# 1. Which licence governs the repository you build from?
curl -sL https://raw.githubusercontent.com/bitwarden/clients/main/LICENSE.txt

# 2. How much of the repo is commercial-only? (GitHub tree API, recursive)
curl -s "https://api.github.com/repos/bitwarden/clients/git/trees/main?recursive=1" \
  | grep -c '"path": "bitwarden_license/'

# 3. Do the two self-hosted artifacts still differ, and by how much?
#    (download both assets from the latest web-v* release, then:)
unzip -l web-*-selfhosted-COMMERCIAL.zip  | tail -1
unzip -l web-*-selfhosted-open-source.zip | tail -1

# 4. Which enterprise routes are in one and not the other?
for z in web-*-selfhosted-*.zip; do
  echo "== $z"; unzip -p "$z" 'build/app/main.*.js' \
    | grep -o -E '/(secrets|projects|service-accounts|access-tokens|key-connector|providers/setup|trash)' \
    | sort -u
done

Three things you cannot check today, and should be able to: whether the download page tells you which licence you are about to accept (it does not), whether a store update changed your build from GPLv3 to commercial in place (there is no in-app build-licence indicator), and what a Linux Flatpak or Snap receives (unanswered in the thread). For a product whose entire pitch is verifiability, that is the part worth pressing on — more than the licence itself.

FAQ

Did Bitwarden relicense its code? No. The repository has been dual-licensed since the Bitwarden License appeared in September 2020, with the /bitwarden_license directory arrangement committed in May 2022. LICENSE.txt has three commits ever, the most recent a reference fix in May 2025.

Is the source still readable? Yes. All of it, including the commercial modules, remains on GitHub. “Source available with restrictions on commercial use” is not the same as closed source, and staff are explicit that “Code under the commercial license is just as viewable and transparent on GitHub.”

So is there a fork I can use? The GPLv3 portion is forkable today, minus trademarks — and that is exactly why the trademark clause and the protocol-compatibility question matter more than the licence text. Note also what happened to the most-cited alternative client: Keyguard (3,443 stars, 12 watchers) is source-available but, per a commenter in the thread who checked, fully copyrighted — not a FOSS fallback either.

Will the free plan survive? Staff: “The free plan is here to stay permanently.” The same sentence pattern appeared on the website until “Always free” was removed in April 2026, so weigh written commitments accordingly.

I self-host. Should I switch? Only if a specific capability you need lives in the commercial build, or if the open-source artifact stops shipping. Self-hosted server users on GPLv3 keep the core vault — the measured gap is enterprise-shaped. If you depend on Vaultwarden, the operational risk is client protocol drift, which argues for pinning client versions and exporting vaults on a schedule rather than migrating in a hurry.

What is the single most informative thing to monitor? The byte diff between the two -selfhosted- zips on each web-v* release. It is public, it is arithmetic, and it updates within minutes of every release. Right now it reads: +52 files, +2,164 strings, +95 routes, all of them enterprise.

The bottom line

The loud version of this story — “Bitwarden is going closed source” — is wrong on the facts. The quiet version is more interesting: a password manager whose entire trust model rests on verifiability shipped two different programs under two different licences for at least eleven days before telling anyone, moved the more capable one onto the channels most users actually install from, and attached a licence whose production-use clause does not cover the people now receiving it. Meanwhile the repository that everyone is arguing about is, byte for byte, unchanged.

The right response is neither panic nor deference. It is to treat the release artifacts as the source of truth and to check them, because unlike a forum reassurance or a privacy page, a 46,666,753-byte zip file cannot be worded carefully. It just is what it is — and this week, it said more than the announcement did.