EN
Back to the archive

The archive · Developer & Business Tools · Strategic decision · 2024

Bitwarden reversed a restrictive SDK license after its open-source community pushed back

Freemium password manager Bitwarden bundled a use-restricted internal SDK into its desktop build; GitHub and HN backlash made it call the move a packaging bug.

Bitwarden

The betThat it could fold a use-restricted SDK into its open-source clients and still be seen as genuinely open — the trust its freemium brand ran on.Live

What the business is

Bitwarden runs a freemium password-management service built around an encrypted vault and clients for many platforms; it has long published code as open source so users and self-hosters can audit what they run.

How it started

Bitwarden founder and CTO Kyle Spearrin built the service on a freemium model, publishing code as open source as part of its trust story. In October 2024, pull request #10974 made the desktop client depend on @bitwarden/sdk-internal, whose license stated: 'You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK.'

What happened

A user filed issue #11611, 'Desktop version 2024.10.0 is no longer free software', arguing that the dependency and its clause 'violates freedom 0' and that the desktop client could not be built without it; other users echoed the concern. Spearrin replied that the SDK and the client are separate programs in separate repositories communicating over standard protocols, so GPLv3 compatibility held, and that the build blocker was 'merely a bug' they planned to resolve; the ticket was then locked to collaborators. Phoronix reported the dispute on 2024-10-20 as 'Concerns Raised Over Bitwarden Moving Further Away From Open-Source', and it reached the HN front page the next day, where commenters debated whether Bitwarden was quietly leaving open source behind.

How it ended up

That evening Bitwarden posted on X that the dependency was a 'packaging bug' and that 'Bitwarden remains committed to the open source licensing model'; a linked Phoronix follow-up reported 'Bitwarden Makes Change To Address Recent Open-Source Concerns'. The company walked the restriction back and reaffirmed the open-source positioning the episode had put at risk.

Background

Bitwarden is a freemium password manager built around an encrypted vault, with clients on many platforms and code published as open source. Its founder and CTO, Kyle Spearrin, built the trust story on that transparency. In October 2024, pull request #10974 made the desktop client depend on @bitwarden/sdk-internal, an internal SDK whose license barred use with software other than Bitwarden or the development of another SDK.

Users immediately read the clause as Bitwarden leaving free software behind. A GitHub issue titled 'Desktop version 2024.10.0 is no longer free software' argued the dependency 'violates freedom 0'; Spearrin answered that the SDK and client were separate GPLv3 programs and the blocker was 'merely a bug', then the ticket was locked to collaborators. Phoronix reported the dispute on 2024-10-20 and the story hit the HN front page the next day (102 points, 60 comments), where the community debated whether the restriction was a slip or a strategy.

Bitwarden responded the same evening on X that the dependency was a 'packaging bug' and that it 'remains committed to the open source licensing model', and a Phoronix follow-up reported that Bitwarden made a change to address the concerns. The episode showed how quickly a licensing change inside a build dependency could test — and, with a public reversal, restore — the open-source trust the freemium brand runs on.

What has to be true

  • Bitwarden's published source code was the evidence its freemium pitch pointed to, so any use restriction read as betrayal rather than packaging.
  • The dependency landed in the desktop build, which packagers and self-hosters compile themselves, so the community hit the clause immediately rather than gradually.
  • The GitHub issue gave critics a numbered, citable artifact, and Phoronix plus HN turned it into a front-page story within 48 hours.
  • Locking the ticket made the exchange look evasive until Bitwarden's public 'packaging bug' statement and follow-up change restored its position.

What can be applied

For an open-source brand, licensing is product: a use restriction inside a build dependency reads as the first step of a rug pull, and only a visible reversal restored trust.

Aftermath

Within a day Bitwarden publicly called the dependency a packaging bug, reaffirmed that it remains committed to the open-source licensing model, and a Phoronix follow-up reported that it made a change to address the concerns. As of the 2026-09-06 review, the GitHub issue page remains public and the Bitwarden GitHub org — 'Open source security solutions for individuals, teams, and business organizations' — is still actively maintained, with the clients repo showing activity on 2026-09-05; no revenue, user or product impact from the episode is documented in the reviewed sources.

Sources

spotted an error? The archive wants to know.

Your turn

You just read one. Describe what you are building, and see who is betting on the same thing.

Free account · 3 free questions · no card

Related cases