前言

开源答应证从最早的 GPL 开端， 逐渐演进到 GPLv2 和 v3，中心还有 Apache、MPL、AGPL、LGPL 等，可是近几年来有一批新的答应证的呈现，引起了社区的一些激烈的评论。这些新的答应证包含 BSL、SSPL、Elastic 以及一个比较特殊的附加条款 Commons Clause。

社区内从争论的角度首要分为两大阵营：原教旨主义和实用主义。原教旨主义的同学们以为只需遵照1998年建立的 Open Source Initiative（OSI）界说的10大原则，经过OSI 这个安排审阅认证过的（OSI-Certified），才可以称之为开源的答应证。实用主义则从开源自身的目的出发，以为在源代码敞开，绝大部分的社区开发者在运用或许奉献时不受影响的情况下，不用纠结于字面的界说怎样，对社区有益即可。

依照 OSI 的开源答应证规矩，现在运用 SSPL 的 MongoDB，运用 Elastic License V2 的 Elastic Search、Airbyte，运用 BSL 的 CockroachDB， 以及附加了 Common Clause 的 Redis，这些大名鼎鼎的开源软件，都不能称之为“开源软件”了。

那么问题来了？如果由于上面的原因，这些软件不被以为是开源了，是 Proprietary 软件了，莫非咱们真的叫这些咱们现已一直在免费运用，并且可以继续运用很好的软件为“闭源软件”或许“商业软件”？好像也不太对。“源代码可用”，略微绕口了一点。

让咱们先从以 SSPL 为代表的新一代开源软件厂商和 OSI 的角度分别来看一下这个问题两个对立面的一些底层逻辑。终究咱们再来共享下关于云年代开源答应证的一些观念。

我所知道的 SSPL

MongoDB 是一个十分受程序员喜爱的 NoSQL 数据库，我是12年左右在硅谷和朋友创业的时分接触到的。在花了一个周末改写了几千行 Python 代码，把和 MySQL 的交互改成了 MongoDB 之后，本来目的是改善并发性能的我却发现了一个意外的惊喜：代码行数缩小到了小几百行，是原来的15%——从此我就义无反顾地开端了我的 NoSQL 之路。

由于在社区比较活跃，自己也写了一个和 MongoDB 相关的开源 NodeJS 组件，所以在13年创业项目中止后我就加入了 MongoDB。在我加入的时分，MongoDB 现已建立6年了，人员规模也有300~400人，每年开销一亿美元，收入呢？其时 MongoDB 的首要营收来自于一些咨询服务和企业版的售卖。可是咨询服务收入真实是少得可怜，企业版也不太好卖，最大的竞品是自己：开源版别。所以只能一直依托很多风投资本不断输血。可是融资现已到了F轮，投资人的耐性终于告罄。在一场董事会后，其时的 CEO 和 CRO 全体撤下，换成一个久经沙场的工作经理人 Dev Ittycheria。

Dev 上马今后当即制定了2-3年内完结上市的目标，推行了一系列新的商业化行动，包含商业化第一优先，进军全球，推出云版产品等一系列办法。我便是在那个时刻，从生活工作了10多年的美国回到我国，作为 MongoDB 在大中华区的第一位正式职工来协助 MongoDB 在我国落地商业化。在我回国的14年下半年，MongoDB 云产品 Atlas 还在研制中，MongoDB 的首要商业化手段还是企业版。

2016年的时分，MongoDB 正式发布了 Atlas 产品，一个在公有云上的保管数据库服务。MongoDB 企业版的客户是可以用百或千计的，可是开源版别的开发者或许有几十万。这些大部分开发者不会购买企业版授权，可是不管怎样他们需求运用和办理维护。这个时分 Atlas 这种云产品形式就很快得到了这些开发者的青睐。虽然本钱不是太低，但毕竟是开箱即用，省了0.5或许0.25个 DBA 的费用，所以MongoDB Atlas 上线后就呈现了比较快的增速，在2017年上市的时分，现已成为 MongoDB 的增加最快的事务了。

