开源许可证传染性界定法律探析及实务合规策略
作者：浙江六和（温州）律师事务所 蔡豪杰、柯展 日期：2023-01-04 阅读：1,236次
摘要：开源软件产品的使用使得全球各地的开发者能够互相和借鉴彼此的作品和技术，有利于实现软件开发的技术进步，其中开源许可证在保护开源软件自由发行方面起到了重要的作用,开发者看来大爱天下的开源许可证传染性特征在实务中却因为缺乏必要边界产生侵权争议和违法问题。本文将在简述和介绍开源许可证相关基础知识的基础上，对已有的涉及开源许可证纠纷的法院判决进行分析，从中提炼出目前国内法院对开源许可证传染性界定方面的裁判观点，从而指导实践，提出相应的实务操作设想与建议。
关键词：开源许可证 传染性 著佐权 著作权 合规
2009年5月20日，全球最大的网络技术设备公司思科（Cisco）与自由软件基金会（Free Software Foundation，以下简称“FSF”）之间的纠纷以和解收尾——思科公司被迫开放公司旗下一百余款路由器程序的源代码，并向FSF捐款数千万美金。 在这“大卫刺杀歌利亚”式的故事中，FSF所使用的“弹弓”便是开源许可证（Open Source License）。
一、开源许可证简述
开源许可证又称开源协议，属于外来的复合概念。其中“开源”代表开源软件（Open Source Software），是指由开发者发布在公共空间，能够被任何人自由使用、修改并进行再发布的软件[1.曲柳莺:《开源软件知识产权问题分析》，《信息技术与标准化》，2009年第6期，第58-64页。]；“许可证”（License）表示为一种许可协议或执照。概括地说，开源许可证是使用者在利用开源软件时默认与开发者签署的有关代码开源、修改、再发布等内容的法律文件。
（一）“著佐权”与开源许可证
20世纪70年代，因特网横空出世，彼时的软件开发领域百花齐放，开发人员之间相互交流、借鉴彼此的代码和算法，是软件开发领域实现快速突破和发展的关键模式。随着技术成果的逐渐成熟，各类商业软件逐步登上历史舞台——它们设计精良、功能完备，但需要付费。此类软件受著作权法等法律的保护，在付费使用之余不允许被共享、不开放源代码、不支持修改、不支持再发布，以达成其商业盈利之目的。
在利益驱动之下，愈来愈多受限制的商业软件在参考免费的、自由的软件的基础上，被不断研发出来，而为了抗衡商业软件的垄断，维护自由分享、合作创作的精神，自由软件基金会于1985年10月成立，其创始人理查德·斯托尔曼创造性地提出了“Copyleft”即“著佐权”的概念。
正如英语单词Left与Right相对，著佐权（Copyleft）亦与著作权（Copyright）相对。对于那些希望从软件创作中收益的开发者，其软件被他人自由使用、修改和再发布是一种权利的减损；而对于那些崇尚自由合作之精神的开发者，前者在参考、改写他们创作的软件之基础上将这些原本徜徉于自由天空下的代码束于私人的保险箱，亦是一种权利的减损。如果说著作权保护的是软件版权受开发者个人保有的权益，那么著佐权所保护的，则是开发者使其软件被自由地使用和修改而不被受限的权益。而自由软件基金会的成员们试图通过这种方式将商业软件开发者夺取的用户自由交还给用户自己。
开源软件或代码的开发者们在自己的作品中加入的开源许可证大致分为两类：著佐权许可证（Copyleft）与宽松许可证（Permissive），著佐权许可证以前文介绍的著作权为核心，限制代码的使用、修改和再发布，而宽松许可协议被称为“无限制协议”，对他人的使用施加最小的限制。但笔者认为，宽松许可协议此二者的分类实际上都体现和保障了著佐权，只是保障程度有所差别，实质上依旧遵循著佐权的运行逻辑。其条款因开发者的不同需求而有所变化，但绝大多数的许可证皆设定了两重义务：形式声明义务和对外开源义务。
1. 形式声明义务
形式声明义务，是指后续开发者的作品需要按照其所使用的开源软件许可证之要求，在进行发布和传播时，需要附带原开源软件的使用声明文件。此类文件包含了开源软件的版权声明、开源许可证文本或者链接，以及不担保声明（即表达因开源所产生的风险由许可证的被许可人自行承担之意思的声明条款）。同时，这些文件可以随作品的安装、压缩包一起分发，也可以将其放在指定网站上供用户下载。
2.对外开源义务
对外开源义务，是指后续开发者依照开源许可证的规定，将作品的源代码对外进行再次开源的义务，开源的内容因可证要求而有所变化。其可能存在的义务履行方式主要有如下三种：
（1）书面邀约模式
在发布和传播作品时附加一封书面邀约（Written Offer），用户可以依自己的需求通过邮件向开发者索要软件的源代码。开发者在收到用户的索取邮件后，再通过光盘（CD）或者文件传输协议（FTP）等方式进行点对点的代码提供。一般而言，该种履行方式会在开源许可证允许的前提下要求用户为源代码支付一定的费用。故商业公司主要采取这种形式来履行对外开源义务。
（2）随作品发布和传播
开发者将需开源的代码随作品一起发布。这种开源的方式成本较高，且无法控制开源的用户范围。故商业公司一般不采取此种形式履行对外开源义务。
（3）网站开源
开发者将需要开源的作品代码投放在自己的网站上，在发布和传播作品时附上具体的链接地址。这种开源的方式没有获取代码的成本，也同样无法控制开源的用户范围，故商业公司一般也不采取此种形式履行对外开源义务。
（二）开源许可证的种类
目前市面上的许可证种类众多，因篇幅受限，在此仅对常用的9种许可证（占GitHub开源项目许可证使用的81%以上[.https://github.blog/2015-03-09-open-source-license-usage-on-github-com/]）根据其主要特征进行分类简介。
| 类别 |
许可证 |
典型项目 |
主要特征 |
| GPL类 |
LGPL V2 |
OpenOffice |
1. 允许各种链接，动态链接无开源义务，静态链接需要开放某些文件。 2. 允许修改再链接到私有软件，但是修改增加的功能实现不能依赖私有软件的数据或功能。 3. 允许不受限制地使用原文件中的某些数值。 4. 仅原则性声明专利应免费许可，无详细规定。 |
| GPL V2、V3 |
Linux、Kdenlive |
1. 允许各种链接，但被链接的整个产品需要开源。 2. 允许修改，但被修改部分及整个产品需要开源。 3. 仅原则性声明专利应免费许可，无详细规定。 4. 只要不向用户发送软件副本，就不需要在GPL程序的ASP使用中公开源代码。（V3版本规定） |
| MPL类 |
CPL V1.0 |
JUnit |
1. 允许各种链接，无开源义务。 2. 允许修改，但修改部分需要开源。 （截取部分或全部开源代码与私有源代码混合将视为对原始软件的修改从而导致私有代码开源） 3. 软件所有人授予专利许可。 |
| EPL V1.0 |
Eclipse |
| MPL V1.0 |
Firefox |
| DDL V1.0 |
OpenSolaris |
| BSD类 |
Apache V2.0 |
ACE Tomcat |
1. 允许各种链接，无开源义务。 2. 允许修改，无开源义务。 3. 软件所有人授予专利许可 |
| BSD |
FreeBSD |
1. 允许各种链接，无开源义务。 2. 允许修改，无开源义务。 3. 无专利规定。 |
| MIT |
ASN.1 |
表 1开源许可证分类及特征介绍
（三）开源许可证的特性
1.遵循著作权并受著作权保护
不论是著佐权亦或是以前者为基础的开源许可证，其核心在于保障自由创作，但这一点不宜被视为对著作权的背反。因为开源许可证发挥作用的前提是开发者享有对作品的著作权，唯有在此基础上，开发者方才有权设置开源许可证等法律文件，允许他人自由使用自己的作品。在著作权语境下，著作权许可常表现为著作权人对特定对象的授权；而在著佐权之上，其表现为权利人向不特定对象授予附解除条件的许可，二者皆不违背著作权的运作逻辑，与著作权殊途同归[3.陈一村：《开放源码软件的著作权保护》，华侨大学学报(哲学社会科学版),2008年第2期，第68-73页。]。
2.许可证选择的相对多样性
随着自由软件运动的推进及开源社区的成熟，涌现出多种多样的许可证类型，其各类条款的限制、用户的权限等条款各不相同，创作者能够依照自己的需求选择以何种许可证加入自己的作品。但这种多样性依旧是受限的，为保障许可证的国际通用性，仅有通过开放源代码促进会（Open Source Initiative）认证的许可证才能被使用于开源项目之中[4.Synopsys, “2020 open source security and risk analysis (ossra) report,https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/2020-ossra-report.pdf, 2020.]。
3.可能存在的传染性
对开源产品的使用，往往还伴随着修改、整合的动作，使用者经常将原有的开源代码根据自身的需求进行进一步的修正和改进，或将其作为代码的一部分加入到自己的产品之中。至此便出现了一个问题——如果开源许可证的相关义务仅局限于原代码的部分，那么修改后或整合后的产品，显然已与原代码不同，此类产品是否需要继受原先的开源许可证义务？如果要继受，是在多大的范围内进行义务的继受？
许多开源许可证会加入“传染性条款”，即用户在接受开源许可证后，基于原作品所创作的后续作品的全体或部分都受该许可证约束——即便只有某个模块亦或是功能使用了开源代码，也需要公开该模块或功能以外的、甚至是全部的软件代码。例如GPL V2协议要求修改或增加后的整体作品受协议约束进行对外开源。
传染性问题是开源许可证纠纷中重要的一环，毕竟绝大多数的开源产品使用者都不会原封不动地将代码换皮进行再发布，两个软件之间必然存在不同。如果原产品的许可证义务不能继受到新的产品上，则开发者的著佐权便不能得到保障；而如果原产品也使用了开源产品，则因此被传染而继受的开源义务也将会成为被告用以抗辩的理由。
二、法院判例及观点分析
如前文所述，开源许可证的属性较为特殊。即便在软件开发领域已被人所熟知，但作为舶来品而言，学术和实务界对其性质等均未达成一致的认识[5.工业和信息化部软件与集成电路促进中心：《开源软件涉及的相关知识产权问题分析》，《中国集成电路》，2010年第10期，第77-89页。]。我国的民法典合同编、著作权法以及计算机保护条例等均未对开源许可证作出相关规定用以指导实践。
截止目前，仅有少量政策文件中有内容涉及开源软件，且大多仅为宣示性条款。如《“十三五”国家信息化规划》、《工业互联网专项工作组2019 年工作计划》、《国务院关于深化“互联网+先进制造业”发展工业互联网的指导意见》等文件表明我国鼓励和支持搭建开源平台、在国际开源组织中维护我国创作者和专利的权益等。
| 文件 |
内容 |
| 《“十三五”国家信息化规划》 |
支持开源社区创新发展。鼓励我国企业积极加入国际重大核心技术的开源组织，从参与者发展为重要贡献者，在优势技术领域争当发起者，积极维护我国相关标准专利在国际开源组织中的权益。 |
| 《工业互联网专项工作组2019 年工作计划》 |
支持龙头企业、技术服务机构开展开源社区、开发者平台和开放技术网络建设。 |
| 《国务院关于深化“互联网+先进制造业”发展工业互联网的指导意见》 |
面向关键技术和平台需求，支持建设一批能够融入国际化发展的开源社区，提供良好开发环境，共享开源技术、代码和开发工具。 |
2020年发布的《最高人民法院知识产权法庭裁判要旨（2019）》中，收录了以开源许可协议为核心争议的最高院判决，其中最高人民法院对开源许可证传染性的界限提出了相应的观点（将在后文详述）。
在缺乏相关法律法规、司法解释的情况下，对开源许可证相关纠纷案件的把握，很大程度上需要从已有的法院判例中汲取经验、总结观点。故笔者搜集了若干典型的法院判例，将对其进行简述和分析，并提炼其中法院对某个问题的观点。
（一）案例简介
1.闪亮公司与不乱买公司侵害计算机软件著作权纠纷案[9.参见（2016）京73民初1111号、（2019）最高法知民终663号判决书。]
本案被收录于《最高人民法院知识产权法庭裁判要旨（2019）》。2016年，不乱买公司以其开发的某软件进行了计算机软件登记。后不乱买公司因闪亮公司的网站代码存在抄袭的情形，向北京知识产权法院提起诉讼。
法院审理查明，闪亮公司的核心员工曾在不乱买公司担任移动事业部总监，存在接触代码之可能性，且经比对，两公司争议的软件代码具有相同的具备个人习惯和特色的注释及错别字等，可以排除是巧合情形，具备实质性相似。
闪亮公司在诉讼过程中提出了开源许可证抗辩，指出不乱买公司的软件代码使用GPL协议。根据GPL协议的要求，不乱买公司应当按照协议将软件整体全部对外进行无偿开源，故即便闪亮公司在自己的网站源代码中使用了不乱买公司的网站代码，亦不属于侵权。
一审法院针对该理由的观点为：不乱买公司网站代码分为前端与后端两个模块，前、后端的代码彼此独立，功能、技术各不相同，不应认为是一个整体。故即便其前端代码使用了GPL许可证，但其后端代码仍不受GPL许可证的传染性影响，闪亮公司仍应承担对其后端代码的侵权责任。后闪亮公司不服提出上诉，二审法院即最高院驳回上诉、维持原判。
2.罗盒公司与玩友公司等侵害计算机软件著作权纠纷案[10.参见（2019）粤73知民初207号判决书。]
罗盒公司股东罗迪将其开发的软件源代码上传到某网站供人下载，并适用GPL V3开源许可证。而后，罗迪在删除了软件中的GPL许可证、加入限制商业使用条款后，宣布停止更新软件代码，继而开始开发该软件的闭源版本用以收费盈利。
玩友公司基于罗迪开发的部分软件代码开发了四款手机软件，将其上传于各类平台供用户下载和使用，其使用模式为：前半小时免费试用，后续使用需要付费。玩友公司并未将软件代码公开供他人下载。
罗盒公司向法院起诉认为，玩友公司的软件功能与罗盒公司的软件构成了实质性相似。且玩友公司未将软件开源及收取费用的行为违反了罗盒公司原软件中的限制商业使用条款和GPL 许可证，故构成著作权侵权。
广州知识产权法院认为，根据GPL许可证的条款内容，罗迪即便是原软件的开发者，也无权在适用GPL许可证的软件内添加限制商业使用条款，此外，GPL许可证即便被删除，也不影响软件及后续版本继续收GPL许可证约束。同时，GPL许可证并未限制使用者将软件用于商业用途之权利，故玩友公司的收费使用行为不违反开源许可证的要求。
鉴于GPL协议的高传染性，玩友公司未将被诉软件整体开源的行为违反许可证条款。因GPL许可证属于附解除条件的合同，故GPL许可证应解除，玩友公司的授权终止，构成侵权。
3.柚子公司等与数字天堂公司侵害计算机软件著作权纠纷案[11.参见（2015）京知民初字第631号、（2018）京民终471号判决书。]
2013年10月21日，数字天堂公司开发HBuilder软件。后数字天堂公司发现柚子公司开发的APICloud软件中，有部分代码与其开发的HBuilder软件的三个插件存在同一性。故诉至法院。柚子公司提出了开源抗辩，认为HBuilder软件使用了GPL许可证，根据GPL许可证的传染性，其插件也应当对外开源，所以柚子公司的行为不构成侵权。
一审法院认为，HBuilder软件的三个插件各自于独立的文件夹中，且其各自所处的文件夹内并无GPL开源许可证的文件。与此同时，在HBuilder软件的根目录中也没有发现GPL开源许可证的文件。所谓的GPL开源许可证文件，处于HBuilder软件的其他插件Aptana的文件夹下，对于涉案的三个插件没有拘束作用。法院因此对柚子公司的抗辩不予认可，认定柚子公司的行为侵犯了数字天堂公司对三个插件的著作权。
柚子公司上诉后，二审法院对柚子公司的开源抗辩所持态度与一审法院相同，但认为柚子公司仅侵犯了一个著作权而非三个，酌情减少了相关赔偿责任。
4.网城公司等达克罗公司等侵害计算机软件著作权纠纷案[12.参见(2016)浙1081民初3924号判决书。]
网城公司曾开发的ShopNC电商系统系列计算机软件，因著作权纠纷起诉达克罗公司。
达克罗公司提出开源抗辩：ShopNC系统是基于PHP+MYSQL编写的软件，但PHP与MYSQL均属于开源软件，分别受CCPL与GPL开源许可证的限制。故根据传染性，ShopNc软件也应受开源许可证限制，属于开源软件。
法院认为达克罗公司对其抗辩理由举证不能，对该抗辩不予认可。
（二）法院判决观点提炼
1.开源许可证的效力与性质：合法有效的附解除条件合同
不论是上述介绍的案例或是其他未被选入本文的案例，多数法院均对开源许可证的法律效力予以默认，并基于此开展说理和裁判。但广东省深圳市中级人民法院在其审理的罗盒公司与风灵公司等侵害计算机软件著作权纠纷案[13.参见(2019)粤03民初3928号判决书。]中对此有所论述：法院认为，开源许可证内容和形式都具备合同的特征，属于开发者对他人进行授权的意思表示，系一种有效的民事法律行为。同时，法院也从开源许可证的对社会公众带来的积极作用进行了说理，以证明其合法有效的应然性。
在罗盒公司与玩友公司等侵害计算机软件著作权纠纷一案中，广州知识产权法院认为开源许可证属于附解除条件的合同。笔者对此表示认同，多数学者也持该观点[14.张汉华；《违法开源软件许可证的法律救济——以德国法为视角》，《法学评论》，2015年第3期，第83-88页。]。在各类开源许可证的文本中，开发者都会通过许可证条款对后续的开源使用者附加这样或那样的义务，而使用者能够得以自由运用和修改开源软件，正是以这样的义务为前提的，使用开源产品便意味着默认签订了合同[15.张平、马晓：《共享智慧——开源软件知识产权问题解析》，北京大学出版社2005年版，第44页。 ]。各类许可证大多规定若使用者违反某项条款，将引发许可证解除或终止的后果[16.付娜、李文宇、毕春丽：《开源中的知识产权风险分析》，《世界电信》，2017年第2期，第42-46页。]。又因开发者基于开源许可证授予使用者相应的权利，所以在许可证解除或终止后，使用者将丧失这部分被赋予的权利，构成侵权。这也解答了为何以自由开放的著佐权为核心的开源许可证，却能够作为提起著作权侵权的依据的这一问题。
需要补充的是，根据现有的判例，开源许可证在全球范围内皆不会因为地区的差异而失去其法律效力。2017年，美国的Artifex软件公司因许可证纠纷在美国境内起诉了韩国的韩软（Hancom）公司，韩软公司在美国境内并无业务活动，并以此提出抗辩，但法院并未理会韩软公司的抗辩，判决其违反相关许可证条款并依照美国联邦法律承担赔偿责任。
2.开源不可逆：不能撤销已发布的许可，不能增加商业限制条款
在罗盒公司与玩友公司等侵害计算机软件著作权纠纷一案中，广州知识产权法院否认了开发者删除开源许可证的效力，同时也否认了其加入的商业限制条款的效力。实际上，大多数主流的开源许可证都规定了开源版本一旦发布，开发者便无法撤销许可证。但值得注意的是，开源许可证允许开发者在后续的版本中对其进行更换或更新。
开源许可证保护的是“自由”而非“免费”，自由软件运动的倡导者及其拥趸只在乎软件的代码能否被自由地分享，而这些代码去向何方、用于何处并非其关心的对象。故即便是最严苛的GPL许可证，依旧保护使用者利用其进行商业活动盈利的权利。
3.传染性限度及开源义务继受
该问题较极为复杂且颇具争议，不同法院的判决所体现的底层逻辑也未能达成一致，故下面做分类讨论分析。
（1）编程工具与软件的传染性隔离
网城公司等达克罗公司等侵害计算机软件著作权纠纷一案中，被告提出涉案的软件是原告使用已经开源的编程工具创作的，根据传染性应当也受相应的开源许可证约束，属于开源软件。浙江省温岭市人民法院对被告提出的开源抗辩以举证不能的理由不予认可。无独有偶，在网城公司的另一起著作权纠纷中，浙江省宁波市鄞州区人民法院也以同样的理由驳斥了被告的抗辩。
笔者认为，法院对该抗辩理由不予认可是较为合理的，但说理方式过于简单，甚至有回避说理之嫌。毫无疑问，开源许可证约束的对象是代码，而非软件，故许可证的条款是作用于其他用户使用或修改软件代码的情形的，单纯地使用软件功能而不使用或修改软件代码，并不会触发开源许可证。网城公司使用编程工具创作自己的软件，并未使用或借鉴编程工具本身的软件代码，而是利用工具来创作自己的软件代码，所以不受开源许可证的约束。如果该案件中被告的抗辩理由成立，将会达致极其不合理的谬论——Linux操作系统是受GPL许可证限制的开源作品，那么在Linux系统中创作的一切软件应当继受GPL许可证的义务进行开源。
（2）软件部分与整体的传染性隔离
在柚子公司等与数字天堂公司侵害计算机软件著作权纠纷案及闪亮公司与不乱买公司侵害计算机软件著作权纠纷案中，法院均以“传染性隔绝”的理由对被告的开源抗辩予以驳斥，但二者有所区别。
在“柚子案”中，北京知识产权法院以及北京市高级人民法院认为：涉案的三个插件所处的文件夹以及主程序HBuilder的根目录下不存在GPL许可证文件，即便其他插件Apanta文件夹中存在GPL许可证文件，也不会对前者起到限制作用。
笔者对此持保留态度。需要明确的是，根据开源产品而进行修改和创作的产品属于演绎作品或派生作品[17.赵昆华：《开放版权许可协议研究》，硕士学位论文，北京:中国社会科学院研究生院,2015:26。]。根据判决书所呈现的事实可知，HBuilder所搭载的插件是为了实现某个具体功能，如“边改边看”和输入法功能等，各个插件与HBuilder本体代码共同构成了软件整体，在使用软件时，必然会同时运行本体与不同插件，进行数据的互相调用[18.张以标：《插件(软件)作品的侵权案法律透析》，《信息网络安全》，2009年第11期，第17-18页。比如在软件中输入文字并反馈结果，必定使用了其输入法插件的代码与本体代码。故在HBuilder这个软件中，插件与本体之间的关系是不可分离的。而案件中的Apanta插件亦是为了实现某个具体功能而被加入到HBuilder软件目录中，可以理解为HBuilder链接和使用了Apanta插件，形成依赖与调用的关系，存在数据交互。而Apanta插件使用了GPL开源协议，根据其条款，HBuilder应当受其感染并继受相应的开源义务。
“柚子案”中，法院对于GPL许可证相关条款的理解过于机械。尽管许可证规定包含受保护程序的“聚合体”不会使许可应用于该聚合体的其他部分，但其隔绝传染亦有前提，其中一则便是聚合体不是为了形成更大的程序。但在本案中，Apanta插件显然是Hbuilder的功能组成部分，其最终呈现为一个程序。在判决中，法院仅仅是简单地查看根目录下是否存在GPL许可证文件，不存在即视为不受约束，此判断未能准确理解开源许可证的性质以及软件本身的运行逻辑，仅从形式层面的“物理隔绝”来判定传染性隔离及义务继受，略有不妥。
但同样是北京知识产权法院，在后续由其审理的“闪亮案”中对传染性隔绝和义务继受的判断标准以及发生转变、趋于科学。在被告提出开源抗辩之后，法院对涉案代码进行了实质性考察，从展现方式、搭载技术、功能区别等方面来把握网页前端代码与后端代码之间的关系，最终判断前、后段软件存在传染性隔离，彼此不继受许可证义务。
北京知识产权法院在此方面所展现的转变，是科学的、合逻辑的。因此，在考察软件之间、插件之间是否存在传染性隔离时，不应只局限于形式，而应该从实质方面对代码之间的关系进行研究，有必要时甚至可以进行单独运行试验。笔者认为，在这种趋势下，开源软件之间的义务继受问题更偏向于技术层面，应以更加充足的资料与说理来应对此问题的交锋。
三、实务操作设想与建议
现今互联网经济体量愈发增加，软件设计已经进入白热化的“军备竞赛”阶段，开源软件和代码在其中起到的作用非同小可，甚至连行业巨头字节跳动、腾讯等公司都会适当地使用开源代码来提高自己的研发效率，开源产品的合规使用已经成为相关产业公司需要谨慎应对的问题。总结前文不难发现，涉及开源许可证的著作权纠纷，其核心在于双方义务的厘清以及软件之间的关系，故笔者结合法院观点对公司合规使用开源产品作以下建议和设想：
1.建立精确到版本的许可证介绍与推荐体系
开源许可证种类繁多，且涉及法律问题，学习成本较高。故建议公司在内部设置相应资料供员工进行学习，强调许可证合规使用的必要性。根据公司自身的业务和风险需要，通过各类文本与培训，向员工介绍公司常用的许可证类型及相关风险，并依照其条款特性进行使用推荐，减少学习成本、提高效率。例如：推荐使用BSD等商业友好型许可证、谨慎使用MPL类许可证（使用后应关注修改后对应的开源义务）、不建议或慎重使用GPL等严格许可证。
同时，各个种类的开源协议均存在多个版本。与法律更迭不同，同一许可证的不同版本之间相互独立、同时存在，旧版本许可证不会因为新版本的发布而失效或被替代。故在进行上述工作时应注意许可证版本的区分。
2.建立严格的许可证使用与审核体系
公司应出台开源软件及软件开源相关的管理办法，对涉及开源产品的使用流程进行严格规范，确立各类使用原则，降低风险。
（1）严格审批原则
员工在编写代码过程中如要使用外部开源产品，或依照开源许可证条款对外进行代码开源的，需要向业务部门提出申请，由业务部门给出执行建议并在开源风险中心或知识产权部门进行备案，备案内容包括开源产品与许可证名称、产品权属、产品源文件、开源依据的许可证条款等。
（2）有限范围原则
由开源风险中心防控中心、知识产权部门及业务部门共同确定可以使用开源或对外开源的业务范围，员工仅能在公司规定的业务范围内使用开源产品或对外开源。超出范围使用开源或对外开源的，应进行严格审批程序的基础上交由上述部门讨论决定，特事特办。
（3）推荐优先原则
由开源风险中心防控中心、知识产权部门及业务部门共同确定在某项业务范围内推荐使用的许可证类型，员工应优先选择本业务部门推荐且应用良好的许可证类型。
（4）风险可控原则
使用开源产品的，应当定期对开源业务使用的许可证义务、技术支持、版本质量和兼容性、开源私有化等几方面进行风险评估，尤其应关注因软件改进、使用环境、版本变化而可能发生的许可证兼容问题。
（5）禁止违规原则
员工应以合规使用为前提，对于无法遵守或无法使用技术手段规避风险的许可证应当谨慎使用、禁止使用。
3.灵活运用代码封装、接口通讯等技术手段
根据法院观点，开源许可证的传染性和义务继受取决于代码之间是否存在依赖和联系，是否彼此独立。故在合规方面，为规避开源协议所造成的法律纠纷，防止过于严苛的开源协议影响公司知识产权安全，或不经意违反开源协议导致公司声誉受损，在代码编写和项目开发时，公司应当尽可能将开源代码与其他自研代码依照许可证的要求进行技术上的隔离。
一，对相关代码进行封装，隐藏相关属性及细节，将其作为一个封闭的产品进行发布使用；二，在使用GPL等具有传染性的开源协议时，将所需项目与公司主要项目隔离，单独立项进行开发，公司主要项目不直接使用该项目源代码，而是以使用pipes等方式进行接口通讯或请求服务的方式间接使用该项目，或者将该项目编译形成动态链接库，同样以间接请求的形式使用。
上述方法旨在规范开源代码使用时的操作手段，增强主体程序与开源产品的相互独立性，避免开源从产品与主体程序被认定为一个整体，从而使得整体产品受到传染。然而，国内尚且没有已公开的判决表明有公司运用此方式对开源产品进行合规使用，若法院沿用北京知识产权法院判决的“柚子案”的裁判思路，则此种方法所产生的侵权风险将大大缩小。但此类手段亦会根据法院的不同而产生不同的认定，但相对于直接取用代码来说更为保险。
当然，最重要的是主动了解每个开源协议的性质，在使用对应开源项目时，主动遵守相关协议规定，防止造成不必要的损失。
4.灵活理解和运用开源义务
前文已述，开源许可证属于附解除条件的合同，权利人诉讼的基础在于使用者违反开源许可证相关条款后解除合同并丧失开源产品的使用权而导致的著作权侵权。在著作权纠纷中，开源义务的继受与履行是一个极为重要的焦点，因为不论是开发者亦或是使用者，在多数的许可证条款约束下都需要对产品进行一定程度的开源。
在产生软件著作权侵权时，开发者和使用者都应该首先审查声称遭受侵权的软件是否存在使用开源产品、使用了何种开源产品、是否继受了开源义务、继受了何种开源义务等情形。若存在开源产品的使用，被指控侵权的一方便可以提出开源抗辩——即声称遭受侵权的软件因使用其他开源产品而继受开源义务成为了开源产品，开发者应履行开源义务，故对其的使用不构成著作权侵权，使用者仅需要继续履行从声称遭受侵权的软件处继受的开源义务即可。
另一方面，在确定存在侵权事实的情况下。对于使用者而言，应当评估自身体量以及开源产品对自身的重要程度，若产品开源对自身的影响较小，则可以主动选择履行产品对外开源义务，使得自身符合许可证要求，进而获得合法使用全部或部分的权利，从而化解纠纷或减少相应的赔偿数额。而开发者可以考虑以要求使用者履行开源义务为筹码，进行谈判与和解。毕竟商业公司一般不能接受自己开发的商业软件对外开源。本文最开始提到的思科与FSF之间的纠纷便是以这种方式完成了最后的和解。但在我国现有的判例中，尚未出现权利人要求继续履行开源义务的案件。同时，笔者认为产品的开源可能属于对著作人身权的行使，即便要求侵权人继续履行，也可能被判定为《民法典》第580条的不适于强制履行的情形从而不受支持。
四、结语
现代社会科技进步迅速，各类信息得以互相交融，从而反哺科技的进步。知识产权的保护需要在个人利益与社会利用之间找寻一个平衡点，既不能缺乏保护，使得开发者丧失创作热情与信心，也不能过度保护，使得知识成果无法为社会所用。开源许可证传染性法律界定正是如今互联网环境下计算机领域的一个合规重要问题，笔者希望通过本文的探析和建议，减少实务中开源许可证使用争议，从而促进网络时代知识产权的良性保护和平稳发展。
参考文献
[1]曲柳莺:《开源软件知识产权问题分析》，《信息技术与标准化》，2009年第6期，第58-64页。
[2]陈一村：《开放源码软件的著作权保护》，华侨大学学报(哲学社会科学版),2008年第2期，第68-73页。
[3]工业和信息化部软件与集成电路促进中心：《开源软件涉及的相关知识产权问题分析》，《中国集成电路》，2010年第10期，第77-89页。
[4]张汉华；《违法开源软件许可证的法律救济——以德国法为视角》，《法学评论》，2015年第3期，第83-88页。
[4]张平、马晓：《共享智慧——开源软件知识产权问题解析》，北京大学出版社2005年版，第44页。
[5]付娜、李文宇、毕春丽：《开源中的知识产权风险分析》，《世界电信》，2017年第2期，第42-46页。
[6]赵昆华：《开放版权许可协议研究》，硕士学位论文，北京:中国社会科学院研究生院,2015:26。
[7]张以标：《插件(软件)作品的侵权案法律透析》，《信息网络安全》，2009年第11期，第17-18页。
1.曲柳莺:《开源软件知识产权问题分析》，《信息技术与标准化》，2009年第6期，第58-64页。
.https://github.blog/2015-03-09-open-source-license-usage-on-github-com/
3.陈一村：《开放源码软件的著作权保护》，华侨大学学报(哲学社会科学版),2008年第2期，第68-73页。
4.Synopsys, “2020 open source security and risk analysis (ossra) report,https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/2020-ossra-report.pdf, 2020.
5.工业和信息化部软件与集成电路促进中心：《开源软件涉及的相关知识产权问题分析》，《中国集成电路》，2010年第10期，第77-89页。
.http://www.gov.cn/zhengce/content/2016-12/27/content_5153411.htm
.https://www.miit.gov.cn/ztzl/rdzt/gyhlw/wjfb/art/2020/artfbe0d4cafba54ac2ad2ac76db231eb61.html
.http://www.gov.cn/zhengce/content/2017-11/27/content_5242582.htm
9.参见（2016）京73民初1111号、（2019）最高法知民终663号判决书。
10.参见（2019）粤73知民初207号判决书。
11.参见（2015）京知民初字第631号、（2018）京民终471号判决书。
12.参见(2016)浙1081民初3924号判决书。
13.参见(2019)粤03民初3928号判决书。
14.张汉华；《违法开源软件许可证的法律救济——以德国法为视角》，《法学评论》，2015年第3期，第83-88页。
15.张平、马晓：《共享智慧——开源软件知识产权问题解析》，北京大学出版社2005年版，第44页。
16.付娜、李文宇、毕春丽：《开源中的知识产权风险分析》，《世界电信》，2017年第2期，第42-46页。
17.赵昆华：《开放版权许可协议研究》，硕士学位论文，北京:中国社会科学院研究生院,2015:26。
18.张以标：《插件(软件)作品的侵权案法律透析》，《信息网络安全》，2009年第11期，第17-18页。
来源：省律协专业委员会工作部
责任编辑：雷雨
申请实习证
会员登录
律协概况
行业要闻
文化建设
业务研究
行业党建
会员管理
地市律协
