Bitwarden 把「读代码」和「用代码」拆开卖了——而它的替代品有 6.9 万星

目录

• 一条公告，两个版本
• 双许可的物理边界：一个目录的事
• 社区的两极：从「理解」到「该跑了」
• 我在 GitHub 上，亲手读了一遍那份协议
• Vaultwarden：68,798 星的反讽
• 信任从来不在许可证里

---

一条公告，两个版本

10 月 9 日，Bitwarden 社区论坛出现了一条帖子，标题平平无奇：「Published version update in app stores」。

发帖人是 Bitwarden 官方员工 RyanL，正文第一句是：

Starting in the next release, the Bitwarden apps published to the various stores will be the commercially licensed builds.

从下一个版本开始，各大应用商店里的 Bitwarden，将是商业许可的构建版本。

一句话，信息量很大。让我把它拆开：

• 应用商店里的官方 App，以后是商业许可的——不再是 GPLv3
• GitHub 上的源码仓库还在，GPLv3 版本还在更新
• 但新功能会「case-by-case」决定归哪个许可——翻译：以后有的新功能，只进商业版
• 免费计划「永久保留」

Bitwarden 特意在编辑里加了三行安抚：

Bitwarden 没有闭源 / 你仍然可以 fork / 自托管不受影响，许可变化针对的是重新打包转卖的人。

听起来很温和。但 HN 上 260 分、192 条评论的反应，一点都不温和。

双许可的物理边界：一个目录的事

先搞清楚「双许可」到底长什么样。Bitwarden 的 clients 仓库根目录摆着三份文件：

• LICENSE.txt —— 总纲：仓库默认 GPLv3，除非文件头指定其他许可
• LICENSE_GPL.txt —— GNU GPL v3.0
• LICENSE_BITWARDEN.txt —— Bitwarden License Agreement v1.0

而那个「其他许可」的物理边界，是一个目录：

bitwarden_license/
├── bit-browser
├── bit-cli
├── bit-common
├── bit-desktop
└── bit-web

bitwarden_license/README.md 只有一句话：这个目录下所有代码，都按 Bitwarden License Agreement 授权。

注意到没有——这个目录里装的全是客户端：浏览器扩展、桌面 App、CLI、Web。密码管理器的客户端，恰恰是用户每天手指碰到的那层。

Bitwarden License v1.0 是什么？我读了原文，核心几条：

• 商业模块只能用于内部开发和测试，不能上生产
• 不能转卖、租借、分发、再许可给第三方
• 不能用它开发竞品
• 不提供维护和支持

翻译成人话：代码你随便看，但想把它变成你的产品——不行。想用它做个竞品密码管理器——更不行。

这跟「闭源」的区别在哪？区别在于：闭源是你看不到，双许可是你看到了但用不了。

社区的两极：从「理解」到「该跑了」

HN 的评论区，基本是两种声音对撞。

一种声音是「理解，但不妨碍我留下」：

我确实更希望它完全开源，但「全部源码可见 + 部分商用受限」仍然比彻底闭源好得多。开源的资金和激励问题至今无解。

只要所有源码继续可见、个人自托管仍然可行，我会继续订阅。

另一种声音是「这就是 enshittification 的开始」：

又一个 elasticsearch、terraform、redis。开源在试图保护自己不被薅羊毛。

新功能进了商业许可，剩下的会慢慢被冷落。是时候跳船了。

问题在于这个许可变更不可执行——现在开发者都觉得自己能 vibe-code 出自己的版本。用不了多久就会出现「OpenWarden」，就像我们从 Redis 迁移到 Valkey 一样。

如果移动 App 不再能从源码构建，自托管的故事就薄了很多。

而最扎心的一条，来自一个自托管老用户：

我为 15 人的团队跑 Vaultwarden 好几年了——客户端才是杠杆，不是服务器。如果客户端停止可从源码构建，自托管就完了。

这句话点破了整个事件的关键：Bitwarden 的服务器端一直有 Vaultwarden 这个开源替代，社区真正依赖的是官方客户端。现在商业许可的刀，恰好落在客户端上。

我在 GitHub 上，亲手读了一遍那份协议

写这篇文章之前，我把 LICENSE.txt、LICENSE_GPL.txt、LICENSE_BITWARDEN.txt 各拉下来读了一遍，又翻了 bitwarden_license/ 目录。