反观国内，某公有云其实也在2016年，比 MongoDB 原厂更早的时刻，推出了云上的 MongoDB as a Service，还是用的 MongoDB 的根据 AGPL 的社区版。其时的我国市场，企业版的出售其实是举步维艰，企业版的售卖逻辑是供给了额定的价值，首要包含原厂技能支撑和一套独立的额定集群办理工具（监控、备份等），MongoDB 数据库才能都是一样的，和开源版比较。可是在软件获取本钱上，一个是0元/年，一个是数十万元/年。在10万元就能请一个工程师的我国企业市场，可想而知企业的付费志愿度有多高。

除了国内，俄罗斯的一些头部云厂商也开端在他们的云上推出了 MongoDB as a Service，也都根据免费的 MongoDB 社区版。在此进程中，云厂商为了可以更好地将一个产品融入到他们一致的云管渠道，供给一些额定的才能支撑，或许自己着手解决一些产品的 Bug 来满足 SLA，势必会对源码做许多修正。在这个时分 MongoDB 发现，某些云厂商并没有彻底依照 AGPL 协议规范，将一切这些改动如数开源。

云商的实践做法往往是如此，首要公开 Fork 某个 MongoDB 的上游版别，然后在这个 Fork 里面标志性地提交一些更新，推到 GitHub。实践上很多的开发会在一个 Private fork 上进行，不会推送到公开的 Fork 上面，更别说回溯到上游了。从 MongoDB 的角度，当发现这些 AGPL 协议并没有在这些云厂商得到很好的合规执行的迹象的时分，就试图从商业化上和云商进行交流，期望对方要么是依照职业的规矩发布代码，要么就达到商业化协作。

经过屡次洽谈，动用到各自的 Legal Team 今后，MongoDB 发现面对的问题是——商业化协作，双方期望值相差太大，一个想吃肉，一个只愿意给肉汤。开源合规方面，云商指着那个基本不怎样更新的 Repo 说咱们现已依照协议开源了。只需到诉诸公堂，才可以去内部取证。怎样办？类似的案件，没有先例，再在一个彻底生疏的国家去走这条路，听上去便是十分崎岖。可是云服务又几乎是一切新一代开源软件公司最首要的收入增加引擎，真实又无法听之任之。

所以 MongoDB 挑选了釜底抽薪。改答应证。

在改协议之前，MongoDB 首要选用的是 AGPL 答应证。这是 OSI Certified 的，一致认可的规范开源答应证类型。为了应对在云厂商这里碰到的困难，MongoDB 在根据 AGPL 协议之上，增加了一个补充条款（解释版，非官方文字）：

第13条：如果你用这个软件来直接在公有云上以“xxx as a Service” 的服务方式售卖这个软件自身，那么你需求将一切相关的改动，包含支撑这个软件运用的后台办理渠道软件，都进行开源。

所以，简略来说，SSPL 就等于 AGPL + 第13条修正。了解这条修正的初衷、目的、影响规模，也就了解了 SSPL 的本质。

  • 初衷：和云厂商在商业化利益上的博弈

  • 目的：防止这种运用开源软件直接获利，可是不遵从游戏规矩的第三方

  • 影响规模：直接供给“开源软件 as a Service”的公有云厂商

在 SSPL 正式发布今后，直接作用是很明显的：云厂商们要么是下线，要么就和原厂达到商业化协作，获取特别的授权来继续供给 MongoDB as a Service。

当然，影响也是极其深远的——对开源界造成了巨大的动荡。针关于运用 SSPL 以及后来的 Elastic License V2 这些新的答应证的软件，是否可以被称之为“开源软件”的争议一时刻充斥了技能交际网络。不少极端的观念以为如果承受这样的开源方式，开源将逐渐消亡。亦有观念以为选用这样的”quasi-开源“ 答应证肯定会引发社区极大反弹，要不了2-3年这些公司就会陨落（这些评论会集在2018年）。

