【开源许可】Redis收紧了许可条款，基本上不讨好任何人

自由／开源软件开发人员必须吃饭，但用户需要确定性

领先的内存数据库供应商Redis正在转向双许可证方法，实施更严格的条款。
这一变化的官方公告切中要害：

从Redis 7.4开始，Redis将在Redis源可用许可证（RSALv2）和服务器端公共许可证（SSPLv1）下获得双重许可。

这不是Redis第一次重写其条款。早在2018年，它就调整了一些模块的许可证，这让不少开源名人感到不安。

Reg以前曾将Redis描述为“世界上最流行的数据库——如果，也就是说，您的世界完全在AWS中”。以前，Redis的源代码是在BSD 3条款许可证下提供的，这是一个允许开发人员免费商业使用代码的许可证。

在这一变化之后不久，另一家大型NoSQL数据库供应商MongoDB也对其许可证进行了全面检查，以减少对其代码的商业利用。它创建了一个新的许可证，称为服务器端公共许可证——这不受一些开源人员的欢迎。即使如此，几年后，Elasticsearch也采用了SSPL——这再次让一些纯粹主义者感到沮丧。

这个有争议的SSPL许可证是Redis在双许可证方法下采用的两个许可证之一，以及自2018年以来它一直在为其一些模块使用的相同RSAV。

该更改将从Redis 7.4版开始生效，我们预计多个Linux发行商将从其代码库中删除Redis。关于openSUSE和Fedora邮件列表的讨论已经开始。

然而，中断可能是适度和暂时的，因为替代方案已经可用——例如仍然由BSD授权的分叉KeyDB。还有微软的Garnet，尽管它有用C#编写的缺点。另一种Redis替代品Dragonfly不太可能出现，因为它被HashiCorp最近采用的BSL覆盖。

对Redis决定的一个可预测的反应是HashiCorp的Terraform发生了什么：代码被分叉为OpenTF，后来更名为OpenTofu。

这些变化反映了FOSS社区越来越绝望地试图让开源付费，这甚至导致开发人员破坏他们自己的代码。其他人停止提供免费的社区支持，而一些人正在尝试赞助方式。

SSPL非常接近GNU Affero通用公共许可证（AGPL），并包含其中的大部分文本–正如您从该比较中看到的那样[PDF]。SSPL的重要区别在于其第13条，其开头为：

如果您将程序的功能或修改版本作为服务提供给第三方，则必须根据本许可证的条款，通过网络免费下载服务源代码给每个人。

传统的GPL要求，除其他外，如果您为用户提供可执行的二进制代码，则还必须为他们提供源代码。早在2007年，AGPL扩展了这一点，因此如果您通过网络为用户提供该代码的功能，则还必须为他们提供源代码，如tldl Legal解释道。

AGPL是SaaS应用程序的GPL：它关闭了GPL中的漏洞，即SaaS供应商没有分发他们的代码。当AGPL还是相当新的时候，这有时是有争议的——有时仍然是。

SSPL扩展了AGPL，因此您不仅必须提供应用程序本身的源代码，还必须提供围绕它构建的整个服务：

“服务源代码”是指程序或修改版本的对应源，以及用于使程序或修改的版本作为服务可用的所有程序的对应源。

这是开源人士感到不安的部分。根据开源倡议行业守护者的说法，SSPL不是开源许可证。它提醒我们，大供应商是多么害怕“病毒式”GPL。

它还让我们想起了最近发生的关于Red Hat更改其源代码可用方式的事件。上个月，这只秃鹫被邀请在布鲁塞尔举行的FOSDEM会议上登台表演，这让他感到震惊——主要是因为他觉得有必要为红帽辩护，使其免受“公开洗涤”的指控

Stack Exchange 上关于AGPL和SSPL之间的重要差异的类似争论将继续。如果OSI说软件是开源的，那么软件就是开源的，但我们认为重要的是要记住，开源与自由软件不同。
从自由软件中赚钱没有什么错。甚至理查德·斯塔尔曼也这么说。

如果这样的许可证有助于软件供应商从他们的努力中赚钱，那是一件好事。如果他们能够做到这一点，并防止价值数十亿美元的企业利用这些产品和公司，那么，对于这位作家来说，这更好.