现场验证的结论：

1. 仓库确实还是「开源」的 —— pushed_at: 2026-10-10T14:32:36Z，昨天还在更新。13,952 星，2,086 fork。源码完整可读。
2. 但「默认 GPL」这个说法有个漏洞 —— 总纲说「默认 GPLv3，除非文件头指定其他许可」。而 bitwarden_license/ 目录整个就是「其他许可」。也就是说，新功能只要放进这个目录，就自动脱离 GPL。
3. 「所有当前功能两个版本都有」这句话，正在被时间侵蚀 —— RyanL 在评论区承认：「一些未来的组件会以商业许可发布，只存在于那个构建里。新功能的许可逐案评估。」

「逐案评估」——这四个字才是真正的变化。过去是「先开源，后考虑商业化」；现在是「先定商业价值，再决定要不要开源」。顺序一颠倒，性质就变了。

Vaultwarden：68,798 星的反讽

现在到了整件事最讽刺的部分。

Bitwarden 官方 clients 仓库：13,952 星。

它的非官方替代服务器 Vaultwarden（dani-garcia/vaultwarden，Rust 写的 Bitwarden 兼容服务器）：68,798 星，是官方的 4.9 倍。fork 3,296，最近提交就在今天。

一个「非官方替代品」比「官方仓库」多出近 5 万颗星。这本身就是一个信号：很大一部分 Bitwarden 用户，早就把「信任」寄托在了一个与官方无关的实现上。

Vaultwarden 的许可证是 AGPL-3.0——比 GPL 更严格的那一档，专门堵 SaaS 商用后门。它用最「左」的许可证，做最「右」的事：让你完全掌控自己的密码。

而 Bitwarden 这边，官方一边说着「我们仍然承诺开源安全与透明」，一边把商店构建切成商业许可。两种姿态放在一起，社区会怎么选，其实不用猜。

在国内的自托管圈子里，这条路径走得比国外更早也更彻底。中文社区里「密码管理器」的讨论，绕不开两个名字：Bitwarden 和它的替代品。少数派这类效率工具媒体早几年就科普过 Vaultwarden 的部署方式——一个 Docker 命令，把自己变成密码库的主人。国内用户对「数据不出境」的敏感，加上对商业公司数据政策的天生警惕，让 Vaultwarden 在这片土壤里长得格外快。当官方把客户端切成商业许可时，国内社区的普遍反应不是「要不要跑」，而是「早跑完了」——docker-compose.yml 里躺着的那份，从来就不是官方的那个。

更微妙的是历史回声。2015 年，Kyle Spearrin 开始做 Bitwarden 这个业余项目，最初的动机就是担心 LastPass 换了东家之后会变坏。十年后，Bitwarden 自己在 2022 年拿了 1 亿美元的 Series B（PSG 领投），换了 CEO——新 CEO 的 LinkedIn 简介第一条写着「M&A 经验，直接参与 PE 收购」。然后「Always free」从官网消失了，Premium 涨价了，现在客户端双许可了。

那个担心 LastPass 变质的人，亲手造出了下一个让人担心会变质的对象。这个循环，密码管理器用户应该很熟。

信任从来不在许可证里

所以 Bitwarden 到底做错了什么？

往轻了说：它什么都没做错。代码还开着，GPL 版本还更新，自托管没受影响。往重了说：它把「读的自由」和「用的自由」拆开卖了，而且刀落在了信任敏感度最高的那层——客户端。

密码管理器不是普通软件。用户把全部数字人生的钥匙交给它，唯一的要求是「这东西不会在我不注意的时候变坏」。当官方开始对「变坏的可能性」做商业评估时，用户的第一反应不是读许可协议，而是问「我该跑了吗」。

HN 上那条评论说得最透：

信任不是从许可证里长出来的，是从行为里长出来的。

Bitwarden 在公告里反复强调「我们仍然是开源的」——这话技术上没错，但行为已经在往另一个方向走。而社区用 6.9 万颗星告诉它：我们早就看懂了，而且我们给自己准备了备胎。

下一个会是谁？当「逐案评估」成为开源公司的新常态，每一个你正在用的开源工具，都可能是下一个 Bitwarden。区别只在于：你有没有备胎。