Bitwarden's Dual-License Change, Explained: What Changed and Why It Won't Be the Last
Bitwarden now defaults to commercial-license builds. Here's what changed, why it echoes HashiCorp, Redis, and Elastic, and how to build an owned fallback.

What did Bitwarden's dual-license change, and why won't it be the last?
Bitwarden now ships its app-store and website downloads under a commercial license by default. A GPLv3 version still exists and is still maintained on GitHub. Self-hosting and forking are still allowed. The free plan is still free. But starting with Bitwarden's next release, the build most users will actually install is the commercial one, not the open-source one, and the company has confirmed some features built from here on will be commercial-license-only.
That's the change in one paragraph. The rest of this piece covers why it happened, why it was predictable, and what it should trigger inside any team that treats a password manager, a secrets vault, or any other "free" open-source tool as load-bearing infrastructure.
TL;DR
- Future Bitwarden features will be exclusive to the commercial track, so the free and open editions will functionally diverge from here.
- Vendors keep abandoning open-source licenses to stop hyperscalers from commoditizing their work, as HashiCorp, Redis, and Elastic did before Bitwarden.
- Growing fears of vendor lock-in are pushing organizations back toward hybrid and on-premises setups.
- A fork maintained by a former vendor employee offers less protection than a consortium-backed fork like Valkey or OpenTofu.
- Teams should negotiate exit terms into renewals so a licensing change never leaves them without a way out.
- Organizations should budget for an owned fallback as a recurring line item, not a reactive project funded after a scare.
What Exactly Changed?
Until this announcement, Bitwarden's main pitch to the security-conscious was that its clients were open source end to end, auditable, and GPLv3-licensed. That's still technically true. What changed is the default. The build that shows up when you search your app store or hit the download page is now the commercially licensed one. The GPL build still exists, but it's no longer the path of least resistance, and it's the one that will fall behind as Bitwarden builds new features exclusively for the commercial track.
A Bitwarden team member framed the move as targeting "parties that repackage and resell Bitwarden" without licensing it or contributing back. That's a specific complaint, not a vague one. Existing features stay available in both versions for now. The forward-looking line, that future features may be exclusive to commercial builds, is the part worth sitting with. It means the free and open editions are set to functionally diverge from here, not just cosmetically differ.
What Is the Pattern Behind Four Scares in Two Years?
If October 2026 were an isolated event, it'd be a licensing footnote. It isn't. It's the fourth entry in a two-year pattern.
- October 2024: the SDK scare. A new build dependency, bitwarden/sdk-internal, shipped with a license clause barring its use with any non-Bitwarden software. Users opened a GitHub issue titled "Desktop version 2024.10.0 is no longer free software," and press coverage asked openly whether the client was still FOSS. Bitwarden called it a packaging bug and restructured the SDK to use only GPL and OSI-approved licenses, with the original repository renamed sdk-secrets.
- January 2026: the price hike. Bitwarden raised its Premium plan from $9.99 a year to $19.80 a year, roughly doubling the price after about a decade of flat pricing. The increase was disclosed inside a blog post about new features rather than called out directly, and the emails notifying users didn't state the new yearly price either.
- February through May 2026: smaller controversies, same direction. A published paper described attacks against Bitwarden's zero-knowledge model under a malicious-server scenario. A malicious CLI package briefly circulated via npm. Bitwarden drew criticism in May for removing "Always free" messaging and revising its stated corporate values.
- October 2026: the dual-license default. Commercial builds become the default app-store download, with future features reserved for that track.
No single item on that list is damning by itself. Taken together, they describe a vendor whose relationship with its open-source identity has gotten more conditional for two years running. That's not one bad week. That's a direction.
Why Do Open-Source Companies Relicense?
Bitwarden's move isn't a strange outlier. It's the same decision three other major open-source infrastructure vendors already made, for the same stated reason.
HashiCorp switched Terraform's license from the open MPL 2.0 to the non-open Business Source License in August 2023, turning the infrastructure-as-code tool underneath tens of thousands of businesses into a potential legal gray zone overnight. Redis moved from BSD to SSPL and RSALv2 in March 2024. CEO Rowan Trollope put it plainly: "the majority of Redis' commercial sales are channeled through the largest cloud service providers, who commoditize Redis' investments and its open source community." Elastic made the same call on Elasticsearch and Kibana back in January 2021, moving them off Apache 2.0 to SSPL and the Elastic License.
The pattern repeats exactly. A vendor builds an open-source product. A hyperscaler resells it as a managed service without paying the vendor or contributing back. The vendor's own commercial tier gets commoditized by its own code running on someone else's infrastructure. Relicensing is the lever every one of these companies pulled to recapture that value. Bitwarden's own language about "parties that repackage and resell Bitwarden" fits the mold exactly.
What Does 'Free' Software Actually Cost You?
The pitch of open-source infrastructure has always been that free, auditable, self-hostable options reduce vendor risk relative to closed SaaS. That pitch assumed the license itself was stable. It isn't, and the market has started pricing that in.
Parallels' 2026 State of Cloud Computing survey of 540 IT professionals found that 94% of organizations are now concerned about vendor lock-in, up from an already elevated baseline a year earlier. Uncertain product roadmaps now factor into platform decisions for 46% of organizations, and fears over future vendor support factor in for 57%, both larger shares than in 2025. The same survey found confidence in cloud-only strategies eroding in practice, not just on paper: 49% of organizations now run multi-cloud, 33% run hybrid, and 49% are actively considering or planning a move back toward on-premises or hybrid infrastructure.
That's the real cost of "free." It isn't a dollar figure on an invoice. It's the governance and legal exposure that shows up the moment a vendor you don't control changes the terms you built on, and it compounds every time the vendor's trust account takes another hit. The same dynamic runs through other corners of the SaaS stack, where switching costs and platform fees only become visible once you try to leave.
What Happens When Trust Runs Out and Users Fork?
What happens when a vendor's open-source goodwill runs out isn't a hypothetical. There's a documented playbook, and it worked every time.
When HashiCorp relicensed Terraform, a coalition of vendors and community members forked the last MPL-licensed release into OpenTofu, now hosted under the Linux Foundation, with Spacelift, env0, Gruntwork, Harness, Scalr, and Cloud Posse backing it from day one. When Redis relicensed, Valkey emerged as a fork backed by the Linux Foundation and, notably, by Amazon Web Services, Google Cloud, Oracle, Ericsson, and Snap, the exact cloud providers Redis had accused of commoditizing its work. When Elastic relicensed Elasticsearch and Kibana, AWS forked them into OpenSearch.
Bitwarden already has a parallel: Vaultwarden, a Rust-based, Bitwarden-compatible self-hosted server built independently of Bitwarden itself. It's a real, working architecture of independence. It's also a reminder to check your assumptions. Vaultwarden's lead developer, Daniel García, was later hired by Bitwarden, which raises a fair question about how independent that fallback really is going forward. A fork maintained by a company's own former contractor isn't the same guarantee as a fork maintained by a hyperscaler consortium.
When Does Self-Hosting Your Password or Secrets Manager Make Sense?
None of this means every team needs to self-host its password manager tomorrow. It means the decision to depend on a vendor's licensing goodwill should be deliberate, not default. A few questions make the call concrete:
| Cost | Feature Access | Vendor Dependence | Independent Backing | Maintenance Burden | |
|---|---|---|---|---|---|
| Commercial build (default)teams wanting latest features with vendor support | Paid license/subscription | Full, including future exclusives | High | Low | Low |
| GPLv3 build (GitHub)teams wanting to stay open-source without forking | Free, self-managed | Lags as features diverge | Medium | Medium | Medium |
| RecommendedVaultwarden (independent fork)teams prioritizing independence from Bitwarden's roadmap | Free, self-hosted | Compatible, built independently | Low | Medium | High |
- How many of your other systems key off this one? If SSO, device provisioning, and incident response all assume your credential vault behaves a certain way, a licensing change upstream isn't a line-item cost. It's an operational dependency.
- Is there an independent fork, and who actually backs it? A fork backed by a single ex-employee of the vendor is a different risk profile than one backed by a consortium of unrelated companies, the way Valkey and OpenTofu are.
- What does self-hosting actually cost you in ops burden? Running Vaultwarden or an equivalent in-house is not free labor. It's a real build-vs-buy tradeoff, the same one covered in why open-core SaaS still traps you in enterprise hell, and the kind of self-hosting-as-risk-management calculus that applies whenever a vendor controls your exit. Price it against the cost of staying exposed, not against zero.
- Does your contract or deployment give you an exit ramp today? If moving off the vendor requires a migration project you haven't scoped, you don't have an exit ramp. You have a plan to someday build one.
For password and secrets management specifically, the calculus tends to tilt toward owning the fallback sooner rather than later, because credential infrastructure sits upstream of almost everything else a company runs. That's a different risk tier than, say, a project-management SaaS tool.
What Should You Do Now If You Depend on Bitwarden, or Any Dual-Licensed Tool?
The mistake every company in this piece's examples made was treating relicensing as a one-time surprise instead of a standing risk to monitor. The fix is procedural, not emotional:
- Audit your license exposure now, not after the next announcement. Know which tools in your stack are open-source-adjacent but commercially controlled, and which license version you're actually running.
- Stand up a self-hosted or forked alternative in a lab environment before you need it. Vaultwarden, OpenTofu, Valkey, and OpenSearch are all production-proven. The time to learn their quirks is not during a migration deadline.
- Negotiate exit terms into renewal contracts, including data export guarantees and pricing locks, the same way you'd negotiate an SLA.
- Put "build an owned fallback" on the budget as a recurring line item, not a reactive project that only gets funded after a scare. Teams that treat this like insurance, not firefighting, are the ones that forked calmly in 2023 and 2024 while everyone else scrambled.
Some teams building that fallback infrastructure are also finding it faster to stand up with AI coding agents like Remy handling the scaffolding, which lowers the cost of the "own it" option relative to a decade ago. That changes the math on when self-hosting makes sense. It doesn't change the underlying lesson. Bitwarden isn't the villain here. It's a company responding rationally to the same commoditization pressure that hit HashiCorp, Redis, and Elastic before it. The lesson for everyone else: "free and open" was never a permanent property of a product. It was a decision a vendor made, and vendors can unmake decisions. Plan accordingly.
Frequently Asked Questions
What exactly did Bitwarden change in October 2026?
Starting with its next release, Bitwarden's official app-store and download-page builds ship under a commercial license by default instead of GPLv3. A GPLv3 version continues to be maintained on GitHub, self-hosting and forking remain allowed, and the free plan is unchanged. Bitwarden has confirmed some future features will be released only under the commercial license.
Is Bitwarden still open source?
The code remains forkable and a GPLv3 build still exists on GitHub, so the project isn't closing its source. But the default download most users get is now commercially licensed, and future features may only appear in that commercial build, so the free/open edition is expected to functionally fall behind over time.
Why do companies like Bitwarden, Redis, and HashiCorp relicense their open-source projects?
In each case the stated reason was the same: large cloud providers were reselling the open-source project as a managed service without paying the originating company or contributing back, commoditizing the vendor's own commercial sales. Relicensing was each company's attempt to recapture that value.
What are the open-source alternatives if I don't trust Bitwarden's roadmap?
Vaultwarden is a Bitwarden-compatible, self-hosted server that predates this announcement, though its lead developer was later hired by Bitwarden, which complicates how independent it really is. The broader precedent, OpenTofu for Terraform, Valkey for Redis, and OpenSearch for Elasticsearch, shows that community and vendor-backed forks can successfully replace a relicensed tool when enough users and companies back them.
How worried should my company be about vendor lock-in from licensing changes?
A 2026 industry survey found 94% of IT organizations are concerned about vendor lock-in, with 57% citing fears over future vendor support and 46% citing uncertain product roadmaps as factors shaping platform decisions. Nearly half of organizations are now actively considering a move back to on-premises or hybrid infrastructure, which suggests this concern is already changing real purchasing behavior, not just sentiment.
How we source, write, and correct our articles. Editorial standards



