律师视点 | 黄斌：开源许可的热点与难点

黄  斌

北京德和衡（深圳）律师事务所

高级联席合伙人

开源是指源代码的开放，实质是技术共享；开源软件是指开放源代码软件，即其源代码可以被公众使用的软件。近年来，开源软件在操作系统、分布式数据库、人工智能框架、大数据、云计算、移动互联网等领域应用越来越广泛，推动了中国互联网的飞速发展和中国互联网企业的快速崛起。开源许可证是开源软件的版权人授予用户学习、修改、分发开源软件的一种法律许可，不同的开源许可证规定有不同的条件与义务，关系到用户是否享有修改或衍生后的代码使用以及商业使用等权利。企业、个人在使用、参与或主导开源软件的过程中，必然会涉及到各式各样的开源许可证，应当牢固树立开源风险意识，通过开源合规治理规避各种法律风险。

一、常见的几种开源许可证之间的区别

开源许可证用以保护作者、权利人、贡献者的权利，限定了使用者使用的条件，明确了使用者的权利和义务，是开源发展的一种法律许可。目前经过Open Source Initiative（OSI，开源促进会）认证的开源许可证共有100多个，木兰开源许可证是中国唯一一个经过OSI认证的国际化开源许可证。许可证大致可以分为四类：开放型开源许可证，允许用户任意自由的使用、修改源代码，修改后再发布可以不包含源代码，甚至可以将修改后的代码作为开源或者专有软件再发布，主要指Apache、MIT、BSD；弱传染型开源许可证，修改或衍生后的代码需要将源代码依照该许可证开源，以保证其他人可以在该许可证条款下共享源代码，主要指LGPL2.1、LGPL3.0、MPL、EPL；传染型开源许可证，只要包含该许可证下部分代码在完全发布时就必须作为整体适用该许可证，主要指GPL2.0、GPL3.0；强传染型开源许可证，要求修改后即使在创建在线服务或者内部解决方案时源代码都必须对外发布，主要指AGPL3.0。

Apache、BSD和MIT许可证再发布或修改后再发布可以不包含原始代码，而LGPL、GPL、AGPL3.0、MPL、EPL许可证修改后再发布必须包含原始代码。BSD、MIT、EPL许可证不要求修改后必须附加修改说明文档，而Apache、LGPL、MPL、GPL、AGPL3.0许可证则要求修改后必须附加修改说明文档。LGPL2.1、LGPL3.0、GPL、AGPL3.0许可证要求修改后还要使用同样的开源许可证再发布，而其他许可证则允许修改后使用不同的开源许可证再发布。MIT、Apache、MPL、EPL许可证允许转授开源许可证授权，而BSD、LGPL、GPL、AGPL3.0许可证则不允许转授开源许可证授权。Apache、LGPL3.0、MPL、EPL、GPL3.0、AGPL3.0许可证包含专利授权条款，而LGPL2.1、GPL2.0、MIT、BSD许可证不包含专利授权条款。BSD、MIT、LGPL2.1、GPL2.0许可证没有专利报复性条款，而Apache、MPL、EPL、LGPL3.0、GPL3.0、AGPL3.0许可证有专利报复性条款。AGPL3.0许可证要求修改后即使创建在线服务或者内部解决方案时，源代码必须对外发布，而其他许可证则没有这个要求。

二、开源许可证兼容性风险

不同的开源许可证规定有不同的条件与义务，在使用一个开源许可证当然不存在问题。但如果一个软件中使用了两个或两个以上开源许可证，就有可能引起各个开源许可证之间的限制或条件发生冲突，如果出现冲突就是不兼容，否则我们认为该几种开源许可证之间是具有兼容性的。使用两个或两个以上开源许可证的情形主要有：将适用不同许可证的两个开源程序合并成一个较大的程序，将一个开源程序的代码合并入另一个开源程序。

通过对许可证文件的阅读和分析，我们可以得出：BSD、MIT、LGPL2.1、GPL2.0、Apache、MPL、EPL、LGPL3.0、GPL3.0许可证均可用于商业使用、分发代码和内部使用，而AGPL3.0许可证也用于商业使用、分发代码，但在内部使用时需分析网络应用使用场景，是创建在线服务还是内部解决方案抑或是其他。BSD、MIT、Apache许可证对修改合并代码、使用库、修改许可协议没有任何限制，而MPL、EPL、LGPL3.0、GPL3.0、AGPL3.0、LGPL2.1、GPL2.0许可证对合并代码、修改代码、使用库时在分发时必须提供源代码，同时不允许自有代码使用不兼容的开源许可协议或闭源分发（其中：MPL、LGPL许可证可能要具体分析，没有一刀切）。

