多年开放之后又毅然决定采用”私有“模式，一年多之后再次回归开放路线，作为当前广受欢迎的即时信息管理系统 Redis 的最新变化，再次在技术界掀起波澜，吸引了很多目光。
有人质疑，从「公开 → 私有 → 再公开」，Redis 的路线是否过于反复无常，这种变化，究竟是对环境的让步，还是一次延后的调整？又会有多少技术人员愿意因此重新加入？
从 Redis 8 起，重新开源！
记得去年三月，Redis的负责人Rowan在官方网站公布了一项消息，内容是《Redis将采用双源许可证》，说明从Redis 7.4版本开始，它将不再使用一直以来的开源BSD三条款许可，而是转变为使用（Redis源代码可用许可证）和（服务器端公共许可证）的“双重授权”方式。
很多人感到难以认同的是，这两种许可证并非 OSI 组织认证的开放源代码许可，而且它们都带有各自的约束条件。使用时，用户不得将软件用于商业目的，也不得将其作为服务提供给第三方，同时不允许移除或遮盖任何许可、版权等信息；而若将产品用作服务，则必须在 SSPL 条款下公开所有修改内容以及管理组件的源代码。
概括来说，由于 Redis 更换了开源许可协议，根据 OSI 的标准，它已经不再被归类为开源项目。
一年之后，在最近的五一假期里，Redis 生态领域的两位核心人物——项目发起人（网名）与 Redis 现任领导者 Rowan 紧接着发布了两篇文章，一篇题为《Redis 重启开源计划》，另一篇名为《Redis 已转入开源许可体系》，表明从 Redis 8 版本起，该项目正式开始“再次开源”。
当前开发者有三种授权方式可供选择,用以采用 Redis 8 及其后续版本,这些授权方式包括三种不同的许可证,开发者可以根据需求挑选其中一种来使用 Redis 8 及以后的版本
Redis CEO：选择 SSPL 后，我们后悔了！
这种变化的原因，Redis的负责人Rowan在最新文章中说明，当初决定采用私有化模式，确实伤害了与Redis群体的联系，他对此表示了歉意。
从商业角度来看，不少公司其实明白 Redis 当初的决定。Redis 团队持续投入研发与维护，但最终却只能眼看着项目被云服务商当作底层设施进行商业运作，却很少得到应有的回报。
正如他指出的那样：超大规模云服务商例如 AWS 和 GCP 的兴盛，让新兴企业和行业巨头获得了极快的成长和巨大的发展空间。然而，这对那些以开源技术为核心的公司构成了严峻的考验：当云平台公司利用开源项目获取利益却不给予任何支持，并且掌握着相关设施的关键权限时，这些开源项目将如何得到持续的创新和资源投入？应对这一挑战，若干企业选用了 SSPL，即服务器端通用授权条款，意图阻止云服务提供商在未提供任何反哺的情况下，获取其研发成果的权益。
因此，Redis 团队起初采取了某种看似平衡的方案：他们发布 Redis Stack，把一些复杂功能放到单独的版本里，并且采用了约束性更强的授权条款。
然而，这种做法在短期内确实在一定程度上维护了 Redis 的创新活力，却引发了显著的负面效应：同时支持两个版本（Redis 社区版与 Redis Stack）不仅增加了开发难度，也造成了社区感受的分离，进而迟缓了核心功能的前进步伐。归纳起来，我们迫切要找的，是那种能直接强化 Redis 核心性能，而非需要同时维护两个版本的方法。
一年评估过后，他最终于 2024 年 3 月正式决定，要把 Redis 全部换成 SSPL 许可证。他坦言，这种做法虽然部分达成了目的——现在 AWS 和 都在照管自己的 Redis 分支，不过也带来了损失：SSPL 并非 OSI 认可的真正开源许可，这次更动使咱们和社区的联系受到了很大影响。
实际情况表明，Redis 组织未能预料到社群的强烈反应。众多技术员觉得遭受了背叛，特别是那些曾经向 Redis 投入过代码的个人。他们不仅对商业化的决定感到不满，还在思考 Redis 公司是否还能称作具备开源理念的机构。还有技术人员直言不讳地表示：“当前运营 Redis 的组织并非其奠基者，其本质源自某个地方。”
为了抵制 Redis，各种分叉项目如雨后春笋般出现：
一时之间，Redis 社区陷入分裂。
Redis 的内部与外部冲突不断加剧，就连多年未曾露面的创始人也终于按捺不住，主动找上门去联系了 Rowan，决定重返 Redis 社区，出任 Redis 公司的技术推广代表，以便和 Rowan 一道探讨 Redis 的未来走向。
Redis 之父回归五个月后，推动 Redis 再开源
Redis 这次决定再次进行开源，是在它成为 Redis 公司成员五个月之后出现的，不难推测，其在此期间付出了多少心血。
对于这一转变，Redis 之父 发文分享了他的心声：
五个月前，我重新接触了 Redis，随后便和同事们探讨过是否要换成 AGPL 许可证，没想到公司内部对此早有商议，而且讨论已经持续了很长时间。
公司内部不少人士认为 AGPL 比 SSPL 更为适宜，尽管 Redis 最终采用了 SSPL，但组织内部的探讨并未就此终止。
我努力增强 AGPL 支持者的声势，SSPL 在实际运用中并未得到社区认可，OSI（开放源代码促进会）也未将其视为开源许可，软件界同样不这么看，这个观念很快在公司内部各层面获得越来越广泛的赞同。
我必须直言不讳：我热切期盼为新的 Sets 数据类型所撰写的程序能够采用开源授权方式发布。投身于开源项目早已成为我职业生涯中不可或缺的一部分，我几乎从不参与开发私有软件。此刻要求我转变已经为时已晚。或许这显得有些天真，但我正是基于预见 Redis（以及我的新职位）即将重归开源项目，才怀着无比的热忱完成了 Sets 的开发。
我明白，我们的主要任务是使 Redis 更加出色——它是一个实用、易用、能适应不同软件架构需求的卓越平台。然而，参照开源协议，这是确保我们的工作与 Redis 项目整体保持一致，赢得用户认可，并汇入超越任何单一企业协作的基础。
因此，尽管我无法将许可证变动的成就归功于个人，但我期盼自己多少尽了些绵薄之力。由于今日我倍感欣喜——Redis 再次转变为开源项目，并以许可证这一载体得以实现。
此刻，应该进入控制台，用最优美的指令，向 Redis 使用者表达敬意了。我还打算对集合类型进行优化，使其功能更强大、应用更便捷。脑海中储备了许多构思，期待大家的意见能引出更多灵感（事实上已经有所启发了）。
目前，Redis 方面不仅公开了 Redis 8 的开源信息，还推出了若干重要举措，旨在促进 Redis 的后续进步，包括但不限于，
开发者：被骗一次是无知，被骗两次就是愚蠢
Redis 这番转变，表面上是宣称要回归开源理念，但实际仍引来不少反对意见。许多开发人员对 Redis 不断更改的做法感到不满，认为已经太晚了。
一位曾经做过贡献的开发者 c0l0 在 HN 上留言：
我以前在 Redis 采用原始授权协议期间，提交过一项微不足道的优化（虽然改动不大，但自认为挺有价值）。后来他们突然决定改用 SSPL 协议，我因此决定不再使用它——作为曾经真心实意支持过这个完全开源项目的参与者，那一刻我深感失望。（坦白说，倘若他们最初就选择 AGPL 授权，从原则上我完全能够理解。）
我十分敬重他，并且觉得他在自由软件界是个心地善良且仁爱之人。不过不管 Redis 公司发布什么言论、采取什么行动，他们都已经完全丧失了我的信任。只要 Redis 的分支版本还在，我就会持续使用它。
另有一位网友也提及，他们先前在相应地点观赏过此事：企业擅自调整了相关执照，居民们集体表示异议，最终企业承受了压力后将执照恢复原状。这两家企业给出的理由也完全相同，声称“尽管经历诸多波折，但最终达到了预期效果”，“我们已经实现了目的”。
然而，任何一方都没有创设相应的法规体系来预防将来可能出现的冲突，并且两家企业都表明了自身并非可靠的守护者，他们在意识到社群的拥护确实关键后，才卑躬屈膝地寻求和解，但此时情形已然是“被欺骗一回是懵懂，被欺骗两回便是愚钝”了。」
有网友表示，自己也有同样的看法，虽然他敬佩对方以及对方所付出的努力，但这次重新邀请他，给人的印象像是 Redis 公司在做出一个愚蠢的选择后，试图用这种方法吸引开发人员回到旗下，毕竟目前已经有许多可以替代的方案，实在不明白为何还要在 Redis 上继续耗费精力（他们已经转向了另一种技术）。
毫无疑问，Redis 这次重新投入开源社区，影响深远。然而，一旦信任被破坏，就很难重建。许多开发者已经将分支项目当作首选方案。至于 Redis 能否凭借诚意和努力重新赢得社区的支持，还有待进一步观察。
对此，你怎么看待 Redis 的“再开源”行为？
参考：