开源软件技术作为互联网企业常规工作中不可或缺的链条之一，为开发者研发各类软件提供重要支撑及效率支持。然而，在软件开源生态的构建过程中，机遇与挑战并存，开发者除了应当充分发挥和利用开源软件优势外，更需要警惕其中的法律风险。本文通过介绍开源许可证的基本情况，分析我国开源许可证相关纠纷的司法实践现状，以期为开源软件使用者提供参考，有效避免许可证的传染风险。

 

 

开源许可证介绍

（一）开源软件的起源与发展

开源软件，即开放源代码软件（Open Source Software，OSS），通常指授权人遵循某种开源许可证，将源代码在不同程度上向公众公开，并允许用户在许可证约定的条件下自由使用、修改和分发计算机软件。开源软件作为人工智能、大数据、区块链、云计算等领域的重要技术，其所倡导的“自由共享、开放协作”精神为相关产业的交流与创新提供了良好的生态环境。20世纪80年代，来自美国麻省理工大学的开源软件鼻祖理查德·斯托曼（Richard Stallman）创建了自由软件基金会（Free Software Foundation，FSF）,并在全世界掀起自由软件运动，其于1984年发表《GNU宣言》以抨击封闭源码行为，并使用了“Copyleft”一词，又被称作“著佐权”，与著作权“Copyright”相对，斯托曼认为此种开放式著作权概念可以确保自由软件的自由性质不被侵蚀。[1]随后，美国著名程序员Eric Raymond认为“自由（free）”一词可能给使用者留下“免费”的误解，便提出了“开源软件”这一概念，并被流传沿用至今。

开源软件兴起于域外，经过数十年的发展，如今已发展成为全世界信息技术开发领域的主战场。有数据统计，不管我们使用手机还是电脑，平均每个程序都要依赖150个开源组件。[2]2021年3月12日，《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》中提出，“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”，未来开源软件将会继续作为软件产业发展的趋势与方向，软件开发技术人员在使用开源软件的过程中通常不会关注到其所使用的开源许可证，进而引发诸多开源许可证相关的风险与纠纷。

（二）开源许可证常见类型及查阅方式

开源许可证发展至今数量众多，截至目前，经过开放源代码首创行动组织（Open Source Initiative，OSI）批准的开源许可协议已多达近百种。常见的开源许可证包含有MIT、Apache、BSD、GPL、MPL等，根据开源许可证限制条件的强弱，可以将其分为强copyleft许可证、弱copyleft许可证以及宽松型许可证。随着开源许可证种类的不断增加，也给开源软件的使用者带来了巨大的挑战。具体而言，当前实践中常见的各类开源许可证在具体条件上存在差异（如表1）：

不同类型及版本的开源许可证虽在具体条件上存有巨大差异，但均以鼓励传播为原则，需要使用人保留并提供版权声明，且均为免费向用户提供，无须额外支付对价，开源软件的便捷性和免费性是深受开发者们喜爱并促使开源产业迅速发展的基础。然而实践中，用户在下载使用开源软件时通常不会注意到开源许可证的存在，以开源软件托管平台GitHub为例，用户在预览选择下载开源软件源代码页面时，在其预览页面即可知晓该软件包含有“LICENSE”文件（如图1），随后用户将该软件打包下载后相关根目录文件如预览所示（如图2），点击该“LICENSE”文件可知晓该开源软件所适用的具体开源许可证，如下图所示软件适用的即为宽松型许可证MIT（如图3）。

 

开源许可证法律分析

开源许可证最初起源于国外，对于其法律性质的认定在不同国家均存在争议。我国近年来先后出现了几起与开源许可证相关的典型案例，并有法院已明确认定开源许可证实质上具有合同性质，本质上是授权方和用户订立的格式化著作权协议。本部分将结合国内外有关开源许可证的司法实践现状，分析开源许可证的法律性质。

（一）开源许可证的法律性质争议

在美国著名的MySQL案中，法院就涉案行为对被告适用了初步禁令。尽管该案以庭外和解的方式结案，且该禁令没有明确支持MySQL关于被告Progress违反GPL许可证的主张，法院未就GPL许可证的性质及效力作出认定。但是，该案件引起了人们对于自由软件及GPL若干核心条款内容及效力的兴趣。[3]作为开源软件起源国，美国系普通法系国家，其关于著作权法与合同法的规定分别适用联邦法及州法，这也导致在美国司法实践中就开源许可证的性质存在较大争议。例如，在加州北区联邦法院审理的Jacobsen v. Katzer案[4]中，法院认为违反GPL许可证的行为属于违约行为，因此驳回了原告关于版权禁令的诉讼请求。但是，美国联邦巡回法院在该案的上诉审理中则认为超出许可证限制的范围即构成侵权行为，同时确认了GPL许可证为具有强制力的许可。