在对开源项目选择许可证时，我们需要首先考虑是否使用其他开源软件，是否需要使用其他开源软件的源代码，在这种情况下我们就需要考虑许可证的兼容性问题。许可证的兼容性问题主要体现在修改合并源代码和使用库两种情况：1、修改合并源代码是指将全部或部分源代码直接合并到开源项目或经修改后合并到开源项目；2、使用库是指在编译或运行时通过链接、导入等方式把要组合的开源代码绑定在一起。

（一）修改合并源代码情形

将带有BSD、MIT许可证的开源软件组合使用到开源项目时，可以使用BSD、MIT、LGPL2.1、GPL2.0、Apache、MPL、EPL、LGPL3.0、GPL3.0、AGPL3.0许可证。

将带有Apache许可证的开源软件组合使用到开源项目时，可以使用Apache、MPL、LGPL3.0、GPL3.0、AGPL3.0许可证，不可以使用GPL2.0许可证，在使用LGPL2.1、LGPL2.1+许可证时可以组合两方代码按照 GPL2.0以后的许可证发布，在使用GPL2.0+许可证时组合遵循GPL3.0许可证。（上述情形下，首先查看双方的许可证协议中是否包含一个条款允许你将协议升级到稍后的版本，LGPL+、GPL+代表许可证授予用户将许可证升级到未来版本的权利，否则是不兼容的）。

将带有MPL 2.0许可证的开源软件组合使用到开源项目时，可以使用MPL 2.0许可证，在使用BSD、MIT、Apache许可证时可以但组合遵循MPL2.0许可证，在使用LGPL、GPL、AGPL许可证时原来按照MPL2.0发布的继续使用MPL2.0许可证，而组合成的作品使用LGPL、GPL、AGPL许可证发布。

将带有LGPL2.1许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照LGPL2.1发布的继续使用LGPL2.1许可证，而组合成的作品使用MPL2.0许可证发布；在使用LGPL、GPL、AGPL许可证时是可以的，但在使用LGPL3.0许可证时组合遵循LGPL2.1许可证。

将带有LGPL2.1+许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照LGPL2.1+发布的继续使用LGPL2.1+许可证，而组合成的作品使用MPL2.0许可证发布；在使用LGPL、GPL、AGPL许可证时是可以的。

将带有LGPL3.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照LGPL3.0发布的继续使用LGPL3.0许可证，而组合成的作品使用MPL2.0许可证发布；再使用GPL2.0许可证是不可以的，在使用LGPL、GPL2.0+、GPL3.0、AGPL许可证时是可以的，但在使用GPL2.0+、LGPL2.1许可证时组合遵循LGPL3.0许可证。

将带有GPL2.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照GPL2.0发布的继续使用GPL2.0许可证，而组合成的作品使用MPL2.0许可证发布；再使用LGPL3.0、GPL3.0、AGPL3.0许可证是不可以的，但在使用其余GPL、LGPL、AGPL许可证时组合遵循GPL2.0许可证。

将带有GPL2.0+许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照GPL2.0+发布的继续使用GPL2.0+许可证，而组合成的作品使用MPL2.0许可证发布；再使用GPL、AGPL许可证时是可以的，但在使用LGPL许可证时组合应遵循GPL2.0+或GPL3.0许可证。

将带有GPL3.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照GPL3.0发布的继续使用GPL3.0许可证，而组合成的作品使用MPL2.0许可证发布；不可以使用GPL2.0许可证，再使用GPL3.0、AGPL3.0许可证时是可以的，但在使用GPL2.0+、LGPL许可证时组合应遵循GPL3.0许可证。

将带有AGPL3.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照AGPL3.0发布的继续使用AGPL3.0许可证，而组合成的作品使用MPL2.0许可证发布；不可以使用GPL2.0许可证，再使用AGPL3.0许可证时是可以的，但在使用GPL2.0+、GPL3.0、LGPL许可证时组合应遵循AGPL3.0许可证。

（二）使用库情形

