为知笔记 编辑wordpress,陕西seo主管,广西网红排名,北京网站建设平台目录 1、前言2、MongoDB与SSPL3、AGPL与SSPL许可证4、OSI Certified许可证5、背景总述 声明#xff1a; 本文主要参考文章#xff1a;https://www.infoq.cn/article/wXlSfiyvUUyxCcT4UZTQ 尊重原创#xff0c;如有侵权#xff0c;请联系删除 1、前言 开源许可证从最早的GPL… 目录 1、前言2、MongoDB与SSPL3、AGPL与SSPL许可证4、OSI Certified许可证5、背景总述 声明 本文主要参考文章https://www.infoq.cn/article/wXlSfiyvUUyxCcT4UZTQ 尊重原创如有侵权请联系删除 1、前言 开源许可证从最早的GPL开始 逐渐演进到GPLv2和v3中间还有Apache、MPL、AGPL、LGPL等但是近几年来有一批新的许可证的出现引起了社区的一些激烈的讨论。这些新的许可证包括BSL、SSPL、Elastic以及一个比较特殊的附加条款Commons Clause
社区内从争论的角度主要分为两大阵营原教旨主义和实用主义
原教旨主义的同学们认为只有遵从1998年成立的Open Source InitiativeOSI定义的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宣布将其开源授权修改为SSPLServer 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来满足SLAService-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许可证 OSIOpen 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 DefinitionOSD的10条要求 Free Redistribution - 分发自由 Source Code - 可以获得源代码 Derived Works - 允许衍生作品以类似的许可证 Integrity of The Author’s Source Code - 原作者源码的完整性 No Discrimination Against Persons or Groups - 不歧视个人或团体 No Discrimination Against Fields of Endeavor - 不歧视任何领域 Distribution of License - 许可的分发 License Must Not Be Specific to a Product - 许可不能针对特定产品 License Must Not Restrict Other Software - 许可证不能限制其他软件 License Must Be Technology-Neutral - 不能以专门的技术或界面完成授权
OSD参考https://opensource.org/osd
针对SSPL的批评集中在第9条规则许可证不能约束其他软件。而SSPL的条款正是在开发者公有云厂商试图直接销售MongoDB as a Service注意是销售数据库服务本身而不是衍生服务的时候会触发对开发者的其他软件云管理平台软件的限制
所以如果按照现有的约定俗成SSPL/Elastic这样的许可证确实是不满足OSI的开源标准。所有MongoDB、Elastic等确实在尊重这个社区共识不直接称呼自己为开源而是“源码可用”
最后我引用Thomas KurianGoogle Cloud CEO对开源软件的态度来佐证在云时代我们需要的是一个共同发展的生态而不是因为云厂商的非对称竞争优势导致那些For-Profit开源软件无法生存的结局
我们坚信最终能够胜利的是那些提供生态而不是扼杀生态的平台云厂商…为了能够让这些开源软件公司能够可持续地生存和发展他们需要一个有效的商业化手段。如果云厂商利用开源协议攻击这些开源公司让这些公司无以为继那这最终会让开源社区变得更加糟糕
5、背景总述 计算机技术进入云时代后一些云服务提供商将开源产品打包成云服务来获利挣的盆满钵满但不反哺开源社区导致开源社区无法生存生存状况日益严峻
开源社区遭受了云厂商的残酷竞争从商标被滥用到公然重新包装开源软件产品甚至从专有代码中获取灵感以上种种行为都是在挑战开源社区的生存底线
开源社区不得不通过修改开源许可证以保护他们在自由软件上的投资同时努力维护开放、透明和协作的原则