与美国不同，采物债二分体系的德国则对这一问题争议较少。在Welte诉D-Link案[5]中，德国法兰克福地区法院根据《德国民法典》第305条第1款第1句，认为GPL开源许可证条款的法律性质是特定的一般交易条款，即通过预先拟定并由著作权人向使用人提出的合同条款。此外，法院认为GPL开源许可证中设定的使用条件应认定为“解除条件”，即德国法院倾向于将许可证性质界定为附解除条件的合同。德国慕尼黑地区法院在Harald Welter v. SiteCom案中也持有相同的观点，该案被告的产品软件使用了原告适用GPL许可证的开源代码，被告在使用中为遵循许可证义务。法院认定其基于GPL许可证获得的授权许可自行终止，继续适用原告源代码的行为构成侵权。[6]

有观点认为我国现行法律框架下对GPL法律性质的分析论证更近似于德国法，即基于物债二分，将缔结和履行GPL的行为归入“负担债法义务的行为”而非变动无权的“处分行为”[7]，且属于债法中的合同行为，即GPL在具体当事人之间产生约束力的过程符合合同成立的一般要件。[8]我国并不存在类似美国联邦和地方法律管辖冲突及合同法适用不一致的问题，我国《著作权法》中关于“著作权许可使用和转让合同”的表述足以说明，在我国法律体系下，基于开源许可证的许可使用本质上表现为为合同形态。也有观点认为Welte诉D-Link案[9]中提出的“解除条件”理论在我国具有适用的空间，即将“表明著作权信息”、“修改说明”、“发布许可证副本”等理解为合同的“解除条件”，如用户因违反所述条件而自动解除合同，则用户已经或正在实施的行为即演变为侵权行为。持该观点的研究者认为我国《民法典》第一百八十五条规定，“民事法律行为可以附条件……附解除条件的民事法律行为，自条件成就时失效”，因此我国法院可以据此在司法实践中采用借鉴德国实践的观点。[10]但是，如果将开源许可证简单视为附解除条件条件的合同，则难以解释超越许可使用范围的行为构成侵权这一问题。实际上，针对违反开源许可证的行为应当适用何种救济方式在实践中存在诸多争议，笔者认为，基于违反开源许可证的行为，违约请求权与侵权请求权相竞合，权利人可以结合实际情况及自身诉求，择一进行救济。

（二）我国司法实践现状

目前，我国国内尚无明确法规就开源许可证的法律性质及效力作出单独规定。近年随着开源软件产业的迅速发展，司法实践中也涌现出了部分由开源许可证引发的纠纷（如表2）。由北京知识产权法院一审、北京市高级人民法院二审的数字天堂（北京）网络技术有限公司与柚子（北京）科技有限公司等侵犯计算机软件著作权纠纷案[11]，系我国司法实践中首例涉及GPL开源许可协议的诉讼案件，为开源许可协议在我国司法程序中的效力认定起到积极意义。尽管在该案中，法院并未明确GPL许可证的法律效力，但理论界和实务界普遍认为法院在论述的过程中实际上默认了GPL许可证具有法律约束力。与该案类似的，在最高人民法院知识产权法庭发布的《最高人民法院知识产权法庭裁判要旨（2019）》，典型案例33不乱买电子商务（北京）有限公司与北京闪亮时尚信息技术有限公司侵害计算机软件著作权纠纷案[12]中，法院同样保持了审慎态度，并未明确GPL许可证的法律效力，但在认定涉案后端代码是否构成GPL意义上的“单独程序”时，法院在判决分析部分直接引用了GPL许可证的部分具体条文。此外，在该案中，法院还首次就GPL的传染性作出了认定，“应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序”，但是就涉案三个插件是否构成独立作品，以及是否受到GPL传染的判断未进行深入分析。

