Bitwarden's store apps go commercial next release, and the GPL build will lose future features

Bitwarden will ship commercially licensed builds to the Apple App Store, Google Play, and the browser extension stores starting with its next release. Ryan L. from Bitwarden posted the notice on the company forum on October 9. The GPLv3 code stays on GitHub. Every feature that exists today ships in both builds. Some future features will not. The thread sat near the top of Hacker News through the weekend with close to 400 points, and the questions people asked there are the ones I'd ask.

I've run Bitwarden for years, both the hosted service and self-hosted instances. The product is good. This post is about the license.

What changed on October 9

The notice is short. Starting with the next release, the apps published to the stores will be the commercial builds. "No action is needed, and the apps will work exactly as they do today." Bitwarden continues to develop and publish the GPLv3 version on GitHub. The free plan is described as permanent.

The replies that followed carry the substance. Ryan L. confirmed that direct downloads from bitwarden.com, including the portable Windows desktop app, will also be the commercial build. He wrote that "some future components will be published under the commercial license and will exist only in that build," and that each new feature will be assessed case by case. If your plan includes a feature that exists only in the commercial build and you installed the GPL build, you won't see it. A second staff member, dwbit, said pricing is not changing and that the change is "not related to a price change." Bernd Schoolmann from Bitwarden said the commercial browser extension will stay compatible with the GPL desktop client for biometric and shared unlock.

Bitwarden's stated motive is resellers. The edited notice says the change affects "those who are repackaging and reselling Bitwarden," and Ryan L. said the commercial build is going to the stores so customers with commercial features, government customers among them, don't have to fetch it from GitHub. No reseller was named.

Two more facts from the thread. A user proposed publishing both builds to the stores. Ryan L. called it "a pretty good idea," said it would roughly double the deployment team's workload, and said he'd take it to leadership. And dwbit said third-party servers such as Vaultwarden are unaffected and can pick which features to support.

The license text has been public for years

Bitwarden has had a split codebase for a long time. The server repository contains a bitwarden_license directory under the Bitwarden License v1.0, and that's where enterprise features such as SSO and SCIM live. The clients repository has the same split, with LICENSE_BITWARDEN.txt sitting next to the GPL. People who called the product "fully open source" were describing the free tier.

Read that license file before you form an opinion. Section 2.1 grants a license for "internal development and internal testing" in a non-production environment. Section 2.2 grants nothing else. Section 2.3 forbids selling, distributing, or sublicensing the commercial modules, and forbids using them "to create a competing product or service." Bitwarden can terminate by notice, after which you destroy your copies. California law, Los Angeles County courts.

So "viewable on GitHub" is accurate. You can read the code and audit it. You cannot run the commercial modules in production without a commercial agreement, and you cannot fork them into something that competes. Bitwarden's claim that users "can still fork it" is true of the GPL portion and false of the commercial portion, and the notice doesn't draw that line.

The store build is where this matters. Today's store apps are built from GPL code with a bitwarden_license tree alongside. After the next release, the binary you install from the App Store is governed by the commercial license as a whole. The features are identical on day one. The terms differ from day one.

October 2024 was the rehearsal

This is the second time in two years Bitwarden has had this argument. In October 2024, a client build pulled in an internal SDK package whose license restricted use to Bitwarden-compatible applications, which meant the clients could no longer be built as free software. Bitwarden called it a packaging bug. Within days it moved the dependency to a new sdk-internal repository under the same licensing as the clients, and Phoronix reported the fix along with the CTO's statement that the open-source commitment was unchanged. Later reporting said the SDK itself moved to GPLv3.

That episode had a clean resolution because the problem was a mistake. This one is a decision. Nobody at Bitwarden is calling it a bug, and nobody is reverting it. The company has told you what it plans to do: ship a commercial binary as the default, keep the GPL tree alive, and put some unnamed future features in the commercial tree alone. Take them at their word on all three.

The open questions in the thread are the ones Bitwarden has not answered. Which features will exist only in the commercial build. Whether self-hosters on a paid plan get them. What the Flatpak and F-Droid builds will use. Whether a build from GitHub will keep parity with the store build in six months. The staff replies on the Privacy Guides forum pointed at the public roadmap (tags, desktop auto-type, native desktop passkeys before year end) without saying which license any of it ships under.

What I'd do if I ran it

If you self-host Bitwarden's server, nothing changes this release. Your server is the same code. Your clients will be the commercial build if you install from a store, and the GPL build if you build from source or wait for a distro package. Both talk to your server today. The thing to watch is the first feature that lands in the commercial client and needs a server endpoint the GPL server doesn't have. That's the day the two trees diverge in practice.

If you run Vaultwarden, your exposure is the API. Vaultwarden reimplements Bitwarden's server API and ships none of Bitwarden's code. Commercial features that need new server endpoints will be features Vaultwarden has to chase or skip. Bitwarden said community servers can choose. That's the same position Vaultwarden has always been in, with one more reason to expect the gap to widen.

If you approved Bitwarden through a procurement or open source review on the basis of GPLv3, run that review again. The binary your staff install from the store will be under a different license than the one you reviewed. For most companies the practical effect is zero, since the license grants are about redistribution and competing products, and your employees are doing neither. But the record should match the software.

If you're a maintainer, the lesson is older than Bitwarden. A project with two licenses and one company holding the copyright can move the line between the free tree and the paid tree whenever it wants. Bitwarden moved it on October 9 by changing which build is the default, without changing a single file's license. The GPL protects the code that is under it. It doesn't protect the position of the code that isn't.

My prediction: the GPL build keeps parity for the rest of 2026, the first client feature that exists only in the commercial build shows up in the first half of 2027, and it will be enterprise enough that most people shrug. The second one will be harder to shrug at.