换协议、改代码，Elastic 要逼开发者二选一？

为应对云服务提供商，Elastic 近日对其 Elasticsearch 数据库的官方 Python 客户端（Elasticsearch-py）做出了修改，使其无法与各分叉版本相兼容，之后又粗暴地关闭了GitHub上的话题评论。这一行为引起了广大开发者激烈讨论。

剑指云厂商

Elasticsearch 是一款数据库管理器与分析引擎，在行业内被广泛使用。官方客户端在 Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby 和许多其他语言中都是可用的。根据 DB-Engines 的排名显示，Elasticsearch 是最受欢迎的企业搜索引擎，其次是 Apache Solr。

Elasticsearch-py旨在为 Python 中一切与 Elasticsearch 相关的代码提供共识，目前客户端的下载量已经超过 20.2 万次。Elasticsearch-py 一直坚持以中立性与高可扩展性作为基本定位，而负责运行 Elasticsearch 查询的高级库 Elasticsearch DSL，也将 Elasticsearch-py 以库的形式来使用。

这次代码修改也是 Elastic 与 AWS 矛盾激化的体现。

作为一款开源产品，Elasticsearch 在今年 1 月份调整了其开源许可证，将之前的 Apache 2.0 许可授权改为双重许可模式（即 SSPL 1.0 和 Elastic 许可），用户可以选择适合自己的许可方式。促使 Elastic 做出该决定的最大原因便是，以此应对公有云平台（特别是 AWS）上发生的不公平使用情况。

“随着很多公司不断向 SaaS 转型，有些云服务提供商使用了开源产品，并在不向社区提供任何回馈的情况下，将其作为一项对外提供的服务。这种做法转移了本可以再投资到产品上的资金，损害了用户和社区的利益。”Elastic 在声明中写道，“社区逐渐认识到，开源公司只有更好地保护自己的软件，才能保持高水平的投资和创新。”

为了应对这一变化，AWS 抢在许可证变更之前对 Elasticsearch 进行了分叉，构建起 Open Distro for Elasticsearch，之后逐渐演变为 OpenSearch，并在上个月发布了1.0版本。

根据 AWS 介绍，OpenSearch 是一个社区驱动的开源搜索和分析套件，源自 Apache 2.0 许可的 Elasticsearch 7.10.2 和 Kibana 7.10.2。它包括一个搜索引擎守护进程(OpenSearch)、一个可视化和用户界面(OpenSearch Dashboards)，以及用于弹性搜索的 Open Distro，包括安全、警报、异常检测等功能。

根据亚马逊网络服务副总裁 Adrian Cockcroft  的说法，发行说明和文档未能阐明什么是开源的、什么不是，这让企业开发人员面临这样的情况：他们会在无意中使用到可能会在未来造成财务或法律问题的代码。AWS 的介入可以确保其客户可以继续运行 Elasticsearch，而不必担心他们的计费周期可能会中断。不过有开发者表示，OpenSearch 社区活跃度还有待提高。

如今，开发者们注意到，Elasticsearch-py 的源代码已经被悄悄更改，其会单独检查数据库属于 Elastic 还是分叉产物。更新说明中提到，“如果响应当中没有 X-Elastic-Product HTTP 标头，或者 X-Elastic-Product HTTP 标头的值不是 Elasticsearch，就会引发错误。”

逼开发者站队？

“神仙打架、凡人遭殃”。这场企业间的对抗深深伤害了曾为 Elasticsearch 做出贡献的开源开发者们。在数据搜索管理开源项目 Invenio 产品经理 Lars Holm Nielsen 看来，Elastic 是在逼迫普通开发者站队。

 “我们开发了一款开源产品，能够轻松与 Elasticsearch 或者 OpenSearch 配合使用，而用户再根据自己的需求选择到底使用 Elasticsearch 还是 OpenSearch……Elastic 的种种行为确实沉重打击了我们对该公司及其旗下产品的信心。别把锅都甩给 Amazon，Elastic 之前已经修改过服务器许可证了，根本没必要再把其他分叉版本拒之门外。”Nielsen 表示。

Elastic 公司高级工程技术经理 Philip Krauss 则回应称，“Amazon OpenSearch 是另外一款不同的产品。虽然与 Elasticsearch 有些渊源，但二者之间的诸多差异必然导致大量问题甚至混乱。”

目前该话题在GitHub上的评论功能已被关闭，后续留言也被删除。

做出修改的不止是其官方 Python 客户端，Elasticsearch 的.NET Connector 也没能幸免，同时开始出现诸如“客户端发现服务器不是受支持的 Elasticsearch 发行版”等错误提示。

