Redis 采用双重源代码可用许可

原文 ↗ Hacker News 讨论 ↗

Redis 有哪些变化

  • 核心 Redis 从 3-clause BSD 改为双重许可：
    • SSPLv1 作为源代码许可（copyleft，未获 OSI 批准）。
    • RSALv2 作为“source-available”使用许可，限制“竞争性产品”（例如 Redis-as-a-service）。
  • 博客和 FAQ 强调：
    • 自托管 / 内部使用仍然免费。
    • 托管服务提供商要么遵守 SSPL（公开其整个服务栈），要么签商业协议。

对用户和发行版的影响

  • 大多数评论者认为：
    • 把 Redis 作为依赖项的普通应用开发者在法律上不受影响。
    • 提供类似 Redis 服务的 SaaS/DBaaS 产品面临很大的法律/运营风险。
  • 许多人预计：
    • Linux 发行版（Debian、Fedora 等）会像对待 MongoDB 一样，把 Redis 下架或移到 non-free 仓库。
    • 用户会越来越多地通过厂商镜像/容器安装，或切换到分支/替代方案。
  • 也有人担心最后一批 BSD 许可版本及其回移补丁的长期安全更新问题。

信任、治理与贡献者反应

  • 一些人把这看作“诱导后反转”：
    • 之前公开保证核心会保持 BSD 许可并采用“社区主导”治理，与突然重新许可以及治理页面被移除形成对比。
    • 新的强制 CLA 让 Redis 能够重新许可未来的贡献；一些贡献者表示他们会停止贡献。
  • 另一些人则认为：
    • BSD 明确允许这样做；贡献者本应了解这种风险。
    • 这个项目一直都在很大程度上受收购商标的公司影响。

分支与替代方案

  • 讨论了多个分支和替代方案：
    • 在变更前的提交上冻结的 BSD 分支。
    • 正在开发中的社区分支（“redict”）在 Codeberg 上。
    • 可直接替换或协议兼容的选项：KeyDB（有 MIT/BSL 历史）、Dragonfly（BSL）、Microsoft Garnet（MIT）、Memcached，以及各种 Redis 协议后端（例如 kvrocks）。
  • 许多人预计，一个由云厂商和前核心开发者支持的强势分支会成为事实上的“开源 Redis”，并引用 MariaDB、OpenSearch 和 OpenTofu 作为先例；但也有人指出，并非所有分支都会成功。

云厂商与公平性

  • 一派观点：
    • 认为 SSPL/RSAL 是对“巨型云公司寄生者”合理的防御，这些云厂商几乎不为 Redis 提供财务支持，却拿去转售。
    • 认为可持续的 OSS 商业模式需要截取部分托管收入。
  • 另一派观点：
    • 反驳说，大型云厂商确实贡献代码和工程师，并且是在 BSD 赋予的自由范围内运作。
    • 认为真正的问题是风险投资支持的“卖支持/卖托管”模式，而不是 OSS 本身。

许可理念与 OSI 争论

  • 普遍同意 Redis 按 OSI 定义已不再是开源；它现在是“source-available”。
  • 争议在于：
    • 有人称 SSPL 是“更真正的 copyleft”，并符合自由软件目标（强制整个服务开放）。
    • 也有人说 SSPL 施加了不可能满足的义务（例如所有“hosting software”），本质上是一种按用途限制。
  • 讨论串突出显示了以下概念的混淆：
    • “permissive” 与 “copyleft”。
    • “open source” 与 “source-available”。
    • “free as in beer” 与 “free as in freedom”。

FOSS 商业模式的可持续性

  • 反复出现的主题：
    • 在云竞争下，open core 和托管服务往往失败；收紧许可（Redis、HashiCorp、Elastic、MongoDB）被视为一种“权利棘轮”。
    • 基金会并非灵丹妙药，但常被拿来与（Postgres、Kubernetes、Linux）相比，作为比 VC 支持公司更稳定的长期维护者。
  • 提出的替代方案：
    • 从第一天就使用 AGPL。
    • 将核心交给中立基金会；通过专有扩展或 SaaS 层变现。
    • 让主要用户通过直接资助和内部贡献成为常态。
  • 对未来的看法分歧：
    • 有人预测会从 FOSS 退回到专有/shareware。
    • 也有人认为，这一事件会促使更早分支、以及更谨慎的许可选择，而不是终结大规模开源。