前言：

随着全球开源创作内容的井喷和开源社区的不断发展，大多数在生产经营活动中开发和使用计算机软件的主体都会不可避免地使用到开源代码，而如何安全、合规地使用开源代码却甚少得到重视。近年来，开源软件权利人在我国境内的维权行动增多，越来越多的企业希望能够事先建立完善的开源代码合规使用体系，并希望在面对违约/侵权指控时能够得到专业的帮助。本文将从实务和现有司法实践角度出发，为开源代码合规使用及风险处置问题提供一定指引。

（一）基本概念

“开源”，即开放源代码（Open source code），亦称为源代码公开。为避免歧义，本文中的“开源代码”或“开源软件”仅用以描述受某种开源协议（开源许可证）约束，并可以在许可范围内自由使用、复制、修改和再发布的代码。

大量既有文章已经对开源代码的发展历史、开源社区的基本情况、开源协议的基本类型进行了充分的介绍，本文就此内容不再赘言，仅以最大化实现开源代码价值为目标，对企业的开源合规和诉讼应对问题提供方案指引。

（二）合规目标

企业进行开源代码合规建设的主要意义主要有三：一是实现合法使用，在降本增效的同时避免各类法律风险；二是保证安全，防止因安全漏洞或潜在限制等原因给企业造成损失；三是方便管理，降低重复分析、选型带来巨大的管理成本，同时有效管理开源软件的生命周期。

（一）开源代码识别

根据笔者的实务经验，绝大多数企业的经营管理者实际上不了解自身开发或使用的软件中是否存在第三方开源代码、存在何种开源代码。这样的情况可能是开发人员隐瞒软件开发过程、企业缺乏软件开发和使用过程监督、软件迭代历史久远等原因综合造成的。那么，如何对既有软件是否使用了开源软件进行核查与识别，就是开源合规的首要问题。

一方面，可以利用专业的第三方工具对现有软件代码进行核查。市面上常用的此类识别工具有BlackDuck、FOSSID、探方（Scantist SCA）等。此类第三方工具能够通过扫描源代码，发现并确认其中存在的开源代码及其版本、许可证信息，识别准确率较高。

另一方面，可以人工对软件根目录、说明文档、库文件名称等进行筛查。大量软件中嵌入的开源代码多以独立组件形式存在，因此有经验的开发人员可以查阅软件根目录、说明文档、库文件名称等信息，并自行在Github等开源平台上进行比对核查。此种核查方式只适用于软件开发过程记录相对清晰、体量相对较小的软件，在缺乏其他校验措施的情况下其结果难免出现错漏。

（二）开源代码尽职调查

识别开源代码只是第一步，为了制定完善的开源代码合规使用方案，还需要结合企业开发和使用软件的具体情况，对相关开源代码具体信息进行尽调。

尽调内容通常包括：软件项目名称、该项目是否存在多个开源代码、开源代码名称及版本、受控的开源协议、代码行数/文件包大小、代码来源、根目录License文件、是否对开源代码进行修改及再分发、该开源组件与主程序的交互方式、该开源组件功能描述及重要性评估、该开源组件是否具有替代方案及替代成本、该项目是否申请专利等。

（三）开源代码归类

在完成尽职调查的基础上，我们会将全部开源代码进行分类处理，通常而言会根据开源许可证对修改及再分发行为的限制程度分为以下三类：

▶A类许可证：A类许可证的核心特点是对修改和再分发行为几无任何限制（但可能要求修改者对修改的内容进行声明），也不强制使用者履行开源义务。典型的此类许可证包括MIT许可证[1]、BSD许可证[2]（包括2条款版BSD和3条款版BSD）、APACHE 2.0许可证[3]等；

▶B类许可证：B类许可证的核心特点是允许使用者将受控代码与自创代码（通过动态链接库、远程服务调用等方式）分开，仅要求对原受控代码（可能包括衍生代码）进行开源，典型的此类许可证包括MPL 2.0许可证[4]、EPL 2.0许可证[5]等；

▶C类许可证：C类许可证的核心特点是具有极强的“开源传染性”，即要求使用者将与受控代码相关的全部代码按照本许可证或指定的许可证开源，如GPL3.0许可证[6]等。

如某个许可证内容无法被归类入以上任何一个类别，那么我们将逐字逐句地对该许可证内容进行分析，尤其关注其对使用、再分发行为的要求以及是否强制要求闭源，并在此基础上针对该开源软件提出后续使用建议。

