SSPL 不是开源许可证

我们已经看到，一些公司放弃了他们最初对开源社区的奉献，将其核心产品从开源许可证（由开源促进会批准的许可证）转变为“伪开源”许可证。伪开源许可证的标志是，那些进行转换的公司声称他们的产品在新许可证下仍然保持“开放”，但新许可证实际上剥夺了用户的权利。

 

目前流行的许可证是服务器端公共许可证 (Server Side Public License)。该许可证已提交给开源促进会以供批准，但后来 被许可证管理员撤回，因为很明显该许可证不会获得批准。

 

开源许可证是开源软件生态系统的基础，该系统促进和便利了软件的协作开发。伪开源许可证允许用户查看源代码，但不允许开源定义（Open Source Definition）保护的其他高度重要的权利，例如在任何领域中使用该程序的权利。正如最近的采用者 Elastic 在一篇题为“加倍投入开放”的帖子中不无讽刺地解释的那样，Elastic 表示，它现在可以“限制云服务提供商以服务形式提供我们的软件”，这违反了 OSD6。Elastic 并没有加倍投入，而是放弃了。

 

软件共享领域也因此变得更加贫乏。Elastic 项目是在 Apache 许可证下提供的。外部贡献者投入了时间和精力，并理解他们的工作是为了更大的利益，即公共软件共享领域。现在，相反，他们的贡献被嵌入到专有产品中。如果他们想享受自己和共同贡献者劳动的成果，他们必须同意专有许可证或进行分支。

 

这并不是说 Elastic 或任何公司不应该采用适合其自身业务需求的任何许可证。那可能是专有许可证，无论是闭源的还是源代码可用的。开源促进会坚信，开源开发模式是开发软件的更好方式，并能产生更优质的产品。但我们也认识到，这并非在所有情况下都适合所有人。公司可能会发现，随着时间的推移，其业务需求和方向发生了变化，以至于最初的许可证选择正在干扰其商业模式。转换可能是正确的选择。

 

但 Elastic 的重新许可并非开源许可模式失败或开源许可证存在缺陷的证据。这仅仅是因为 Elastic 当前的商业模式与开源许可证旨在实现的目标不符。其当前的业务愿望正是专有许可证（包括源代码可用许可证）所设计的用途。

 

公司不得做的是声称或暗示根据未经开源促进会批准的许可证（更不用说不符合开源定义的许可证）许可的软件是开源软件。声称软件具有开源的所有好处和承诺，而实际上并非如此，这纯粹是欺骗。

 

签名，
OSI 董事会