LWN：Elastic名为"open"实际上走向专有！

关注了就能看到更多这么棒的文章哦～

Elastic promises "open"—delivers proprietary

By Jake Edge
January 27, 2021
DeepL assisted translation
https://lwn.net/Articles/844016/

众所周知，开放源码软件可以被任何人使用，可以用于任何目的，这是开放源码定义（open source definition）的基石。但是，一些经营 open-source 项目的公司对于其他公司从这些项目中获取到了利润感到越来越不满意。这导致了近年出现了各种旨在试图将这些利润收入囊中的努力，也就是所谓的 "license reform (许可证改革)" 。到目前为止，这些做法只是产生了更多的非开源（non-open-source）许可证，从而使得项目不再符合 open source 的标准。我们最近又看到了一例，Elastic 在 1 月中旬宣布改变部分项目的许可证。

Elastic 将从 7.11 版本开始，把 Elasticsearch 搜索引擎软件及其数据可视化工具软件 Kibana 的许可证从 Apache 软件许可证第 2 版（ASL, Apache Software License）转变为服务器端公共许可证（SSPL，Server Side Public License）。同之前的版本一样，这些项目同时也拥有 Elastic License 方式，所以支持 dual-licensed。因此，不想（或无法）遵守 SSPL 的用户可以向 Elastic 购买许可。

当然，我们以前也看过类似做法，但这次 Elastic 介绍其这个改动时的遮遮掩掩的方式在 FOSS 社区内引起了麻烦。很明显，该公司对亚马逊网络服务(AWS)将 Elasticsearch 和 Kibana 变成与 Elastic 自己的产品竞争的营利性产品相当不满。不过，不太清楚许可证更改之后是否真的就解决了 Elastic 所抱怨的问题。除此之外，AWS 在依据 ASL 选择使用这些软件模块的时候，依据的是 Elastic 允许自由使用的许可证。现在 ASL 显然不再适用于 Elastic，该公司宣称说切换到专有许可证可以 "doubling down on open，加倍开放"，这显然不是这么回事，这种说法是相当可笑的。

从法律意义上讲，Elastic 显然有权改变这些产品/项目的许可条款。但在很多人看来，SSPL 只是另一种形式的专有许可。SSPL 并没有被开源计划（OSI）批准为开源许可证，当时审查意见中明确表示不会接受它时，SSPL 的 OSI 申请就被撤回了。项目中所有贡献者都签署了一份贡献者许可协议（CLA），允许 Elastic 根据自己的需要重新授权代码，Elastic 公告声明行使了这项权利。

当然，之前在 ASL 下发布的版本仍然可以自由使用，有兴趣的开发者或组织可以从这个节点上 fork 出来并独立维护一份代码。AWS 有这样的兴趣，其实并不令人意外。它直接出面 fork 了这些项目。因此，Elastic 有可能不仅要与 AWS 的产品竞争，还要与它自己这个 project 的 fork 版本来竞争，它可能比自己维护的版本更加流行。Elastic 应该已经预见到了这一点，所以假如 Elastic 所说的是真的，那么我们无法理解它希望从中获取什么好处：

我们将继续开放开发我们的代码，与我们的社区互动，并在 Elastic 许可证下免费发布我们的版本，就像我们过去三年所做的那样。我们仍然致力于保持我们所有的免费功能–我们不会对哪些功能是免费的，哪些功能是在付费订阅中提供做出任何改变。

SSPL 是由 MongoDB 创建的，目的是希望将 copyleft 的概念延伸，从而涵盖更多的软件，而不仅仅是包含根据许可证所发布的代码。它是 GPLv3 的修改版，就像 Affero GPL（AGPL）。它针对 network service 中使用的代码部分进行了修改。AGPL 要求提供网络服务中如果修改了源代码，就必须发布出来，但 SSPL 将这一要求扩展到几乎所有相关或不相关的代码了（"包括但不限于管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件"）。此外，这些作品的源代码必须在 SSPL 下发布，而不是简单地在 FOSS 许可证下发布。

许可证中的这一条款很明显是作为 "毒丸" 来写的，以确保大型服务提供商必须使用双重许可证中的另一个许可方式，从而向许可方（MongoDB，或本案中的 Elastic）支付费用来购买其专有许可。SSPL 尚未在法庭上进行过检验，但该条款很容易被解释为服务器上的所有代码都必须在 SSPL 下发布，这对许多服务提供商来说几乎是不可能做到的。许多代码已经依据 FOSS 许可证提供了（如 Linux），但不可能简单地使用另一个许可证条款来发布。

虽然 GPL 本身将其范围扩大到了它所涵盖的代码之外（如 Matthew Garrett 在 SSPL 发布后不久所指出的那样，扩大到了构建脚本等），但这种 "范围微调，scope creep" 要比强迫人们将完全不相关的软件（比如说备份软件）发布出来影响要小得多，也更合理。SSPL 显然让使用这种所谓的开源软件的行为充满了法律风险，无论用户是不是 AWS 这个体量巨大的云提供商。实际上，如果你想使用 Elasticsearch 或 Kibana 赚钱，你就需要能够在 SSPL 下发布你使用的所有代码，否则就得从 Elastic 那里获得专有许可。