（四）制定《开源软件管理办法》

在完成尽调、归类和分析的基础上，我们建议企业进一步制定《开源软件管理办法》。《开源软件管理办法》不是具体的操作规范，而是结合企业具体情况明确开源软件管理的意义、运行机制和权责规范。

《开源软件管理办法》通常包括：总则（企业开源软件管理的意义、涉及部门、名词定义等）、部门与职责（需求提出部门-审核与监督部门-实际开发部门-资产管理部门）、运行流程、更新与准出标准等具体章节。

（五）编写《开源软件使用手册》

《开源软件使用手册》（以下简称“《手册》”）是开源软件的全流程使用指南，是合规工作的落地指引。

对于既有软件而言，《手册》将明确针对受控于上述A类、B类和C类的开源代码指明后续使用方式、整改方式（例如增加开源说明文件、更改动态链接方式等）以及替换退出期限，并以附件形式将不可归类的开源代码使用注意事项进行标注。

对于未来的开源软件使用需求，《手册》将明确各类主体（包括需求提出人、软件开发人、软件使用人、软件审批人、软件监管人等）的职责，绘制使用管理流程图，并对各个流程提出规范指引（例如：在审批环节明确非经特殊批准禁止使用C类许可证软件；在入库环节要求需求提出者注明开源代码来源和版本、提供链接及许可证全文、将未归类许可证内容提交审查等）。

（六）企业宣贯

上述工作完成后，我们将配合企业进行数轮的宣贯，尤其注重对软件开发人员的培训，有效落实《手册》的规定和要求。

相比于少量能够事先建立开源代码合规体系和风险防范机制的企业，更多的企业往往是在面对权利人的侵权指控时才意识到自身可能存在违反开源许可证的行为，那么针对此类风向应当如何处置呢？

（一）开源代码相关案例

1、某盒v.某灵案[7]

裁判观点（最高人民法院）：关于GPL3.0协议的性质及效力问题。GPL3.0协议的内容具有合同性质，开源软件的发布可视为要约，用户使用即为承诺，在用户使用开源软件时合同成立……被诉侵权软件使用了某盒公司采用GPL3.0协议发布的涉案软件中的源代码，福建某灵公司对此亦予以确认。因此，被诉侵权软件应当遵循GPL3.0协议，向公众开放源代码……被诉侵权软件本应遵循GPL3.0协议向用户开放源代码，其对于涉案软件源代码的使用因后续未开源而丧失正当的权利来源基础，因此某灵公司对涉案软件源代码的使用属于未经著作权人许可而使用其作品的行为，已经构成对某盒公司涉案软件著作权的侵害。

风险提示：使用受强传染性协议控制的开源代码时，应当履行后续开源义务，否则可能承担包括停止侵权、赔偿损失等在内的著作权侵权责任。

2、某拓v.某湘案[8]

裁判观点（武汉中院）：原告虽然在开源条款中开放其涉案软件源代码，公开许可终端用户免费使用其涉案软件，但在开源条款中，原告明确终端用户使用其软件时应该保留涉案软件署名标识和版权链接。该协议不违反我国法律、法规规定，软件作品署名信息和保留链接信息应受尊重和保护。原告提交的第三方取证平台抓取的被诉网站的相关页面显示，被诉网站没有按照开源协议限制条款署名原告软件标识和网站尾页底部版权声明链接，违反原告涉案软件开源条款，被诉网站使用涉案软件行为超出了该软件开源条款授权许可范围，侵害原告涉案软件署名权。

风险提示：对开源代码进行使用时，如违反开源许可证明确约定的义务，则可能构成侵权。

3、任某v.某致案[9]

裁判观点（最高人民法院）：涉案软件源代码被上传至GitHub网站，任某对此解释为：其出于保存源代码的考虑在开发初期将源代码同步保存在GitHub网站……虽然某致公司主张其从未授权任某公开涉案软件的源代码，但是没有证据表明某致公司内部对于软件源代码的保存设有规章制度。某致公司对于员工开发软件等工作行为也应当进行相应的日常管理，但某致公司在整个软件开发过程中对于任某的行为没有提出异议，某致公司当时对任卫的行为很可能持默许态度，至少持放任态度，某致公司本身对此具有明显过错。诉讼发生后任某在一审开庭审理前已经删除了GitHub网站上的源代码，及时制止了损害结果。据此，本院认定任某对于开发工作中出于工作需要将涉案软件源代码上传至GitHub网站并导致源代码被公开，并无明显过失，更不存在故意或重大过失，对某致公司并不构成侵权。