针对GPL许可证传染性的问题，广州知识产权法院在其审理的济宁市罗盒网络科技有限公司与广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案[13]中存在进一步论述，该案是中国法院首次在判决中确认开源协议系具有合同性质的格式化著作权协议，并明确GPL许可证具备传染性。法院在判决书中以安卓操作系统举例，论述谷歌公司发布的该系统通过将系统分为多个独立的不同层级框架，并对每个层级适用不同的开源授权许可协议以解决GPL许可证的传染性问题。法院认为玩友公司的涉案沙盒分身部分功能代码是作为被诉侵权软件的衍生部分而整体发布的，其未举证证明该部分功能源代码是独立的，或是使用了类似谷歌公司的安卓系统分层方法。

综上，从司法实践来看，开源许可证的本质仍为合同。作为软件开发者，可以通过理解并遵循各类型开源许可证的适用条件，同时回归开源许可证本身的性质及条款，采取合理的技术手段，从而实现阻断开源许可证传染性的效果。

 

开源许可传染性阻断路径探析

（一）明确开源许可证类型并适用具体条款

对于使用开源软件的主要群体技术人员而言，相关的开源代码是否便捷易用是选用开源软件代码时的主要参考因素，而开源软件是否存在开源许可证、开源许可证的类型为何通常遭到忽略。因此，当开发者使用了一项适用强传染性的开源许可证软件而未履行相应的条件时，将产生极大的法律风险。

规避因开源许可证传染性带来的潜在风险，一方面，需要企业及技术人员加强开源软件业务合规审查，建立企业内部自有的开源合规体系，如部分企业采用的开源风险中心备案制或开源代码使用审批制。另一方面，亦需为开发者普及更多开源许可证相关的法律知识，充分了解各类许可证的适用差异，结合开源代码适用的底层逻辑，在使用开源代码进行软件开发的过程中运用“技术+法律”双重手段，防止因开源许可证传染性而带来的不必要损失。

以传染性较高的GPL许可证为例，根据GNU官网，常用的GPL许可证主要是2.0及3.0版本，而不同版本的许可证均独立、有效，适用不同的许可条件。开发者在使用开源软件代码时，除了确定该代码适用的许可证类型，也要明确许可证类型的具体版本。如本文前述对于开源软件下载步骤的介绍中所示，通过开源社区下载的软件通常能够在开源社区中找到明确标示的许可证类型及版本号。在“不乱买公司v.闪亮时尚”案[14]中，法院对于该案软件适用的GPLv3协议部分条款进行了说明。如“修订”程序是指从软件拷贝或者做出全部或一丁点儿的修改，这不同于逐字逐句的拷贝，是需要版权许可的。修订成果被称为先前程序的“修订版本”或者“基于”先前程序的程序。并在判决书中摘选了影响开源许可证传染性认定的关键条款，即第5条和第7条中对于“聚合体”（aggregate）的规定：

第5条，发布修改过的源码版本，您可根据第4条的条款，以源码形式发布一个基于本程序的程序，或者从本程序中制作该程序需要进行的修订，但是您必须同时满足所有以下条件：a）……b）……c）……本包。……d）……如果一个受保护程序和其他独立程序的联合作品，则若该联合作品并非该程序的自然拓展，也不是为了在某个存储或发布媒介上生成更大的程序，且如果联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，这样的联合作品就被称为“聚合体”。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分；

第7条……您遵守GPL有关程序和修订版的各方面规定，但例外程序除外。所有例外程序是修订版本可识别部分，不是程序的衍生产品，例外程序本身可以合理视为独立和单独的程序，并可根据其最初许可的例外许可发布，例外程序本身不能以Aptana发布给您的形式进行修订。这部分的目标代码或可执行形式附随相应机器可读的完整源代码，在同一媒介上的这部分的对应目标代码或可执行形式，被适用例外许可作为这部分的对应目标代码或可执行形式，按照GPL规定，与本程序、或存储或发布媒介量的修订版本整合的例外程序，是聚合体……。

（二）采用恰当的通信机制或动态链接等技术手段实现隔离

