夜雨聆风随着全球人工智能产业进入爆发式增长阶段，开源已成为AI技术创新和产业落地的核心驱动力。从大语言模型Llama3、Qwen2.5到多模态模型Gemini Flash、GLM-4，从向量数据库Milvus、Chroma到AI开发框架PyTorch、TensorFlow，开源AI技术栈几乎覆盖了从底层算力到上层应用的全产业链。然而，在AI开源一片繁荣的表象之下，一场悄无声息的“许可证战争”正在席卷整个行业。
一、开源软件“先开源后闭源”的案例逐渐增多
笔者深圳王小敏律师，最近遇到一起涉开源软件“先开源后闭源”的案件。某科技公司收到MinIO公司发出的侵权告知函，指控其未经授权使用MinIO商业闭源版软件，要求支付数百万元的许可费并承担侵权赔偿责任。据该企业反映，最初在GitHub上下载使用MinIO时，该软件明确采用商业友好的Apache2.0许可证，允许自由使用、修改和再分发。然而，MinIO在2021年5月突然将许可证变更为具有强传染性的AGPLv3，并于2023年起将企业版完全转为闭源商业许可证，整个过程未对已使用企业进行有效告知。
这一事件并非个例。在传统软件领域，Grafana于2021年4月将核心项目从Apache2.0变更为AGPLv3；Elastic多次变更许可证并在2024年9月增加AGPLv3选项；Redis从BSD许可证先后变更为SSPL和AGPLv3；罗盒公司的VirtualApp软件更是直接从GPLv3转为完全闭源商业版，并以此为由起诉多家企业获得胜诉。
随着AI模型训练成本的指数级上升和商业变现压力的加剧，越来越多的AI开源项目方开始效仿传统软件行业的“先开源后闭源”商业模式，在项目初期采用宽松的Apache2.0、MIT许可证快速抢占市场、积累用户，待形成技术壁垒和用户粘性后，突然变更为具有强传染性的AGPLv3、SSPL甚至完全闭源的商业许可证。例如，Cohere 的新一代基础模型已转向闭源 API 模式，不再走传统开源路线；而 Meta 在发布 Llama 4 时也通过设置极高的用户规模门槛（MAU月活用户超 7 亿），实质上限制了超大型商业应用的自由使用。
因此，无论是传统软件还是AI模型，开源都不再是企业可以放心享用的“免费午餐”。对于广大使用方而言，如何识别和防范此类“变脸”风险，以及在遭遇侵权索赔时如何有效应对，已成为企业AI合规管理中亟待解决的重要问题。
二、开源软件使用方普遍存在的合规盲区
（一）认知误区：将“开源”等同于“免费商用”
绝大多数企业在使用开源软件和AI模型时，都存在一个根本性的认知错误：认为只要是开源软件就可以免费用于商业目的。事实上，开源软件的“开放”仅指源代码或模型权重的可获取性，而非使用权限的无限制。不同的开源许可证对商业使用、修改、再分发等行为有着截然不同的规定：
（1）宽松型许可证（MIT、BSD、Apache2.0）：允许商业使用、修改和闭源再分发，仅需保留原版权声明和许可证文本
（2）弱传染性许可证（LGPL、MPL）：允许以库的形式被闭源软件调用，但对库本身的修改必须开源
（3）强传染性许可证（GPL、AGPL、SSPL）：任何基于该软件的衍生作品都必须以相同许可证开源，AGPL还增加了网络使用条款
（4）AI专用许可证（Llama许可证、Qwen许可证）：通常对商业使用设置收入门槛、用户数量限制或其他特殊条件
（二）缺乏持续的许可证变更监控机制
企业在引入开源软件或AI模型时，通常只会核查当时的许可证条款，而不会建立持续的监控机制。然而，开源项目的许可证并非一成不变。项目方有权在后续版本中变更许可证，且这种变更在法律上通常是有效的：
（1）对于宽松型许可证（如Apache2.0），项目方完全有权将后续版本变更为任何其他许可证，包括商业闭源许可证
（2）对于Copyleft许可证（如GPL），项目方若拥有全部代码的著作权，也有权变更许可证
（3）许可证变更仅对变更后发布的版本有效，变更前的版本仍受原许可证约束
对于AI模型而言，许可证变更的风险更高。AI模型的迭代速度远快于传统软件，企业为了获得更好的性能往往会频繁升级模型版本，这使得企业更容易在不知不觉中使用了许可证已变更的版本。
（三）对AGPL等强传染性许可证的风险认识不足
AGPLv3许可证被称为“商业软件杀手”，其第13条“远程网络交互”条款规定：如果您修改了程序，您修改后的版本必须显著地向所有通过计算机网络与之远程交互的用户提供完整的对应源代码。这意味着：
（1）即使企业只是将AGPL软件作为内部服务使用，只要有员工通过网络访问，就可能触发开源义务
（2）即使企业没有修改AGPL软件，只是将其作为服务提供给客户，也必须公开自己的全部源代码
（3）对于SaaS企业和AI服务提供商而言，使用任何AGPL软件都可能导致整个产品被迫开源
在AI领域，AGPL许可证的传染性问题更加复杂。目前司法实践中对于“基于AI模型的衍生作品”的界定尚未形成统一标准，微调后的模型是否属于衍生作品、是否需要开源，存在很大的法律不确定性。
（四）没有建立完善的开源软件资产管理体系
多数企业没有建立专门的开源软件资产清单，无法准确掌握公司内部使用了哪些开源软件、具体版本号、对应的许可证类型以及使用范围。当开源项目变更许可证时，企业无法快速评估影响范围和风险程度，只能被动等待侵权告知函的到来。
对于AI模型而言，资产管理的难度更大。AI模型的使用方式更加灵活，可能被嵌入到不同的产品和服务中，也可能被多个团队同时使用和修改。如果没有统一的资产管理体系，企业很容易出现“影子AI”问题，即未经合规审查的AI模型被用于核心业务。
三、构建开源软件专项合规管理体系
针对上述潜在的风险漏洞，建议企业构建自己的开源软件合规使用管理体系：
（一）建立开源软件准入审查机制
企业应在技术选型阶段就引入法律合规审查，建立“先审查后使用”的制度：
1、许可证分级管理：
结合相关实务，建议将开源许可证分为如下三个风险等级：
（1）绿色许可（MIT、BSD、Apache2.0）：可自由使用，仅需履行基本的署名义务
（2）黄色许可（LGPL、MPL、大多数AI专用许可证）：限制使用，需评估商业使用条件并采取隔离措施
（3）红色许可（GPL、AGPL、SSPL）：原则上禁止或避免使用，确需使用的需经法务和技术负责人双重审批
2、项目健康度评估：除许可证外，还应评估项目的社区活跃度、贡献者结构、商业支持情况以及历史许可证变更记录。对于由单一商业公司控制的项目，特别是AI模型项目，应特别警惕其未来变更许可证的可能性。
3、替代方案储备：对于每个关键开源组件和AI模型，都应提前储备至少一个采用宽松许可证的替代方案，并完成API一致性测试和性能压测，以便在原项目变更许可证时能够快速迁移或替换。
（二）部署软件成分分析（SCA）工具
SCA工具是开源合规管理的基础设施，能够自动扫描代码库中的开源组件，识别其许可证类型、版本号以及已知的安全漏洞。建议企业将SCA工具集成到CI/CD流水线中，实现：（1）提交代码时自动扫描，阻止引入高风险许可证的组件；（2）定期全量扫描，生成开源软件资产清单或SBOM；（3）实时监控开源项目的许可证变更和安全漏洞信息；（4）自动生成合规报告，满足审计要求。
对于AI模型，企业还应部署专门的AI模型资产管理工具，跟踪模型的来源、版本、许可证、使用范围和修改记录。
（三）采用技术手段隔离高风险组件
对于确需使用的高风险许可证组件，建议采用技术手段将其与企业自有代码进行隔离，避免触发许可证的传染性：
（1）微服务隔离：将AGPL组件或AI模型封装为独立的微服务，通过标准的RESTful API与其他服务进行通信。只要两个服务之间通过网络进行通信，且没有共享内存空间，通常不会被视为衍生作品。
（2）进程隔离：将高风险组件作为独立进程运行，通过管道、套接字等方式与主程序进行通信。
（3）插件化设计：将高风险组件设计为可选插件，用户可以选择是否安装和使用该插件。
但需强调的是，隔离的有效性依赖于具体实现，若服务间存在深层数据耦合或共享内存，仍可能被认定为衍生作品。
（四）签订商业许可协议锁定授权
对于核心业务依赖的开源软件和AI模型，建议直接与项目方签订商业许可协议，明确授权范围、使用期限、服务级别以及许可证变更条款。商业许可通常会豁免AGPL等许可证的开源义务，并提供官方技术支持和法律赔偿保障。
在签订商业许可协议时，应特别注意加入“许可证冻结”等条款，约定在协议有效期内，即使项目方变更了开源许可证，企业仍有权按照原许可证条款继续使用已获取的软件版本和模型权重。
四、收到开源软件侵权索赔函后该怎么办？
当企业收到开源软件商的侵权函件时，切勿恐慌，更不要盲目承认侵权或支付费用。建议按照以下步骤冷静处理：
第一步：立即启动应急响应机制
1、成立专项工作组：由法务、技术、业务和管理层组成专项工作组，统一负责事件的处理。
2、证据保全：立即对公司内部使用的涉案软件版本、下载时间、使用范围、代码修改情况等进行取证保全。
3、信息隔离：禁止任何员工在未经授权的情况下与对方进行沟通，避免因不当言论自陷困境。
第二步：全面核查对方的权利基础
收到侵权函后，首先要核查对方是否拥有合法的权利基础：
1、著作权归属核查：尽可能要求对方提供完整的著作权权属证明，包括软件著作权登记证书、原始开发文档、贡献者CLA协议等。如果项目接受过外部贡献且未签署CLA，项目方可能无权单方面变更许可证。
2、许可证变更合法性核查：核查许可证变更的时间点和具体版本号；确认企业使用的版本是在许可证变更前还是变更后发布的；核查原许可证是否允许项目方单方面变更后续版本的许可证等
3、权利有效期核查：确认对方主张的著作权是否在保护期内，是否存在权利终止或无效的情形。
第三步：客观评估自身行为的合规性
在核查对方权利基础的同时，应客观评估企业自身的使用行为是否符合许可证要求：
1、版本对应性分析：明确企业实际使用的软件版本号，以及该版本对应的原始许可证。如果使用的是许可证变更前发布的Apache2.0版本，则完全不受后续AGPLv3许可证的约束。
2、使用方式分析：比如，是直接使用二进制文件/模型权重还是进行了二次开发/微调？是内部使用还是作为服务提供给第三方？是否对软件/模型进行了修改和再分发？是否履行了原许可证要求的义务（如保留版权声明、公开修改部分等）？
3、衍生作品认定分析：结合技术架构和通信方式，分析企业的产品是否构成涉案软件的衍生作品。如果采用了微服务隔离、进程隔离等技术手段，通常不构成衍生作品。
第四步：制定针对性的应对策略
基于上述核查和评估结果，制定针对性的应对策略：
评估结果 | 建议应对策略 | 具体措施 |
对方权利基础存在瑕疵 | 积极抗辩 | 回函指出对方权利瑕疵，要求其撤回侵权指控；必要时提起确认不侵权之诉 |
企业使用的是变更前的版本 | 不侵权抗辩 | 提供下载时间和版本号证明，明确主张适用原许可证条款 |
企业使用方式不触发开源义务 | 不侵权抗辩 | 提供技术架构证明，说明不构成衍生作品 |
侵权可能性较大但对方索赔过高 | 谈判和解 | 争取以合理价格获得商业许可；要求对方豁免历史使用责任 |
对方恶意维权或敲诈勒索 | 法律反击 | 收集对方恶意维权的证据，向市场监管部门投诉或提起不正当竞争诉讼 |
第五步：实施技术整改措施
无论采取何种法律应对策略，都应同时启动技术整改工作，降低潜在的法律风险：
1、版本回退：如果可能，将涉案软件或模型回退到许可证变更前的最后一个稳定版本。
2、技术隔离：对仍在使用的高风险版本实施技术隔离，避免触发许可证传染性。
3、替代迁移：制定详细的迁移计划，逐步将业务切换到提前储备的替代方案。
4、全面审计：对公司所有开源软件和AI模型使用情况进行全面审计，排查其他潜在的合规风险。
五、一旦被诉侵权该如何有效抗辩？
在与开源软件商的民事诉讼纠纷中，建议企业可以从以下几个方面提出抗辩：
（一）许可证变更不具有溯及力抗辩
这是企业最有力的抗辩理由。根据合同法的基本原则，合同的变更仅对变更后发生的行为有效，不具有溯及既往的效力。开源许可证本质上是著作权人与使用人之间的合同关系。因此，企业在许可证变更前已经下载和使用的软件版本和模型权重，仍受原许可证条款的约束；项目方无权要求企业按照变更后的许可证条款履行义务；企业有权继续按照原许可证条款使用已获取的软件版本和模型权重。
最高人民法院在(2021)最高法知民终2063号（即“罗盒公司诉风灵公司”VirtualApp 案）判决中明确指出：只要后续版本中有使用先前开源版本中的源代码，并且先前版本使用了GPL3.0协议，则后续版本也必然受GPL3.0协议的约束。这一判决虽然是针对GPL协议的，但也可以供其他开源许可证的变更情形参考或借鉴。
（二）不构成衍生作品抗辩
AGPL等强传染性许可证的适用前提是企业的产品构成涉案软件的衍生作品。根据我国著作权法理论和司法实践，以下情形通常不构成衍生作品：
1、独立程序通过标准接口通信：如果两个程序是独立的可执行文件，通过标准的API、网络协议或进程间通信机制进行交互，通常不构成衍生作品。
2、聚合而非修改：仅仅将多个独立的程序聚合在一起分发，而没有对每个程序本身进行修改，不构成衍生作品。
3、功能性使用：仅仅使用软件提供的功能，而没有复制或修改软件的源代码，不构成衍生作品。
对于AI模型而言，目前实务中普遍认为，仅仅使用开源模型进行推理而不进行微调，通常不构成衍生作品。对于微调后的模型是否构成衍生作品，需要结合微调的程度、使用的数据量以及对原模型的依赖程度等因素综合判断。
（三）合理使用抗辩
根据我国《著作权法》第二十四条的规定，为个人学习、研究或者欣赏，使用他人已经发表的作品；为学校课堂教学或者科学研究，翻译、改编、汇编、播放或者少量复制已经发表的作品，供教学或者科研人员使用，可以不经著作权人许可，不向其支付报酬。
如果企业使用开源软件或AI模型仅是为了内部研发和测试，而没有将其用于商业产品或对外提供服务，可以主张合理使用抗辩。
（四）权利瑕疵抗辩
如果开源项目存在以下情形，企业可以主张对方的权利存在瑕疵：
1、项目方未获得全部贡献者的同意就变更了许可证；
2、项目本身包含了其他开源项目的代码，且未遵守相应的许可证条款；
3、项目方在变更许可证时存在欺诈、胁迫或重大误解等情形。
总结
在开源软件和AI模型已经成为现代软件开发和人工智能产业基础设施的今天，开源合规不再是可有可无的“锦上添花”，而是企业必须面对的“合规大考”。对于企业而言，应当摒弃“开源即免费”的错误认知，建立健全开源软件和AI模型合规管理体系，在遭遇相关侵权索赔时冷静应对、依法维权。
同时，笔者也呼吁开源社区和项目方能够更加透明、负责任地进行许可证变更，事先充分告知用户拟变更的内容和影响，给予用户足够的时间进行调整和迁移。只有在项目方和使用方之间建立起互信互利的关系，开源生态才能健康、可持续地发展下去。
声明：
Disclaimer:
本文仅代表作者个人观点，不视为正式法律意见或建议。交流讨论或申请转载/加入“云端数智法”社群，请扫描下方二维码或添加微信freefly2105
The views expressed herein are solely those of the author and do not constitute formal legal advice or opinion. For discussions, reprint permissions, or to join the "Cloud Digital Intelligence Law" community, please scan the QR code below or add WeChat: freefly2105.
About Shenzhen-based Lawyer Wang Xiaomin
Lawyer Wang Xiaomin is dedicated to creating and reshaping legal value in the AI era. He positions himself as a practitioner of AI compliance, a mitigator of AI hallucinations, an advocate for AI ethics, and a guardian of AI safety.
A graduate of Southwest University of Political Science and Law—one of China's prestigious "Five Schools and Four Departments"—Wang brings a unique dual perspective from both legal practice and in-house counsel roles. He previously worked at Tencent Group and Tencent Music Entertainment Group (TME). Currently, he practices at a leading national law firm in Shenzhen.
His practice focuses on legal research and practice within the digital economy and artificial intelligence sectors, with particular expertise in intellectual property and trade secrets, data privacy and protection, AI cyberlaw, and dispute resolution.