这种从开源许可证转变到不那么开源的许可证的趋势已经持续了一段时间。可以在软件即服务（SaaS）模式中使用的 project 通常在一开始是完全开源的，这通常可以得到更快采用，在投资者看来是很好的事情。但是，今后的方向上，这些投资者可能不会喜欢用户行使他们被赋予的自由权，所以这些自由就会被进一步限制了。在其他行业，这种策略被称为 "bait and switch，引诱后再切换"。

该策略是否能够成功，很大程度上取决于许可提供方（licensor）是否能够转向专有方向。它需要能够提供一些新的功能，也就是所谓的 "secret sauce"，从而让其价值超过旧版本的代码以及别人所 fork 出来的所有版本。这样一来就无法继续使用 ope-source 方式了，或者说至少是非常难以继续使用 open-source 了。很想知道这次 Elastic 是否能遵守承诺，尽管我们猜测很少有人会真正寄希望于此。

早在 2019 年年中，VM（Vicky）Brasseur 就很好地总结了这种策略的问题：

这些项目更改许可证并不是为了保护它们免受 Amazon 的影响。声称这是它们的主要目的，要么是他们太天真了，要么就是故意在撒谎。这些公司对现有项目更改许可证协议，是为了掩盖他们对如何经营成功的业务一无所知的事实。他们故意在原有许可协议下发布了他们的产品特有功能，并且也看到这样做之后竞争对手就可以利用相同的技术创造出更有吸引力的产品了。这种行为不仅是关于这些公司特意选择了什么许可证，同时也显示了他们的市场竞争力情况。唯一的问题是，这些所谓的 "open source" 公司之前没有做好这种准备，于是现在他们的应对就很糟糕。

FOSS 社区对 Elastic 公告有了迅速反馈，不少反馈都相当激烈。人们感到愤怒的部分原因是由于 Elastic 以一种欺骗性的方式使用了 "free & open source" 这样的说法。正如 Drew DeVault 所说：

Elastic 并没有被 Amazon 弄得都没饭吃了。他们去年收入 5 亿美元。不要惹炸了我们。不要把你的产品称为 "free & open"，故意用 "free & open source" 这种常用语来误导用户。你这样做是为了获得更多的钱，你这样做是为了建立对 Elasticsearch 的垄断，你这样做是不顾社区对你的信任。

他继续提醒开发者，只要签署了他们的 CLA 就会出现这样的漏洞，如果公司没有得到这些 CLA 授权，那么就不能重新更改代码许可证。他还提出，Elastic 以及其他要求签 CLA 的公司故意这么做，目的就是为了以后更改许可证。虽然不容易评判这个行为是否正确，但是公司如果确认自己永远不会更改许可证的话，就不会要求签署 CLA。因此这个工作显然是为了给今后可能做这个工作所预先进行的准备。

不过，AWS 是否是一个更加可以依赖的选手，这还有待观察。到目前为止，只有 1 月 21 日的代码 fork 公告，尽管其中确实有一些给人希望的说法：

我们维护的 Elasticsearch 和 Kibana 分支将是基于最新的 ALv2 授权的代码库，也就是 7.10 版本。我们将在未来几周内发布新的 GitHub 仓库。一段时间之后，这两个版本将被包含在现有的 Open Distro 发行版中，取代 Elastic 提供的 ALv2 构建。我们是为了长远的发展，并将以一种促进健康和可持续的开源实践的方式来推进，这包括与社区贡献者一起来共同管理这个公共项目。

这里没有提到 CLA 的要求（或许是忘了提），但除非之前所有的贡献者（还要包括 Elastic）都签署新的 CLA 协议，否则 AWS 无论如何都无法更改代码许可证。那么，似乎很有可能他们维护的分支将更多地是以社区开源的方式（community-open-source）运作，而不是作为一个企业开源项目（corporate-open-source）。

一路走来，FOSS 世界出现过几次许多出于投机目的导致的泡沫性繁荣。曾几何时，只要在公司名称中加入 "Linux" 就足以吸引到投资，而这些投资在很多情况下最起码也是过于乐观了。最近，"open source" 作为一种商业模式已经成为创业界备受关注的理念，但正如 Brasseur 在 2018 年所指出的那样，"open source is not a business model，开源不是一种商业模式"。开源是一种可以被公司用来赚钱的开发方法，但它并不是可以将数百万用户变成付费客户的神奇魔法，不管有多少硅谷风险投资公司对此有不同看法。

可悲的是，这类公司中许多都相当成功，尽管阻碍了他们其他人分享 secret sauce。它们只是还不够那么成功，或者说不够迅速，于是无法满足目前的风险投资和其他投资者。不过，与此同时 FOSS 社区中的相关开发者们被这个改变而导致了自己的工作戛然而止，这让人非常不愉快。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～