Bitwarden 双重许可模式

原文 ↗ Hacker News 讨论 ↗

Bitwarden 转向双重许可模式后，未来功能可能以商业、闭源许可发布，而核心代码仍保持开源，这引发了人们对其逐渐偏离开源根基的担忧。评论者争论这究竟是为了应对资金需求和大型云厂商对 OSS 的“白嫖”，还是由私募股权和涨价推动的经典“烂掉化”开端。许多人正在考虑 Vaultwarden、基于 KeePass 的工具、Proton Pass，或 Apple 自带的密码管理器等替代方案，并质疑在当前商业压力下，真正开放、值得用户信任的密码管理器是否具有可持续性。

变更范围与动机

  • Bitwarden 正在转向一种双重许可 / 类开源核心（open-core）的模式：现有开源代码仍然保留，但未来某些组件/功能将仅采用商业的、可获源码但受限的许可。
  • 官方解释比较含糊；几位评论者表示，其理由（“为什么是现在，究竟改变了什么”）沟通得很差。
  • 有人认为此举是为了防止大型云服务提供商“吸血”式地利用 OSS（Elasticsearch、Redis 的模式）。也有人认为这纯粹就是“他们想赚更多钱”，以及与私募股权/VC 回报有关。

信任、“烂掉化”，以及 VC 担忧

  • 许多人把这看作“温水煮青蛙”式烂掉化的开端：今天是双重许可，明天是企业专属功能，再之后就是放弃 OSS 路线。
  • 新管理层带有私募股权背景，这让人们对长期方向和定价更加担忧。
  • 一些付费订阅用户目前还可以接受，只要没有明显的对用户不友好的举动就会继续使用；另一些人则因信任破裂而立即取消订阅。

自托管、Vaultwarden 与客户端

  • Vaultwarden（Rust 编写、自托管、与 Bitwarden 兼容）被广泛讨论为替代后端；它因资源占用低以及自带“高级”功能而受到好评。
  • 关键风险在于：真正的杠杆在官方客户端（浏览器/移动端）。如果它们不再是 OSS、无法构建，或者破坏协议兼容性，自托管就会变得脆弱。
  • 有人预计，一旦不兼容不断增加，最终会出现一个生态分叉（服务端 + 客户端）；也有人提到借助 AI 重新实现，但认为这在法律和实践上都颇具疑问。

替代方案与迁移思路

  • 常见建议包括：KeePassXC + 移动客户端（KeePassDX、KeePassium）配合 SyncThing/WebDAV/OneDrive；Proton Pass；1Password；Enpass；Apple Passwords/Keychain；pass/gopass；AliasVault；以及各种纸质/离线工作流。
  • 讨论到的权衡包括：易用性、自托管负担、缺乏 SSO、闭源、平台锁定，以及缺少如 YubiKey 支持或 passkey 迁移之类的功能。

安全与托管之争

  • 关于托管、自托管与完全离线的密码管理，争论十分激烈：
    • 有人认为任何托管型密码管理器都等同于公开密码；也有人强烈反对，认为这是缺乏信息安全常识的说法。
    • 一些人把自托管视为主权的核心；另一些人则认为，与信任一个专业安全团队相比，自托管带来的风险和维护成本是不必要的。
    • 人们还在争论设计差异（单一主密码 vs 额外秘密/密钥、2FA/YubiKey 的作用、围绕入侵和政府访问的威胁模型）。

OSS 许可、CLA 与可持续性

  • Bitwarden 的贡献者许可（将版权转让给公司）被指出是其能够重新授权的原因。
  • 更广泛的观点是：许多人注意到，大型 OSS 项目需要真正持续的资金支持；捐赠通常无法覆盖真实成本，因此往往只能依赖 VC 或企业支持，以及随之而来的许可收紧。