MongoDB更换开源许可协议背后的法律风险

[[262419]]

一、SSPL许可协议解读

(一)事件背景

随着开源软件在云计算、大数据、人工智能等ICT新兴领域发挥越来越重要的作用，企业也逐渐成为开源的主要推动力量。开源不仅仅是一种可以汇集产业力量进行协同开发的生产模式，而且也是企业竞争的重要手段。一些维护开源项目的企业通过修改开源项目的许可协议以实现降低产品风险、打击竞争对手的目的。2018年10月，MongoDB宣布其开源许可协议从AGPL  v3切换到 Server Side Public License (SSPL)。2018年10月16日之前发布的MongoDB社区服务器版本采用AGPL  v3许可协议，2018年10月16日当天或者是以后发布的所有的MongoDB社区服务器补丁和新版本都采用SSPL许可协议，包括旧版本的未来的补丁。

(二)SSPL许可协议解读

1、SSPL许可协议基本介绍

SSPL许可协议是在GPL v3基础上修改得到的。SSPL许可协议共有17个条款，除第13条款与GPL v3规定不同外，其余条款与GPL  v3大致相同。SSPL许可协议有以下特点：

***，SSPL与GPL等开源许可协议一样，赋予被许可人四项基本的权利，包括：自由运行程序、自由获得源代码、自由发布复制程序、自由修改程序并将自己作出的改进版本向公众发行传播。

第二，SSPL是强传染性许可协议。这意味着：用户如果对SSPL许可的软件或基于SSPL许可的软件的作品再发布时，必须以SSPL许可协议进行再发布。

第三，将SSPL许可下的程序再发布或将程序作为服务提供时，必须提供源代码。无论SSPL约束的软件以目标代码或是可执行程序复制、发布时，都必须提供源代码。

第四，SSPL明示了专利授权。与GPL  v3完全相同，SSPL许可协议的第11条款明示了专利授权。程序发布者即使就发布的贡献申请了专利，在获得专利授权后也必须将相关专利授权都免费许可给使用该程序的每一个人。

第五，SSPL存在不担保条款。几乎所有的开源许可协议都存在不担保条款，不提供任何明示或暗示的担保，包括但不限于适销性和用于特定目的的适用性担保。对于使用开源程序发生的任何损失，版权所有人或其他第三方均不承担任何责任。因为开源软件已经是免费许可，因此就不对软件版权所有人要求担保义务。

2、SSPL、GPL v3、AGPL v3对比分析

GPL v3、AGPL v3、SSPL这三个许可协议的差异主要体现在第13条款。GPL v3第13条款是“和AGPL一起使用”的相关条款的规定。AGPL  v3第13条款是“远程网络交互：和GPL许可协议一起使用”的相关条款规定。SSPL第13条款是关于“将程序作为服务提供”的规定。通过对比这三个许可协议的第13条款的规定，可以发现：

***，AGPL、SSPL许可协议的规定比GPL更为严苛。按照GPL许可协议的规定，任何人都可以以提供技术服务为目的，运行私有修改的GPL许可下的程序，只要不发布软件，不需要公开源代码。但是，AGPL许可协议将Copyleft这一概念延伸至网络上自由软件所交付的服务。在AGPL的规定中，如果其许可的程序与用户通过网络进行远程交互，那么就需要提供源代码给用户，所有的修改也需要提供给用户。常见的“通过计算机远程网络交互”的场景有：网络和邮件服务器、基于互动的网络应用程序和在线播放的游戏服务器等。在SSPL许可协议中，明确规定将程序或程序的修改版本的功能作为服务向第三方提供时，需要提供“服务源代码”。最为典型的场景即云平台提供商将软件托管产品打包成服务。

第二，GPL、AGPL、SSPL都是强著佐权型许可协议。GPL、AGPL许可协议第13条款分别规定了GPL许可下的程序和AGPL许可下的程序在一起使用的情况，因此，GPL、AGPL许可协议是兼容的。但是，SSPL许可协议与GPL、AGPL都不兼容，也即：SSPL许可的代码不能和GPL或AGPL许可的代码组成一个程序发布。

二、MangoDB更改许可协议原因分析

(一)法律层面分析

AGPL v3许可协议的规定不明确导致很多企业一直在考验AGPL的边界。AGPL  v3第13条款规定了“远程网络交互”的限制条件。但是，业界对于AGPL远程网络交互的触发条件以及范围存有争议。因此，SSPL明确规定了将程序作为服务提供的条件限制。

AGPL v3传染性范围判断也较为模糊。GPL v3/AGPL  v3提出了“聚合体”的概念，认为将GPL许可下的程序纳入到聚合体中不会导致对聚合体的其他部分适用GPL v3/AGPL  v3许可协议，即不会产生“传染性”。然而，关于两个程序是否组成了“聚合体”，产业界仍然有很大争议，司法界也没有相关判例。这直接导致很多企业一直游走在违反AGPL许可协议的灰色地带。

(二)商业层面分析