OSI Certified

咱们再来看看 OSI， 开源软件规范的守护者。

当咱们说一个软件是否可以被称之为“开源软件”时，严谨的说法应该是这个软件如果运用了某一个 OSI Certified 答应证，那么可以称之为“开源软件”。反之如果运用的答应证不在 OSI Certified 列表里，那么这个软件或许就不应该被称之为“开源软件”。OSI Certified 答应证咱们常见的有这些：

  • MIT

  • BSD

  • Apache

  • MPL

  • GPL

  • LGPL

  • AGPL

  • ……

值得留意的是，这种界说更多是一个社区的自我束缚，并不具有法令含义上的束缚。依照 OSI 自己的说法，“开源”这个词并不是个注册商标，所以理论上谁都可以运用，你无法运用法令手段来禁止某个软件自称“开源软件”，哪怕它并没有取得 OSI 的认可。

可是，咱们都是在一个生态里面。这个生态便是有各种成员组成。在这里，在法令管辖规模之外，更多的是职业的一些约定俗成和规范化安排。OSI 便是一个为鼓舞促进开源软件的蓬勃开展而建立的安排。试想一下，如果没有OSI 经过严厉的流程来审阅答应证，界定软件的安全运用规模，供给权威的解释，那么市场上的答应证或许会是形形色色，形形色色。关于开源社区绝大多数的成员，开源软件的运用者，来说，这将是个巨大的认知和危险本钱。如果你用了一个不知名的答应证，也没有请律师细心审阅，只是由于代码可以用就集成到你的产品里来，等你小有成功的那一天，没准便是你收到对方律师信的一天。

不说其他，就从这一点上看，咱们需求 OSI 这样的安排，以及 OSI Certified 答应证机制。这不是约束，目的是协助社区用户移除隐性的开源软件运用危险，为了维护开源社区更好的开展。

这也是为什么 MongoDB 在宣告了 SSPL 今后，MongoDB 的 CTO Elliot 向 OSI 提交了 SSPL 认证请求，期望 OSI 审阅经过，将 SSPL 列为 Certified 答应证。（可是后来 MongoDB 很快就收回了请求，原因是 OSI 在开端正式审阅流程之前，现已在交际媒体上预判了 SSPL的死刑， MongoDB 以为在这样的情况下是无法保证一个比较公正的审阅进程。）

咱们来看下 OSI 对现行开源答应证的认定原则。OSI 以为，一个答应证是不是开源的特点，要看它是否符合（Open Source Definition，OSD）的10条要求：

1. Free Redistribution-分发自由

2. Source Code- 可以取得源代码

3. Derived Works- 允许衍生著作（以类似的答应证）

4. Integrity of The Author’s Source Code – 原作者源码的完好性

5. No Discrimination Against Persons or Groups – 不轻视个人或集体

6. No Discrimination Against Fields of Endeavor – 不轻视任何范畴

7. Distribution of License – 答应的分发

8. License Must Not Be Specific to a Product – 答应不能针对特定产品

9. License Must Not Restrict Other Software – 答应证不能约束其他软件

10. License Must Be Technology-Neutral – 不能以专门的技能或界面完结授权

针对 SSPL 的批评，会集在第9条规矩：答应证不能束缚其他软件。而 SSPL 的条款，正是在开发者（公有云厂商）试图直接出售 MongoDB as a Service（留意是出售数据库服务自身，而不是衍生服务）的时分会触发对开发者的其他软件（云办理渠道软件）的约束。

所以如果依照现有的约定俗成，SSPL/Elastic 这样的答应证，确实是不满足 OSI 的开源规范。一切 MongoDB 、 Elastic 等确真实尊重这个社区共识，不直接称号自己为开源，而是“源码可用”。作为一个非盈利的 MongoDB 中文社区运营方，咱们最近做了一个小调查，来看看作为社区的首要成员——开发者和用户们是怎样看待这些问题的。

