开源许可证的变更带给我们什么启示？
文 | 大东BE
近日，Elastic 公司将旗下的知名开源项目 Elasticsearch 和 Kibana 的开源许可证变更的事件持续发酵，再次把我们的目光聚焦到开源公司与云服务厂商之间的矛盾旋涡中。
事实上，Elastic 公司与云服务厂商的“积怨”由来已久。回顾这家全球知名的开源上市公司的发展史，我们可以一窥现代开源软件公司在商业化进程中的机遇与挣扎。
成功
时间回到 2004 年，ElasticSearch 的创始人 Shay Banon 彼时还是一个失业的程序员。Shay 的妻子想要去伦敦学习当厨师，于是 Shay 跟着她来到了伦敦。在待业期间，Shay 打算帮妻子做一个食谱搜索引擎，好让她的厨艺进步更快。
Shay 最初使用的是开源检索引擎 Apache Lucene 的一个早期版本，但他发现自己直接使用 Lucene 十分困难，为了方便在 Java 程序中直接添加搜索功能，Shay 为其做了一个抽象层，并集成了自己的第一个开源项目 Compass，这就是 Elasticsearch 的雏形。
后来的工作中，Shay 需要为一个高性能、分布式环境下的内存数据网格开发分布式搜索引擎，他决定重写 Compass，把它变为一个独立的服务并取名为 Elasticsearch。
Elasticsearch 的第一个公开版本于 2010 年 2 月发布，并一跃成为 Github 上最活跃的开源搜索引擎项目之一，在短时间内迅速吸纳了超过 300 名 contributors 。 于是在 2012 年，Shay 专门创立了 Elasticsearch 公司，开始围绕 Elasticsearch 项目提供商业服务，并为项目的新特性开发提供资金支持。凭借将复杂的底层逻辑封装和提供简单易用的 API，Elasticsearch 很快风靡全球，成为很多企业搭建搜索引擎的首选开源软件。
Elasticsearch 早期的商业化与很多知名开源项目一样，采用内核开源、扩展付费的模式，即项目的基本功能保持开源和免费，而对一些专为企业定制的扩展功能进行订阅收费的模式。2014 年，成立仅 18 个月 Elasticsearch 公司就获得了 7000 万美元的融资，顺利进入发展快车道。
很快，Elasticsearch 公司在 Elasticsearch 的基础上扩展出了日志解析工具 Logstash 和可视化工具 Kibana，构建了完整的 ELK 日志分析系统产品生态。随后又开发了用于监控的 Marvel、用于安全的 Shield 等商业化插件，并围绕搜索和分析业务陆续收购了一些创业团队。由于公司的主要产品已经从单一的 Elasticsearch 变为完整的搜索、分析业务整合方案，Elasticsearch 公司在 2015 年正式更名为今天的 Elastic。
凭借成功的开源商业模式，Elastic 公司于 2018 年顺利 IPO，成为一家市值超过 50 亿美元的上市公司。包括 Shay Banon 在内的一众创始团队成员也实现了财富自由。
威胁
前面说到，Elasticsearch 之所以能够从一个单纯的个人项目发展成为一家市值数十亿美元的上市公司，与其成功的开源商业模式密不可分。通过内核开源，扩展付费的方式，Elastic 公司早期从企业客户中赚取了可观的利润。
然而正是在 Elastic 公司高速发展的时期，以 AWS、谷歌云、微软 Azure 为代表的云服务厂商开始陆续推出基于开源数据库的云服务，对包括 Elastic 公司在内的开源软件公司的商业模式带来了巨大的威胁。
2015 年，AWS 推出 Amazon Elasticsearch 服务，将开源的 Elasticsearch 集成到自家的云服务中以供客户使用。大量的企业客户购买了这些配套的云服务，使得 Elastic 公司失去了很大一部分市场。据统计，AWS 单单 Elasticsearch 一项服务的收入就已经高于 Elastic 公司的所有收入。
为了夺回一部分市场，Elastic 公司也尝试将 Elasticsearch 中的一些高级功能改为商用收费模式，以限制云厂商的索取。而 AWS 这边的应对方式则是索性自己分支了一个 Elasticsearch 版本 ，并把 Elastic 收费的模块全部开源。
除了 Elasticsearch 以外，这些云服务厂商早前也针对 MySQL、PostgreSQL、MongoDB、Redis 等开源数据库项目推出对应的云存储服务，对这些开源项目所属商业公司的付费业务造成了直接的冲击。
变更
正是在这样的背景下，以 AWS 为代表的云服务厂商与一众开源商业公司结下了梁子，迫使后者采取了一些激进的反制行动，包括变更项目原有的开源协议，甚至直接改为商业授权等：
- 看不惯云计算公司流氓行为，MongoDB 更改开源协议
- “分叉并商品化”，GitLab 和 Elastic 炮轰 AWS 的开源方法
- 不想云厂商坐收渔翁之利，Kafka 团队修改 KSQL 开源许可
- Confluent 修改开源许可证，限制云供应商滥用
- 不想让云提供商白白获利，Neo4j 宣布企业版彻底闭源
- MariaDB CEO 痛斥云厂商对开源的无尽掠夺，从不回馈社区
- 开源软件受云服务商影响，共用条款终止开源滥用现象
- CockroachDB 修改开源协议，限制商业构建 DBaaS
Elastic 采取的举措则是删除旗下项目 Elasticsearch 与 Kibana 项目原本的 Apache 2.0 许可证，仅保留 SSPL 许可证与 Elastic 商业许可。其中 SSPL 是由 MongoDB 于 2018 年推出的新型许可证。
2018 年，MongoDB 牵头发布了新的许可证 Server Side Public License，即 SSPL，用于取代原本使用的 AGPL 协议。SSPL 与 AGPL 大体上类似，唯一的区别就是针对云服务商提出了更严格的限制：明确要求托管 MongoDB 实例的云计算公司要么从 MongoDB 获取商业许可证，要么向社区开源其服务代码。
MongoDB 首席技术官 Eliot Horowitz 表示，由于云计算的出现，开源社区应该重新考虑并更新原有的开源许可证，以“应对新环境中的新挑战”。Horowitz 认为，经过 OSI 认证的传统开源许可证，主要的精神是确保用户可以对软件的原代码随心所欲地进行操作，但不能将开源软件变为专有软件来销售。而如今云计算的出现，能够让云服务厂商在不违反开源协议的情况下将开源项目以 SaaS 的形式来赚钱。SSPL 就是为了限制这种情况而诞生。
然而，SSPL 并没有获得 OSI 的认可。现代开放源代码定义的合著者、OSI 创始人之一 Bruce Perens 表示，SSPL 协议与 OSI 开放源代码定义的第九条相违背，该定义要求“开源许可证不得限制该开源项目（包括下游分支）以外的其他软件”。但 SSPL 要求云厂商将与 MongoDB 集成在一起的所有 SaaS 软件开源，因此未能通过 OSI 的认证。
如今 Elastic 公司也采取了与 MongoDB 相同的变更许可证举措，在保持开源与商业化之间面临新一轮的舆论考验。
争议
Elastic 等开源软件公司将旗下开源项目许可证变更的举动在社区中引发了巨大的争议，舆论导向也分成了正反两派。
支持开源公司变更许可证的一方与这些开源软件公司的观点基本一致：云服务厂商长久以来对开源社区“只索取不回馈”，从开源社区的劳动成果中获得了巨大的利益，同时对开源社区本身的利益造成了损害，确实应该对其加以限制。
而反面的观点似乎更加丰富。
一些受 Elasticsearch 协议变更影响的下游开源项目首当其冲。比如使用 Elasticsearch 作为存储后端的 Apache Skywalking，其对于 Elastic 变更许可证的回应是“不能再仅使用 Elasticsearch，会考虑其他存储方案，例如同为 Apache License 2.0 许可的 InfluxDB、TiDB 和 H2 Server”。显然，Elastic 擅自变更许可证对于其下游的开源项目来说也算是一种“变节”。
还有舆论认为，云服务厂商近年来也参与了开源社区的贡献，例如 AWS 分支 Elasticsearch 后做的一系列优化也都回馈给了上游社区，对项目的发展起到了一定的积极作用。此外，以 AWS 分支并完全开源 Elasticsearch 的付费模块这件事来说，这样的做法实际上从项目本身的推广以及社区用户来说都是有益的，而唯一利益受损的似乎只有依靠 Elasticsearch 盈利的 Elastic 公司。
知名开源产业记者 Scott Gilbertson 表示，Elastic 的做法与其他从开源转为专有的软件在本质上是一样的。“开源的初衷是通过允许最大范围的用户使用你的软件，建立一个最大的社区，让更多地人关注到软件中的错误，同时也让更多的人来修复它们。在这个过程中，社区会变成软件发展的动力。而社区规模的增长会成为市场份额，有时市场份额会变成利润，但这些利润不应该是开源本身追求的东西。”Scott 认为，既然利用开源收获了庞大的社区和市场，就不应该因为外部的竞争压力而改变开源的本质。“如果你基于开源构建了它，在它发展壮大后又将其拿走，这可能比你从未构建过它更糟糕。”
总而言之，开源公司在法律上拥有擅自更改旗下开源项目许可证的权利，而云服务商基于开源项目提供云服务以及分支开源项目也没有违反现有开源许可证的要求。双方在均未违反“游戏规则”的前提下，各自的出发点都是基于自身的利益。而正是由于双方利益的冲突，造成了一系列许可证变更的事件。
启示
既然涉及到利益，那么事件的双方也就不是简单的非黑即白了。
开源软件公司面对来自云厂商的市场竞争压力，采取变更开源许可证的方式来自救无可厚非，但确实也伤害了包括下游开源社区在内的开源软件用户；云厂商通过分支开源项目，并将优化的代码回馈到上游社区，对社区和用户来说是有益的，但将开源项目以 SaaS 的方式获利也确实威胁到了原生开源公司的生存。
以现有的案例来看，有没有一些相对较好的解决方案能够带给我们一些启示呢？
从开源软件公司一方来看，CockroachDB 采用的解决方式就挺有意思。CockroachDB 是开源的云原生 SQL 数据库，为了扼制云服务厂商的索取，同时又保持项目本身的开源理念，其官方采用了一种介于闭源和开源之间的许可证 —— BSL 。BSL 是 MariaDB 公司提出的一个新型许可证，它本质上是闭源和 Open Core 开源模式的“中间模式”，但也得到了 OSI 创始人 Bruce Perens 的认可。在 BSL 之下，源码始终是自由的，并且保证在某个时间点会变成“真的”开源（OSI 定义的开源），表现在 CockroachDB 中是版本发布三年后会自动切换为 Apache 2.0 许可证。
在该协议之下，CockroachDB 用户可以将 CockroachDB 扩展到任意数量的节点，可以使用 CockroachDB 或将其嵌入到他们的应用中，无论是将这些应用分发给客户还是将其作为服务运行，甚至还可以在内部将其作为服务运行。但是唯一不能做的是在没有取得授权的情况下以商业形式用 CockroachDB 提供数据库即服务（DBaaS）。
这种附带“延时属性”的开源许可证在阻止云厂商利用开源项目获利的同时，也确保了下游开源项目不受影响，且项目源代码会在一定时间后完全开源，是业内目前比较看好的一种解决方案。
当然，也有像 Red Hat 这样已经做大做强的开源软件公司，索性自己也推出云服务，“打不过就加入”也是一种解决方案。
而从云厂商一方来看，为避免类似的争端，将资源投入到更加中立的第三方开源软件基金会是现阶段的趋势。
由专业的开源基金会管理的项目通常在开放治理方面做得更好。一方面是开源基金会由多家厂商共同参与，各方能够在互利互惠的前提下制衡发展，实现合作共赢；另一方面，由开源基金会管理的项目在版权上也更加中立，变更许可证往往需要经过社区内部各方的严格评审投票通过才可进行（通常不会轻易变更许可证），这样的开源项目在开放治理的模式下拥有更加广阔的市场前景。
如今主流的开源基金会如 Apache 软件基金会、Linux 基金会、CNCF 等，旗下的很多项目都不乏来自各大云厂商的重要贡献，正是得益于包括云厂商在内来自各方的大力支持，这些基金会的开源项目社区才能够发展得非常好，比如 Linux Kernel、Kubernetes 等。
开源软件发展到今天，已经客观形成了一个巨大的开源产业生态，参与者有云服务大厂，有基于各开源项目的创业公司，也有千千万万对开源充满热情的个人开发者和用户，每一个参与者都是不可忽视的。云厂商有自己的盈利模式，开源软件公司也有自己的生存法则，在不伤害个人开发者和用户的前提下，平衡各方的利益和谐发展，是未来整个开源世界需要长期思考和探索的重要课题。
参考链接：
https://www.oschina.net/news/126717/es-n-kibana-licensing-change
http://www.ruanyifeng.com/blog/2019/06/open-database-relicensing.html