“软件即服务”的兴起冲击了MangoDB的商业模式。开源不仅是一种软件开发模式，也代表了一种独特的商业模式。MangoDB开源软件采用了双许可的商业模式。MangoDB分为企业版、开源社区版两个版本。开源社区版本以SSPL许可协议免费许可给用户，这样便于测试软件、获得改进信息、得到开发者的支持、赢得口碑，有助于市场推广。企业版本采用商业许可，为企业使用者提供更为丰富的功能以及提供技术支持、担保等服务。MangoDB通过向商业用户收取授权费用而盈利。采用双许可模式的开源企业，通常会为其社区版本选择如GPL、AGPL这样的强著佐权型的许可协议，一定程度上限制了其他企业在社区版本的基础上修改并销售软件。

近几年，“软件即服务”的观念深入人心，IT产业逐渐向服务化转型。用户不需要购买软硬件，而是通过互联网向厂商订购所属的应用软件服务。IT厂商越来越倾向于通过服务收费，而不是通过售卖软硬件收费。一些云服务厂商将MangoDB的社区版本修改后向用户提供其数据库的托管商业版本，而不将修改的源代码公开回馈给社区。如此一来，这些云服务厂商相当于从MangoDB企业版销售中分了一杯羹，抢占了其销售份额。MangoDB更换许可协议就是要遏制云服务提供商攫取开源软件价值却不给予开源社区任何回报的行为。

三、MangoDB更改许可协议影响分析

(一)许可协议更改对开源社区的影响

许可协议更改不影响MangoDB社区服务器的常规用户。在开源社区中，SSPL赋予用户的自由与AGPL许可下的MongoDB赋予用户的自由是相同的——用户仍然可以自由地使用、审查、修改、再发布源代码。如果某公司仅仅将MangoDB在公司内部使用，或将其作为服务提供给子公司使用，不属于提供服务给第三方的情况，不需要受13条款的约束，也不受更换许可协议的影响。此外，许可协议更改后，要求云服务厂商将其对MangoDB的修改反馈给开源社区，这将有助于开源软件不断完善，对开源社区的发展有长远意义。

(二)许可协议更改对云服务商的影响

MangoDB更换许可协议之后，云服务厂商如果想销售基于MangoDB的云服务，要么需要完全公开其服务源代码，要么需要向MangoDB购买商业许可。MangoDB许可协议中，对“服务源代码”的范围界定非常宽泛，不仅包括MangoDB或其修改版本对应的源代码，还包括管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件的源代码。将这些“服务源代码”完全公开，意味着这些云服务厂商丧失了产品差异化的能力。因此，其他云服务厂商可能也就没有积极性销售基于MangoDB的云服务。

四、MangoDB更改许可协议对我国企业开源的启示

(一)理解开源的游戏规则

随着商业公司逐渐成为开源的主要力量，开源变得越来越不那么“纯粹”，逐渐成为企业盈利的一种方式。开源软件开发模式的选择、开源许可协议的选择、开源软件的盈利模式的选择，都是一脉相承、紧密相关的。例如，开源基金会主导的开源软件，往往会选择Apache、BSD、MIT这样的宽松的开源许可协议，以吸引更多的商业公司参与。商业企业主导的开源软件，往往会选择GPL这类强著佐权型许可协议，以保证其双许可商业模式的实现。企业只有理解了开源的游戏规则，才能在开源中获利，有效降低知识产权侵权风险。

(二)谨慎选择开源软件

开源不是“免费的午餐”，企业主导的开源项目往往充满了层层陷阱。如果一个开源软件是一家企业主导，这家企业又拥有全部开源代码的著作权的话，那么这家企业就可以随时变更该开源软件的开源许可协议，甚至将其变为闭源。例如，Redis将自建的Redis模块——RediSearch，Redis  Graph，ReJSON，ReBloom和Redis-ML的许可协议由AGPL v3变更为Apache v2与Commons  Clause相结合的许可协议，实际上是这些自建模块已经不是开源软件，而仅仅是可以获得源代码。这种许可协议的突然变更，会使得使用这些开源软件的企业陷入两难境地。在自己的产品中更换开源软件，则替换成本很高;如不更换开源软件，新的许可协议往往需要将私有代码公开甚至不允许商业销售。因此，企业一开始就谨慎选择开源软件，不仅仅要对其性能进行检测，也需要对充分考虑其知识产权风险。

(三)使用开源软件应遵从开源许可协议

开源软件不是公共领域的软件，不可以任意使用。绝大部分开源软件都是有著作权，且受著作权法保护的。开源软件的著作权人通过开源许可协议将开源软件的复制权、修改权、发行权等部分权利让渡给了被许可人，被许可人在遵从开源许可协议规定的前提下，才可以行使这些权利。如果企业没有按照开源许可协议的规定使用开源软件，就存在很大的著作权侵权风险。

(四)做好开源软件的风险防控

开源许可协议往往都有“不担保”条款，这意味着企业使用开源软件需要风险自负。在这种情况下，企业对开源软件的风险防控显得尤为重要。一方面，要完善企业开源软件管理流程，规范企业内部对开源软件的使用，降低因不合规使用开源软件带来的法律风险;另一方面，要关注所使用的开源软件的相关法律纠纷，建立风险预警机制，及时在产品中更换有风险的开源代码。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删