风险提示：公司应制定完善的软件开发、管理制度，否则需要自行承担公司资产受到的损失（例如源代码被公开）。

（二）风险应对建议

1、核查权利人侵权警告内容是否属实

根据笔者经验，部分权利人在发出侵权警告时存在并不审慎乃至警告错误的情况。例如，某些开源软件存在多个版本且受控许可证不同，权利人在发现软件中包含某一名称的开源组件便以使用人违反了GPL协议的传染性为由主张侵权，但实际上该特定版本的组件并不受GPL协议控制。

此外，部分软件权利人通过设置软件“后门”的方式获取所谓的“侵权证据”，且侵权警告函中拒不说明证据的来源和具体内容，被警告人无从具体查证。

上述情况多发于部分采取“广撒网”方式进行维权的主体，此类警告大多“没有后文”。 我们建议企业核查权利人侵权警告是否属实，如警告不实或无法查证，可书面回函澄清或要求权利人提供完整的证据材料。如权利人发出的侵权警告确有错误且已经对企业的生产经营造成影响，也可以考虑主动提起确认不侵权之诉。

2、确认具体使用行为是否违反了开源许可证条款

需要澄清的是，绝大部分的开源许可证并不限制“商业使用”。即使以限制最严格的GPL协议为例，在使用人没有修改、将受控源代码编入新程序的情况下，使用人在商业场景中使用受控于GPL协议的软件并不构成侵权。

因此，在面对侵权警告或诉讼时，实际使用人应当仔细核查开源许可证的权利义务要求，并分析实际使用行为是否超出了授权范围或违反了其他义务。

3、核查开发者链条和许可证链条

面对侵权警告或诉讼时，实际使用人应当仔细核对其使用的开源软件版本信息和开发历史。如实际使用部分并非警告人或原告创作的，此时警告人或原告不应就该部分向实际使用人主张权利。

此外，实际使用人还应当就被控开源软件的许可证链条（如有）进行核查。如果警告人或原告本身也是在既有开源代码的基础上进行二次创作的，而其又将创作成果以违反原许可证的条件进行分发甚至闭源，那么警告人或原告可能并不享有相应的警告权利或请求权基础。

4、尽快修正使用行为以重新满足许可证要求

如确实在使用过程中违反了开源许可证的要求，我们建议实际使用人尽快修正其使用行为。有些情况下，实际使用人只需要通过诸如增加版权说明或者修改库文件调用方式等手段就可以更正其违约/侵权行为。但是，就此前已经发生的违约/侵权行为，实际使用人的责任不能就此完全免除。

此外，实务中存在大量以下情况：权利人开发某款工具类软件后，推出商用付费版和非商用开源版两个版本，且非商用开源版往往根据GPL 3.0等C类许可证进行发布。实际使用人使用了上述非商用开源版组件进行软件开发，程序开发完毕后却没有按照许可证的要求开源，最终开源组件的权利人警告或起诉，索要极高的赔偿金。此种情况下，实际使用人可以在权衡独立研发成本、替代软件可行性等因素的情况下，主动购买该软件的商用付费版。

5、主动替换高风险开源代码

使用开源代码可能产生的风险包括但不限于：因开源协议传染性导致自主研发软件无法实现商业价值的风险、专利限制风险、安全漏洞风险、因违反许可证要求导致的违约/侵权风险等。

在开源合规梳理和风险应对的过程中，企业应当明确自身的“不可承受之重”，对于可能给企业带来无法承受风险的开源代码，应当尽早进行替换。

以上内容是笔者结合自身实务经验及现有司法实践归纳总结的开源代码合规使用及风险方案，谨供读者参考。针对不同企业、不同软件客体的实际情况，相关使用合规及风险处置方案需要进一步丰富和调整。如有任何问题，欢迎与笔者联系。

[1]https://www.mit-license.org/

[2]https://opensource.org/licenses/BSD-2-Clause；[3]https://opensource.org/licenses/BSD-3-Clause

[4]https://www.apache.org/licenses/LICENSE-2.0

[5]https://www.mozilla.org/en-US/MPL/2.0/

[6]https://www.eclipse.org/legal/epl-2.0/

[7]https://www.gnu.org/licenses/gpl-3.0.en.html

[8]参见（2021）最高法知民终2063号民事判决书。

[9]参见（2022）鄂01知民初2520号民事判决书。

[10]参见（2021）最高法知民终1246号民事判决书。