MongoDB 中文社区答应证问卷调查结果

咱们的问卷在半天的时刻，收集了99份有用答卷，以下是部分调研结果：

开源中国专访 TJ：开源许可证，欢迎来到云时代

开源中国专访 TJ：开源许可证，欢迎来到云时代

开源中国专访 TJ：开源许可证，欢迎来到云时代

完好问卷链接：mongoing.com/wp-content/…

这里是一些摘要的数据，可以供给一些跃然纸上的观察：

  • 91%的用户支撑开源软件做商业化，7%不支撑，2%其他

  • 开源软件的代码奉献者仅占8%，其余的可以了解为运用者。也便是说，开源社区绝大多数是开源软件的用户

  • 关于挑选开源软件，只需6%的用户表明软件的答应证形式是一个比较重要的考量

  • 多达73%的用户表明 SSPL/Elastic 针对云厂商的修正是合理并支撑的，10%表明无所谓，17%对立

  • 关于开源软件用户，89% 的用户表明答应证的改动对他们继续运用软件没有影响

  • 关于开源软件的奉献者，7%的用户由于答应证改动而中止了奉献。

咱们该如理性看待云年代开源答应证

在经过对 SSPL 和 OSI Certified 的一些评论以及一些对社区的调查之后，回到咱们的核心问题：

在云年代，咱们该怎样看待这些新的开源答应证？

考虑到 MongoDB、Elastic 以及 Redis 这些软件厂商修正答应证的初衷，他们其实都是在寻找一种对立公有云厂商不公正竞赛的一种解决方案。所以咱们说，这个问题是一个云年代才呈现的问题。 我先罗列一些不具太多争议性的事实和观念：

  • MongoDB / Elastic / Redis 都是取得了巨大成功，十分干流的开源软件厂商

  • 这些软件的继续健康开展，不管OSI 持什么情绪，依然可以服务绝大部分的开源社区用户(89%)

  • 这些厂商的开源答应证的修正都是在面对云厂商的碾压式商业竞赛情况下采纳的应对办法

  • 开源社区需求具有包容性，就如既定的规矩里就有不轻视任何个人和集体一样

  • OSI 的开源10大规矩建立于20多年前，在公有云这个跨年代形态呈现之前

  • OSI 的最大的含义之一是制定规范，协助社区用户界定不同开源答应证的鸿沟规模

  • 追求商业化的开源软件，依然是开源社区合理的一部分

  • 社区的用户是支撑开源软件商业化的（91%）

  • 咱们不喜爱独占、独断、一家独大，咱们喜爱生态百花齐放，鼓舞立异

在上面的这些根底观念之下，我共享一些我的观点：

① MongoDB / Elastic / Redis 代表的是开源技能厂商，他们的特点是以一家技能立异型公司的形式，将代码敞开出来，经过开源社区进行产品的传播，在为社区供给可免费取得的十分优异的软件的同时，吸收社区的奉献和反应，并服务于自己的商业化诉求。比较于没有商业化公司支撑的开源软件，这种 For-profit 的开源有它自己共同的优势：产品路线清晰（开发者可以定心规划），技能迭代快速（有足够多十分优异的工程师全职研制），安全问题或许重大 bug 有保障得到解决。

② 20多年前 OSI 诞生的年代，开源社区大多是以个别奉献者为干流的 Hobbist。而现在绝大部分的开源社区数量上是由开发者（运用者）而非奉献者组成。开发者关于一个名词的科学界说的感知度是相对较低的（6%的开发者关注答应证的内容），反过来优异的性能、功能及成熟度是社区用户之首要关注点。

