Linuxeden开源社区Airbyte 是一个用于数据集成的EL（Extraction-Loading）平台，组织可以使用该平台在数据源之间构建管道，与 Singer的数据协议兼容。2020年7月创建至今，Airbyte 通过开源的方式得到了迅速成长，目前其在数据领域知名度不小。
10月初，Airbyte 作出了一项重大转变——其核心平台许可证从 MIT 转换至 Elastic License 2.0（简称 ELv2，目前并不被认为是标准的开源协议），这意味着 Airbyte 成为继 MongoBD、Elasticsearch、Confluence等前辈之后，又一“背离”开源（Open Source）的开源公司。
GitHub显示，Airbyte 已启用 ELv2，https://github.com/airbytehq/airbyte/blob/master/LICENSE
Airbyte 表示，如果继续使用 MIT 许可证，其利益将会被某些大公司侵犯，“这种事广为人知”。其中，箭头瞄准的正是饱受争议的云厂商们。
“一些大公司会通过复制 Airbyte 的项目，来发行 Airbyte Cloud 竞品，从中牟利。”而在 Airbyte 的观念中，个人或者小团体应该得到免费且开源的资源，而当我们的项目满足的是机构需求时，就应该是商业盈利的。
与此同时，Airbyte 转换许可证之后（ELv2 禁止商业用途），立即在10月6日上线了 Airbyte Cloud。但是，Airbyte 并未停止开放源代码，而是计划采取一种新型自创的“参与模式”（participative model），通过与相关维护者和开发者分红的方式来运行社区。
这当然不是孤例。近几年，越来越多的开源软件公司采取行动来对抗云厂商，已经形成一股不可忽视的力量。同时与他们并存的是：斥责他们“离经叛道”的传统开源者和因为赚钱得罪他们的云厂商们。
这三股势力各执一词、争论不下，局中人因为立场不同看法自然也不同。“三方博弈”的格局下，传统开源定义会发生改变吗？云计算到底是开源的“灾星”还是“救星”？这场博弈最终会走向何方呢？或许，只有时间才能解答。
01 “开源社区的暗面”爆发，开源公司为何出走？
今年7月，一篇名为《开源社区的暗面》的文章探讨了开源贡献者们的各种“不满”。
有维护者因为社区“迷信明星程序员”而离开，社区管理者与项目拥有者到底谁说了算？也有维护者因为社区各种各样的要求烦不胜烦而离开，他们的付出和收益对等吗？更有维护者直言 “Pay Me or Fork This”，决定“不再免费为世界500强公司工作”。
Node.js 社区中赫赫有名的 web 框架 hapijs 和数据验证类库 joi 的核心贡献者之一Eran Hammer就在自己的文章《How to Use Open Source and Shut the F**k Up At the Same Time》中直接指出了所有问题的核心：项目消费者的权利和贡献者的义务是否具有天然正当性的？
似乎，开源社区所有潜在的“暗面”都直接与这一问题相关，包括这几年涌现的开源公司“出走潮”。这一现象在2018年的时候达到了一个高潮，而且所有矛头都指向了近些年大火特火的云厂商们：
2018年8月，数据库开发商 Redis Labs闭源了 RediSearch、Redis Graph、ReJSON、ReBloom、Redis-ML 等项目，经过两次变更，将一些模块的许可证变为 Redis 源码可用协议（Redis Source Available License，RSAL）。
2018年10月份，开源数据库的开发商 MongoDB推出了自己的许可证服务器端公共许可证（SSPL），MongoDB CEO Dev Ittycheria 在发言中特意提到了阿里巴巴、腾讯和 Yandex 等云服务提供商，指责他们“在考验AGPL的边界”。
2018年底，图数据库 Neo4j 宣布，从 Neo4j 3.5 版本开始，企业版仅在商业许可下提供，不再提供源代码。Philip Rathle 在官博中解释，这是为了避免云提供商只从开源中“薅羊毛”而不为这些项目作贡献，还影响开源项目的健康发展。
随后，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 官网上，开源定义（The Open Source Definition，简称OSD）那一页的第一行内容便是：“ Open source doesn’t just mean access to the source code. （开源并不意味着源代码可获取。）”要想被称之为货真价实的开源项目，还必须满足分发自由、原作者源码完整性、不歧视个人或团体、不歧视任何领域、不限制其他软件等十项原则。目前，已经有100多个开源许可证获得了 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），并不代表开源。况且，从开源诞生至今，这种被商业利用的事情并不少见，真正的开源的重点是分享和奉献精神。
对此产生的争议，OSI 重申：“如果没有对开源进行标准定义，软件开发是不可能走下去的。如果任何人都可以提出自己对开源的定义，那么这个世界就会缺乏信任，而如果没有了信任，就不会有社区，不会有合作，也不会有创新。”
但是，开源概念真的不可更改吗？云原生计算基金会首席技术官 Chris Aniszzczyk 曾指出：“最初的开源概念必须得到修正，因为它不再合适当今这个时代，云计算可以利用其垄断力量采用成功的开源项目而不对其做出任何贡献。”这样的改变会发生吗？
03 云计算“吞噬”开源，云厂商似乎也没做错
或许，这个云计算的时代的确让开源发生了一些微妙的变化。
有言论认为，开源面临的真正挑战来自于云计算正在改变的商业格局，云计算这种新的“信息架构”的普及产生了SaaS/订阅付费模式，这也是一种新的产品分发模式。
云计算在“吃掉”了企业软件之后，正在渗透进开源软件扎堆的基础软件中。冲突一触即发。分布式存储提供商 Storj Labs 的 CEO Ben Golub 直言：“开源软件是云计算的最大受害者（loss leader）。”
实际上，云厂商并没有违反相应开源协议的约定，却被修改后的一系列协议“歧视”了。
以被狙得最厉害的亚马逊为例，作为云服务商“一哥”，亚马逊被Mongo BD、Elastic等点名多次，原因是亚马逊复制了他们的软件（甚至一些专有功能），并集成到AWS，用于盈利却无所回报。这直接导致了Mongo BD、Elastic等等公司的“修改协议”行为。2019年4月，6家开源创企在硅谷召开会议，主题就是如何针对亚马逊提出反垄断诉讼。
被“围剿”的亚马逊也有自己的说法。在与 Elastic 的争论中，亚马逊解释自己并不是“分叉（fork）”，开发 Open Distro for Elasticsearch 纯粹是由于 Elastic 把大量专有代码塞入到了核心的 Elasticsearch 项目。这使得 AWS 客户面临风险，因为什么是完全免费使用的开源、什么是公司的专有代码并非一目了然。亚马逊希望通过开发自己的 Elasticsearch 版本，为客户提供可信任的软件版本。
没有任何开源协议强制要求使用者必须回馈社区， Chris Aniszzczyk 也认为，亚马逊向开源社区贡献额外代码是好事，Open Distro 为 AWS 客户解决了一个实际问题。
这些争论所展现的，或许并非开源与否，而是实力弱势的开源提供商与巨头之间的不平衡关系。有评论认为，那些开源软件商的潜台词实际上是“云厂商抢了开源软件厂商的潜在客户”。像RedisLab、MongoDB 这样的商业公司，真正关心的是云厂商能不能给自己分润，而不是贡献代码。
要知道，正在被云计算占领的企业软件市场是一个全球每年大概有4000亿美元市场的生意。
也有观点认为，开源公司与云厂商之间的关系，更应该是合作而不是竞争。 Open UK 的 CEO 兼首席策略官Amanda Brock 就认为，Elastic、MongoDB等从开源领域撤退的几家公司，他们的核心产品都不再是开源软件。开源公司应该学习与云厂商巨头合作，而不是尝试为他们制定特殊条款。
至此，由Elastic、MongoDB等组成的开源“反叛力量”与 OSI 把持的传统开源权威以及以亚马逊为代表的云厂商势力一起，使开源世界呈现出了“三方博弈”的局面，这样的局面会持续多久呢？又将怎样结束呢？我们拭目以待。
来源：OSCHINA