云厂商和开源社区之间的“冲突”再一次爆发：Elastic修改开源协议

2021 年 1 月，云厂商和开源社区之间的“冲突”，再一次爆发了！

MongoDB 的前车之鉴

2018 年 10 月，知名数据库系统 MongoDB 官网宣布修改开源协议。为什么要突然修改。因为看不惯某些云厂商的行为，恼火的 MongoDB 只好走这步棋了。

MongoDB 的 CEO 在接受采访时直接给点名了。

被云厂商“吸血”，MongoDB 并不“孤单”。两年多后，就在2021 年 1 月，ElasticSearch 创始人、Elastic 公司 CEO Shay Banon 也做出了同样举动：修改开源协议。

虽然 Elasticsearch 和 Kibana 将要改变开源协议，但是对于大部分人（比如使用云服务如阿里的 ES 服务或者是下载默认 ES 版本进行自建服务的用户）没有任何直接的影响。改变协议的原因，就是跟很多开源产品一样，要反击那些用他们开源免费的产品赚钱但是又不做任何回报的云服务商。云服务商不回馈的行为对于开源产品、开源产品的公司都是致命的，即打击开发者的积极性又影响公司获取所需投资，到最后没人愿意开源的话，咱们这个行业最让人骄傲的地方都消失了。

注：下文中的“我们”是指 Elastic 公司。

Elasticsearch 和 Kibana 即将迎来开源许可协议变更

我们正在把 Elasticsearch 和 Kibana 源代码从Apache 2.0协议调整为 SSPL（Server Side Public License[1]）和 Elastic License[2] 双协议，（译注：大致为允许免费使用，但是不能对最终产品进行修改、重新发布、提供 SaaS 等）我们的用户可以在两者中进行选择。本次许可协议的变更保证我们的社区和客户拥有对代码进行使用、修改、重新发布和协作的权利。我们将通过对那些提供 Elasticsearch 和 Kibana 云服务，却没有回馈社区的云服务商进行限制，来保护我们用于开发免费开放产品的持续性投资。本次变更会覆盖到所有 Elasticsearch 和 Kibana 维护中的代码分支，并且会在即将到来的7.11版本发布前生效。

本次源代码的许可协议变更，对我们社区的绝大多数用户（使用免费的默认发布版本的用户）没有任何影响。同样的，对于那些使用云服务和自建服务的用户，都没有影响。

近年来，随着市场的革新，开发社区开始认识到，开源公司应该要更好的保护自己的产品，以便进行持续的创新和必要的投资。当前越来越多公司开始转向使用 SaaS 服务，一些云服务提供商便使用开源产品搭建相应服务并提供给第三方（译注：直接使用开源产品盈利），但这些云服务商对相应的开源社区却没有任何回馈（译注：不说资金方面的回馈，代码上也没有）。

       在将近 3 年前，我们就公开了我们的商业代码并提供免费版本（均在 Elastic License协议下），我们的下一步就像其他开源公司开发的开源产品一样（如 MongoDB，SSPL 协议就是 MongoDB 公司发明的协议），自然是迁移到 SSPL 与 Elastic License 的双协议策略。SSPL 允许用户免费、无限制的使用和修改产品，只有一个简单的要求，如果你使用开源产品来当做服务，你必须沿用 SSPL 协议并公开你修改过的代码和服务管理层的代码。

我们开放的起源（梦开始的地方）

我个人踏上开源这条道路已经很久了。2005 年，我开源了我的第一个项目，Compass（基于 Lucene 的 Java 框架），当时我正在为我的妻子制作一个食谱应用。接下去的 5 年时间，我投入了大量周末和夜晚在这个项目上，从写代码到帮助用户解决 bug、功能特性、回答问题。

当时我也不知道我为啥这么拼，特别是我白天还得上班，但我就是狂热地陷入这个充满正能量机遇中，那就是开发一个非常棒的项目，更重要的是，我们有一个非常棒的社区，我们用的是开源的力量来进行这个项目（译注：我们用爱发电）。

2009 年，我决定再次出发，开始写一个全新的项目 Elasticsearch。我又花了许多夜晚和周末，并且在 2010 年，我将它开源了。我甚至辞职，将我所有精力投入到其中来。为了就是能够为我的用户们提供帮助（To be there for the users 作者这文笔，差点把我都看哭了），写代码、在 GitHub 上维护项目、回邮件、回消息。