将带有BSD、MIT许可证的开源软件组合使用到开源项目时，可以使用BSD、MIT、LGPL2.1、GPL2.0、Apache、MPL、EPL、LGPL3.0、GPL3.0、AGPL3.0许可证。

将带有Apache许可证的开源软件组合使用到开源项目时，可以使用Apache、MPL、LGPL3.0、GPL3.0、AGPL3.0许可证，不可以使用GPL2.0许可证，在使用GPL2.0+许可证时组合遵循GPL3.0许可证。

将带有MPL 2.0许可证的开源软件组合使用到开源项目时，可以使用BSD、MIT、Apache、MPL2.0许可证，在使用LGPL、GPL、AGPL许可证时原来按照MPL2.0发布的继续使用MPL2.0许可证，而组合成的作品使用LGPL、GPL、AGPL许可证发布。

将带有LGPL2.1许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache、LGPL、GPL、AGPL许可证时是可以的，在使用MPL2.0许可证时原来按照LGPL2.1发布的继续使用LGPL2.1许可证，而组合成的作品使用MPL2.0许可证发布。

将带有LGPL2.1+许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache、LGPL、GPL、AGPL许可证时是可以的，在使用MPL2.0许可证时原来按照LGPL2.1+发布的继续使用LGPL2.1+许可证，而组合成的作品使用MPL2.0许可证发布。

将带有LGPL3.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照LGPL3.0发布的继续使用LGPL3.0许可证，而组合成的作品使用MPL2.0许可证发布；再使用GPL2.0许可证是不可以的，在使用LGPL、GPL2.0+、GPL3.0、AGPL许可证时是可以的，但在使用GPL2.0+许可证时组合遵循GPL3.0许可证。

将带有GPL2.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照GPL2.0发布的继续使用GPL2.0许可证，而组合成的作品使用MPL2.0许可证发布；再使用LGPL3.0、GPL3.0、AGPL3.0许可证是不可以的，但在使用其余GPL、LGPL、AGPL许可证时组合遵循GPL2.0许可证。

将带有GPL2.0+许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照GPL2.0+发布的继续使用GPL2.0+许可证，而组合成的作品使用MPL2.0许可证发布；再使用GPL、AGPL许可证时是可以的，但在使用LGPL许可证时组合应遵循GPL2.0+或GPL3.0许可证。

将带有GPL3.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照GPL3.0发布的继续使用GPL3.0许可证，而组合成的作品使用MPL2.0许可证发布；不可以使用GPL2.0许可证，再使用GPL3.0、AGPL3.0许可证时是可以的，但在使用GPL2.0+、LGPL许可证时组合应遵循GPL3.0许可证。

将带有AGPL3.0许可证的开源软件组合使用到开源项目时，在使用BSD、MIT、Apache许可证时可以但组合遵循原许可证，在使用MPL2.0许可证时原来按照AGPL3.0发布的继续使用AGPL3.0许可证，而组合成的作品使用MPL2.0许可证发布；不可以使用GPL2.0许可证，再使用AGPL3.0许可证时是可以的，但在使用GPL2.0+、GPL3.0、LGPL许可证时组合应遵循AGPL3.0许可证。

三、相关司法裁判

1、“GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。”的认定

在北京闪亮时尚信息技术有限公司、不乱买电子商务（北京）有限公司侵害计算机软件著作权纠纷二审案中，法院认为：第一，前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。同时，前端代码与后端代码是可以分别独立打包、部署的。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。第二，不乱买公司作为权利人在本案中明确放弃以前端代码主张权利，仅以后端代码主张权利，因此涉案软件仅为后端代码而非闪亮公司所称前端文件和后端文件共同构成涉案软件。第三，根据2007年6月29日发布的GPL协议第3版第5条关于“一个受保护程序和其它独立程序的联合作品，在既不是该程序的自然扩展，也不是为了生成更大的程序，且联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，被称为聚合体。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分”的规定，闪亮时尚公司所称GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。本案中，虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源。

2、“涉案三个插件并不属于该协议中所指应被开源的衍生产品或修订版本”的认定

