在云时代，我们该如何看待新的开源许可证？

1、前言

开源许可证从最早的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为代表的新一代开源软件厂商MongoDB和OSI的角度分别来看一下这个问题两个对立面的一些底层逻辑

2、MongoDB与SSPL

2018年11月，MongoDB宣布将其开源授权修改为SSPL（Server Side Public License，服务器端公共许可证）

为什么MongoDB要修改开源许可证呢？

2007年，MongoDB公司的前身10gen正式成立。2009年2月开源数据库MongoDB 1.0正式问世，以开源的方式进入市场接受考验。MongoDB产品主要分为企业版和社区开源版，2014年下半年，MongoDB开始进军全球，正式在中国落地商业化。2016年之前，MongoDB云产品Atlas还在研发中，MongoDB的主要商业化手段是企业版

2016年，MongoDB正式发布了Atlas产品，一个在公有云（AWS、Azure和GCP）上的托管数据库服务。发布不久，Atlas云产品就很快得到了开发者的青睐。虽然成本不是太低，但毕竟是开箱即用。省了约0.50个DBA 的费用。MongoDB Atlas上线后呈现了较快的增速，在2017年上市的时候，已经成为MongoDB增长最快的业务了

反观国内，某公有云其实也在2016年比MongoDB原厂Atlas更早的时间，推出了云上的MongoDB as a Service，还是用的MongoDB基于AGPL的社区开源版。 当时的中国市场，企业版的销售其实是举步维艰，企业版的售卖逻辑是提供了额外的价值，主要包括原厂技术支持和一套独立的额外集群管理工具（监控、备份等），MongoDB数据库能力都是一样的和开源版相比。但是在软件获取成本上，一个是0元/年，一个是数十万元/年。在10万元就能请一个工程师的中国企业市场，可想而知企业的付费意愿度有多高

除了国内，俄罗斯的一些头部云厂商也开始在他们的云上推出了MongoDB as a Service，也都基于免费的MongoDB社区开源版。在此过程中，云厂商为了能够更好地将一个产品融入到他们统一的云平台，提供一些额外的能力支撑，例如动手解决一些产品的Bug来满足SLA（Service-Level Agreement，服务等级协议，是服务提供商与客户之间定义的正式承诺），这势必会对源码做许多修改。在这个时候，MongoDB发现，某些云厂商并没有完全按照AGPL协议规范，将所有这些改动如数开源

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

经过多次协商，动用到各自的Legal Team以后，MongoDB发现面临的问题是——商业化合作，双方期望值相差太大，一个想吃肉，一个只愿意给肉汤。开源合规方面，云厂商指着那个基本不怎么更新的Repo说我们已经按照协议开源了。只有到诉讼公堂，才可以去内部取证。怎么办？类似的案子，没有先例，再在一个完全陌生的国家去走这条路，听上去就非常坎坷。可是云服务又几乎是所有新一代开源软件公司最主要的收入增长引擎，实在又无法听之任之

于是MongoDB选择了釜底抽薪，修改许可证

3、AGPL与SSPL许可证

在改协议之前，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-开源“许可证肯定会引发社区极大反弹，要不了几年这些公司就会陨落

4、OSI Certified许可证

OSI（Open System Interconnect）是一个国际标准化组织，是一个旨在推动开源软件发展并维护开源标准的非盈利组织

那么，一个软件怎么才能说它是开源呢？开源到底如何定义？

当我们说一个软件是否可以被称之为“开源软件”时，严谨的说法应该是这个软件如果使用了某一个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 - 不能以专门的技术或界面完成授权

OSD参考：https://opensource.org/osd

针对SSPL的批评，集中在第9条规则：许可证不能约束其他软件。而SSPL的条款，正是在开发者（公有云厂商）试图直接销售MongoDB as a Service（注意是销售数据库服务本身，而不是衍生服务）的时候会触发对开发者的其他软件（云管理平台软件）的限制

所以如果按照现有的约定俗成，SSPL/Elastic这样的许可证，确实是不满足OSI的开源标准。所有MongoDB、Elastic等确实在尊重这个社区共识，不直接称呼自己为开源，而是“源码可用”

最后我引用Thomas Kurian（Google Cloud CEO）对开源软件的态度，来佐证在云时代，我们需要的是一个共同发展的生态，而不是因为云厂商的非对称竞争优势导致那些For-Profit开源软件无法生存的结局：

我们坚信最终能够胜利的是那些提供生态而不是扼杀生态的平台（云厂商）…为了能够让这些开源软件公司能够可持续地生存和发展，他们需要一个有效的商业化手段。如果云厂商利用开源协议攻击这些开源公司，让这些公司无以为继，那这最终会让开源社区变得更加糟糕

5、背景总述

计算机技术进入云时代后，一些云服务提供商将开源产品打包成云服务来获利，挣的盆满钵满，但不反哺开源社区，导致开源社区无法生存，生存状况日益严峻

开源社区遭受了云厂商的残酷竞争，从商标被滥用，到公然重新包装开源软件产品，甚至从专有代码中获取灵感，以上种种行为都是在挑战开源社区的生存底线

开源社区不得不通过修改开源许可证，以保护他们在自由软件上的投资，同时努力维护开放、透明和协作的原则

参考文章：https://www.infoq.cn/article/wXlSfiyvUUyxCcT4UZTQ