Amazon Elasticsearch Service 正式更名，云厂商和开源社区间必有一战？

云计算的普及几乎颠覆了各个行业和职能角色，商业开源市场自然也不例外。云服务所强调的效率、灵活性与可用性，同开源软件开发及商业化领域的既定秩序爆发出一场激烈的冲突。最典型的就是，近日亚马逊云科技与 Elastic 之间酝酿已久、并在今年全面爆发的冲突对抗。

全面爆发的对抗

“Elasticsearch 事件”时间线梳理：

• 2010 年，Shay Banon 在标准 Apache 2 开源许可下将 Elasticsearch 开源。2012 年，Banon 成立Elastic，提供围绕 Elasticsearch 订阅、托管和培训等服务。这家公司非常成功，吸引了超过 1.62 亿美元的融资，并在 2018 年上市，估值在 15 亿至 30 亿美元之间。Elastic 雇佣了一些 Lucene 提交者，这些人并为 Lucene 和 Elasticsearch 的开发作出了重大贡献。

• 随后，Elastic 在他们自己的“可用源”许可下发布了一些增强功能，即Elastic License。Elastic 规定对 Elasticsearch 的任何贡献（在任何一个许可下）均由其管理。Elastic 因将一些新功能置于此许可证下而受到了批评，因为这些新功能始于开放、社区讨论和想法。很明显，该许可证不是已批准的开源许可证。这种模式是“开放代码”——但 Elastic 对于“开放”的特定价值，即对产品的路线图和方向进行了集中控制。

• 亚马逊和一些较小的公司开始以软件即服务模式 (SaaS) 提供托管 Elasticsearch，直接与 Elastic 的产品竞争。Elastic 开始将他们的代码部分混合为 Apache 2 和 Elastic License，使这些企业难以仅使用开源部分，而亚马逊通过有效的分叉 Elasticsearch提供了一个完全 Apache 2 许可的版本，他们将其命名为Elasticsearch OpenDistro。此外，Elastic 还起诉了 Floragunn GmbH，后者提供了构成 OpenDistro 一部分的安全插件，并单独起诉 AWS 商标侵权。

• 2021 年 1 月，Elastic 称将在双重许可模式下发布 Elasticsearch 的所有未来版本，使用他们的 Elastic 许可和由 MongoDB 创建的 SSPL 许可，专门用于防止亚马逊等第三方提供其软件的托管版本。

• 2021 年 4 月，亚马逊云科技将分叉项目 Elasticsearch OpenDistro 重新命名为 OpenSearch，并计划将 Amazon Elasticsearch Service 更名为 Amazon OpenSearch Service。7 月，亚马逊云科技发布了 OpenSearch 1.0 版本。

• 2021 年 9 月，Amazon Elasticsearch Service 再更名为 Amazon OpenSearch Service，并支持 OpenSearch 1.0。

变更许可证时，Elastic 与亚马逊科技的冲突几近高潮。

Elastic 公司创始人兼 CEO Shay Banon 表示，变更许可证是为了保证企业无法在未与 Elastic 合作的情况下将 Elasticsearch 与 Kibana 产品作为商业服务来牟利。Banon 还在博文中写道，“设想一下，当亚马逊在 2015 年推出基于 Elasticsearch 的服务并将其定名为 Amazon Elasticsearch Service 时，我们有多么惊讶。”

作为回应，亚马逊云科技的高管们表示，“亚马逊云科技将加紧建立并维护开源 Elasticsearch 与 Kibana 的 ALv2 许可分支。”其 Elasticsearch 服务的所有新版本都将基于此分支，而且这场变化不会“减慢服务的发展速度”。

OpenSearch 与 Elasticsearch 在 GitHub 代码贡献对比

双方在你来我往，各说各的道理，持续爆发的争执也让用户们对于 OSS 许可的限制感到困惑。扑面而来的压力，也让 Elastic 越来越担心项目的后续资金供应跟不上发展需求。

作为一家上市企业，Elastic 的 Elasticsearch 软件一直在为沃尔玛、奥迪等企业客户提供网站搜索支持。亚马逊却将 Elastic 的开源 Elasticsearch 重新打包并出售给客户。Elastic 认为，亚马逊在本质上是夺取了由整个社区共同创造的自由代码，并通过巧取豪夺的方式保证只有自己能够从中获取价值。

开源的商业模式需要改变了？

自由软件运动以来，开源许可也随之发生了重大变化。

如今市面上有数十种开源许可证，但使用者最多的是以 Apache 2.0 和 MIT 为代表的少数许可证。Apache 2.0 和 MIT 被称为宽松许可证，因为它们允许商业供应商重新分发开源软件（OSS）及其专有的附加内容，唯一的要求是必须在分发过程中保留原始 OSS 的源代码及版权信息。

宽松许可证大受欢迎，因为像 Banon 这样的 OSS 开发者可以将原始代码与专有附加组件共同打包到商业产品当中，以此实现货币化转换。这样，开放许可也不会影响到专有代码，而 GNU 等通用公共许可证就作出了这方面限制。

Cloudera、Elastic、MongoDB 以及 Talend 等公司都依赖这样的商业模式，即先让用户喜欢上软件的免费开源版本，再在之后的生产应用当中付费来获取额外的企业功能与技术支持。

MongoDB 在其 2017 年的 S-1 募股文件中就有过类似的表述，其中提到 MongoDB 数据库的免费版本并不包含商业版本的所有功能，主要是为了“鼓励开发者使用、熟悉并接纳我们的平台”。

这种商业开源软件（COSS）模式在企业私有基础设施安装与运行的时代表现不错。然而，云服务的横空出世颠覆了一切：云服务开始在生产级服务上直接提供 OSS 功能与 API 的租赁式访问，这在根本上对 COSS 模式构成了威胁。

