写点什么

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

  • 2022-08-15
    北京
  • 本文字数:6826 字

    阅读完需:约 22 分钟

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

前言


开源许可证从最早的 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 相关的开源 Node JS 组件,所以在 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 年)。


延伸阅读:https://oscimg.oschina.net/public_shard/opensource-guanzhi-20220810.pdf

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 - 不能以专门的技术或界面完成授权

 

原文参照: https://opensource.org/osd

 

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

 

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

 

作为一个非盈利的 MongoDB 中文社区运营方,我们最近做了一个小调查,来看看作为社区的主要成员——开发者和用户们是怎么看待这些问题的。 

 

MongoDB 中文社区许可证问卷调查结果:


我们的问卷在半天的时间,收集了 99 份有效答卷,以下是部分调研结果:

 




 完整问卷地址:https://mongoing.com/wp-content/uploads/2022/08/52c020886a57cf6.pdf

 

这里是一些摘要的数据,可以提供一些跃然纸上的观察:

 

  • 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%)

  • 我们不喜欢垄断、独断、一家独大,我们喜欢生态百花齐放,鼓励创新

 

在上面的这些基础观点之下,我分享一些我的看法:

 

1) MongoDB / Elastic / Redis 代表的是开源技术厂商,他们的特点是以一家技术创新型公司的形式,将代码开放出来,通过开源社区进行产品的传播,在为社区提供可免费获得的非常优秀的软件的同时,吸收社区的贡献和反馈,并服务于自己的商业化诉求。相比于没有商业化公司支撑的开源软件,这种 For-profit 的开源有它自己独特的优势:产品路线明确(开发者可以放心规划),技术迭代快速(有足够多非常优秀的工程师全职研发),安全问题或者重大 bug 有保障得到解决。

 

2)20 多年前 OSI 诞生的时代,开源社区大多是以个体贡献者为主流的 Hobbist。而现在绝大部分的开源社区数量上是由开发者(使用者)而非贡献者组成。开发者对于一个名词的科学定义的感知度是相对较低的(6%的开发者关注许可证的内容),反过来优秀的性能、功能及成熟度是社区用户之首要关注点。

 

3)作为一个面向社区的组织,OSI 需要以发展的视角来看待新生事物。如果真心是为社区用户着想,可以做一些基于社区投票的机制,来吸纳社区的反馈,共同修订已经 20 多岁的规定,容纳一些有商业化考量的许可证到开源这个大家庭里。比如说,可以对开源软件从不同的维度进行分类,对有商业化诉求的许可证单独放到一个类别下,并对一些常见的合规条款进行明确的阐述和审核,帮助大家正确采用合适的开源软件。甚至可以考虑,只要软件代码开源并且可以免费获得,剩下的一些限制性条款,可以从 Most Permissive 到 Most Restrictive 这样一个开放程度,分成 Level 1,2,3 这样。大家可以各自按需采用相应 level 的开源软件。这样才是一个真正为社区服务,而非一个“靠机构赞助运营,受非常有意见性的一些少数派影响的”的标准组织。

 

4)对于绝大多数用户,以及贡献者,这些云时代新的许可证的出现,你需要理解背后的初衷和意图。就像我们对技术进行科学选型的时候,我们都知道不能只听市场上的声音,最终要看是否适合自己的业务场景。如果这些许可证的改变对你的场景没有影响(一个简单的判断:你是否为公有云厂商,如果不是,大概率这些对你来说是没有变化的),你完全可以坦然接受这些新的“源码可用”许可证。

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 开源软件无法生存的结局。

 

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


原文链接:


https://techcrunch.com/2019/04/09/google-clouds-new-ceo-on-gaining-customers-startups-supporting-open-source-and-more/

 

作者简介:


唐建法(TJ),Tapdata 创始人 CEO,MongoDB 中文社区主席,前 MongoDB 大中华区首席架构师。

 

2022-08-15 17:417918
用户头像
李冬梅 加V:busulishang4668

