Elastic与AWS就滥用开源许可再度开撕
2021-01-22 22:27:33 
阿炯
2021年1月20日消息，据外媒报导，Elastic 公司 CEO Shay Banon 在公司官网发文表示，他们决定将 Elasticsearch 和 Kibana 的开源协议由 Apache 2.0 变更为 SSPL 与 Elastic License，这是因为被 AWS 的所作所为逼于无奈作出的选择，坚决更改开源协议以抵制AWS不端行为。
Shay Banon 在文中强烈表达了自己的不满，措辞激烈：
“亚马逊于 2015 年基于 Elasticsearch 推出自己的服务，还将其称为 Amazon Elasticsearch Service，这是很明显的商标侵权行为。NOT OK。”
“我在 2011 年借了一笔个人贷款来注册 Elasticsearch 商标...... 看到商标如此公然地滥用，我特别痛苦。亚马逊问题迫使我们提起诉讼。NOT OK。”
“商标问题让用户感到困惑，以为是 Elastic 和亚马逊之间有合作，这不是真的。NOT OK。”
“...... 多年来这种困惑仍然存在。NOT OK。”
“亚马逊针对 Elasticsearch 的 Open Distro 分支，进一步分裂了我们的社区，引发了相当多的混乱。NOT OK。”
“..... 最近，我们发现了更多挑战道德底线的例子。我们已经在专有功能方面上与众不同，现在这些设计却被视为来自亚马逊的灵感。NOT OK。”
1、Elastic 更改开源协议，社区有意见
2021年1月15日，Shay Banon 在公司官网发文，宣布将更改开源协议，从 Elastic 7.11 版本开始，Elasticsearch 与 Kibana 代码所遵循的 Apache 2.0 许可会调整为 SSPL 与 Elastic License 双许可。
SSPL 是由 MongoDB 制定的源代码许可。针对云服务提供商做出了限制，即要求云服务提供商在未对项目做出贡献的情况下，不得发布自己的开源产品即服务。SSPL 允许用户以自由且不受限制的方式使用并修改代码成果，唯一的要求是：如果将产品以作为一种服务进行交付，那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。
Shay Banon 在其博客中写道：
之所以选择这条道路，是因为这才是继续保持开放的正确思路，同时也将给我们的社区与公司提供保护。在某种程度上，这一切将使我们的开放程度进一步提高。作为后续措施，我们将逐步将免费专有功能从 Elastic License 转向 SSPL 加 Elastic License 双许可，旨在进一步增强我们希望达成的产品自由与开放目标。
Shay Banon 反复表示源代码许可的改变对绝大多数免费使用默认发行版的社区用户没有任何影响。Elastic 布道师们也宣传道：“只要你不是公有云厂商，License 的变化和你一点关系也没有，自己搭建部署 elk 没有任何合规的问题，只是针对基于它做云服务盈利还不开源出来回馈社区的这种情况。云厂商也能继续用 Elasticsearch，只不过前提是要全部开源出来，这样才有利于整个社区的发展。”
但是 Elastic 修改协议的这个行为还是引发了社区不满。
有开发者吐槽表示：“Elasticsearch 属于社区中的 1573 位贡献者，这些贡献者保留其版权，并授予 Elastic 不受限制地分发其作品的许可。开源是社区的工作......Elastic 更改协议是为了获得更多的钱，是为了建立对 Elasticsearch 的垄断...... 这是反开源的举动。Elastic 的行为辜负了社区，辜负了大家的信任。"
因为 Elastic 更改协议，也导致一些企业开始寻求 Elasticsearch 的开源替代方案。比如开源平台 Hopsworks 使用了 Elasticsearch 为 AI 资产(功能，模型，实验，数据集等)提供自由文本搜索，他们关注到自己的行为可能违反了 SSPL 的许可条款：
“如果您将本程序的功能或修改的版本作为服务提供给第三方...(适用许可条件)”
所以 Hopsworks 的开发者从 Elasticsearch 切换到了适用于 AWS(已获得 Apache v2 许可)的 Open Distro，并且发文总结了他们的迁移过程。
2、最终还是跟随了 MongoDB 的脚步
MongoDB 公司因其“NoSQL”数据库产品 MongoDB 而创立。MongoDB 并不是唯一的 NoSQL 数据库，但它是其中使用最广泛的数据库之一。另外 MongoDB 还引领潮流地创建了一种新的开源许可。
云厂商 AWS 或 Azure 打包 MongoDB 并将其作为基于云的 SaaS 服务(Software as a service)的一部分进行售卖，这样的问题在于，这些服务直接与 MongoDB 自己基于云的 SaaS 服务——MongoDB Atlas 形成了竞争。这种情况下，受到威胁的不是 MongoDB 的源代码，而是 MongoDB 自己的 SaaS 服务，而这恰恰是该公司的主要收入来源。
MongoDB 的 CTO Eliot Horowitz 认为，随着计算机技术进入云的新世界，有必要采取一些措施对开源软件业务进行保护。
2018 年 10 月，MongoDB 宣布其开源许可证将从 GNU AGPLv3，切换到 SSPL，新许可证将适用于新版本的 MongoDB Community Server 以及打过补丁的旧版本。
一开始，MongoDB 将该 SSPL 许可证提交给开放源代码促进会(OSI)， OSI 负责监督和批准新的开源许可证。但是有些人认为，SSPL 与 OSI 的开源定义第九条是不兼容的，第九条说“许可证不能限制其他软件”。并且经过 OSI 来来回回的一系列邮件讨论后，再加上该许可证本身的措辞问题，使得 SSPL 不太可能被 OSI 批准，所以 MongoDB 又取消了对 SSPL 许可的申请。于是，SSPL 并不是开源许可，而且将来也不可能成为正式许可。
MongoDB 更改开源协议也曾引起极大关注，RedHat 等厂商纷纷表示将弃用 MongoDB。一时之间，MongoDB 似乎深陷险境。但两年过去后，这家公司不仅还活着，而且活得很好，其股价也从 2018 年的不足 100 美元/股涨到现在的 361 美元/股。
MongoDB 也绝对不是唯一一个抱怨云计算正在侵蚀其利润的公司。像 Redis Labs、Confluent 这样的公司都更改了软件许可证，从原来的开源许可证转向更严格的条款，限制了软件的功能，使其不再属于开源软件。
3、Elastic License + SSPL
如果使用的 Elasticsearch 是直接从官方下载且是 6.3 之后的版本，那么按照 Elastic License 的条款，很可能已经违反了使用许可，Elastic 公司会保留追究权利。 这起源于2021年1月Elastic 公司宣布将采用 Apache License 2.0 的 Elasticsearch 和 Kibana 的源代码变更为双重许可模式：Elastic License + SSPL。
按照 Elastic License 和 SSPL 的条款，两者对于商用都有严格的要求。比如，SSPL 针对云服务商提出了严格的限制：“如果您将本程序或修改版的功能作为服务提供给第三方，则必须根据本许可的条款，需要通过网络下载免费向所有人提供服务源代码。”
Elastic License 虽然允许免费使用、修改、创建衍生作品和重新分发，但有三个基本的限制条件：
不得将产品作为托管服务提供给其他人
不得规避许可密钥功能或删除 / 隐藏受许可密钥保护的功能
不得删除或隐藏任何许可协议、版权或其他声明
摘自：elastic-license-faq
具体来说，Elastic License 禁止下列操作：
将 Elastic 公司的产品直接作为一项服务对外出售（如 Amazon Elasticsearch Service）
篡改源代码以达到在不订阅的情况下使用 Elastic 付费功能的目的，或者将修改后的版本投入生产之用
摘自：license-change-clarification
由于双重许可模式从 Elasticsearch 7.11 开始生效，为了规避上述限制，许多人会选择使用不受影响的 7.10.2 及更早的版本。
如果用户直接从官方下载了上述版本的免费 Elasticsearch 发行版，并且基于 Elasticsearch 向第三方提供服务，那么按照 Elastic License 的条款，这已经违反了使用许可，Elastic 会保留追究权利。因为从 Elasticsearch 6.3 开始，原本闭源的「X-Pack」功能开放了源代码 —— 采用 Elastic License，并被默认打包到发行版里面。所以从 6.3 起的所有免费发行版都包含了一个使用 Elastic License 的组件：X-Pack。根据 Elastic License 的条款，X-Pack 隐藏着 “潜在风险”。
因为无论是否使用 X-Pack，所下载的 Elasticsearch 都包含了该组件，如果基于该 Elasticsearch 向第三方提供服务。根据 Elastic License 的限制，这已经违反了许可，所以 Elastic 公司会保留追究权利。
前文提到，这是一种 “潜在风险”。之所以称为 “潜在风险”，是因为到目前为止，尚未出现因 X-Pack 使用的 Elastic License 而出现纠纷的案例。此外，根据开源专家的介绍，即使用户下载的 Elasticsearch 发行版包含了 X-Pack，并且它采用的是 Elastic License。如果用户没有启用它，那就无需遵循 License 的条款。而 X-Pack 正好是没有默认启用的功能 —— 需要用户手动开启。
如果用户手动启动了 X-Pack，将被视为接受 Elastic License。所以这名开源专家认为，默认情况下，用户使用 6.4 到 7.10 版本，依旧是只需遵循 Apache License 2.0。可以看到，「X-Pack」是导致问题的重要成因。如果要规避此 “潜在” 问题，要么遵循 Elastic License 许可，要么可以选择自行从 Elasticsearch 源代码构建不包含 X-Pack 的版本。当然，还可以考虑使用其他开源替代方案。
Elastic 也有同样的困扰，也面临着来自 AWS 的激烈竞争。两年前，亚马逊在 AWS 上提供了 Elasticsearch，还打包了自己版本的 Elasticsearch 代码库，并将其扩展为免费提供的好几项服务。亚马逊宣布推出 ElasticSearch 开源代码独立库时，还曾造成 Elastic 股价下跌，跌幅高达 5%。
面对这样的挑战，Elastic 公司一直未采取行动，除了状告亚马逊注册商标侵权以外。到现在，Elastic 终于觉得再不对 AWS 和 Amazon Elasticsearch Service 采取行动，“事情只会变得更糟”。Shay Banon 希望此更改“对用户产生零影响”，不伤害“公有云”之外的友商，但还是有 Hopsworks 这样的开源平台选择迁移到 Elasticsearch 的 Open Distro 分支，所以许可证变更的影响还有待观察。大家可以回顾一下这些旧闻。
Redis Labs再次更改开源许可证
MariaDB CEO痛斥云厂商滥用开源许可
MongoDB不满AWS等云厂商坐收渔利
CockroachDB 修改开源协议以限制商业构建 DBaaS
开源公司抱团取暖-讨论如何在云厂商环境下生存
当然AWS肯定不会就此示弱，这两天也没有闲着，这不今天(1月22日)就宣布创建“真正”开源的 Elasticsearch 分支。
Elasticsearch 和 Kibana 宣布变更开源许可证后引发了各方激烈讨论，但整起事件的另一个关键角色——被 Elastic 公司 CEO 发文怒斥的 AWS 却一直没有发声。然而就在1月22日，AWS 宣布将基于目前仍为开源状态的 Elasticsearch 和 Kibana--即 7.10 版本)创建分支，开源许可证也会继续使用 Apache License 2.0。为了确保由他们创建的分支能得到良好支持，AWS 会负责后续的维护工作。AWS 声称自己创建的分支是“真正”开源的 Elasticsearch，显然这是在暗讽 Elastic 公司即将采用的双许可证方案--SSPL + Elastic License)，毕竟 SSPL 和 Elastic License 都不是 OSI 批准的开源许可证。
AWS 曾在 2019 年推出 Elasticsearch 发行版——Open Distro for Elasticsearch，它采用了 Apache License 2.0，声称 100% 开源。据 AWS 自己介绍，在构建 Open Distro for Elasticsearch 过程中，他们遵循了众人推崇的“upstream first”开源开发实践，对 Elasticsearch 的所有改动都以 PR 形式提交给了上游，并将 Elastic 提供的“oss”构建合并至他们创建的发行版。
AWS 推出 OpenSearch：基于 Elasticsearch 的开源分支
2021年年初 AWS 宣布创建“真正”开源的 Elasticsearch 分支有了下文。2021年4月中旬，AWS 宣布推出 OpenSearch 项目，这是 fork 自 Elasticsearch 和 Kibana 的开源分支。
OpenSearch 项目由 OpenSearch (fork Elasticsearch 7.10.2) 和 OpenSearch Dashboards (fork Kibana 7.10.2) 组成，包括企业安全、告警、机器学习、SQL、索引状态管理等功能。OpenSearch 项目中的所有软件均采用了 Apache License 2.0 开源许可协议。AWS 介绍称，它们推出的 OpenSearch 删除了 Elasticsearch 中受 Elastic 商业许可证限制的功能、代码和商标，以兼容 Apache License 2.0，自称这是每个人都可以构建和创新的基础，任何人无需签署 CLA (Contributor License Agreement) 即可为项目贡献代码。另外，AWS 现有的 Amazon Elasticsearch Service 被重命名为 Amazon OpenSearch Service，AWS 表示更名不会影响正在运营的业务，Amazon OpenSearch Service 会提供一系列可供部署和运行的开源引擎，包括当前可用的 19 个版本的 Elasticsearch(7.9 和更早版本、近期推出的 7.10)以及新版本的 OpenSearch。
AWS 还说到会继续通过安全性和错误修复来支持和维护采用 Apache License 2.0 的 Elasticsearch，并将通过 OpenSearch 和 OpenSearch Dashboards 提供所有新功能。Amazon OpenSearch Service API 将与现有服务 API 向后兼容。此外，AWS 会提供从现有 Elasticsearch 6.x 和 7.x 托管集群迁移至 OpenSearch 的无缝升级路径。AWS 表示，当前版本的代码尚处于 alpha 阶段，未经彻底测试并且不适合用于生产环境。它们计划在接下来的几周内发布 Beta 版本，有望在2021年中期发布稳定版并投入生产环境使用。
包括红帽、SAP、Capital One 和 Logz.io 等在内的多个组织对 AWS 创建 OpenSearch 项目表示了支持。
Elastic也是上市公司，这种掌握在一家公司手上的项目，开源拉新在前，割韭菜再后，这个可以看看Qt。都是利益争斗罢了，没有谁比谁更高尚。坚持社区多元化，不被单一公司掌控的项目才是好的开源。越是大型商业公司，就越是热衷于开源，因为开源能为他们带来大量的免费劳动力，能大幅度的降低他们的研发和维护成本。但是他们不担心别人掌握了和他相同的技术后被反噬吗？完全不用担心，因为即便你掌握了同样的技术，也无法提供和他们相对抗的服务，软件本身没有任何商业价值，有价值的永远是服务。像 mongodb 和 elasticsearch 根本就无力和云厂商对抗，他们费尽心力研发的产品被云厂商拿来对外提供服务大赚特赚而引发强烈反弹是必然的。
2024年9月，Linux 基金会宣布成立 OpenSearch 软件基金会。
Elastic再次开源并希望与OSI合作再创新许可证
Elasticsearch于2024年8月下旬宣布再次开源，计划在未来几周内添加 AGPL 作为 ELv2 和 SSPL 之外的另一个许可选项。Elasticsearch 和 Kibana 又可以被称为开源了。很难表达这句话让我有多高兴。我激动得简直要跳起来了。我们 Elastic 的所有人都是如此。开源是我的 DNA。这也是 Elastic 的 DNA。能够再次将 Elasticsearch 称为开源，我感到非常高兴。简而言之，将在未来几周内添加 AGPL 作为 ELv2 和 SSPL 之外的另一个许可证选项。在更改许可证之后，我们从未停止过对开源社区的信仰和行为。但通过使用 AGPL（OSI 批准的许可证），我们可以使用开源一词，从而消除人们可能存在的任何疑问或疑惑。
3年前的2021年，Elastic 公司宣布变更 Elasticsearch 和 Kibana 的其中一项开源许可协议 —— Apache License 2.0，将其变更为双授权许可，即 Server Side Public License (SSPL) + Elastic License，而这两种许可证都不是符合 OSI 标准的开源许可证。在 Elasticsearch 和 Kibana 宣布变更开源许可证后引发各方激烈讨论后，AWS 则创建了一个自称真正开源的 Elasticsearch 分支 —— OpenSearch，并获得了包括红帽、SAP、Capital One 和 Logz.io 等在内的多个组织和厂商的支持。时至今日，Elastic 又采取了新的行动，“更改许可证是一个错误，Elastic 现在放弃了这一决定”。
对于3年前的这一转变，他们给出的理由是为了应对 “与 AWS 以及他们的产品造成的市场混乱存在问题......现在的情况完全不同了。我们不再生活在过去，并希望为用户创造更美好的未来。正是因为我们当时采取了行动，才有能力现在采取行动。”
增加 AGPL 许可选项不会影响使用 SSPL 或 ELv2 的现有用户，Elastic 的二进制发行版也不会有任何变化。同样对于在 Elasticsearch 或 Kibana 上构建应用程序或使用插件的用户来说，也不会有任何变化 --Elastic 的客户端库将继续采用 Apache 2.0 许可。
Elastic 创始人：热爱开源，希望合作 OSI 创建新许可证
许可证纠纷长期以来一直是商业开源领域的一个突出问题。一些大型供应商已经转向更严格的 “copyleft” 许可证，例如 Grafana 和 Element；或者完全采用专有许可证，例如 HashiCorp 去年对 Terraform 所做的。但有一家价值 80 亿美元的公司却选择了另一条路。Elastic 是企业搜索和数据检索引擎 Elasticsearch 和 Kibana 可视化仪表板的创建者，2024年9月，它在转而采用几种专有的 “source available” 许可近4年后，突然宣布将再次开源。这一举措与无数公司完全放弃开源的趋势背道而驰。有些公司甚至在创建一种全新的许可模式，如 “fair source”- 已被多家初创公司采用。
“这花了太长时间”，2021 年，Elastic 与亚马逊的云计算子公司 AWS 发生冲突，后者销售自己的 Elasticsearch 托管版本，几年后，Elastic 转用闭源许可证。鉴于 Apache 2.0 许可证的宽松性质，AWS 完全有权这样做，但 Elastic 对 AWS 使用 “Amazon Elasticsearch” 等品牌营销其产品的方式感到不满。Elastic 认为这造成了太多的混淆，因为客户和最终用户并不总是太关注开源项目和相关商业服务的复杂性。
Elastic 联合创始人兼首席技术官 Shay Banon 于2024年10月在接受 TechCrunch 采访时表示：“人们有时认为我们改变许可证是因为我们对亚马逊将我们的开源项目作为‘服务’提供感到不满。说实话，我一直都接受这种做法，因为许可证允许他们这样做。我们一直纠结的只是商标侵权问题。”
Elastic/联合创始人兼首席技术官 Shay Banon
Elastic 寻求法律途径迫使亚马逊放弃 Elasticsearch 品牌，这种情况让人想起了最近发生的 WordPress 纠纷。尽管 Elastic 后来与 AWS 达成了商标纠纷和解，但此类法律纠纷耗费了大量资源，而该公司想要做的只是保护自己的品牌。“当我们考虑走法律途径时，我们觉得我们有一个非常好的案例，而且我们最终也赢得了胜利，但由于我们对 Elasticsearch 许可证所做的更改，这已经不再重要了。但这实在是太耗时了 —— 你可能要花四年时间才能赢得一场官司，但到那时，你已经因为混乱而失去了市场。”
回到未来
这种变化在公司内部一直是一个痛点，因为公司被迫使用 “free and open” 而不是 “open source” 这样的语言。但这一变化正如 Elastic 所希望的那样，迫使 AWS 分叉 Elasticsearch 并创建一个名为 OpenSearch 的变体，而这家云计算巨头本月刚刚将其移交到 Linux 基金会。
随着时间的流逝，OpenSearch 的地位也已经稳固，Banon 和公司决定改变方向，再次将 Elasticsearch 开源。“我们知道亚马逊会分叉 Elasticsearch，但这并不是一个宏伟的总体计划 —— 不过，我确实希望，如果分叉时间足够长，我们也许可以回归开源。说实话，这是出于一个非常自私的理由 —— 我热爱开源。”
不过，Elastic 还没有完全走完这一轮。该公司并没有重新采用以前宽松的 Apache 2.0 许可证，而是采用了 AGPL，后者的限制更多 —— 它要求任何衍生软件都必须在相同的 AGPL 许可证下发布。在过去4年中，Elastic 为客户提供了专有 Elastic 许可证或 SSPL 的选择。SPL 由 MongoDB 创建，但后来未能获得官方开源定义管理机构 OSI 的 “open source” 批准。虽然 SSPL 已经提供了一些开源许可证的好处，例如查看和修改代码的能力，但随着 OSI 认证的 AGPL 的加入，Elastic 可以再次称自己为开源。
“Elastic（和 SSPL）许可证已经非常宽松，允许你免费使用 Elasticsearch；它们只是没有‘开源’的标签。我们对这个领域非常了解，但大多数用户并不了解 —— 他们只是在谷歌上搜索‘open source vector database’，他们看到一个列表，然后在它们之间进行选择，因为他们关心开源。这就是我关心是否在那个名单上的原因。”
展望未来，Elastic 表示希望与 OSI 合作创建新的许可证，或者至少讨论哪些许可证可以归类为开源，哪些不能。根据 Banon 的说法，完美的许可证是 “介于 AGPL 和 SSPL 之间” 的许可证，尽管他承认 AGPL 本身可能在大多数情况下就足够了。但就目前而言，Banon 表示，仅仅能够再次称自己为 “开源” 就已经足够了。
开源这个词依然充满魔力 —— 开源搜索、开源基础设施监控、开源安全。两个字眼就包含了很多东西 —— 它概括了代码的开放和所有社区方面，概括了我们开发人员喜欢拥有的一系列自由。
Shay Banon 在文中强烈表达了自己的不满，措辞激烈：
“亚马逊于 2015 年基于 Elasticsearch 推出自己的服务，还将其称为 Amazon Elasticsearch Service，这是很明显的商标侵权行为。NOT OK。”
“我在 2011 年借了一笔个人贷款来注册 Elasticsearch 商标...... 看到商标如此公然地滥用，我特别痛苦。亚马逊问题迫使我们提起诉讼。NOT OK。”
“商标问题让用户感到困惑，以为是 Elastic 和亚马逊之间有合作，这不是真的。NOT OK。”
“...... 多年来这种困惑仍然存在。NOT OK。”
“亚马逊针对 Elasticsearch 的 Open Distro 分支，进一步分裂了我们的社区，引发了相当多的混乱。NOT OK。”
“..... 最近，我们发现了更多挑战道德底线的例子。我们已经在专有功能方面上与众不同，现在这些设计却被视为来自亚马逊的灵感。NOT OK。”
1、Elastic 更改开源协议，社区有意见
2021年1月15日，Shay Banon 在公司官网发文，宣布将更改开源协议，从 Elastic 7.11 版本开始，Elasticsearch 与 Kibana 代码所遵循的 Apache 2.0 许可会调整为 SSPL 与 Elastic License 双许可。
SSPL 是由 MongoDB 制定的源代码许可。针对云服务提供商做出了限制，即要求云服务提供商在未对项目做出贡献的情况下，不得发布自己的开源产品即服务。SSPL 允许用户以自由且不受限制的方式使用并修改代码成果，唯一的要求是：如果将产品以作为一种服务进行交付，那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。
Shay Banon 在其博客中写道：
之所以选择这条道路，是因为这才是继续保持开放的正确思路，同时也将给我们的社区与公司提供保护。在某种程度上，这一切将使我们的开放程度进一步提高。作为后续措施，我们将逐步将免费专有功能从 Elastic License 转向 SSPL 加 Elastic License 双许可，旨在进一步增强我们希望达成的产品自由与开放目标。
Shay Banon 反复表示源代码许可的改变对绝大多数免费使用默认发行版的社区用户没有任何影响。Elastic 布道师们也宣传道：“只要你不是公有云厂商，License 的变化和你一点关系也没有，自己搭建部署 elk 没有任何合规的问题，只是针对基于它做云服务盈利还不开源出来回馈社区的这种情况。云厂商也能继续用 Elasticsearch，只不过前提是要全部开源出来，这样才有利于整个社区的发展。”
但是 Elastic 修改协议的这个行为还是引发了社区不满。
有开发者吐槽表示：“Elasticsearch 属于社区中的 1573 位贡献者，这些贡献者保留其版权，并授予 Elastic 不受限制地分发其作品的许可。开源是社区的工作......Elastic 更改协议是为了获得更多的钱，是为了建立对 Elasticsearch 的垄断...... 这是反开源的举动。Elastic 的行为辜负了社区，辜负了大家的信任。"
因为 Elastic 更改协议，也导致一些企业开始寻求 Elasticsearch 的开源替代方案。比如开源平台 Hopsworks 使用了 Elasticsearch 为 AI 资产(功能，模型，实验，数据集等)提供自由文本搜索，他们关注到自己的行为可能违反了 SSPL 的许可条款：
“如果您将本程序的功能或修改的版本作为服务提供给第三方...(适用许可条件)”
所以 Hopsworks 的开发者从 Elasticsearch 切换到了适用于 AWS(已获得 Apache v2 许可)的 Open Distro，并且发文总结了他们的迁移过程。
2、最终还是跟随了 MongoDB 的脚步
MongoDB 公司因其“NoSQL”数据库产品 MongoDB 而创立。MongoDB 并不是唯一的 NoSQL 数据库，但它是其中使用最广泛的数据库之一。另外 MongoDB 还引领潮流地创建了一种新的开源许可。
云厂商 AWS 或 Azure 打包 MongoDB 并将其作为基于云的 SaaS 服务(Software as a service)的一部分进行售卖，这样的问题在于，这些服务直接与 MongoDB 自己基于云的 SaaS 服务——MongoDB Atlas 形成了竞争。这种情况下，受到威胁的不是 MongoDB 的源代码，而是 MongoDB 自己的 SaaS 服务，而这恰恰是该公司的主要收入来源。
MongoDB 的 CTO Eliot Horowitz 认为，随着计算机技术进入云的新世界，有必要采取一些措施对开源软件业务进行保护。
2018 年 10 月，MongoDB 宣布其开源许可证将从 GNU AGPLv3，切换到 SSPL，新许可证将适用于新版本的 MongoDB Community Server 以及打过补丁的旧版本。
一开始，MongoDB 将该 SSPL 许可证提交给开放源代码促进会(OSI)， OSI 负责监督和批准新的开源许可证。但是有些人认为，SSPL 与 OSI 的开源定义第九条是不兼容的，第九条说“许可证不能限制其他软件”。并且经过 OSI 来来回回的一系列邮件讨论后，再加上该许可证本身的措辞问题，使得 SSPL 不太可能被 OSI 批准，所以 MongoDB 又取消了对 SSPL 许可的申请。于是，SSPL 并不是开源许可，而且将来也不可能成为正式许可。
MongoDB 更改开源协议也曾引起极大关注，RedHat 等厂商纷纷表示将弃用 MongoDB。一时之间，MongoDB 似乎深陷险境。但两年过去后，这家公司不仅还活着，而且活得很好，其股价也从 2018 年的不足 100 美元/股涨到现在的 361 美元/股。
MongoDB 也绝对不是唯一一个抱怨云计算正在侵蚀其利润的公司。像 Redis Labs、Confluent 这样的公司都更改了软件许可证，从原来的开源许可证转向更严格的条款，限制了软件的功能，使其不再属于开源软件。
3、Elastic License + SSPL
如果使用的 Elasticsearch 是直接从官方下载且是 6.3 之后的版本，那么按照 Elastic License 的条款，很可能已经违反了使用许可，Elastic 公司会保留追究权利。 这起源于2021年1月Elastic 公司宣布将采用 Apache License 2.0 的 Elasticsearch 和 Kibana 的源代码变更为双重许可模式：Elastic License + SSPL。
按照 Elastic License 和 SSPL 的条款，两者对于商用都有严格的要求。比如，SSPL 针对云服务商提出了严格的限制：“如果您将本程序或修改版的功能作为服务提供给第三方，则必须根据本许可的条款，需要通过网络下载免费向所有人提供服务源代码。”
Elastic License 虽然允许免费使用、修改、创建衍生作品和重新分发，但有三个基本的限制条件：
不得将产品作为托管服务提供给其他人
不得规避许可密钥功能或删除 / 隐藏受许可密钥保护的功能
不得删除或隐藏任何许可协议、版权或其他声明
摘自：elastic-license-faq
具体来说，Elastic License 禁止下列操作：
将 Elastic 公司的产品直接作为一项服务对外出售（如 Amazon Elasticsearch Service）
篡改源代码以达到在不订阅的情况下使用 Elastic 付费功能的目的，或者将修改后的版本投入生产之用
摘自：license-change-clarification
由于双重许可模式从 Elasticsearch 7.11 开始生效，为了规避上述限制，许多人会选择使用不受影响的 7.10.2 及更早的版本。
如果用户直接从官方下载了上述版本的免费 Elasticsearch 发行版，并且基于 Elasticsearch 向第三方提供服务，那么按照 Elastic License 的条款，这已经违反了使用许可，Elastic 会保留追究权利。因为从 Elasticsearch 6.3 开始，原本闭源的「X-Pack」功能开放了源代码 —— 采用 Elastic License，并被默认打包到发行版里面。所以从 6.3 起的所有免费发行版都包含了一个使用 Elastic License 的组件：X-Pack。根据 Elastic License 的条款，X-Pack 隐藏着 “潜在风险”。
因为无论是否使用 X-Pack，所下载的 Elasticsearch 都包含了该组件，如果基于该 Elasticsearch 向第三方提供服务。根据 Elastic License 的限制，这已经违反了许可，所以 Elastic 公司会保留追究权利。
前文提到，这是一种 “潜在风险”。之所以称为 “潜在风险”，是因为到目前为止，尚未出现因 X-Pack 使用的 Elastic License 而出现纠纷的案例。此外，根据开源专家的介绍，即使用户下载的 Elasticsearch 发行版包含了 X-Pack，并且它采用的是 Elastic License。如果用户没有启用它，那就无需遵循 License 的条款。而 X-Pack 正好是没有默认启用的功能 —— 需要用户手动开启。
如果用户手动启动了 X-Pack，将被视为接受 Elastic License。所以这名开源专家认为，默认情况下，用户使用 6.4 到 7.10 版本，依旧是只需遵循 Apache License 2.0。可以看到，「X-Pack」是导致问题的重要成因。如果要规避此 “潜在” 问题，要么遵循 Elastic License 许可，要么可以选择自行从 Elasticsearch 源代码构建不包含 X-Pack 的版本。当然，还可以考虑使用其他开源替代方案。
Elastic 也有同样的困扰，也面临着来自 AWS 的激烈竞争。两年前，亚马逊在 AWS 上提供了 Elasticsearch，还打包了自己版本的 Elasticsearch 代码库，并将其扩展为免费提供的好几项服务。亚马逊宣布推出 ElasticSearch 开源代码独立库时，还曾造成 Elastic 股价下跌，跌幅高达 5%。
面对这样的挑战，Elastic 公司一直未采取行动，除了状告亚马逊注册商标侵权以外。到现在，Elastic 终于觉得再不对 AWS 和 Amazon Elasticsearch Service 采取行动，“事情只会变得更糟”。Shay Banon 希望此更改“对用户产生零影响”，不伤害“公有云”之外的友商，但还是有 Hopsworks 这样的开源平台选择迁移到 Elasticsearch 的 Open Distro 分支，所以许可证变更的影响还有待观察。大家可以回顾一下这些旧闻。
Redis Labs再次更改开源许可证
MariaDB CEO痛斥云厂商滥用开源许可
MongoDB不满AWS等云厂商坐收渔利
CockroachDB 修改开源协议以限制商业构建 DBaaS
开源公司抱团取暖-讨论如何在云厂商环境下生存
当然AWS肯定不会就此示弱，这两天也没有闲着，这不今天(1月22日)就宣布创建“真正”开源的 Elasticsearch 分支。
Elasticsearch 和 Kibana 宣布变更开源许可证后引发了各方激烈讨论，但整起事件的另一个关键角色——被 Elastic 公司 CEO 发文怒斥的 AWS 却一直没有发声。然而就在1月22日，AWS 宣布将基于目前仍为开源状态的 Elasticsearch 和 Kibana--即 7.10 版本)创建分支，开源许可证也会继续使用 Apache License 2.0。为了确保由他们创建的分支能得到良好支持，AWS 会负责后续的维护工作。AWS 声称自己创建的分支是“真正”开源的 Elasticsearch，显然这是在暗讽 Elastic 公司即将采用的双许可证方案--SSPL + Elastic License)，毕竟 SSPL 和 Elastic License 都不是 OSI 批准的开源许可证。
AWS 曾在 2019 年推出 Elasticsearch 发行版——Open Distro for Elasticsearch，它采用了 Apache License 2.0，声称 100% 开源。据 AWS 自己介绍，在构建 Open Distro for Elasticsearch 过程中，他们遵循了众人推崇的“upstream first”开源开发实践，对 Elasticsearch 的所有改动都以 PR 形式提交给了上游，并将 Elastic 提供的“oss”构建合并至他们创建的发行版。
AWS 推出 OpenSearch：基于 Elasticsearch 的开源分支
2021年年初 AWS 宣布创建“真正”开源的 Elasticsearch 分支有了下文。2021年4月中旬，AWS 宣布推出 OpenSearch 项目，这是 fork 自 Elasticsearch 和 Kibana 的开源分支。
OpenSearch 项目由 OpenSearch (fork Elasticsearch 7.10.2) 和 OpenSearch Dashboards (fork Kibana 7.10.2) 组成，包括企业安全、告警、机器学习、SQL、索引状态管理等功能。OpenSearch 项目中的所有软件均采用了 Apache License 2.0 开源许可协议。AWS 介绍称，它们推出的 OpenSearch 删除了 Elasticsearch 中受 Elastic 商业许可证限制的功能、代码和商标，以兼容 Apache License 2.0，自称这是每个人都可以构建和创新的基础，任何人无需签署 CLA (Contributor License Agreement) 即可为项目贡献代码。另外，AWS 现有的 Amazon Elasticsearch Service 被重命名为 Amazon OpenSearch Service，AWS 表示更名不会影响正在运营的业务，Amazon OpenSearch Service 会提供一系列可供部署和运行的开源引擎，包括当前可用的 19 个版本的 Elasticsearch(7.9 和更早版本、近期推出的 7.10)以及新版本的 OpenSearch。
AWS 还说到会继续通过安全性和错误修复来支持和维护采用 Apache License 2.0 的 Elasticsearch，并将通过 OpenSearch 和 OpenSearch Dashboards 提供所有新功能。Amazon OpenSearch Service API 将与现有服务 API 向后兼容。此外，AWS 会提供从现有 Elasticsearch 6.x 和 7.x 托管集群迁移至 OpenSearch 的无缝升级路径。AWS 表示，当前版本的代码尚处于 alpha 阶段，未经彻底测试并且不适合用于生产环境。它们计划在接下来的几周内发布 Beta 版本，有望在2021年中期发布稳定版并投入生产环境使用。
包括红帽、SAP、Capital One 和 Logz.io 等在内的多个组织对 AWS 创建 OpenSearch 项目表示了支持。
Elastic也是上市公司，这种掌握在一家公司手上的项目，开源拉新在前，割韭菜再后，这个可以看看Qt。都是利益争斗罢了，没有谁比谁更高尚。坚持社区多元化，不被单一公司掌控的项目才是好的开源。越是大型商业公司，就越是热衷于开源，因为开源能为他们带来大量的免费劳动力，能大幅度的降低他们的研发和维护成本。但是他们不担心别人掌握了和他相同的技术后被反噬吗？完全不用担心，因为即便你掌握了同样的技术，也无法提供和他们相对抗的服务，软件本身没有任何商业价值，有价值的永远是服务。像 mongodb 和 elasticsearch 根本就无力和云厂商对抗，他们费尽心力研发的产品被云厂商拿来对外提供服务大赚特赚而引发强烈反弹是必然的。
2024年9月，Linux 基金会宣布成立 OpenSearch 软件基金会。
Elastic再次开源并希望与OSI合作再创新许可证
Elasticsearch于2024年8月下旬宣布再次开源，计划在未来几周内添加 AGPL 作为 ELv2 和 SSPL 之外的另一个许可选项。Elasticsearch 和 Kibana 又可以被称为开源了。很难表达这句话让我有多高兴。我激动得简直要跳起来了。我们 Elastic 的所有人都是如此。开源是我的 DNA。这也是 Elastic 的 DNA。能够再次将 Elasticsearch 称为开源，我感到非常高兴。简而言之，将在未来几周内添加 AGPL 作为 ELv2 和 SSPL 之外的另一个许可证选项。在更改许可证之后，我们从未停止过对开源社区的信仰和行为。但通过使用 AGPL（OSI 批准的许可证），我们可以使用开源一词，从而消除人们可能存在的任何疑问或疑惑。
3年前的2021年，Elastic 公司宣布变更 Elasticsearch 和 Kibana 的其中一项开源许可协议 —— Apache License 2.0，将其变更为双授权许可，即 Server Side Public License (SSPL) + Elastic License，而这两种许可证都不是符合 OSI 标准的开源许可证。在 Elasticsearch 和 Kibana 宣布变更开源许可证后引发各方激烈讨论后，AWS 则创建了一个自称真正开源的 Elasticsearch 分支 —— OpenSearch，并获得了包括红帽、SAP、Capital One 和 Logz.io 等在内的多个组织和厂商的支持。时至今日，Elastic 又采取了新的行动，“更改许可证是一个错误，Elastic 现在放弃了这一决定”。
对于3年前的这一转变，他们给出的理由是为了应对 “与 AWS 以及他们的产品造成的市场混乱存在问题......现在的情况完全不同了。我们不再生活在过去，并希望为用户创造更美好的未来。正是因为我们当时采取了行动，才有能力现在采取行动。”
增加 AGPL 许可选项不会影响使用 SSPL 或 ELv2 的现有用户，Elastic 的二进制发行版也不会有任何变化。同样对于在 Elasticsearch 或 Kibana 上构建应用程序或使用插件的用户来说，也不会有任何变化 --Elastic 的客户端库将继续采用 Apache 2.0 许可。
Elastic 创始人：热爱开源，希望合作 OSI 创建新许可证
许可证纠纷长期以来一直是商业开源领域的一个突出问题。一些大型供应商已经转向更严格的 “copyleft” 许可证，例如 Grafana 和 Element；或者完全采用专有许可证，例如 HashiCorp 去年对 Terraform 所做的。但有一家价值 80 亿美元的公司却选择了另一条路。Elastic 是企业搜索和数据检索引擎 Elasticsearch 和 Kibana 可视化仪表板的创建者，2024年9月，它在转而采用几种专有的 “source available” 许可近4年后，突然宣布将再次开源。这一举措与无数公司完全放弃开源的趋势背道而驰。有些公司甚至在创建一种全新的许可模式，如 “fair source”- 已被多家初创公司采用。
“这花了太长时间”，2021 年，Elastic 与亚马逊的云计算子公司 AWS 发生冲突，后者销售自己的 Elasticsearch 托管版本，几年后，Elastic 转用闭源许可证。鉴于 Apache 2.0 许可证的宽松性质，AWS 完全有权这样做，但 Elastic 对 AWS 使用 “Amazon Elasticsearch” 等品牌营销其产品的方式感到不满。Elastic 认为这造成了太多的混淆，因为客户和最终用户并不总是太关注开源项目和相关商业服务的复杂性。
Elastic 联合创始人兼首席技术官 Shay Banon 于2024年10月在接受 TechCrunch 采访时表示：“人们有时认为我们改变许可证是因为我们对亚马逊将我们的开源项目作为‘服务’提供感到不满。说实话，我一直都接受这种做法，因为许可证允许他们这样做。我们一直纠结的只是商标侵权问题。”
Elastic/联合创始人兼首席技术官 Shay Banon
Elastic 寻求法律途径迫使亚马逊放弃 Elasticsearch 品牌，这种情况让人想起了最近发生的 WordPress 纠纷。尽管 Elastic 后来与 AWS 达成了商标纠纷和解，但此类法律纠纷耗费了大量资源，而该公司想要做的只是保护自己的品牌。“当我们考虑走法律途径时，我们觉得我们有一个非常好的案例，而且我们最终也赢得了胜利，但由于我们对 Elasticsearch 许可证所做的更改，这已经不再重要了。但这实在是太耗时了 —— 你可能要花四年时间才能赢得一场官司，但到那时，你已经因为混乱而失去了市场。”
回到未来
这种变化在公司内部一直是一个痛点，因为公司被迫使用 “free and open” 而不是 “open source” 这样的语言。但这一变化正如 Elastic 所希望的那样，迫使 AWS 分叉 Elasticsearch 并创建一个名为 OpenSearch 的变体，而这家云计算巨头本月刚刚将其移交到 Linux 基金会。
随着时间的流逝，OpenSearch 的地位也已经稳固，Banon 和公司决定改变方向，再次将 Elasticsearch 开源。“我们知道亚马逊会分叉 Elasticsearch，但这并不是一个宏伟的总体计划 —— 不过，我确实希望，如果分叉时间足够长，我们也许可以回归开源。说实话，这是出于一个非常自私的理由 —— 我热爱开源。”
不过，Elastic 还没有完全走完这一轮。该公司并没有重新采用以前宽松的 Apache 2.0 许可证，而是采用了 AGPL，后者的限制更多 —— 它要求任何衍生软件都必须在相同的 AGPL 许可证下发布。在过去4年中，Elastic 为客户提供了专有 Elastic 许可证或 SSPL 的选择。SPL 由 MongoDB 创建，但后来未能获得官方开源定义管理机构 OSI 的 “open source” 批准。虽然 SSPL 已经提供了一些开源许可证的好处，例如查看和修改代码的能力，但随着 OSI 认证的 AGPL 的加入，Elastic 可以再次称自己为开源。
“Elastic（和 SSPL）许可证已经非常宽松，允许你免费使用 Elasticsearch；它们只是没有‘开源’的标签。我们对这个领域非常了解，但大多数用户并不了解 —— 他们只是在谷歌上搜索‘open source vector database’，他们看到一个列表，然后在它们之间进行选择，因为他们关心开源。这就是我关心是否在那个名单上的原因。”
展望未来，Elastic 表示希望与 OSI 合作创建新的许可证，或者至少讨论哪些许可证可以归类为开源，哪些不能。根据 Banon 的说法，完美的许可证是 “介于 AGPL 和 SSPL 之间” 的许可证，尽管他承认 AGPL 本身可能在大多数情况下就足够了。但就目前而言，Banon 表示，仅仅能够再次称自己为 “开源” 就已经足够了。
开源这个词依然充满魔力 —— 开源搜索、开源基础设施监控、开源安全。两个字眼就包含了很多东西 —— 它概括了代码的开放和所有社区方面，概括了我们开发人员喜欢拥有的一系列自由。