前言

开源许可证从最早的 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 的角度别离来看一下这个问题两个对立面的一些底层逻辑。最初咱们再来分享下对于云时代开源许可证的一些观点。

我所晓得的 SSPLMongoDB

是一个十分受程序员喜爱的 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份无效答卷，以下是局部调研后果：

残缺问卷链接：https://mongoing.com/wp-

这里是一些摘要的数据，能够提供一些跃然纸上的察看：

  • 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 开源我的项目（https://github.com/tapdata/tapdata）。

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] https://opensource.org/osd
[2] https://techcrunch.com/2019/04/09/google-clouds-new-ceo-on-gaining-customers-startups-supporting-open-source-and-more/

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

退出开源社区

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

GitHub 我的项目链接：
https://www.github.com/tapdata/tapdata

原文地址：https://tapdata.net/thoughts-on-open-source-licensing.html