在柚子（北京）移动技术有限公司等与数字天堂（北京）网络技术有限公司二审案中，法院认为：柚子科技公司、柚子移动公司认可该三个插件均处于独立的文件夹中，该文件夹中并无GPL开源协议文件。不仅如此，在HBuilder软件的根目录下亦不存在GPL开源协议文件。根据GPL协议的相关规定，GPL协议的许可客体是在GPL协议许可下批准的受版权保护的程序以及基于该程序的衍生产品或修订版本。对于数字天堂公司涉案三个插件而言，在其所处文件夹中并无GPL开源协议文件，而HBuilder软件的根目录下亦不存在GPL开源协议文件的情况下，尽管HBuilder软件其他文件夹中包含GPL开源协议文件，但该协议对于涉案三个插件并无拘束力，据此，涉案三个插件并不属于该协议中所指应被开源的衍生产品或修订版本，柚子科技公司、柚子移动公司认为数字天堂公司软件为开源软件的相关抗辩理由不能成立。

3、“ShopNC计算机软件由PHP语言编写，PHP软件手册自带的开源CC许可证协议是否使得ShopNC软件也应受传导而开源”的认定

在浙江阿凡提电子商务有限公司、天津市网城天创科技有限责任公司侵害计算机软件著作权纠纷二审案中，法院认为：需指出本案上诉人所举证据所涉PHP开源软件中文官网手册（manual）明确以CC协议为附带的开源授权许可协议，该CC协议即是一种许可证，该CC许可证条款明确“许可人在此授予您全球性、免版税、非独占并且在本作品的著作权存续期间内均有效的许可，就本作品行使以下权利：复制本作品或将本作品收入一个或多个汇编作品中；创作和复制演绎作品，但是任何演绎作品，包括任何形式的翻译作品，均需以合理方式清楚地标示、区分或以其他方法表明原始作品已经被修改或变更；发行、公开传播本作品；发行、公开传播演绎作品。”及“当您发行或公开传播演绎作品时，许可人给获得作品的第三方提供本作品的许可，其条款和条件与您所获得的许可相同。”等内容，CC许可证要求使用者创作的演绎作品，也应传导开源属性遵循相同的CC许可证，无偿给予演绎作品的后续使用者许可。但需明确的是该软件使用手册的开源性质CC许可证并不等同于软件的许可证，PHP软件是否开源及开源权利取决于PHP软件作者选择何种许可证，本案中上诉人并未举证证明涉案PHP软件的许可证状况，PHP的手册文档所记载的“PHP一种被广泛应用的开源通用脚本语言”描述并不足以证明PHP软件的开源具体状况。另外，本案两被上诉人主张著作权保护的ShopNC电商系统计算机软件由PHP语言编写，但计算机语言本身具有工具属性，以特定计算机语言编写的ShopNC软件作品通过作者创造性的智力劳动所表现的作品独创性与计算机语言之间并未体现以后者为基础的派生关系，故也并非属于PHP语言演绎作品。即使以演绎作品的角度审查，CC许可证的上述开源传导性，指向的是原作品的演绎作品，涉案ShopNC软件也并不受软件手册CC许可证开源义务的约束。本案中，ShopNC电商系统计算机软件既未附带开源CC许可证，又在实际公开发布中表明属商业软件，故上诉人作为软件用户和电商同业者应明知ShopNC软件为非开源属性，上诉人未经许可作商业性的复制使用等，构成对该作品著作权的侵权。原审判决停止侵权赔偿损失属处理得当。

4、“使用了附带GPL3.0协议的开源代码，却拒不履行GPL3.0协议规定的使用条件构成侵权。”的认定

在济宁市罗盒网络科技有限公司诉被告福建风灵创景科技有限公司(以下简称福建风灵公司)、被告北京风灵创景科技有限公司(以下简称北京风灵公司)、被告深圳市腾讯计算机系统有限公司(以下简称腾讯公司)侵害计算机软件著作权纠纷一审案中，法院认为：针对被诉“点心桌面”App(V6.5.8)应否开源的问题。经查，被诉“点心桌面”App(V6.5.8)中使用了原告采用GPL3.0协议发布的VirtualApp，被告对此亦予以确认。根据GPL3.0协议第5条第1款c项、第7条和第10条规定的相关内容及“强传染性”特征，对在逻辑上与开源代码有关联性且整体发布的派生作品，只要其中有一部分是采用GPL3.0协议发布，那么整个派生作品都必须受到GPL3.0协议的约束。一项遵循GPL3.0协议的源代码不能同非自由的源代码合并。因此，被诉“点心桌面”App(V6.5.8)应当遵循GPL3.0协议向公众无偿开放源代码。被告福建风灵公司辩称未实质性修改所使用的开源代码，故无需公开“点心桌面”App(V6.5.8)的源代码缺乏理据，本院不予支持。综上，被告福建风灵公司使用了附带GPL3.0协议的开源代码，却拒不履行GPL3.0协议规定的使用条件。根据GPL3.0协议第8条自动终止授权的约定及《民法总则》第一百五十八条的规定，被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对VirtualApp实施的复制、修改、发布等行为，因失去权利来源而构成侵权。

