从下一个版本起，发布到各大应用商店的比特沃登（Bitwarden）应用将采用商业许可构建版，无需操作，功能与现在相同。比特沃登称仍致力于开源安全与透明，GPLv3 开源版本继续在 GitHub 更新发布，所有功能两版皆有，许可详情见 GitHub，免费方案永久保留；并说明不会闭源，仍可 fork，自托管无变化，许可调整只影响重新打包和转售者。

RyanL 的发帖（1 天前）

大家好！

从下一个版本开始，发布到各个应用商店的 Bitwarden 应用将是商业许可构建。无需任何操作，这些应用的使用方式和今天完全一样。

• Bitwarden 仍致力于开源安全与透明
• GPLv3 OSS 许可版本会继续更新并发布在 GitHub 上
• 所有当前功能在两个版本中都可用
• 许可证细节见 GitHub
• Bitwarden 仍致力于为所有人提供强大且永久免费的套餐

如果有任何问题，请在这个帖子中提出。谢谢大家！

编辑补充：

• Bitwarden 不会闭源
• 你仍然可以 fork Bitwarden
• 自托管没有变化，此次许可变更只影响那些重新打包并转售 Bitwarden 的人
• 免费套餐会永久保留

grb 的发帖（1 天前）

Bitwarden 下载页面 上的 Portable Desktop App 链接 下载到的构建，会是商业许可还是 OSS 许可？

这两个并行版本之间会有什么差异？

RyanL 的发帖（1 天前）

部分未来的组件会以商业许可发布，并且只存在于那个构建中。新开发的功能会逐个评估，决定适用哪种许可证。

RyanL 的发帖（1 天前）

这是个好问题。我会去确认这些信息。

编辑：下载页面也会直接链接到商业许可证。

grb 的发帖（1 天前）

啊，原来“current（当前）”这个词在前面那句话里承担了很重的分量：

不过，那些被排除在 GPLv3 OSS 许可构建之外的新功能，还会是开源的吗？

grb 的发帖（1 天前）

既然已经有很多功能仅对 Premium 订阅解锁，现在会不会最多出现四个功能层级（如下表所示）；如果是，会不会最多有四个不同的定价档位（其中至少包含一个“Free”选项）？

| 相对成本 | GPLv3 许可证 | 商业许可证 | | --- | --- | --- | | 非 Premium | 免费 | ？？？ | | Premium | $ | $$$ |

社区整体对 Bitwarden 把部分代码/新功能迁到商用许可感到失望和警惕，多数人把它看作拿了风险投资之后又一次“变味”，担心自托管、客户端构建与信任被逐步削弱；但也有少数人为其辩护，认为这是开源项目被云厂商白嫖、捐赠无法覆盖资本成本后的合理自卫。分歧主轴在于：这是可持续商业化的必要一步，还是借许可变更慢慢收回开源承诺、牺牲自托管者的可验证性。

认为这是“变味”和走向封闭，自托管与替代方案才是出路

• 批评者把这次许可变更和 Elasticsearch、Redis、Terraform 的遭遇类比，认为拿了投资后走向“源码可见但商用受限”几乎是必然；新功能会进商业许可，开源侧会被慢慢冷落，自托管故事每一步都在变差。真正的杠杆不在服务端而在客户端：一旦移动应用不再能从源码构建，即便服务端还能自建，自托管也名存实亡；而且官方即便承诺保留开源通道，用户也不再能验证构建。自建这类服务本身还有很强的安全维护要求，分叉客户端也意味着要转而信任未来的维护者，因此不少人开始推荐 Vaultwarden、Keyguard、KeePassXC、PearPass 等替代方案，有人甚至期待 Rust 版 Vaultwarden，或干脆改用 Apple/自同步；也有人表态愿意出资支持承诺持续发布自由构建、不玩这类花招的项目。（较多人） > 真正要盯的是客户端而不是服务端：如果移动应用不再能从源码构建，自托管的故事就会薄很多。（@hn3ufz62f7）

认为这是融资后不可避免的商业化，根源是云厂商白嫖与开源资金无解

• 理解者认为，拿了风险投资的钱就迟早要走向更严格的许可；大厂靠分发和品牌直接把 Elasticsearch、Redis、Terraform 这类开源代码拿去赚钱并反噬原项目，捐赠和小额订阅根本覆盖不了 Bitwarden 这种规模的资本开支，所以“源码仍可见＋限制商用”已远好过彻底闭源，继续订阅也说得通。（少数人） > 只要源码还能拿到、个人自托管仍可行，“源码可见＋限制商用”也远好过彻底闭源，因为大公司白嫖才是开源激励问题的核心。（@dannyw）

认为许可变更挡不住分叉，大语言模型时代社区复制会很快抹平商业优势

• 也有人怀疑这类许可根本挡不住社区：在大语言模型时代，任何被放进开源侧的商业功能都可能被迅速“提示”出来，分叉只是时间问题，预计会出现 OpenWarden，就像 Redis 变成 Valkey。（少数人） > 在大语言模型之后这种商业策略行不通：任何放到开源侧的商业功能，都会立刻被人用提示词复制出来。（@charcircuit）

认为普通用户其实不必恐慌，只要别重蹈 LastPass 覆辙

• 也有用户认为，对只把 Bitwarden 当成熟产品用的普通人来说，许可条款本身并不是大事；多年付费订阅者关心的是它继续稳定好用，只要不出现 LastPass 那种安全事故或明显背刺，就不必急着迁移。（少数人） > 除非他们搞出 LastPass 那种事，否则对普通用户来说并不是什么大事。（@caaqil）

接受涨价和商业化，但反对用许可变更慢慢收回开源承诺

• 中间派表示，随着时间推移为优秀产品多收费完全可以接受，但把涨价、改许可和“逐案决定是否回到开源”绑在一起，会让人感觉是在悄悄走向并购/收割，而不是诚实提价。（少数人） > 能理解他们需要提价，但把涨价、改许可和“逐案决定是否回到开源”绑在一起，感觉就是在慢慢抽走开源用户的地毯。（@andrewjneumann）

认为官方解释糟糕，按文件混用许可在 GPL 下存疑

• 还有开发者表示根本没看懂动机和具体变化：代码库被拆成两种许可、每个文件二选一，却声称最终应用适用商用许可而非 GPL，这让 GPL 是否允许此类操作、是否等于拿 GPL 代码给自己赚钱变得很可疑。（少数人） > 我有点困惑他们到底在做什么：代码现在被两种许可覆盖，每个文件二选一，他们却声称最终应用适用的是 Bitwarden 商用许可而不是 GPL；这到底怎么运作，GPL 真的允许吗？（@contravariant）

有价值的补充

• 技术上，官方浏览器扩展被批评太重：只为显示一个小弹窗却加载完整 JavaScript 框架；若基于开源代码重写，点击后的加载时间可压到 100ms 内，而官方版在 M1 Max 上都很慢。
• 实践上，Vaultwarden 是与 Bitwarden 协议兼容的自托管服务端，但它与官方客户端存在摩擦：iOS 客户端自动更新可能破坏与自建服务器的兼容，需要同步更新 Docker 实例；自建这类服务本身还有很高的安全维护门槛。
• 类比上，这种“一个协议分裂出多个服务端和客户端实现”的局面让人想起 Subsonic；也有人因此期待 Rust 版 Vaultwarden 或第三方浏览器扩展来填补官方客户端的体验缺口。