Argues that Bitwarden is executing a softer, slower version of the same exit pattern used by Elastic, MongoDB, Redis, and HashiCorp: build goodwill on OSS, then quietly relicense the parts that matter so no one can compete on your own code. The move of cryptographic and core logic into a source-available SDK with anti-competition clauses is the mechanism, even if the messaging is subtle.
The OSNews piece, surfaced to the top of HN with 187 points, frames this as urgent: 'Get your passwords out of Bitwarden while you still can.' The argument is that Vaultwarden users are one client update away from being legally stranded once the official clients fully link against the Bitwarden License SDK.
Highlights the subtle mechanics: the server stays AGPL and clients stay GPL, but the SDK they increasingly depend on uses a bespoke source-available license that prohibits building competing products. The result is a de facto fork ban — you can read the code, but you cannot legally swap the backend and ship it, which kills Vaultwarden's long-term viability.
Bitwarden, the open-source password manager that for years has been the default recommendation whenever someone asks "what should I use instead of LastPass," is no longer the unambiguously open project it used to be. An OSNews post that hit the top of Hacker News with 187 points crystallized a concern that has been quietly building in the self-hosting community: Bitwarden's clients and SDK are being relicensed in ways that make true community forks legally untenable.
The mechanics are subtle, which is part of why this has taken so long to surface as a public fight. The Bitwarden server has historically been AGPL. The clients (desktop, browser, mobile) were GPL. But over the past year, Bitwarden has been moving cryptographic and core logic into a separate SDK licensed under the Bitwarden License — a bespoke source-available license that prohibits using the code to build a competing product. The clients increasingly link against this SDK. The net effect: you can still read the source, but you cannot legally fork the client, swap the backend, and ship it.
This matters because Vaultwarden — the unofficial Rust reimplementation of the Bitwarden server that most self-hosters actually run on their NAS or VPS — depends on the official clients speaking its protocol. If the clients become legally encumbered, Vaultwarden's entire user base is one client update away from a license trap. The OSNews piece's title — "Get your passwords out of Bitwarden while you still can" — is hyperbolic on the timeline but accurate on the trajectory.
This is the HashiCorp playbook running again, and it is becoming the dominant exit pattern for VC-backed open source. Take the OSS community goodwill, build a business on top, then quietly relicense the parts that matter to prevent anyone from competing with you on your own code. Elastic did it. MongoDB did it. Redis did it. HashiCorp did it. Now Bitwarden is doing a softer, slower version of the same move — and because it's wrapped in an SDK rather than a top-level license flip, it has attracted far less attention than the BSL conversions.
The community reaction on HN was sharper than the typical "vendor bad" pile-on. Several long-time Vaultwarden users pointed out that Bitwarden's CEO has previously committed publicly to the clients remaining GPL. A GitHub issue from earlier this year — referenced repeatedly in the thread — had a Bitwarden employee initially claim the SDK *was* GPL, then walk that back after legal review. That sequence is the tell: when a company's own engineers don't know what license their code ships under, the license has become a marketing surface rather than a legal commitment.
Password managers are also a particularly bad category to play license games with. Unlike a database or a CI runner, a password manager is lifetime-critical infrastructure for individuals. Your vault contains every recovery path you have. A migration is not a weekend project — it's auditing two decades of accumulated 2FA seeds, recovery codes, and "that one site that uses email-as-password." The switching cost is precisely what makes the lock-in valuable to a relicensed Bitwarden, and precisely what makes the move feel like a betrayal to users who chose it specifically *because* it was open.
There's also a quieter security angle. The Bitwarden SDK contains the cryptographic primitives. Moving crypto code into a license that forbids derivative implementations means the only people who can audit, fork-fix, or fast-patch a vulnerability in your password vault are Bitwarden employees. For a project whose entire pitch was "don't trust us, read the code," that's a meaningful regression even if the source remains visible.
If you self-host Vaultwarden, you have time but you don't have unlimited time. The current clients still work. The current SDK is permissive enough that the existing ecosystem isn't broken today. But every future client release is a roll of the dice on whether new SDK code with stricter terms gets pulled in.
The practical migration paths, ranked by how much disruption they cause:
1. KeePassXC + Syncthing — Local-first, fully GPL, zero vendor risk. The desktop UX is rougher than Bitwarden's, the mobile story is acceptable (Strongbox on iOS, KeePassDX on Android), and you handle sync yourself. This is the move for people who want to never have this conversation again. 2. Proton Pass — Centralized but the company has a credible track record on jurisdiction and stance. You're trading one vendor relationship for another, but Proton's incentives are less likely to drift than a US-VC-backed company approaching a liquidity event. 3. 1Password — Never claimed to be open source, so at least the contract is honest. Best UX in the category. If you were going to end up on a closed-source manager anyway, this is the one. 4. Stay on Vaultwarden, pin your clients — Viable for another 6–12 months. Not viable as a permanent answer.
The actionable step for this week: run `bw export` (or the GUI equivalent) into an encrypted file and stash it somewhere you'll find it in two years. That single command costs you ten minutes and buys you optionality regardless of which way Bitwarden's licensing eventually lands.
For teams: this is a procurement conversation, not an engineering one. If your company standardized on Bitwarden Teams or Enterprise because it was open source, that justification is degrading. Either accept that you're now on a proprietary product with an open-ish veneer, or start a 12-month migration plan to something with a contract that matches your actual requirements.
The broader pattern here is that "open source" as a procurement signal is dying, replaced by a messy spectrum of source-available, fair-source, BSL, SSPL, and bespoke licenses. The companies that hold the line — SUSE, Postgres, the Linux Foundation projects — increasingly look like the exceptions rather than the norm. For developer tools, the question is no longer "is this open source" but "who has commit access, who has the trademark, and what happens when the cap table demands monetization." Bitwarden's slow drift is a useful case study because it's gentle enough that most users will simply absorb it. Which, if you're a VC-backed founder watching how this plays out, is exactly the lesson.
While I'm not _happy_ about the messaging changes, those alone are not enough to do more than start paying closer attention. I highly, highly doubt that vault export would be the first meaningful feature change, and so I think there will be stronger signals of actual issues before then.As I und
I've been recommending Bitwarden for a few years now and have also been paying a yearly sub since 2022, as I always thought 10$ was a really good value.But with all this stuff coming out, I'm holding off on recommending it anymore; at least until everything calms down and the new value pro
Serious question - how come free is a requirement for a password manager? Everyone's gotta eat, including the maintainers of password managers.Tech has generous TC, lots of high-end laptops and phones worth thousands, AI & cloud spend, and yet the only acceptable price for secrets managemen
I store my passwords using this: https://www.passwordstore.org/It's a shell script that stores passwords in a git repository, containing one file per entry. The files are encrypted using a GPG key. Because it's just a git repository, you can synchronise it between devices us
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
This is an incredible overraction over a minor change that did not even happen. You can still find "Always free" in the pricing line of the very same page everyone keeps linking as proof https://bitwarden.com/products/personal/#whats-the-differenc...Edit: it actual