四、开源许可的难点

开源软件依赖于现有知识产权及相关法律体系的保护，权利人将其享有的知识产权财产权和部分人格权授予用户行使，其目的是创设一种自由开发、使用或传播的环境。将初始版本的源代码在Github等网站上公开发布的项目人，虽然不是唯一的贡献者，但其作为主要贡献者之一，无需经过其他贡献者一致同意或授权，可作为原告提起侵权等相关诉讼并获得全部赔偿。

贡献者可在开源前就开源软件相关的技术方案申请专利，否则将因为专利技术方案的公布而导致失去新颖性。Apache、LGPL3.0、MPL、EPL、GPL3.0、AGPL3.0许可证包含专利授权条款，而LGPL2.1、GPL2.0、MIT、BSD许可证不包含专利授权条款，但依据许可证进行使用的用户在许可证约定范围内使用不构成侵犯专利权。

GitHub规定，用户与GitHub之间的本协议以及对网站或服务的所有访问或使用，均受美国联邦法律和加利福尼亚州法律的管辖。中国开源平台“码云”的用户协议规定，本网站内容及本使用条款的解释和适用均适用中华人民共和国法律，由于使用本网站而产生的一切纠纷，除另有约定，均由中华人民共和国人民法院管辖。因此，我们在开源时要尽量选择适用由中华人民共和国人民法院管辖。

开源软件的用户关注的主要有：是否可以商用、是否需要保持链接、是否可以闭源等。所以我们选择开源许可证时要关注是否可以闭源，因为这关系到我们代码中的源代码是否能够作为技术秘密来保护，否则因被迫公开而失去商业秘密的特性。

不遵守许可证时许可协议的行为，到底是违约之诉还是侵权之诉已经讨论争议很多年了。我们认为，使用了附带许可证协议的开源代码为附解除条件的授权，如果用户拒不履行许可证协议，视为该许可证协议授权已因解除条件的成就而自动终止，该拒不履行许可证协议的用户因失去权利来源而构成侵权。

或许您还想看

作者简介

黄  斌

北京德和衡（深圳）律师事务所高级联席合伙人

黄斌律师，华中科技大学法律硕士，北京德和衡律师事务所数字经济与人工智能业务中心副总监，深圳律协数字经济专委会副主任，北京德和衡（深圳）律师事务所高级联席合伙人，公司业务部副主任，专利代理人。

擅长领域：数字经济、元宇宙、NFT、虚拟人、区块链、虚拟货币、公司法、建设工程、知识产权。

黄斌律师专注于中小股东保护，深度研究数万个判例进行解码，从董事推荐、公司决议、股东退出等多维度完成了公司中小股东保护法律服务产品；在大学从事近十年建设法规教学，从建工合同的签订、入场、施工、变更、退场等多维度保护建工企业及实际施工人的权益；曾从事三年专利代理工作，参与了武烟集团公司知识产权战略规划。2017年完成江西省工商联课题“民企知识产权保护”。

现为北大法律信息网签约作者，中国最大法律人社区无讼阅读“商标有道”专栏作者，在北大法律信息网和无讼阅读平台上发表过《中国好声音：到底是谁的好声音》等100多篇知识产权法文章，《麦当劳中国更名为“金拱门”相关法律问题评析》荣获“无讼”阅读2017年度专业文章第一名，《短视频版权保护的江湖风云》收录在《大数据—北大法律信息网文粹（2018-2019）》一书。

代理案件中江西网络电视台诉暴风科技信息网络传播权侵权案入选江西省高院2017年十大知识产权经典案例、田某某侵犯商业秘密罪案（判三缓五）入选2021年江西省检查机关保护知识产权典型案例。

手机：[phone]

邮箱：[e-mail]

质控人简介

辛小天

合伙人

数字经济与人工智能业务中心总监

[e-mail]

END