亚马逊|三方博弈，开源世界正在发生改变( 二 ) 云计算|MongoDB|开源软件

随后， Confluent、Cockroach、Kafka、Elastic 等开源公司纷纷修改开源协议，从 AGPL、Apche 2.0 等官方标准开源协议转向 SSPL、ELv2等具有争议的协议。至此，这股“开源反叛潮”开始呈现出愈演愈烈的态势。
此次， Airbyte 所采用的 ELv2 就属于后者。 Airbyte 表示，这次许可证的变更不会影响到任何一位用户， “超越开源模式”是 Airbyte 走向商业化的第一步。

Airbyte 并未完全抛弃 MIT ，只是在核心层面使用了ELv2
对此， Airbyte 提出了一种全新的参与模式（participative model）——一旦项目被用于 Airbyte的商业版本中，项目维护者（maintainers）可以得到一笔收入分红。相应地，这些拿到分红的维护者则对上述项目的 SLAs、新 features 和 bug 负有责任。
在 Airbyte 看来，在参与模式下， Airbyte 贡献者社区将与商业化路径一样，能够获得利益。无论是卖方、代理商还是开发者，只要能够 Airbyte 及其生态更加完善都能从中分得一杯羹。
02 开源（Open Source）并不是源代码可见（source avalibale）
但是，在传统开源范畴内， Airbyte所提出的模式，并非“开源” ，而是个不折不扣的商业模式。
什么是开源？或者准确说，什么是“Open Source” ，其实有个明确的定义。 1998年成立的开放源代码促进会（ Open Source Initiative ，缩写：OSI ）提出的开源十项原则，是目前大家所公认的。
在 OSI 官网上，开源定义（，简称OSD）那一页的第一行内容便是：“ Open source doesn't just mean access to the source code. （开源并不意味着源代码可获取。）”要想被称之为货真价实的开源项目，还必须满足分发自由、原作者源码完整性、不歧视个人或团体、不歧视任何领域、不限制其他软件等十项原则。目前，已经有获得了 OSI 认证。

而上文所述的“开源反叛者”所制定的许可证，不在此列。
2018年10月， MongoDB 更换为SSPL的同时，也向 OSI 提交了申请，当时 MongoDB 坚信 SSPL 符合开源计划的批准标准。然而， 2019年3月， MongoDB 首席技术官兼联合创始人Eliot Horowitz 宣布从 OSI 的批准程序中撤回 SSPL 软件许可证。
OSI官方对此也是十分恼火，不仅在当时就拒绝了这一申请，并且表示“ SSPL 不是开源许可协议，虽然自称具有开源的所有优点和承诺，但事实并非如此。 ” ，甚至在2021年1月的时候，又， “SSPL 是一种典型的‘fauxpen’源许可证。 ”
那么，以SSPL、ELv2为代表的许可证们得不到开源认可的原因是什么呢？看看几个典型例子，或许就能发现。
SSPL 明确要求托管 MongoDB 实例的云厂商要么获取商业许可证要么向社区开放其服务源码；Confluent 的 Confluent Community License 不允许将项目源码作为 SaaS 产品提供给用户；Redis Labs 推出的 RSAL 要求源码不能集成到数据库产品、缓存引擎、流处理引擎、搜索引擎、索引引擎或者机器学习/深度学习/AI 服务引擎；Cockroach 采用 BSL（Bussiness Source License）也要求用户唯一不能做的是在没有取得授权的情况下以商业形式用 CockroachDB 提供数据库即服务（DBaaS）；而 Airbyte 事件中的主角ELv2则表明：不可将产品作为托管服务提供给其他人、不得规避授权密钥功能，或是阻碍授权密钥运行、不可以删除或是掩盖任何授权许可、版权和声明。
这些限制条件“剑指”云厂商的同时，也毫无疑问违背了 OSD6（不歧视任何领域）和 OSD3（允许他人修改或衍生该作品）等开源原则。
在传统概念中， “Open Source”是个专用词组，开源标准很高，仅仅是在代码托管平台上公开，只能称之为“源代码可见”（source available），并不代表开源。况且，从开源诞生至今，这种被商业利用的事情并不少见，真正的开源的重点是分享和奉献精神。