夜雨聆风作者：王红燕 沈杨雨岚 汪媛雅 刘珂诗 章雨璐
《中国人工智能企业出海百问百答》第五部分
本专栏由中伦王红燕律师团队持续更新，从出海前置尽调到落地后风险处置循序渐进，持续输出落地型合规解决方案，聚焦实务、直击痛点，助力国内 AI 从业者避开海外合规红线、低成本稳妥布局全球市场。本期作为专栏第五部分：软件合规与开源协议。欢迎大家关注！四十五、在软件发行说明中，如何合规地披露使用的第三方开源组件及其许可证信息？
软件发行时，如果使用了第三方开源组件，企业通常需要按照相应开源许可证的要求向用户提供版权、许可证等信息。需要注意的是，“开源”并不意味着可以不受限制地使用，不同许可证对再分发的要求并不相同。因此，发行说明中的披露应当以具体许可证的要求为基础，而不能采用一套统一模板处理。
首先，应当明确披露哪些信息。一般而言，第三方开源软件声明应至少列明开源组件名称、版本、版权声明以及适用的许可证名称和版本。例如：
Component: XXX
Version: X.X.X
Copyright: XXX
License: Apache-2.0
对于软件中包含的组件较多的情况，可以通过SCA工具进行识别，并形成开源组件清单或SBOM，以避免遗漏直接依赖或间接依赖的开源组件。
其次，应当按照许可证要求提供相应文件。对于要求保留版权声明、许可证声明或者NOTICE信息的许可证，应当将相关内容随软件一并提供。实践中，可以在安装包、发行包或者软件的“关于”“法律声明”“第三方开源软件”等页面设置LICENSE、NOTICE或THIRD-PARTY-NOTICES文件。Apache License 2.0[1]即要求再分发时提供许可证副本，并保留相关版权及归属声明；对于原软件包含NOTICE文件的，还应按照许可证规定处理NOTICE信息。如果多个开源组件适用同一种许可证，可以在符合法许可证要求的情况下集中提供该许可证文本及相关声明，无需机械地对每一个组件重复附上相同文本。但对于各组件特有的版权声明、NOTICE或其他归属信息，仍应按照相应许可证的要求分别保留。
再次，应当根据许可证类型确定披露范围。对于MIT、BSD等较为宽松的许可证，通常重点关注版权声明和许可证声明的保留；对于Apache License 2.0，还应注意许可证副本、NOTICE以及修改声明等要求[2]。对于GPL、AGPL等Copyleft许可证，仅披露组件名称和许可证名称通常并不足够，还应根据具体许可证版本及软件的使用、修改和分发方式，判断是否存在提供相应源代码等义务。例如，GPLv3第6条[3]对目标代码形式的传播规定了Corresponding Source的提供要求，AGPLv3第13条[4]则针对修改后的程序通过网络向用户提供服务的情形规定了相应的源代码提供要求。因此，对于GPL、AGPL等许可证，不能简单理解为“在Release Notes中注明GPL即可”，企业应当进一步确认许可证要求的源代码、许可证文本等是否已经以规定方式向用户提供。
最后，应当注意Release Notes与开源许可证文件的关系。Release Notes可以作为披露第三方开源组件的一种方式，但如果许可证要求提供完整许可证文本、NOTICE或者相应源代码，仅在发行说明中列出组件名称和许可证名称，并不能替代这些义务。实践中，可以将Release Notes作为信息入口，同时在软件安装包、发行包或指定页面提供完整的第三方开源软件声明及相关文件。因此，企业在发布软件前，建议逐项核对“组件名称、版本、版权声明、许可证、许可证要求以及实际披露位置”，并保存与具体发行版本对应的开源组件清单及许可证文件。对于许可证版本发生变化、来源不明或者涉及GPL、AGPL等许可证的组件，应在发布前进一步进行法律审查。
四十六、如果修改了GPL协议的代码并用于SaaS服务（不分发），是否必须开源全部代码？
原则上不需要，判断关键不在于“是否修改”，而在于是否向他人“分发”（distribution）或“传递”（conveying）受GPL约束的软件副本。GPLv3第0条明确，用户仅通过计算机网络与程序交互、未取得程序副本，不属于“传递”；第2条又允许在不传递的情况下制作、运行和传播受保护作品。[5]因此，企业仅在自有或受其控制的服务器上运行修改后的GPLv2/v3程序，以网页或API向客户提供SaaS，客户只获得计算结果而不取得程序副本时，通常不因该行为承担公开源代码的义务，学术研究亦将此称为传统GPL在SaaS模式下的“网络服务漏洞”。[6]
但“不必开源全部代码”并不等于没有GPL风险。若企业向客户交付私有化部署包、可执行文件、Docker镜像、虚拟机镜像或客户端程序等，或者让独立关联公司取得副本，即可能构成分发或传递；网页加载到用户设备的GPL JavaScript等也可能属于副本交付；此时应向接收者依GPL提供相应源代码，并保留版权、许可证及修改说明。[7]开源范围也不是当然覆盖企业全部代码：GPLv3第5条将基于GPL程序形成的整体作品纳入同一许可，但明确排除可合理认定为独立、分离的作品及单纯聚合作品；专有模块是否与GPL组件构成一个结合作品，应结合代码复制、静态或动态链接等，不能仅凭“微服务”名称下结论。[8]
还须核对许可证是否实际为AGPL。AGPLv3第13条规定，修改后的程序支持远程网络交互时，必须向远程用户显著、免费提供该版本的对应源代码；这是其与普通GPL的核心区别。[9]企业应建立软件物料清单，记录许可证全称、版本、例外条款和修改情况，并审查部署拓扑、外包运维、镜像仓库、前端交付及私有化部署安排；若难以维持清晰隔离或未来需要向客户交付，宜事先取得商业许可、替换组件或完成专项法律评估。[10]
四十七、 针对海外军工或敏感行业客户，软件出口是否需要申请额外的商业管制许可证？
向海外军工或其他敏感行业客户提供软件是否受管制，应结合软件本身的技术属性、是否列入管制清单、最终用户及最终用途综合判断。中国现行出口管制体系以《出口管制法》为基础，并通过《两用物项出口管制条例》和《两用物项出口管制清单》具体实施。[11]
《两用物项出口管制条例》将两用物项定义为既有民事用途，又有军事用途或者有助于提升军事潜力的货物、技术和服务，包括相关技术资料等数据[12]。对于列入《两用物项出口管制清单》或实施临时管制的物项，出口经营者应当申请许可；相关物项存在《出口管制法》第十二条第三款规定情形的，也应当申请许可。因此，软件是否需要许可不能仅依据软件名称或客户所属行业判断，而应重点核查其具体技术参数、功能及实际用途。
如果客户属于军工、国防、航空航天等敏感行业，应重点核查其最终用户、最终用途以及是否属于管控名单或关注名单。对于列入管控名单的最终用户，原则上不得进行相关两用物项交易（经许可的除外）；列入关注名单的，出口经营者申请许可时还须提交风险评估报告。此外，2026年商务部已针对特定国家和地区进一步加强两用物项出口管制，还应当关注目标国家、最终用户及最终用途相关的专项管制措施。
出口前应以软件的具体技术指标、功能和用途为基础，对照《两用物项出口管制清单》进行分类判断，不能仅依据海关编码或产品名称。[13]对于可能受管制的AI、加密、航空航天及其他高技术软件，应留存技术参数及分类判断记录；同时对进口商和最终用户开展尽职调查，核实其身份、业务范围、制裁及管控名单情况，并取得最终用户和最终用途证明文件。申请两用物项出口许可时，原则上需提交相关合同、技术说明以及最终用户和最终用途证明等材料；如发现最终用户或最终用途已经或可能发生变化，应立即停止出口并报告。
对军工及其他敏感客户，建议在合同签署和产品交付前设置出口管制审核节点，将产品分类、客户筛查、最终用途审查及许可证判断纳入统一流程；合同中同时设置最终用途保证、禁止擅自转让或再出口等条款。对无法确定是否属于两用物项的，可向国务院商务主管部门提出咨询。未经许可擅自出口受管制物项，可能面临警告、罚款、责令停业整顿、吊销相关许可证或资质，情节严重的还可能承担刑事责任。
四十八、如何进行软件版本的合规管理，确保旧版本（存在漏洞）不再被新客户使用？
【风险等级提示：绿线问题】
软件版本合规管理的重点，是在发现漏洞之前就建立一套能够识别、下架并阻断风险版本继续流入新客户的全生命周期管理机制。
首先，应建立统一的版本台账和退役机制。每个正式版本至少记录发布日期、组件依赖、已知漏洞、修复状态、支持期限及停止销售、停止支持时间，并区分“在售、维护、停止销售、停止支持”等状态。销售、交付、官网下载、应用商店、镜像仓库和许可证系统应共用同一版本白名单。
其次，发现漏洞后不能只更新官网说明。现行《网络安全法》第24条明确要求，网络产品、服务存在安全缺陷、漏洞等风险时，提供者应立即采取补救措施，及时告知用户并持续提供安全维护。《网络产品安全漏洞管理规定》第5条和第7条进一步要求产品提供者及时验证、评估和修补漏洞；需要用户通过软件升级等方式修复的，还应及时告知风险、修补方式并提供必要技术支持。因此，对于高危漏洞版本，企业内部最好形成“修复版本发布—旧版本下架—新客户准入拦截”的联动流程。
再次，要区分新客户禁用与存量客户升级。新客户原则上只交付仍在支持期且通过安全测试的版本；对已经使用旧版本的客户，则应结合漏洞等级、业务连续性及合同约定设置升级窗口，并保留漏洞通知、版本推送和客户升级记录。NIST安全软件开发框架同样强调，应将漏洞发现、修复及持续改进纳入整个软件开发生命周期。[14]
这一趋势在欧盟规则中更加明显。《网络韧性法案》（CRA）要求数字产品制造商确定产品支持期限，在支持期内持续处理漏洞并及时提供安全更新；在符合条件的情况下，可以重点维护最新重大版本，但旧版本用户应能够免费取得最新版本，且原则上不应因此承担额外的软件、硬件适配成本。[15]CRA的漏洞及重大安全事件报告义务将自2026年9月11日起适用，主要产品安全义务自2027年12月11日起适用。
因此，真正有效的软件版本合规，不是简单提醒客户“不要使用旧版本”，而是让存在漏洞的旧版本从销售、下载、交付、授权到部署各环节退出新客户链路，同时为存量客户保留可验证、可追踪的安全升级路径。
编辑|王佳佳
[1]Apache License, Version 2.0, §4（Redistribution），规定了再分发时提供许可证副本、保留版权及归属声明以及在适用情况下处理NOTICE信息等要求；
[2]Apache License, Version 2.0, §4；MIT License及BSD 2-Clause、BSD 3-Clause License的许可条件。不同许可证对版权声明、许可声明及其他信息的保留要求存在差异，应以具体许可证文本为准。
[3]GNU General Public License, Version 3, §6（Conveying Non-Source Forms）。该条规定，在特定情况下以目标代码形式传播受保护作品时，应按照规定方式提供Corresponding Source；
[4]GNU Affero General Public License, Version 3, §13（Remote Network Interaction）。该条针对修改后的程序通过计算机网络向用户提供交互服务的情形，规定了提供Corresponding Source的特殊要求。
[5]参见Open Source Initiative：GNU General Public License version 3（GPLv3），第0、2条， https://opensource.org/license/gpl-3-0；GNU General Public License version 2（GPLv2），第2条，https://opensource.org/license/gpl-2-0；
[6]孙福洲、钱瑾、杨静、钱岭：《云服务时代下的开源发展》《电信科学》2020年第11期，第156—164页，DOI：10.11959/j.issn.1000-0801.2020298；
[7]Linux Foundation：Docker containers and open-source licensing，https://training.linuxfoundation.org/；GNU：The JavaScript Trap，https://www.gnu.org/philosophy/javascript-trap.html；
[8]参见Open Source Initiative：GPLv3，第1、5、6条，https://opensource.org/license/gpl-3-0；赵亮、高超、苏晓艳：《开源许可证对比研究》《计算机科学与应用》2021年第11卷第12期，第2971—2981页，DOI：10.12677/csa.2021.1112300。
[9]参见Open Source Initiative：GNU Affero General Public License version 3（AGPLv3），第13条，https://opensource.org/license/agpl-3-0；
[10]段志超、鲁学振、杨可依：《“开源合规”系列之三——SaaS应用场景下的开源合规》，汉坤律师事务所，2022年11月22日，https://www.hankunlaw.com/portal/article/index/cid/8/id/12521。
[11]中华人民共和国《出口管制法》第十二条，https://www.gov.cn/xinwen/2020-10/18/content_5552203.htm。
[12]中华人民共和国《两用物项出口管制条例》（2024年国务院令第792号），https://www.gov.cn/zhengce/content/202410/content_6981399.htm。
[13]《中华人民共和国两用物项出口管制清单》，https://www.mofcom.gov.cn/zcfb/zc/art/2024/art_461aafbb5e974f47b1c23866643cb71c.html.
[14]NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218。该框架强调将安全开发、漏洞处置及持续改进措施嵌入软件开发生命周期，以降低已发布软件中的漏洞风险。
[15]Regulation (EU) 2024/2847（Cyber Resilience Act），Art. 13(8)、13(10)、13(19)及Annex I Part II。CRA要求确定支持期限、持续处理漏洞、安全分发更新；对于后续推出重大修改版本的软件，符合条件时可仅针对最新版本履行部分漏洞修复义务，但此前版本用户须能免费取得最新版本，且无需额外调整其软硬件环境。
本文版权归「科技法全球合规观察」所有，如需转载，请联系下方秘书号洽谈授权。
如果您有相关法律咨询需求，
欢迎添加团队秘书号：
