Bitwarden SDK relicensed from proprietary to GPLv3

Original Article ↗ Hacker News Discussion ↗

Bitwarden has reversed a recent move to make its Rust SDK proprietary, relicensing it under GPLv3 and restructuring repositories so the core password manager clients can again be built purely from free/open‑source components. Commenters are broadly relieved but divided on whether the original licensing change was an honest packaging mistake or a deliberate step toward more proprietary control, with several noting Bitwarden’s open‑core model, VC funding, and the importance of “forkability” for long‑term trust. The episode prompts wider comparisons with alternatives such as Firefox’s built‑in manager, KeePass variants, Vaultwarden, and other self‑hosted tools, as users weigh usability, security, and openness when choosing where to store their passwords.

Context of the Licensing Change

  • Bitwarden’s Rust SDK, previously under a proprietary “Bitwarden SDK License,” has been reorganized and relicensed so that the clients can be built using only GPL/OSI-licensed code.
  • The new sdk-internal repo is GPLv3 (or dual-licensed GPLv3/Bitwarden license), with proprietary parts isolated in bitwarden_license directories, mainly for their separate Secrets Manager product.

Was It a Bug, a Strategy, or a Walk-Back?

  • One camp calls this a “packaging mistake” or dependency mix-up that conflicted with Bitwarden’s long-standing open-source positioning, now corrected.
  • Others point to prior statements like “no plans to adjust the SDK license” and explicit awareness of F-Droid incompatibility as evidence it was a deliberate move toward more proprietary control, reversed only after public backlash.
  • Some users say this episode damaged trust but that the quick course-correction and willingness to listen are positive signs; others see it as the start of a slow “enshittification” pattern.

GPLv3, Dual Licensing, and Distribution Constraints

  • Discussion clarifies that:
    • GPLv3 obligations trigger on distribution, not SaaS; hence AGPL exists to close that gap.
    • Bitwarden’s SDK is dual-licensed (GPLv3 or proprietary Bitwarden license), with some code still non-free.
  • There is debate over whether GPL apps can be meaningfully forked and shipped via Apple’s App Store; the legal situation is described as murky and potentially still hostile to forks, giving Bitwarden a de facto iOS advantage.

Open-Core Model and Business Concerns

  • Bitwarden is framed as open-core rather than fully free software. Some see that as acceptable and necessary to “have something to sell.”
  • Others argue that organizations mixing proprietary and GPL code tend to drift proprietary over time, especially after taking VC funding; users are urged to “keep an eye on them.”

Alternatives, Self-Hosting, and UX

  • Vaultwarden (Bitwarden-compatible server), KeePass variants, pass, Passbolt, Psono, and others are mentioned as alternatives.
  • Many still prefer Bitwarden for its cross-platform UX, sharing, TOTP/passkey support, and self-hosting options; some now favor Firefox’s built-in manager or Apple Keychain for less technical users.

Security, 2FA, and Backups

  • No evidence in the thread that the license change compromised cryptographic security.
  • Significant side-discussion: whether storing TOTP secrets in the same vault as passwords undermines “true” 2FA; consensus is it reduces security versus separate devices, but may be acceptable trade-off for convenience depending on threat model.
  • Multiple users recommend regular exports or parallel KeePass/pass setups as backups against Bitwarden outages or lockouts.