发布了 1093 篇内容, 共 707.9 次阅读, 收获喜欢 1243 次。

关注

评论

发布
暂无评论
发现更多内容

当当网按关键字搜索dangdang商品 API (item_search-按关键字搜索dangdang商品-dangdang.item_search)在电商中的应用

技术冰糖葫芦

API

万字图解 | 深入揭秘IP层工作原理

云舒编程

IP MTU 路由表 子网划分 图解网络

《Hive编程指南》读书笔记

京东科技开发者

NineData和Klustron完成产品兼容互认证

NineData

数据库 数据管理 NineData Klustron 泽拓昆仑

大规模集群下,如何快速实现无死角网络连通性的主动巡检

ii2day

云原生 压力测试 Cloud Native kubernetes 运维 自动巡检

开发人员是怎么失去成就感的

云舒编程

程序员 发展 职业生涯 开发. #最有成就感的事

想在 Mac 里装 Windows ?试试 Parallels Desktop虚拟机!

Rose

Windows系统 Mac双系统安装 Parallels Desktop

马斯克接手Twitter一年后的成果-工作量化的重要性

云舒编程

twitter 马斯克 推特

TCP close_wait 引发的血案

云舒编程

TCP 压测 Wait 连接池

得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践

JackJiang

网络编程 即时通讯 IM

NLP国内外大模型汇总列表[文心一言、智谱、百川、星火、通义千问、盘古等等]

汀丶人工智能

nlp 大模型

非常火爆“太空种田”游戏Slipways mac破解版

Rose

mac游戏 苹果电脑游戏推荐

Mac游戏星露谷物语 - 创造梦想中的田园生活

Rose

苹果电脑 模拟经营游戏 星露谷物语游戏下载 macos游戏推荐

万万字图解| 深入揭秘Golang锁结构:Mutex(上)

云舒编程

golang 设计 mutex 字节

苹果macos效率神器alfred5新功能介绍 及alfred 5汉化包下载

Rose

mac软件下载 Alfred 5破解版 Alfred 中文 Mac效率办公软件

WorkPlus构建便捷高效的企业移动门户平台

BeeWorks

bean的一生

京东科技开发者

QSpace Pro 一款简洁高效的多窗格文件管理器,灵活且实用!

Rose

Mac软件 QSpace 多窗格文件管理器

foobar2000 for mac多功能音频播放器 v2.6.1免激活版

Rose

mac音乐播放器 foobar2000中文版 foobar2000破解版

苹果电脑游戏:以撒的结合:重生+忏悔+胞衣 Mac中文版下载

Rose

mac游戏 以撒的结合:忏悔

Axure RP 8使用技巧分享 含axure rp8汉化授权码

Rose

axure rp9下载 Axure RP 8汉化包 Axure破解版 Axure使用教程

【技术探讨】如何选择一款距离远的无线通信模块?

Geek_ab1536

SnapGene 5最新补丁版 生物分子学软件snapgene5 for Mac安装教程

Rose

Mac软件 SnapGene 5破解版 SnapGene 5下载 DNA序列分析

探讨 LLM 的潜在风险 (偏见与毒性等),是否存在解决之道?

Baihai IDP

人工智能 程序员 AI LLM 白海科技

WorkPlus Meet私有化视频会议内网部署

BeeWorks

010 Editor v14.0激活版 Mac十六进制编辑器 含010 editor注册码

Rose

010 Editor破解版 010 Editor注册码 Mac文件编辑器 苹果电脑软件下载

万万字图解| 深入揭秘Golang锁结构:Mutex(下)

云舒编程

golang 面试 mutex 字节

“纯血”鸿蒙到来,对开发者是机会吗?

云舒编程

华为 鸿蒙 开发者 HarmonyOS 生态

万字图解| 深入揭秘IO多路复用

云舒编程

异步 epoll select poll I/O 多路复用

在云时代,我们该如何看待新的开源许可证?_文化 & 方法_唐建法_InfoQ精选文章