3 年后 Elasticsearch 再改开源协议，还与 AWS 化敌为友？为啥？_AI阅读总结 — 包阅AI

Elasticsearch 是一个广泛应用的分布式搜索和分析引擎，其开源性曾经是吸引大量用户的重要因素。

然而，在 2021 年，Elasticsearch 将其核心产品从 Apache 2.0 协议更改为 Server Side Public License (SSPL) 和 Elastic License (ELv2) 双重许可，引发了广泛的讨论和争议。

参见：https://www.elastic.co/cn/pricing/faq/licensing

如今，Elastic 创始人Shay Banon 2024年8月30日发文（如下截图）决定再次调整其开源策略，引入 AGPL (Affero General Public License) 作为新的许可选项。那么，这一变动背后的原因是什么？它对企业用户又会产生怎样的影响？本文将对此进行详细探讨。

https://www.elastic.co/cn/blog/elasticsearch-is-open-source-again https://simonwillison.net/2024/Aug/29/elasticsearch-is-open-source-again/

AGPL，全称为 Affero General Public License（阿弗罗通用公共许可证），是 GNU 通用公共许可证 (GPL) 的一种变体。AGPL 的主要目的是弥补 GPL 在网络应用场景中的漏洞，即当用户通过网络使用软件时，确保用户仍然有权获取对应的源代码。

AGPL v3 官方链接: https://www.gnu.org/licenses/agpl-3.0.en.html

（1）网络交互源代码发布要求：

AGPL 与 GPL 类似，要求对修改后的软件进行发布时，必须开放源代码。而与 GPL 不同的是，AGPL 进一步要求，如果软件通过网络提供给用户使用（如作为在线服务），开发者也必须提供修改后的源代码。这意味着，即使企业没有直接发布软件的二进制文件，只要提供了网络服务，就必须遵循开源的义务。

（2）强制开源：

AGPL 被称为“强制开源”许可证，因为它确保了无论软件以何种形式发布或使用，最终用户都能够获取到源代码。这对于那些基于开源项目构建网络服务的公司来说，具有很强的约束性。

AGPL 目前被多个知名的开源项目使用，这些项目通常涉及到网络服务或平台，以确保在网络环境下也能保护开源软件的自由性和透明性。以下是一些使用 AGPL 的知名开源项目：

https://grafana.com/licensing/

首先，让我们回顾一下 Elasticsearch 协议变更的历史背景。

2021 年，Elastic 决定放弃 Apache 2.0 协议，转而采用 SSPL 和 ELv2。

这一决定主要是为了应对 AWS 等云服务提供商利用开源代码提供商业服务的问题。AWS 的行为被认为是“搭便车”，这引发了 Elastic 对市场竞争环境的担忧。

为了解决这一问题，Elastic 选择了更具保护性的许可证，以防止其开源软件被直接用于竞争性服务。

然而，这一变化并未得到所有用户的认可，甚至导致了社区的分裂。

AWS 随即推出了 OpenSearch 项目，一个基于 Elasticsearch 的开源分支，进一步加剧了市场的混乱局面。

注意：OpenSearch 使用的是 Apache 2.0 许可证（Apache License 2.0）。这是一个宽松的开源许可证，允许用户自由使用、修改和分发代码，无需担心开源代码的使用方式受到过多的限制。

三年后，Elastic 决定在原有许可的基础上，增加 AGPL 作为第三种许可选项，以重新连接开源社区。

那么，为什么 Elastic 选择在此时引入 AGPL？有几个关键原因：

Elastic 在 2021 年的许可变更导致了与开源社区之间的隔阂。通过引入 AGPL 这一 OSI 认证的开源许可，Elastic 希望修复与社区的关系，重新确立其开源项目的定位。

SSPL 和 ELv2 的引入虽然在一定程度上保护了 Elastic 的商业利益，但也带来了一些法律上的不确定性。AGPL 的引入则是为了提供一种更明确、更容易被企业接受的开源许可。

AGPL 要求所有修改后的代码在提供网络服务时必须公开，这种“共赢”的模式可能有助于吸引更多的社区贡献者，同时继续保护 Elastic 的商业模式。

对于已经使用或计划使用 Elasticsearch 的企业用户，这一变动可能带来以下几个方面的影响：

AGPL 的引入意味着企业在选择许可证时需要更加谨慎。AGPL 要求在网络环境中提供服务时公开修改后的代码，这可能会对企业的内部开发和部署策略产生影响。（总感觉国内用户貌似影响不大，欢迎大家留言）

企业用户现在可以根据自身需求选择最合适的许可证类型。如果企业更注重开源的透明性和社区贡献，AGPL 可能是一个更好的选择；而对于那些希望保留更多内部开发成果的企业，ELv2 依然是一个不错的选择。

在 OpenSearch 和 Elasticsearch 之间，企业用户需要重新评估其长期使用的风险和收益。

Elastic 的这一变化可能会影响企业对未来平台选择的决策，特别是在考虑迁移到 OpenSearch 或继续使用 Elasticsearch 时。

AGPL 虽然是一个 OSI 认证的许可，但在实际应用中可能仍然存在法律上的不确定性。企业在选择使用 AGPL 许可的 Elasticsearch 时，可能需要咨询法律顾问，以确保合规性和业务安全。

许多用户对于 Elastic 重新采用开源许可证（AGPL）表示欢迎，认为这有助于修复与开源社区的关系，并消除了之前因许可证变更带来的困惑和疑虑。

一些用户认为 AGPL 相对于 Elastic 之前的许可证（ELv2）更加限制性，因为它要求任何修改后的代码在通过网络提供服务时必须公开源代码。但也有用户认为 ELv2 更为宽松，因为它只限制了使用 Elastic 代码创建直接竞争服务的行为。

企业用户需要重新评估 Elastic 的新许可证对其业务的影响，特别是对于那些可能需要修改 Elastic 软件以适应特定需求的公司。

一些用户担心 Elastic 可能会再次改变其许可证策略，从而影响用户的长期利益。这种担忧源于 Elastic 之前的许可证变更，以及对大型科技公司使用开源软件的普遍顾虑。

讨论中频繁提到 OpenSearch，这是 AWS 为了应对 Elastic 许可证变更而创建的 Elasticsearch 分支，并且继续使用更宽松的 Apache 2.0 许可证。一些用户认为 OpenSearch 已经获得了相当的社区支持和开发动力，可能不会受到 Elastic 重新开源的影响。

这些观点反映了社区对 Elastic 重新开源的复杂反应，既有积极的欢迎态度，也有对长期影响和潜在风险的担忧。

——数据来源：https://news.ycombinator.com/item?id=41394797

Elastic 引入 AGPL 作为新的许可选项，是其在应对过去几年市场变化和社区反馈的结果。这一变化不仅仅是对开源社区的示好，更是为了平衡商业利益与开源精神之间的关系。

对于企业用户来说，这一变动意味着更多的选择，但也要求更谨慎的策略制定。

未来，Elasticsearch 和 OpenSearch 之间的竞争可能会更加激烈，企业用户在做出技术决策时需要更加注重长远的规划和法律合规性。这一切都显示出，开源软件在快速发展的技术领域中，既是机遇，也是挑战。