2026 年 10 月 9 日，Bitwarden 在官方论坛发帖确认：从下一个版本开始，上架各大应用商店的 Bitwarden 客户端将换成商业许可构建，GPLv3 开源构建继续在 GitHub 上更新，两条线并行。官方在帖子中列了四条不变：源码继续公开、可以继续 fork、自托管政策不变、免费计划永久保留。
这个公告在 Hacker News 上一天内拿到 124 分和 76 条评论，讨论的焦点其实只有一个：应用商店里的那个 Bitwarden，从 GPLv3 软件变成了源码可查的商业软件，这算不算开源退场的第一步。
变更前后的差别
先把实际变化列清楚。变更涉及的是分发渠道，不是代码仓库：
| 商店版（App Store、Google Play、官网直链） | GitHub 开源构建 | |
|---|---|---|
| 许可 | 商业许可（Bitwarden License） | GPLv3（客户端）/ AGPLv3（服务端） |
| 源码 | 可查看，仓库公开 | 可查看、可修改、可再分发 |
| 功能 | 现阶段与开源版一致 | 现阶段与商店版一致 |
| 未来功能 | 部分新组件只出现在商业构建 | 逐案评估，部分功能不会进入 |
官方人员在帖子里说明了新功能的分配规则：Some future components will be published under the commercial license and will exist only in that build. Newly developed features will be evaluated on a case-by-case basis for which license applies to them. 也就是说，未来每个新组件由 Bitwarden 单方面决定放在哪条轨道，放进商业许可的组件只存在于商店版。
商业许可具体限制了什么
Bitwarden License v1.0 并不是 2026 年的新文件，它发布于 2020 年 9 月 4 日，此前只用于企业模块。条款核心有三条：
- 商业模块只授权内部开发和内部测试，且仅限非生产环境；
- 不得出售、转授权、分发商业模块给第三方；
- 不得用商业模块做竞争产品或服务。
对照 GPLv3：GPLv3 允许任何人运行、修改、再分发，唯一硬约束是衍生品必须同许可开源。两者的实际差异在再分发权：一个第三方团队此前可以把 GPLv3 的客户端重新打包上架（改个名字、避开商标），现在对商店版商业构建这样做会违反许可条款。
官方论坛里被问得最多的一个问题是：这是不是"闭源"。官方的回答是没有闭源：商业许可下的代码同样在 GitHub 公开可查，只是不授予生产环境使用权和再分发权。用 OSI（开放源代码促进会）的标准衡量，Bitwarden License 从 2020 年起就不符合开源定义，LICENSE_FAQ 里官方自己也承认这一点。
两条轨道的仓库现状
Bitwarden 的代码组织方式早就为这次切换做了铺垫。客户端仓库（bitwarden/clients）的 LICENSE.txt 写明：仓库默认 GPLv3，商业代码只放在 /bitwarden_license 目录；服务端仓库（bitwarden/server）同理，默认 AGPLv3，/bitwarden_license 目录下是企业单点登录等模块，这些模块生产使用需要付费订阅。
截至公告发出，两个仓库的许可文件没有任何变动：android 和 ios 仓库根目录的 LICENSE 仍是 GPLv3 全文。变化只发生在"哪个构建进商店"这一层。F-Droid、官方 GitHub Releases 这类渠道拿到的仍是 GPLv3 构建。
社区的三种立场
HN 评论区的分歧可以归成三类。
接受派认为这是对"白嫖式竞争"的合理防御。有人直接点名历史案例：Elasticsearch 被 AWS 拿去做托管服务逼出 SSPL 转身、Redis 的云厂商兼容层之争、Terraform 被 OpenTofu 分叉。密码管理器领域的对应场景是：第三方服务商用 Bitwarden 开源服务端搭托管、按月收费，与官方云服务直接竞争。Shield 商业许可挡的正是这类再分发。
警告派引用了安全行业的具体先例。有评论详细复述了 Coinkite ColdCard 的案例：硬件钱包固件源码公开但不含 FOSS 许可，社区没有 fork 和审计的动力，一个本可以被外部发现的低级漏洞存活到了造成数百万美元损失的那天。这个论证的逻辑是：密码管理器的安全性依赖独立审计，审计的前提是社区有法律权利运行修改后的版本；许可一旦不给这个权利，"公开"不等于"可验证"。
观望派关心自托管环境的长期演化。官方在帖子编辑区补了澄清：自托管行为不变，第三方社区服务端（Vaultwarden 这类兼容实现）可以继续按自己的节奏支持功能。但一个具体问题官方没有正面回答：商业构建独占的新功能，会不会在协议层面破坏与开源客户端、第三方服务端的互操作性。社区最担心的场景是浏览器扩展的商业版与开源服务端之间出现协议差异，让自托管体验逐步降级。
行业序列里的位置
把这次变更放进时间线，它是同一条轨迹的延续：Elastic 2021 年转 SSPL、MongoDB 2018 年转 SSPL、Redis 2024 年加 RSALv2/SSPLv1、HashiCorp 2023 年转 BUSL，然后是 HashiCorp 被收购。共同剧本是：VC 支持的开源公司面对云厂商的托管竞争，收窄许可保住商业化空间，开源社区分叉出开放替代品（OpenSearch、OpenTofu、Valkey）。
Bitwarden 的不同点在于它是消费级产品：前面几家的直接客户是企业开发者，而 Bitwarden 的商店版装在普通人的手机里。普通人不会读许可文件，也不区分 GPLv3 和商业许可——对他们来说什么都没变。真正受影响的是三层人：把 Bitwarden 开源服务端拿来卖托管的服务商（再分发被禁）、自托管玩家（现阶段无影响，未来功能可能缺席）、F-Droid 生态用户（需确认构建更新节奏）。
Vaultwarden 问题
Vaultwarden 是用 Rust 重写的 Bitwarden 兼容服务端，是自托管社区事实上的标准方案。它的法律位置在这次变更后需要拆开看：它实现的是 Bitwarden 的同步协议和 API，不包含 Bitwarden 的代码，所以 Bitwarden 商业许可约束不到它；它自己按 AGPL v3 发布（仓库 LICENSE.txt 全文为 AGPLv3）。官方在论坛里确认第三方服务端可以继续选择支持哪些功能。
真正的长期变量是客户端。如果未来某个商业版客户端功能依赖新的服务端接口，而该接口只在商业构建的服务端实现，Vaultwarden 社区就需要对协议做逆向兼容。协议目前没有加密封锁的迹象，端到端加密的设计决定了数据层面的互操作性保留在客户端本地，这层不受许可影响。
这次变更的实际边界
回到事实层面收束一下：商店分发渠道换成了商业许可构建；GitHub 上的 GPLv3/AGPLv3 构建继续更新，许可文件未变；自托管、免费计划、fork 权利都有官方书面确认；未来新功能的许可归属由 Bitwarden 逐案决定，判断标准未公开。两个构建会在功能上保持一致多久，取决于有多少新组件被划进商业许可——这个数字目前是零（官方原话：现阶段所有功能两个版本都有），未来会变成多少，公告里没有给承诺。
来源：