时间来到 2012 年，我们成立了 Elastic 公司，我把同样精神带到了公司。我们投入了很多在免费开源产品上，为用户量飞快增长的社区提供帮助。我们从最开始的 Elasticsearch 到 Kibana、Logstash,、Beats，再加上Elastic Enterprise Search、Observability 和 Security，我们拥有了一套完整的 Elastic Stack 解决方案。

我们成功使产品迈向成熟，促进了围绕产品的活跃的社区，专注于为我们的广大用户提供更多更好的价值。今天，我们有几百位工程师每天醒来就是为了将我们的产品做的更好；我们有成百上千的社区成员与我们密切交流，为我们的共赢风险力量。

我对我们创建的公司非常自豪，对于我们赢得的广大用户的信任感到受宠若惊。这一切的一切都源自于我们的公开、透明，我们始终对我们的社区和用户真诚以待。

为了胜利而开源

回到 2018 年，我们使用 Elastic License 协议对我们的免费和付费特性代码进行了开源，并且我们修改默认发布版本为包含所有特性的版本，所有免费特性默认都为启用状态。

我们这么做是有原因的。这样可以让我们与付费用户的交流像与社区一样开放。但这样也使得许多用户可以把我们的产品直接拿来当做云服务，例如 Amazon Elasticsearch 服务，让他们有机会免费用我们的产品进行盈利，却不回馈社区。

我们这个开源方式广受好评，至今超过 90% 的新下载用户选择这个默认发布版本，这使得我们在经营一个成功的公司的同时，还能保证大多数工作成果都是免费的。

在这个免费、开放、所有权的许可协议下，我们得到了很大的提升。我非常感谢我们的团队和社区，做出的巨大的成就，以至于我想在这里跟大家分享一下：

我们大幅地提高了 Elasticsearch 的速度、可扩展性和可靠性，通过一个新发布的一致性算法和显著地减少了内存的使用，另外新的数据存储和压缩的方法，使得我们在提升索引效率和查询吞吐量的同时，还减少了接近 40% 的典型索引的大小。我们添加了一些用于地理信息分析的字段类型，还有更高效的日志存储和查询，更快速和大小写不敏感的加密数据查询。

关于 Kibana，得益于持续多年的平台重构项目，我们缩减了 80% 的加载时间、去除了全页面刷新，同时我们推出了一款拖拽式的所见即所得的数据可视化产品 Kibana Lens，主要的功能有 dashboard 的深入分析等等。

在过去的三年里，我们为大多数用户案例提供了最好的体验。在安全领域，我们在 Kibana 中开发了一个免费开源的 SIEM（Security Information and Event Management），它拥有功能强大的探测引擎，支持通过一个新的 Elasticsearch 查询语言 EQL 来进行简单规则和负杂关系的定义。我们和我们的社区一起，开发并内置了几百条检测规则。我们还联合了 Endgame（一家行业领先的终端安全公司），我们的发行了免费的强大的故障防护功能，集成于 Elastic Agent 中，为服务器和终端提供统一的 observability 和 security 代理，还有更多的功能会在后续发布。

在 observability 中也是一样，我们在 Kibana 中，开发了一个 observability 套装，包括实时的、支持尾部查看（tail）的日志 UI，还有包括 hosts、pods、containers 的主要的指标和告警的可视化基础设施级别的视图。现在我们还拥有一个全功能的APM（Application Performance Management）产品，包括开源的数据采集器和代理，支持OpenTelemetry，RUM（Real User Monitoring），综合监测，还有最近刚新增的用户体验监测。

关于 Elastic Enterprise Search，我们推出了 App Search，这是一个建立于 Elasticsearch 之上的功能，它能简化富应用的搭建，提供强大的相关调优和数据分析管理接口。我们还提供了一个免费的 Workplace Search 产品，它可以让你更方便的集成并搜索你生活或者公司事物的数据内容，比如说 Google Workplace、Microsoft 365、Atlassian Jira 和 Salesforce.

我们打造了这么多产品并且还将他们免费提供给社区使用，这是多么 amazing 的事情。我感到非常高兴、受宠若惊，能看到大家积极参与和采用我们的产品，并且看到这些产品帮助许多人和事业取得成功。这一切的一切，都归功于那些选择我们（所有功能都公开免费的基于 Elastic License 协议的）默认发型版本的社区的极大多数用户。

为什么要换协议