上述适用GPLv3许可证下，关于开源代码传染性的作品聚合例外规定，实际上衍生于v2版本，即仅将另一个不是基于本开源程序的作品，与本开源程序聚合在一起，即可以豁免传染性。GPLv3版本系对聚合的概念进行了进一步明确。此外，根据GNU就“许可证常见问题”发布过的常见问题解答[15]，“聚合”与“修改”的区别在于“聚合”包含有多个独立的程序，并在同一个CD-ROM或其他媒介上发行。区分的合理标准既依赖于通信的机制，也依赖于通信的语义所交换的信息。因此，把握软件是否“聚合”可成为阻断开源许可证传染性的关键路径。在“济宁罗盒V.广州玩友”案中法院提到的谷歌公司安卓系统分层法是阻断传染的一大成功案例，谷歌公司在安卓操作系统的内核使用了遵循GPL的开源Linux内核， 那么个人或企业为安卓系统开发的应用软件也必须遵循GPL进行公开，这将严重降低企业和个人开发者参与安卓系统开发的积极性，妨碍整个开源操作系统生态环境的建立。谷歌公司为了解决该问题，通过将GPL的适用局限在安卓系统独立的底层Linux内核空间中，而在上层的类库和应用框架以及用户空间部分则适用较为宽松的ASL开源软件许可协议，由于上层的类库和应用框架以及用户空间部分并不视为底层Linux内核的衍生产品，因此避开了GPL许可传染至整个安卓系统，那么安卓系统上层的硬件驱动和应用框架程序就是独立的，其开发者适用ASL进行开发，可以自由选择是否公开其源代码。[16]

实践中，采用与谷歌公司类似的技术手段能够避免被开源许可证传染。结合自由软件基金的许可证问题解答[17]，如果两个模块均包含在同一个可执行文件中，该两个模块一定是一个程序的组件；如果两个模块运行时共享空间地址连接在一起，该两个模块亦几乎构成一个组件。因此，通过采用不同的通信机制能够达到使模块独立的效果。譬如，可以采用管道通信（pipes）、套接字（sockets）和命令行参数等方式使几个模块隔离，进而避免GPL的传染性。

不同许可证的差异性规定促使阻断开源许可证传染的方法具备特定性和多样性。不同于GPL许可证，使用MPL许可证的开源代码，应当把许可证的代码放在单独的文件内避免许可证传染；而LGPL许可证起初系专门针对库而制定，因而上述对调用程序的影响在这类许可证中更易避免。根据LGPLv2许可证第6条的规定，采用共享库的机制将LGPL库与自由代码进行链接，且保证用户可以在接口兼容的前提下修改链接的库，此时自由代码将不会被传染。因此，对于使用LGPL许可证的开源软件，可以采用动态链接的方式调用该许可证的库实现隔离。

 

 

结语

开放、共享、协作、自由的开源软件文化为企业研发提供了极大便利，为用户使用便捷多样的软件增加了可能性。但同时，技术与法律之间的行业壁垒也让开发人员有时会因忽视开源许可证的存在而引发法律风险。如文章中提到的诸多国内外司法实践案例，违反开源许可证适用规定而引发的传染性问题不仅会转化为企业的侵权成本，使企业面临高额判赔，还可能导致代码强制开源，进而影响企业竞争优势。为避免开源许可证的传染风险，企业应主动建立体系化的开源合规制度，增进技术开发人员与法务风控等部门工作链接，采用“技术+法律”双重操作手段，合理利用开源软件。

 

 

注释：

[1] 王韬：《copyleft及其译法》，载《科技资讯》2008年第32期。

[2] 参见“开源软件，中国来了”，“央视财经”微信公众号2021年5月10日发表，https://mp.weixin.qq.com/s/KOfHgA14dMLNHjUm5dQy6g.

[3] 张韬略：《MySQL AB诉Progress Software Corp,.NUSPHERE Corp.案——GPL许可证与法律失之交臂》，载《网络法律评论》2004年第2期。

[4]Jacobsen v. Katzer，535 F.3d 1373.

[5]District Court of Frankfurt am Main，In re Welte v. D-Link Deutschland GmbH，September 22，2006。

[6] 张汉华：《违反开源软件许可证的法律救济——以德国法为视角》，载《法学评论》2015年第3期。

[7] 王泽鉴：《民法总论》，北京大学出版社2009年版，第218页。

[8] 张长丹：《GPL的法律性质及各方法律风险研究——以违反GPL的案例为视角》，载《电子知识产权》2018年第1期。

[9] 同5。

[10] 潘亮：《开源软件司法保护探析》，载《电子知识产权》2022年第6期。

[11] 参见北京市高级人民法院（2018）京民终471号民事判决书。

[12] 参见最高人民法院（2019）最高法知民终663号民事判决书。

[13] 参见广州知识产权法院（2019）粤73知民初207号民事判决书。

[14] 同上12。

[15] 参见“自由软件基金会”发布的《关于GNU许可证常见问题》，https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation,2023年3月5日访问。

[16] 同上13。

[17] 同上15。