开源协议专题的前三篇文章，我们已经对开源许可证的分类及GPL开源许可证的传染性特征进行了分析，本篇文章我们将聚焦于一个具体的问题，变更开源协议是否具有合法性基础，是否可能被认定为违约或侵权，如果构成违约或侵权需要承担何种责任。关于开源许可证变更，目前还没有检索到成熟的司法判例，因此本篇文章的观点仅代表作者的个人观点，欢迎交流和讨论。

目前经过OSI认证的开源许可证有100多种，每种许可证的约定及侧重点均有所不同，通常可以分为Permissive和Copyleft两种，其中Permissive Licenses指宽松型开源许可证，包括常见的MIT、Apache 2.0、BSD（2-clause）、BSD（3-clause）等，这些许可证在使用、更改和分发代码方面提供了更大的灵活性。而Copyleft Licenses是我们常说的病毒性许可证，包括GPL、Affero GPL、Lesser GPL、MPL等，这些许可证通常要求以相同许可证分发衍生作品，而且具有传染性。当然还存在很多非经OSI认证的开源许可证，这些许可证在是否允许二次开发闭源、专利及商标许可、是否具有传染性、是否允许用于商业化用途等均有不同的约定，其种类更加繁杂。

开源软件的原始发布者会根据自己的需求选择许可证类型，甚至可能采用双许可证的方式进行开源。但是随着项目研发过程的推进，许可证的兼容性、社区用户的接受程度、法律规定均会出现变化，甚至发布者的需求也在发生变化，因此已经出现多起变更开源许可证的商业案例。但是开源许可证的变更，对于发布者、用户、代理商均会产生深远的影响，比如对于发布者而言变更的行为是否具有合法性基础，是否有承担违约或侵权责任的风险；对于用户（比如依赖于开源软件的研发企业）而言需要重新评估商业前景，开源许可证的变更可能导致其研发成本增加，或甚至无法继续原先的研发路径；对于代理商而言其是否可以继续保持产品的差异化，继续原先的销售模式可能会产生著作权或专利侵权责任。

由于开源的发展历程时间较短，目前还没有检索到与开源许可证变更有关的生效司法判例。为了便于理解，我们先列举几个关于开源许可证变更的商业案例，之后再针对不同案例的情形进行分析。

2024年3月20日，Redis公司宣布Redis将从BSD 3-Clause许可证过渡到双重许可证模式，包括Redis源代码可用许可证（RSALv2）和服务器端公共许可证（SSPLv1），这一变化将从Redis 7.4版本开始，贯穿到未来所有的Redis发布版本。Redis的大部分商业销售是通过大型云服务提供商进行的，这些提供商将Redis的投资及其开源社区商品化，而没有为Redis的开发做出相应的贡献，通过新的许可证，托管Redis产品的云服务提供商将不再被允许免费使用Redis的源代码。变更过后其中双许可证之一的RSALv2允许用户查看、修改和分发Redis源代码，但不能将软件商业化或作为管理服务提供给他人，另一许可证SSPLv1规定云服务商不仅必须提供应用程序本身的源代码，还必须提供围绕源代码构建的整个服务对应的代码。但这一许可证并未被开源代码促进会（OSI）认定为开源协议，多个发行商如Fedora, openSUSE等在这一变更之后从其代码库中删除了Redis。^[1]

2017年3月24日，OpenSSL项目宣布将许可证从原来的OpenSSL License和SSLeay License更改为Apache License 2.0。这一变更旨在解决原有许可证与GPL许可证不兼容的问题，使OpenSSL能够更方便地整合到使用GPL许可证的软件中。但由于该项目代码被修改了三万多次，共计有400多位贡献者，OpenSSL团队需要获取全部贡献者的授权许可后才可以对许可证进行变更，为此OpenSSL团队花费了数年时间，并专门建立了一个网站与贡献者获得联系。由于OpenSSL团队在变更过程中保持了足够的透明度及开源社区参与度，虽然有一部分用户认为OpenSSL无权变更开源许可证，但整体来说还是获得了社区较为积极的反响，并最终完成了变更工作。^[2]