③ 作为一个面向社区的安排，OSI 需求以开展的视角来看待新生事物。如果真心是为社区用户着想，可以做一些根据社区投票的机制，来吸纳社区的反应，共同修订现已20多岁的规定，包容一些有商业化考量的答应证到开源这个咱们庭里。比如说，可以对开源软件从不同的维度进行分类，对有商业化诉求的答应证单独放到一个类别下，并对一些常见的合规条款进行清晰的阐述和审阅，协助咱们正确选用适宜的开源软件。甚至可以考虑，只需软件代码开源并且可以免费取得，剩余的一些约束性条款，可以从Most Permissive 到 Most Restrictive 这样一个敞开程度，分红 Level 1，2，3 这样。咱们可以各自按需选用相应level的开源软件。这样才是一个真正为社区服务，而非一个“靠机构赞助运营，受十分有意见性的一些少数派影响的”的规范安排。

④ 关于绝大多数用户，以及奉献者，这些云年代新的答应证的呈现，你需求了解背面的初衷和目的。就像咱们对技能进行科学选型的时分，咱们都知道不能只听市场上的声音，终究要看是否合适自己的事务场景。如果这些答应证的改动对你的场景没有影响（一个简略的判别：你是否为公有云厂商，如果不是，大概率这些对你来说是没有改变的），你彻底可以坦然承受这些新的“源码可用”答应证。

咱们在 Tapdata 的实践

在离开 MongoDB 之后，我创立了 Tapdata.inc，并对咱们公司报以很大的期望，期望咱们成为一家极具任务感的公司——让企业可以更加简略、低本钱运用实时的数据，来发挥更大的事务价值，Make Data on Tap。

历经3年打磨，数十家客户的线上验证，Tapdata 俨然成为了一个以全链路实时为核心技能才能栈的实时数据渠道，同时也是首个支撑50多个数据源的实时异构数据集成渠道。

为了达到任务，咱们发现降低获取 Tapdata 的本钱和鼓舞社区传播是这个年代最有用的一个手段。所以咱们于近期正式在 Github 上敞开了源代码，建立了 Tapdata 开源项目（github.com/tapdata/tap…）。

Tapdata 开源项目选用的是一个混合答应证形式。咱们的战略是针对社区奉献者使用咱们 Plugin Development Kit 来开发各种数据源和数据核算插件代码，选用 Apache V2 的答应证，而 Tapdata 开源团队研制的核心引擎结构，包含数据类型规范化、流核算引擎、自研的算子以及 UDF 才能等会选用 SSPL 答应证形式。

咱们期望依托于 Tapdata 开源项目在实时数据范畴的先发和抢先优势、强大的产品才能，以及有用的商业化手段，为社区开发者和咱们的客户继续不断地供给一个最优异的数据产品。

终究我引证 Thomas Kurian, Google Cloud CEO 对开源软件的情绪，来佐证在云年代，咱们需求的是一个共同开展的生态，而不是由于云厂商的非对称竞赛优势导致那些 For-profit 开源软件无法生计的结局。

The most important thing is that we believe that the platforms that win in the end are those that enable rather than destroy ecosystems…

… In order to sustain the company behind the open-source technology, they need a monetization vehicle. If the cloud provider attacks them and takes that away, then they are not viable and it deteriorates the open-source community.

咱们坚信终究可以成功的是那些供给生态而不是扼杀生态的渠道（云厂商）

…… 为了可以让这些开源软件公司可以可继续地生计和开展，他们需求一个有用的商业化手段。如果云厂商使用开源协议攻击这些开源公司，让这些公司无以为继，那这终究会让开源社区变得更加糟糕。

开源答应证，欢迎进入云年代！

参阅链接：

[1] opensource.org/osd

[2] techcrunch.com/2019/04/09/…

**来源：**OSCHINA 开源观止 & Tapdata

**作者：**唐建法（TJ），Tapdata 创始人& CEO，MongoDB 中文社区主席，前 MongoDB 大中华区首席架构师。

加入开源社区

增加 Tapdata 小姐姐（ID：Tapdata2022）获取 Tapdata 开源社区第一资讯！

GitHub 项目链接： www.github.com/tapdata/tap…

原文地址：开源我国专访 TJ：开源答应证，欢迎来到云年代 – Tapdata