ARTICLE · 1217364
拆解最高法AI纠纷意见第十三条:人工智能开源软件侵权责任的认定
一家科技企业从开源社区下载人工智能模型代码，在此基础上进行二次开发，并将其集成到商业软件中。产品上线后，企业收到权利人的侵权通知，理由是该软件使用的部分开源组件违反了原有许可条件。
企业认为，代码既然已经公开，任何人都可以免费使用；研发人员则认为，相关代码来自第三方开源项目，责任不应由使用企业承担。
争议的关键并不在于软件是否免费，也不在于企业是否修改了代码，而在于开源许可是否有效、相关行为是否超出授权范围，以及侵权责任应由谁承担。
最高人民法院《关于依法审理涉人工智能纠纷案件的意见》第十三条，将人工智能开源软件相关纠纷纳入司法指导范围。
这一条值得关注的，不是给开源软件设置新的使用障碍，而是明确一个基本边界：
开源不等于放弃著作权，免费使用不等于可以不遵守许可条件。
对于依赖开源框架、模型代码和第三方软件组件的AI企业而言，开源合规已经不只是研发管理问题，也可能直接影响产品交付、商业发行和知识产权侵权责任。
01｜核心判断：开源不是免责，侵权也不能无限向上追溯
人工智能技术的发展高度依赖开源生态。
从模型训练框架、数据处理工具，到推理引擎、向量数据库和各类软件组件，企业很难完全依靠自主开发构建一套AI系统。
一个商业化AI产品，往往包含数十甚至数百个直接或间接依赖的软件组件。
问题在于，当下游企业利用开源代码开发的产品发生侵权时，责任是否应当一直追溯到最初的开源开发者？
如果所有下游侵权行为都可能使最初的开源贡献者承担责任，开源社区的参与成本将显著增加。
但如果所有开源软件开发者都可以因为免费提供代码而免责，也可能损害权利人的合法权益。
第十三条正是在这两者之间寻求平衡。
它并没有确立“开源软件一律免责”的规则，而是强调结合许可协议、安全合规措施、信息披露和具体侵权行为，合理确定责任边界。
02｜第十三条的规则定位：综合考量、适当豁免
《意见》第十三条的核心规定可以分为两个层次。
第一层：综合判断开源软件相关主体的侵权责任。
法院审理涉开源软件案件，应当综合考量开源许可协议类型、权利限制的具体内容、安全合规举措和信息披露程度等因素，依法合理认定开源软件开发者、提供者及后续开发者、提供者的侵权责任，并给予适当责任豁免。
这意味着，开源软件侵权责任不能简单依据代码传播链条确定。
例如，最初开发者提供一个通用算法模块，下游企业在其基础上增加其他功能，并将系统用于侵权活动。
如果最初开发者没有参与下游行为，对相关使用缺乏控制能力，而且已经合理披露模块功能和安全风险，其责任评价就不应当与实际实施侵权的下游企业相同。
第二层：符合特定条件的免费开源代码提供者，可以不承担下游侵权责任。
第十三条进一步明确，开源软件开发者、提供者以免费开源方式提供AI软件研发所需要的部分代码模块，并公开说明其功能和安全风险，他人使用该代码模块导致侵权的，法院可以认定原开发者、提供者不承担侵权责任。
这里有几个不能忽视的限制条件：
以免费开源方式提供相关代码模块； 提供的是涉AI软件研发所需要的部分代码模块； 已公开说明模块的功能和安全风险； 侵权损害发生于他人使用该模块的行为； 是否免责，仍由法院结合案件事实判断。
其中最重要的是“可以认定”，而不是“应当认定”。
免费开源、功能披露和风险说明，为适当免责提供了重要依据，但不是不经审查即可适用的绝对免责条款。
03｜开源软件免费使用，不等于放弃知识产权
理解第十三条，首先需要明确开源软件的法律基础。
开源软件通常仍然受到著作权法保护。
所谓开源，并不是开发者放弃全部著作权，而是权利人通过特定许可协议，允许其他人在约定条件下使用、复制、修改或者分发软件。
因此，企业能否合法使用开源代码，需要回到具体许可协议。
MIT、Apache 2.0等宽松型许可证
这类许可证通常允许较广泛的使用、修改和商业分发。
但仍然可能要求保留著作权声明、许可证文本或者其他必要信息。
例如，Apache License 2.0还涉及专利许可、修改声明和NOTICE文件等问题。
因此，使用宽松许可证的软件，不意味着可以删除全部版权信息后作为完全自主开发的代码对外发布。
GPL、AGPL等具有较强共享要求的许可证
这类许可证在特定传播或者网络服务场景下，可能触发相应的源代码提供义务。
例如，GPL许可下的软件在满足相关条件的分发场景中，可能要求按照许可证规定提供相应源代码。
AGPL则对特定网络交互场景设置了额外要求。
但必须注意：
不能简单认为，只要商业软件使用了GPL组件，整个软件就必然需要开源。
具体判断取决于许可证版本、组件之间的结合方式、是否形成相关衍生或组合作品，以及是否触发许可证规定的义务。
AI模型许可证与传统开源软件许可证不能完全混同
在人工智能领域，还需要区分软件源代码、模型权重、训练数据和生成内容。
一个模型项目可能公开源代码，却没有开放训练数据。
也可能公开模型权重，但附加特定商业用途限制。
还有一些项目虽然被行业习惯性称为“开源模型”，但其许可条件未必符合严格意义上的开源软件定义。
因此，企业不能仅凭项目页面上的“Open Source”或者“Open Model”标签，就推定全部模型资产都可以不受限制地商用。
第十三条主要讨论涉AI开源软件相关方的侵权责任，不能直接将其扩展为所有开放权重模型、训练数据和生成内容的统一免责规则。
04｜开源许可协议，是责任判断的重要起点
第十三条明确将开源许可协议类型及权利限制的具体内容列为考量因素。
这说明，开源许可不是一个纯粹的技术社区约定，而是具有法律意义的授权安排。
例如，某企业使用第三方开源组件开发商业AI软件。
如果企业在许可证允许的范围内使用、修改和分发相关代码，通常具有相应授权基础。
但如果企业违反了适用的许可条件，就需要进一步分析其行为是否超出了授权范围，以及是否构成著作权侵权或者其他法律责任。
这里需要区分两个问题。
违反许可证，并不必然等于所有情形下都构成著作权侵权
有些许可条件直接关系到著作权授权范围。
违反这些条件，可能使相关复制、修改或者分发行为失去许可基础。
另一些争议则可能涉及合同义务或者其他法律关系。
究竟适用著作权侵权责任、合同责任还是其他规则，需要结合许可证条款性质及具体行为判断。
许可证中的免责声明，也不能排除所有法定责任
不少开源许可证包含不提供担保、限制责任等条款。
但这些条款的效力及适用范围，仍然受到相关法律规定约束。
不能因为许可证写有“按现状提供”，就认为开发者对任何侵权行为都不承担责任。
第十三条之所以特别规定免费开源代码提供者的责任豁免条件，恰恰说明免责需要结合具体法律关系和案件事实判断。
05｜免费开源代码提供者免责，关键在于功能披露与风险说明
第十三条最值得深入研究的，是对免费开源代码提供者的特殊规定。
最高人民法院在《意见》的理解与适用文章中进一步说明，免费开源代码提供者通常不从代码模块的提供行为中获利，对下游使用者如何使用相关代码也往往缺乏控制能力。
因此，应当根据权责对等、责任与控制能力相匹配的原则，合理确定其注意义务。
但这里的免责并不是没有条件的。
第一，是否真正属于免费开源
需要关注开发者或者提供者是否从代码模块的提供行为中获利。
例如，一个开发者将通用算法模块免费发布到公开代码仓库，与一家企业以商业化方式提供相关软件服务，并不是完全相同的法律场景。
不能仅凭代码仓库可以免费访问，就当然认定相关主体符合第十三条的特定免责条件。
第二，是否公开说明功能
开发者需要合理说明代码模块能够实现什么功能，以及相关功能的适用范围。
例如，一个图像识别模块可能适用于特定图像质量、硬件环境或者运行条件。
如果开发者对这些边界已有明确认识，适当披露有助于下游使用者正确理解模块能力。
第三，是否公开说明安全风险
对于可能涉及人身安全、财产安全、信息安全或者其他风险的代码模块，安全风险说明可能直接影响责任评价。
例如，某开源AI组件仅用于研究测试，并不具备生产环境所需的安全控制能力。
开发者已经明确说明相关风险，而下游企业仍将其直接部署到高风险商业场景。
在符合第十三条其他条件的情况下，这种风险披露可能成为判断原开发者是否应承担侵权责任的重要因素。
但反过来，开发者仅写一句“使用风险自负”，也不当然等于已经充分履行信息披露义务。
信息披露的价值，在于让下游使用者合理理解模块功能及已知风险，而不是通过一句免责声明转移全部法律责任。
06｜从技术架构看，开源软件的责任链条并不等于代码依赖链条
一套AI应用可能采用如下技术架构：
开源基础框架 → 第三方算法组件 → 企业二次开发 → 模型部署 → API服务 → 最终业务应用
在这一架构中，最初的开源代码可能经过多次修改、封装和集成。
不同主体对最终产品的控制能力并不相同。
基础开源框架
例如，企业使用某个开源深度学习框架进行模型训练。
框架提供通用计算能力，但通常不直接决定企业训练数据的来源、模型输出内容或者最终业务用途。
如果企业后续利用该框架实施侵权行为，不能仅因存在技术依赖关系，就当然要求框架开发者承担责任。
第三方算法组件
例如，企业使用开源图像处理、语音识别或者自动化控制模块。
需要分析模块本身的功能、许可条件、风险说明，以及被诉侵权行为是否与模块开发者的行为有关。
企业二次开发
企业可能修改原有代码，增加新的业务逻辑、接口和数据处理功能。
此时，企业已经不仅是被动使用者，还可能成为后续开发者和提供者。
如果侵权行为与新增功能有关，不能简单将责任转移给上游开源社区。
商业部署与运营
企业将软件部署为SaaS平台或者通过API向客户提供服务。
这一阶段可能涉及新的数据处理、用户行为管理、内容生成和商业传播活动。
这些行为是否侵权，需要结合实际服务模式分别评价。
由此可以得出一个重要结论：
软件依赖关系说明代码从哪里来，侵权责任关系则需要说明谁实施了什么行为、是否存在相应责任基础，以及行为与损害之间有什么联系。
两者不能直接画等号。
07｜假设案例：开源AI组件被用于侵权系统，原开发者是否承担责任
假设某独立开发者A在公开代码仓库发布了一套免费的图像处理模块。
A在项目文档中说明了模块的主要功能、适用范围以及已知安全风险。
企业B下载该模块后进行了二次开发，并将其集成到商业化图像生成系统中。
B随后利用该系统实施侵害他人合法权益的行为，造成损害。
受害人认为，A提供的代码模块是整个系统的重要组成部分，因此要求A与B共同承担侵权责任。
这一争议不能只根据代码来源判断。
对A，需要审查免费开源及风险披露情况
A是否以免费开源方式提供代码模块？
是否公开说明相关功能和安全风险？
是否参与B的后续开发或者侵权行为？
是否对B的具体使用具有控制能力？
这些事实关系到第十三条规定的责任豁免能否适用。
如果A符合特定条件，法院可以结合案件事实认定其不承担侵权责任。
对B，需要审查其实际开发和使用行为
B是否修改了代码？
是否增加了与侵权有关的功能？
是否违反原有开源许可？
是否直接实施或者参与了被诉侵权行为？
B不能仅因为基础代码来自开源社区，就当然免除其自身依法应承担的责任。
如果A实际上参与了商业化侵权活动，结论可能不同
例如，A不仅提供通用代码模块，还实际参与了被诉侵权系统的定制开发或者运营。
此时，就不能仅凭其最初发布过免费代码，直接适用免责结论。
仍需要审查A在具体侵权行为中的实际作用。
这个案例说明：
第十三条保护的是符合条件的开源创新活动，而不是为所有参与侵权技术链条的主体提供统一免责。
08｜开源代码的知识产权风险，与软件安全风险需要分别评价
第十三条同时提到开源许可协议、安全合规举措和信息披露程度。
这容易让人产生一个误解：只要开源软件存在安全漏洞，就必然构成侵权。
实际上，软件安全风险与知识产权侵权并不是同一问题。
知识产权风险
例如，企业违反开源许可证要求，未经许可复制或者分发受著作权保护的软件代码。
这一问题主要涉及著作权授权范围及相关侵权责任。
软件安全风险
例如，某开源组件存在已知漏洞，下游企业没有采取必要措施，导致系统遭受攻击并造成损害。
这一问题可能涉及网络安全、合同义务或者其他民事责任规则。
AI应用风险
例如，企业将研究用途的开源模型组件直接用于高风险业务场景，导致系统产生不当结果。
需要结合具体损害、相关行为和适用法律判断责任。
第十三条要求关注安全合规举措和风险披露，并不意味着所有安全问题都被统一纳入著作权侵权责任。
更合理的理解是：
安全合规和信息披露，可以帮助评价相关主体是否履行合理注意义务，以及是否具备适当免责的事实基础。
但具体责任类型仍然需要根据案件事实和适用法律确定。
09｜企业使用开源AI软件，应当建立可追溯的组件治理机制
对企业而言，开源合规不能只依靠研发人员在代码仓库中查看许可证。
特别是AI应用通常依赖大量第三方组件，直接依赖之外还可能存在多层间接依赖。
企业需要建立覆盖软件引入、开发、部署和交付的管理机制。
建立开源组件清单
记录所使用组件的名称、来源、版本、许可证和使用位置。
对于重要系统，可以采用软件物料清单（SBOM）等方式管理组件依赖关系。
但SBOM只是识别组件及依赖关系的工具，不能自动完成法律合规判断。
建立许可证审查机制
在引入开源组件时，确认许可证允许的使用、修改、分发和商业化方式。
对GPL、AGPL等许可证，应结合实际软件架构和分发模式开展针对性审查。
对AI模型，还需要分别核查源代码、模型权重和数据集的许可条件。
建立版本与修改记录
保存开源组件的原始来源、引入版本、主要修改内容和更新记录。
这不仅有利于技术维护，也有助于纠纷发生后说明哪些功能来自原项目、哪些功能由企业自行开发。
建立安全风险评估机制
关注开源项目披露的安全风险、已知漏洞和适用限制。
企业将开源组件部署到生产环境前，应根据业务风险采取必要的测试和安全控制措施。
建立对外分发与交付审查
企业将软件交付客户、嵌入设备或者提供网络服务时，应当审查是否触发相应的许可证义务。
对于需要提供许可证文本、著作权声明或者源代码的情形，应依法依约履行。
建立开源贡献和信息披露规范
企业不仅可能使用开源代码，也可能将内部开发的部分组件对外开源。
此时，应当明确开源范围、知识产权归属、许可协议、功能说明和已知安全风险。
特别是对外发布AI算法模块，应当根据实际情况说明适用边界和相关风险。
开源治理的目标不是减少使用开源软件，而是使组件来源、许可条件、技术修改和风险披露具备可追溯性。
10｜建立开源AI软件侵权责任的五层分析框架
结合第十三条，可以将涉AI开源软件侵权责任分析整理为五个层次。
这是一套实务研究方法，并非最高人民法院规定的统一五步裁判程序。
第一层：权利与许可
确认争议代码是否受到相应知识产权保护，以及适用什么开源许可证。
明确许可证授权范围、限制条件和相关义务。
第二层：主体与行为
确认原开发者、原提供者、后续开发者、后续提供者分别实施了什么行为。
区分代码发布、修改、分发、集成、部署和商业运营。
第三层：侵权构成
判断被诉行为是否符合相应侵权责任的法律构成。
不能仅凭代码被使用，就推定原开发者实施了侵权行为。
第四层：免责条件
对主张适用第十三条特定责任豁免的主体，审查是否免费开源、是否提供部分代码模块、是否公开说明功能和安全风险，以及其他相关事实。
第五层：证据与责任
结合许可证、代码版本、修改记录、功能文档、风险说明和相关行为证据，依法确定各方责任。
这一框架的价值，在于把软件工程中的依赖关系，转化为法律上可以审查的具体事实。
技术链条可以很长，但法律责任必须建立在具体行为和相应法律依据之上。
11｜进一步判断：开源AI治理正在从许可证管理延伸到责任边界管理
过去，企业讨论开源软件合规，通常集中于许可证义务。
例如，是否需要保留版权声明、是否需要提供源代码、是否允许商业使用。
这些问题仍然重要。
但在AI技术广泛应用后，开源软件的使用方式发生了变化。
一个基础代码模块可能被集成到不同模型、不同产品和不同业务场景中。
原开发者通常无法控制所有下游用途。
与此同时，下游企业可能通过二次开发和商业运营，对最终系统具有更强的控制能力。
第十三条强调综合考量开源许可、安全合规、信息披露，并对符合条件的免费开源代码提供者给予适当责任豁免，体现了对这一技术现实的回应。
从司法角度看，责任认定需要避免两个极端。
一是因为下游系统发生侵权，就无限追溯上游开源贡献者。
二是因为代码以开源方式提供，就排除所有开发者和提供者可能承担的法律责任。
从企业治理角度看，开源合规也需要从单纯的许可证检查，延伸到组件来源管理、修改记录、安全评估和对外信息披露。
但这种延伸属于对第十三条的实务理解，不意味着最高人民法院已经建立了一套强制适用于所有AI企业的统一开源治理技术标准。
第十三条真正体现的，是让开源软件相关主体的责任与其实际行为、风险披露及控制能力相匹配。
结语
人工智能的发展离不开开源生态。
开源软件降低了技术研发门槛，也使复杂AI系统能够建立在全球开发者共同贡献的基础之上。
但开源不等于没有知识产权，免费提供代码也不意味着任何情况下都可以免责。
《意见》第十三条通过综合考量开源许可协议、安全合规举措和信息披露程度，为合理认定开源软件相关主体的侵权责任提供了司法指导。
对于开源开发者，重要的是明确许可条件、合理说明功能和安全风险。
对于使用开源软件的企业，重要的是遵守许可证、管理组件来源、控制二次开发风险，并对自身实际实施的行为负责。
保护开源创新，不是让所有参与者承担相同责任，而是让责任回到各自实际实施的行为与能够控制的风险。