应用服务商通过互联网出售对 COSS 产品的访问权，这种访问是由专有增强功能再打包核心 OSS 代码创建而成，基本设计只需要考虑如何在多租户云基础设施及其他专有云服务中稳定运行，全程不涉及任何实际分发。

像亚马逊云科技这样的企业并不是在销售 Elasticsearch 软件，而是在销售基础设施、运营支持 Elasticsearch 各种功能。这种情况下，他们甚至将使用 REST API 或 SQL 语法的分布式搜索作为按需服务进行销售。

云服务商的服务产品并不会直接威胁到 COSS 商业模式，毕竟厂商可以通过单独的许可对其中的专有功能予以限制。让 COSS 陷入困境的主要有以下两个原因：

• 企业开发者使用等效的云服务替代内部运营的软件安装方案，消除了由 COSS 厂商向企业出售附加组件安全性、可靠性及集成功能的空间。

• Elastic 等企业可能利用开源运动中的善意，创建伪 OSS 许可证来保护其专有代码，同时继续保留 OSS 产品的外衣。

云时代下，商业开源模式应该如何发展？

面对这个问题，Elastic 当前“我全都要”的态度只会让情况进一步恶化。他们既想当 OSS 道德楷模，又想把握住商业软件供应商的丰厚利润。糟糕的是，他们为了限制软件商业用途而使用的全新服务器端公共许可证（SSPL）已经被开源软件倡议（OSI）公开嘲讽。

OSI 指出，Elastic 的 SSPl 许可证存在几个问题，特别是对于 OSS 的拥护者们而言，他们长期支持开源项目的善意未来很可能被锁定在专有限制性许可证之下。OSI 认为，Elastic 的变化并不代表着 OSS 许可模式的失败。相反，它反映出“Elastic 在现有商业模式与开源许可证设计目标上存在着内生冲突。”

企业应该如何参与开源

事实上，亚马逊云科技的 OpenSearch 分叉反而成了 Elasticsearch 乱局的最佳解决方案。当然，必须要有足够多的独立开发者（即与亚马逊云科技无关的开发者）参与进去，该项目才能取得真正的成功。

在 Linux 基金会及跨行业开源安全基金会的支持下，《哈佛商业评论》对企业使用开源项目进行了调查。调查指出，企业进入开源生态时，需要认真思考事关开源生态未来的以下几个问题：

• 企业的参与是否会对开源生态的未来健康和福祉产生负面影响？

• 如果开源项目较少受到社区意识的驱动，而更多被追求利润的机构所摆布，开发者是否会决定停止参与？

• 企业是否会单纯关注有利可图的开源项目，忽略掉全社会所依赖的其他关键基础设施？这类软件的安全维护难度大吗？

• 如果更多开源落入少数企业手中，是不是代表着参与 bug 及潜在漏洞检查的人手会越来越少？

如今的开源生态成熟且庞大，单靠志同道合人们的努力不可能保持高效运转。企业和政府这样的大型机构应该明白，当自己直接或间接赞助开源项目时会对整个生态系统产生怎样的影响，同时遵循一些必要的原则。

首先，企业和政府应该在不扼杀社区精神这一基本贡献动机的前提下，推动开源继续稳步发展。换句话说，企业应该设定明确的开源策略（最好鼓励员工尽可能为开源做贡献）。调查发现，不少员工对其所在企业的开源策略并不了解，导致他们一直犹豫要不要公开使用并参与到开源项目中。此外，企业和政府也可以主动支持开源项目，保证那些与自身运作息息相关的重要项目能够稳定发展下去。

第二，使用开源项目的企业（其实这几乎涵盖了所有企业）应该提高自身对所使用开源项目的认知水平。近期，美国出台的总统行政令要求将政府购买的所有产品汇总成一份软件材料清单（SBOM），确保政府了解使用了哪些开源软件和专有软件，进而做出潜在漏洞预判。

这一点非常重要，也值得其他企业效仿。这样能够帮助企业更好地理解自己对于开源社区的依赖性，并以更高的透明度了解到自己是否会受到新披露安全漏洞的影响。当前很多企业都在使用过时的开源版本，如果未能及时更新，则意味着软件中可能包含已知的 bug 及安全漏洞。同时，商业软件中使用范围最广的各大开源软件包都被存放在个人开发者（而非整体社区）的账户之下，这不仅会引发安全性问题，更存在着可靠性隐患。

第三，随着企业深入参与开源项目，各方都应该关注当前软件的稳定性，企业应该鼓励员工为那些对公司有用的项目出力，同时参与到常规的安全维护工作中。另外，企业应该意识到这些项目背后的志愿者社区至关重要，理应受到保护。通过这种方式，他们不仅能够被准许自己新添加的功能，同时也能保证整个开源生态的未来健康与福祉。

尽管越来越多的贡献者能够拿到企业赞助，但他们的主要驱动力并不是金钱。换言之，企业采取的传统激励杠杆也许起不了作用，必须更多关注贡献者们的内驱因素，例如对学习的热情、对开源社区的归属感及对程序员这一专业身份的认同等。

结束语

亚马逊云科技与 Elastic 之间围绕 Elasticsearch 商业用途的斗争，凸显出开源软件供应商在云时代下已经必须要作出改变了。但开源生态系统中涉及的利益相关方数量众多，任何单一的参与者都很难解决所有问题。因此，未来需要企业、政府机构及个人贡献者等多方的共同努力，来保障开源生态系统的发展与活力。

相关链接：

https://hbr.org/2021/09/the-digital-economy-runs-on-open-source-heres-how-to-protect-it

https://searchcloudcomputing.techtarget.com/opinion/Elastic-vs-AWS-highlights-open-source-monetization-dilemma