就像之前提到过的，近三年时间里，随着市场的革新，开发社区开始认识到，开源公司应该要更好的保护自己的产品，以便进行持续的创新和必要的投资。随着交付模式向 SaaS 的转变，许多云服务提供商使用开源产品做为服务，却不回馈社区。这将导致本可以用来投资开源产品的资金被转向到服务商的口袋中，严重影响到开源社区和用户的利益。

跟很多致力于开源事业的伙伴们一样，我们亲身体验到了这些伤害开源产品的经历，包括滥用我们的商标，企图通过重新打包我们的开源产品来分裂我们的社区，甚至还有人从我们的收费功能的代码中“获取灵感”。各个开源公司都已经采取了一下略有不同的方法来解决这个问题，大部分都修改了他们的开源许可协议来保护他们免费的投资，当然他们都尽可能地保留自己的原则：公开、透明、合作。同样的，我们的下一步自然是要考虑如何修改我们的源代码协议。这个改变不会对我们的极大多数用户产品影响，但它可以限制云服务商使用我们的产品作为服务。

我们意料到一定会有些竞争者会针对我们此次调整，通过各种 FUD（Fear, Uncertainty and Doubt，通过诋毁竞品洗脑用户）宣传手段来影响我们。这里我想对所有否定我们此次调整的人说清楚，我们将始终坚持免费的原则并做好开源产品，并且我们的一切始终对社区透明。我们以往的成绩可以证明这一承诺，我们将会在此基础上继续努力。

本次调整

从即将发布的 Elastic 7.11 开始，我们将把原 Apache 2.0 协议的 Elasticsearch 和 Kibana 源码调整为 SSPL 和 Elastic License 双协议，让用户自由选择。SSPL 是一个 MongoDB 发明的源码可使用的协议，它即体现了开源的原则，又防止那些服务商用了开源产品但又不回馈。SSPL 允许免费无限制地使用和修改源码，只有一个简单的前提，如果你把这个产品拿来当做服务提供给第三方，那你必须公开发布你的所有改动代码，以及公开必须同样基于 SSPL 许可协议的服务管理层的代码。

我们之所以做这样的选择，是因为它给予了我们尽可能开放又保护社区和公司的机会。某种程度上，这样的开发可以让我们甚至更加开放。作为这个改变的下一步，我们将把我们的免费的专有特性也从 Elastic License 迁移到与 SSPL 一起的双协议下，这会使得专有特性变得更加开放，这能更好的达到我们想让产品尽可能开放和免费的目标。

尽管说修改源码的改变对我们公司来说是一件非常大的事情，但是对于极大多数的社区用户来说，事实上不会体验到什么差别。如果你是我们的客户，即使是 Elastic Cloud 用户或者是本地部署的用户，都没有任何改变。如果你一直都是下载并使用我们的默认发型版本，它仍然是基于同样的 Elastic License 的免费版本。如果你是一直都在为 Elasticsearch 或者Kibana 做贡献的成员（万分感激），一样没有任何变化。

就像我们这三年所做的一样，我们将会继续以开源的方式开发我们的代码、与社区积极沟通、基于 Elastic License 许可协议发布我们的免费产品。我们仍然坚定地让我们的免费特性继续免费，我们不会对任何免费特性和付费功能做任何非功能性的改变。

我们意识到，团结对社区来说是至关重要的。这次的改变使我们继续向大家展示我们的诚意并获得你们信任，就像我们在过去 10 年内做的一样。

补注1：在 Elastic 发布了这篇文章后，他们还另外发了两篇文章来提供更多关于许可协议的细节：《协议变更说明》[3] 以及 《对 Amazon 说不！为什么我们必须修改协议》[4] 。（Elastic CEO 在这篇文中火力十足，把 AWS 怼的很惨。）

补注2：Elastic 官博点名吐槽 Amazon 之后，AWS 在 1 月 21 日发文，针锋相对地宣布他们要创建“真正”开源的 Elasticsearch 分支。

参考资料

[1]

Server Side Public License: https://www.mongodb.com/licensing/server-side-public-license

[2]

Elastic License: https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt

[3]

协议变更说明: https://www.elastic.co/blog/license-change-clarification

[4]

为什么我们必须修改协议: https://www.elastic.co/blog/why-license-change-AWS

责任编辑：xj

原文标题：炮轰云厂商“吸血”，Elastic 修改开源许可

文章出处：【微信公众号：Linux爱好者】欢迎添加关注！文章转载请注明出处。