2013年，Facebook公司通过BSD许可证开源React.js。2016年7月，Facebook在原有的React.js开源许可协议中附加了“专利反击”条款，内容为如果React的用户针对Facebook或其子公司、关联公司提出的任何软件、技术、产品或服务提出专利侵权指控，或者从专利侵权指控中获得直接的经济利益，则React的开源许可将自动终止。修改后的许可证被称为“Facebook BSD+Patents”，由于这份开源协议限制了其他用户可能的合法诉权，因此受到了众多企业的抵制。

2017年9月，Facebook 宣布将部分开源项目(包括React.js) 协议更改为 MIT license。但是，Facebook仍有一些项目( 如React Native等）使用前述“Facebook BSD+Patent”的许可协议。^[3]

MongoDB分为商业版和社区版，其商业版采用商业许可协议，社区版之前采用AGPL v3 许可协议。2018年10月，MongoDB 宣布其开源许可协议从AGPL v3变更为 Server Side Public License(SSPL)。

AGPL V3是GPL的衍生版本，区别在于AGPL如果其许可的程序与用户通过网络进行远程交互，也需要提供源代码给用户，所有的修改也需要提供给用户。但是AGPL V3对于网络远程交互的约定并不明确，而SSPL明确规定将程序或程序的修改版本的功能作为服务向第三方提供时，需要提供“服务源代码”。MongoDB 采用AGPL许可协议时， 一些云服务厂商将 MongoDB 的社区版本修改后向用户提供其数据库的托管商业版本，而不将修改的源代码公开回馈给社区。变更许可协议之后，云服务厂商如果想销售基于MongoDB 的云服务，要么需要完全公开其服务源代码，要么需要向MongoDB购买商业许可。^[4]

TechStart是一家软件初创公司，其开发了数据可视化库DataViz，并通过MIT许可证开源，由于MIT是非常宽松的permissive许可证，DataViz在社区中非常受欢迎，被众多项目采纳并使用，包括在一些商业应用程序中。TechStart也从社区贡献中获益，扩展了DataViz的功能。但是随着DataViz的应用越来越广泛，MIT许可证的弊端也开始显露，由于MIT许可证并未对使用者进行具体的限制，一些大型科技公司将DataViz纳入其产品，但是并未将其修改贡献反馈给发布者，甚至有部分用户企业通过DataViz提供商业支持服务，与发布者TechStart进行直接竞争，瓜分其市场份额。TechStart为了解决前述问题，考虑将MIT许可证变更为GPL许可证，这样可以强制要求其用户共享修改内容，但是变更许可证需要获取之前贡献者的授权，而且可能导致其原有用户群体产生分裂，这些问题难以在短时间内得到解决。^[5]

前述案例中，开源软件发布者基于多个原因对许可证进行变更，比如为了限制竞争对手瓜分其市场份额，限制云代理服务商通过开源软件盈利却拒绝回馈社区，通过变更许可证增加开源软件的接受程度及使用范围，提升开源软件与GPL兼容性等等。但是这些变更行为并非均具有合法基础，开源协议本质上是一种知识产权许可合同，判断其变更行为合法性的关键在于许可证本身的约定，对于特定种类的许可证还需要结合履约事实判断。

以GPL v3为例，该许可证在第2条基本许可中约定“根据本协议授予的所有权利的期限为程序的版权期限，此等授权在满足条件的情况下是不可撤销的”。在第5条约定“你必须根据本协议将作品整体完整地许可给任何拥有其副本的人。本协议及其适用的任何根据本协议第7条附加的条款适用于整个作品和作品的所有部分，无论其如何封包。本协议不允许以任何其他方式许可该作品，但如果你单独接受了其他方式的许可，本协议并不当然导致该等许可无效”。

GPL许可证的逻辑是通过强制开源，确保修改成果可以反馈给开源社区，因此GPL最重要的特质在于其稳定性，这也是众多社区用户相信并选择GPL的原因，如果可以随意变更GPL许可证，前述约定将毫无意义。而且从GPL协议本身的约定来看，其授权期限与版权期限一致，而且是不可撤销的，即使许可方发布了变更通知，我认为社区用户仍然可以主张以GPL合法获取其源代码而不受影响。如果许可方打算以其他许可证开源更新、升级后的程序代码，由于原始版本以GPL协议开源，更新、升级后的代码应当视为其修改作品，受到GPL传染性的约束，因此也无法用其他许可证开源。

结合上述案例，MongoDB 宣布其开源许可协议从AGPL v3变更为 Server Side Public License(SSPL)，由于AGPL属于copyleft许可证，而且也有与GPL V3一致的传染性约定，而SSPL并非OSI认证的开源许可证，更不是AGPL或者GPL V3允许的变更版本，因此MongoDB变更许可证虽然有合理的理由，但是违反了AGPL的约定，不具有合法性基础。

与copyleft许可证不同，permissive许可证对于使用者几乎没有任何具体的约定，其本身并没有限制许可方撤销或变更许可证的行为，前述案例中Tech start、Facebook、Redis均是从MIT或者BSD变更为其他许可证，似乎从许可证本身的约定来看，这些变更无法认定为违约行为。

在判断这个问题之前，我们需要考虑一个问题，知识产权的授权许可能否被许可方单方撤销或者修改？授权是一个单方行为，如果是一份单方出具的授权书，应当是可以被撤回的，也可以被修改的，不需要经过被许可方的同意。但是如果是一份授权许可合同，似乎这种变更行为会受到更多的限制，因为合同是双方互有对价的，最常见的是被许可方会向许可方支付版权费或者专利许可费，这种情况下许可方想要变更许可方式，或者撤回许可，除非合同约定了单方解除权，或者符合法定解除权的条件，否则被许可方是有权拒绝这种变更的。

第二个问题，如果一家公司基于Permissive许可证开源其软件代码，是否可以通过该开源获得相应的对价？这是一个有争议的问题，因为很多企业变更MIT或者BSD许可证的原因，就是其无法确保用户将修改成果反馈给发布者或者开源社区，但也正是基于该许可证的宽松约定，可以吸引大量的研发人员对开源软件进行完善和修改，大部分发布者是通过Permissive许可证扩展或完善了开源软件的功能，而这些贡献者实际上给予了开源许可方相应的对价。

第三个问题，Permissive许可证并未禁止撤销或变更行为时，开源发布者变更许可证是否需要经过社区用户的同意？基于Permissive许可证的约定，贡献者对于其修改内容应当是享有著作权的，如果开源许可方采纳了该种修改或贡献，证明其已经从中获利，之后其变更许可证的行为应当经过所有给予对价的贡献者同意，这也是Tech Start和OpenSSL变更许可证时所遇到的问题。但如果一家公司通过Permissive许可证开源，但是并未因开源获益，对于许可方而言该开源许可证的作用相当于单方的授权许可，其变更许可证应当是有合法性基础的。

因此，和Copyleft许可证不同，Permissive许可证是有可能进行变更的，但是需要满足一定的条件，否则仍然可能认定为违约行为。

以下是作者对于变更许可证行为可能产生的法律责任的一些思考和观点，无论是Copyleft许可证或者Permissive许可证，其均没有对具体的违约责任进行约定，GPL V3有终止授权和恢复授权的救济条款，对于其他违约行为则没有具体的违约责任条款。需要注意，开源许可证的约定是判断变更许可证行为合法性基础的重要依据，但是并非认定法律责任的唯一依据，即使开源许可证本身并未约定具体的违约责任，但是仍然可以根据成文法规定，甚至是法律原则来认定其违约或侵权责任。

针对Copyleft许可证，由于病毒型许可证本身要求修改作品强制开源，因此全部社区用户如果对开源软件进行了修改贡献，均需要反馈给开源社区，这些用户与开源许可方形成双方互利的合同关系，如果许可方变更许可证，我认为这些用户均有权提出主张，包括要求撤销变更行为恢复GPL开源，或者针对变更行为导致的经济损失提出索赔请求；或者即使许可方发布变更声明，但是用户仍然可以依据GPL许可证获取开源代码。

针对Permissive许可证，情况则有所不同，如果是对该开源软件进行修改的贡献者，其修改内容被许可方采纳，这是对于许可方及社区的一种正向反馈，许可方需要获取贡献者的同意后，才可以对许可证进行变更，否则贡献者有权认为该变更行为构成违约或侵权。但如果该用户通过Permissive许可证使用开源代码，但是对于二次开发成果采取闭源方式使用，并未对发布者或社区进行任何回馈，相当于只有该用户一方受益。该类用户能够主张的权利范围，应当小于贡献者。作者认为该类用户无权针对许可证的变更提出主张，但如果该许可证变更构成违约或者侵权，该用户有可能针对其受到的经济损失提出索赔请求，但是要根据具体的事实和证据进行判断。

更进一步，开源本质上是一种新型的竞争方式，开源许可方通过许可证公开其软件代码，吸引更多的用户（包括研发企业或人员）使用其开源软件，或采纳其开源软件或者市场产品的一部分，扩大其市场使用率，同时集合众多用户的修改成果完善开源软件的功能。因此，作者认为，开源行为除涉及到知识产权许可合同的法律关系外，还应当受到反不正当竞争法的制约。

前述案例中，Facebook在BSD许可证中添加专利报复条款，其目的是杜绝开源软件的用户对其提出专利侵权指控的可能，但是从另一个方面来看，相当于给Facebook提供了一个侵权行为的挡箭牌，即使Facebook确实实施了侵权其他企业专利的行为，如果该企业的其他产品涉及到React.js，基于专利报复条款这些企业在提出专利侵权指控时也会投鼠忌器。Redis和MongoDB实际是出于商业目的变更开源协议，MongoDB的变更行为还具有一定合理性，因为云服务商不提供修改后的代码，使得其商业版软件难以正版化，虽然其变更行为可能违反了AGPL约定，但是并不具有不正当竞争的恶意。而Redis公司将通过BSD 3.0开源变更为双许可证，其中RSALv2不允许进行商业化使用，与原先的BSD 3.0许可证完全不同，其目的在于限制云服务商通过Redis商业销售获利。但是这种变更行为将导致Redis与其他适用GPL的软件模式难以兼容，进而导致原先的用户企业需要重新审查软件研发及商业模式，甚至可能产生严重的经济损失，部分发行商已经从代码库删除了Redis，有一些软件研发公司也针对Redis的变更行为重新审查软件模块的兼容性。

从上述案例可以看出，开源许可证的变更和商业竞争紧密相关。根据我国《反不正当竞争法》第二条规定，“经营者在生产经营活动中，应当遵循自愿、平等、公平、诚信的原则，遵守法律和商业道德。本法所称的不正当竞争行为，是指经营者在生产经营活动中，违反本法规定，扰乱市场竞争秩序，损害其他经营者或者消费者的合法权益的行为”。开源许可证的变更行为同样需要遵循自愿、平等、公平、诚信的原则，如果恶意变更开源许可证，限制开源用户或消费者的合法权益，有可能在司法程序或行政程序中被认定为不正当竞争行为。

虽然对于研发企业或研发人员而言，开源代码是一种简单且低成本的授权途径，但是开源许可是可能在研发或产品销售过程中发生变化的，对于开源许可方而言，应当由专业的律师团队结合其商业需求，慎重选择初始开源协议，在变更开源协议时需要对其合法性进行判断和分析，否则可能面临严重违约或侵权指控。对于社区用户而言，尤其是在开源代码基础之上进行研发的企业，或通过开源软件提供商业服务的代理商，应当提前对开源许可证进行审查，并设置备选预案，避免开源许可证的变更产生不可挽回的商业损失。