面对用户的抱怨，Elastic 高级软件工程师 Steve Gordon 回应称：“建议大家升级到 Elasticsearch 的最新默认发行版，此版本可以在 Elastic License v2 下免费使用……我们将此次修改视为增强功能，因为它只会影响到不受支持的客户端与服务器组合。在受支持的配置中，变更不会给业务造成任何影响。这次调整的目的是通过快速失败的方式声明不兼容性，避免消费者错误地认为可以在未经测试、且可能无法达成预期效果的配置下长期运行负载。”

此外，还有一个变化：Elasticsearch 的 Java 客户端也已切换为 Elastic License。这个问题已经在 OpenSearch 社区中引发用户们的焦虑。

“OpenSearch 要怎么处理当前可用的各种编程语言所对应的多种 connector 和 binding？根据报道，其中很多已经集成了反竞争机制。”有开发者提出疑问。

许可约束跟产品检查还不是一回事。Elastic 公司表示，“我们的客户端库仍然遵循 Apache 2.0 许可证，但其中不包括 Java 高级 Rest 客户端（Java HLRC）。Java HLRC 依赖于 Elasticsearch 核心，因此该客户端库将采用 Elastic License。随着时间推移，我们会逐步消除这种依赖性，并将 Java HLRC 转移至 Apache 2.0 许可。”

如果在代码层面阻止连接，那么遵循 Apache 2.0 许可证的这些客户端（包括 Python 与.NET 客户端）将无法与 OpenSearch 协同使用。当然，各客户端的分叉与修改难度并不高，应该还是会有解决办法。

利益之争

云的兴起给基础软件公司和开源公司提供了很好的分发渠道，能够更好地构建竞争壁垒，还可以迅速将开源用户发展到云上来。在云上统一部署，省去了企业要给每一个用户安装、部署甚至定制化的高成本。但这对传统的开源软件企业的商业模式形成了冲击。

近年来，云厂商与开源厂商之间的矛盾日益显著。早在 18 年底，图数据库 Neo4j 便宣布，从 Neo4j 3.5 版本开始，企业版仅在商业许可下提供，不再提供源代码。近几年，Confluent、MongoDB、Kafka、Redis 等也纷纷修改开源协议，限制云厂商从中牟利却不做贡献的行为。

针对两个阵营之间的纷争，开发者们的观点也不相同。

“我个人也受不了 Elastic，因为他们收取企业级的支持费用，然后提供开源级别的支持。你在遇到一个问题时，得到的回应通常是‘为什么要尝试这样做?’，或者‘请参考这个自 2016 年以来就不新鲜的问题’。”有代码贡献者分享了自己使用 Elastic 的感受。

随着竞争的加剧，开源软件背后的商业公司可能不得不考虑如何进化自己的服务和商业模式。

不过，Open UK 首席执行官兼首席政策官 Amanda Brock 认为，开源是多种多样的，但它不是一种商业模式。像 Elastic 这样对云提供商使用其代码方式感到不满的公司并没有完全理解开源许可证的含义。“根据我的经验，云提供厂商正在以开源许可范围内可接受的方式使用它。”

当然，也有开发者表示理解 Elastic 开源厂商的做法：

如果 Elastic 在 ElasticSearch 上取得成功，那么完全可以预想到，其他公司也会加入这一风口，并尝试从中获利。作为创造产品的公司，可能并不是能从中获利最多的公司，企业应该计划获得足够的利润。但事情变得复杂的地方在于，没有企业希望他们从自己创造的产品中获得的收益比依赖该产品的其他企业要少几个数量级。

 

开源软件企业们没有预见到，云服务提供厂商的出现，最大限度地降低了他们的价值主张。亚马逊可以投入大量资源，甚至可能比 Elastic 本身还要多。有人可能会争辩说，亚马逊滥用了他们在云服务领域的垄断地位，提供了 Elastic 永远无法与之竞争的捆绑式 ElasticSearch 体验。即使他们开发了替代的内部产品，它看起来也与当年 Microsoft 将 Internet Explorer 与 Windows 捆绑在一起的情况完全相同。

 

即使在今天，如果企业愿意开发一个开源或免费的软件产品，一旦足够成功，便很可能会成为大型企业的利用目标。公司始终可以选择重新许可内部编写的代码，以及由适当的贡献者许可协议 (CLA) 的签署人提交的任何代码。

 

利益分配问题确实是开源厂商和云厂商之间最大的争论点，这个问题或许还是要从商业角度解决，看谁能在两者之间的博弈中占据上风。