一、大模型开源协议的演进趋势

近年来，尤其是在中国，大模型技术的迅猛发展催生了人工智能（AI）领域的开源浪潮。与传统软件开源不同，大模型开源涉及代码、模型权重、训练数据等多种技术要素，其开源策略与协议选择呈现出独特的演进路径。

从行业现状来看，当前国内头部大模型厂商主要采用宽松型传统开源协议，但在演进路径上呈现出“从自定义协议回归标准协议”的趋势。以DeepSeek为例，其DeepSeek-R1、DeepSeek-V3-0324模型的代码和模型权重均采用MIT协议发布[1][2][3]；而此前的DeepSeek-V3原版及其他早期模型虽然代码许可采用MIT协议，但模型许可则采用基于OpenRAIL修改的DEEPSEEK LICENSE AGREEMENT自定义协议[4]。国际上，Meta的Llama系列，总体上其模型一直采用其自定义的Llama Community License体系，而非标准OSI开源协议。最新的Llama 4适用Llama 4 Community License Agreement[5]，对月活跃用户超过7亿的主体设置额外授权要求，并通过Acceptable Use Policy对违法用途及部分高风险使用场景作出限制[6]。Google的Gemma系列中，对于Gemma 4以前的模型，Gemma Terms of Use适用于其页面附录所列模型[7]；2026年3月31日发布的Gemma 4则改为采取Apache 2.0[8]。

整体而言，国内外大模型开源协议的形成了两条并行路线：一条是以MIT、Apache 2.0为代表的宽松型标准协议；另一条则是在开放代码与权重的基础上，针对模型能力、商业使用或高风险场景附加额外条件的自定义协议或双层许可安排。有意思的是，国内外的大模型企业在“开源”的具体对象上出现高度趋同：几乎所有开源项目对外开放的内容限于代码与权重，其训练数据通常仅披露来源类别、规模或处理方法，并未整体公开。只有Eleuther AI的Pythia、LLM360的K2-V2等少数模型提供接近“代码+权重+训练数据”的完全开放形态。可见，当前大模型“开源”的核心问题在于开源边界的界定：有关代码、模型权重以及训练数据应如何进入开源框架。本文将围绕开源边界问题，进一步讨论传统开源协议在大模型场景下面临的适用困境，并就大模型开源要件的重塑展开讨论。

二、开源人工智能的界定

（一）开源人工智能的分歧

关于开源AI的界定，目前主要存在两种观点。

第一种观点主张完全开源，认为为了保证可复现性，模型的每个组件都应详细记录并公开，包括代码、权重、训练数据、算法细节等全部内容。第二种观点则采取务实路线，将开源AI界定为可以直接获取并轻松、方便应用的模式，即开放代码和权重模型。在这种模式下，开发者公开模型权重和推理代码，使第三方可以部署和微调模型，但不要求公开训练数据和完整的训练过程。

开源倡议组织（Open Source Initiative, OSI）于2024年10月发布了《开源人工智能定义》（Open Source AI Definition, OSAID）1.0版本[9]，为开源AI设立了标准化的界定框架。根据OSAID的定义，开源AI系统必须允许任何人不经许可即可自由使用、研究、修改和共享该系统，并要求提供三类核心组件：一是数据信息，即关于训练数据的充分详细说明；二是代码，包括用于训练和推理的完整代码；三是参数，包含模型权重及其他配置设置，可能涵盖训练的关键中间阶段检查点及最终优化器状态。

该定义的关键争议点在于对训练数据的处理方式。OSAID并未要求开发者直接公开训练数据本身，而是要求提供“足以让熟练人员构建实质等效系统的数据信息”[10]。该定义刻意回避了训练数据公开可能涉及的知识产权及数据保护风险问题，选择以数据说明代替数据本身的公开。这一折中立场引发了广泛争议：批评者认为不要求公开训练数据实质上降低了开源标准[11]；支持者则认为这是面对数据版权复杂性的合理解决方法。目前，经过OSI验证、符合OSAID标准的模型数量相当有限[12]，业界影响力最大的“开源”模型，如Meta的Llama系列、DeepSeek系列等，均不符合OSAID的严格标准，这揭示了行业“开源”实践与开源定义之间的显著落差。

（二）兼顾透明性与可行性的开源边界

1.公开训练数据面临的多重现实障碍

公开训练数据的主张虽然在科学理想上具有吸引力，但在当前技术条件与法律环境下面临着现实障碍。

首先，大模型训练数据的规模本身构成了公开的技术壁垒。以Llama 3为例，其训练语料超过15万亿Token[13]；DeepSeek-V3的训练数据量亦达到14.8万亿Token[14]。这一数量级的数据集，其存储、传输和托管所需的基础设施成本极为高昂，对绝大多数开发者和研究机构而言并不现实。即便技术上可行，如此大规模数据集的版本管理、持续更新与一致性维护也将构成沉重的工程负担。其次，训练数据中不可避免地包含大量受版权保护的内容，直接公开将使开发者面临严重的侵权诉讼风险。事实上，在司法层面，围绕AI训练数据的版权争议已经进入密集诉讼阶段。再次，训练数据往往包含大量个人信息，完整公开将引发数据保护法律的合规风险。

2.比较法视角下“披露而非公开”路径的合理性

对于AI系统的监管，除了要求训练数据的来源合法、权利保护之外，还要求其具备真实性、准确性、客观性、多样性。因此，开源AI的训练数据达到一定的透明度，是满足监管要求的前提。值得注意的是，主要法域的立法和监管者在面对AI训练数据透明性需求时，不约而同地选择了“披露数据信息”而非“公开数据本身”的监管策略。

欧盟《人工智能法案》第53条第1款第（d）项要求通用AI模型（general-purpose AI model）的提供者起草并公开一份关于训练数据内容的“足够详细的摘要”（sufficiently detailed summary）[15]。2025年，欧盟AI办公室发布了该摘要的标准模板及填写指引[16]。这一制度设计的要义在于，通过结构化的信息披露使外部主体能够评估训练数据的合法性与质量，同时避免强制公开数据本身所引发的知识产权和隐私风险。

中国《生成式人工智能服务管理暂行办法》第19条规定，提供者应在有关部门检查时对训练数据的来源、规模、类型、标注规则、算法机制予以说明[17]。该条虽然是“监管披露”，即将训练数据信息的透明义务限定于向特定监管主体履行、以特定事由触发，而非面向社会公众的无差别公开，但可以借鉴其披露的范围以实现开源AI所需的透明性。

3.开源边界：代码、权重与可复现的训练数据说明

基于实践可行性以及法律法规管控要求，笔者认为，主张开源AI的边界应包括三个层次的开放要素：代码、权重以及可复现的训练数据说明。其中，“可复现的训练数据说明”是区别于单纯开放权重以及代码模式的关键要素。对于模型的可复现性和透明性而言，真正关键的不是获得训练数据本身的副本，而是理解数据的构成与处理方式。“可复现的训练数据说明”不要求开发者承担完整公开训练数据的法律和技术风险，但要求提供足以支撑独立评估和实质等效复现的信息基础。

三、传统开源协议在开源人工智能场景下的适用难题

（一）适用对象适配性不足

传统开源协议的设计逻辑建立在源代码是软件核心资产的前提下，开源即授权他人自由获取、修改和分发源代码。但大模型的知识载体发生了根本性转变。一个大模型至少包含四类性质截然不同的技术要素：一是训练与推理代码，即模型架构代码、训练脚本和推理框架；二是模型权重，即预训练权重、后训练权重及其量化权重，是大模型能力的真正载体；三是训练数据集，包括预训练语料、指令微调数据等；四是配套文档与评估材料，包括技术报告、模型卡和评估基准结果。

从法律性质上看，上述要素的权利基础各不相同。代码可享有软件著作权，配套文档与评估材料通常可被认定为技术文档，可以适用著作权法或商业秘密的保护框架。对于模型权重，其作为参数文件或机器学习产物，其法律属性在理论与实务中均存在重大争议，其是否可被界定为作品、数据库或其他受保护客体，尚无定论，实践中虽常通过合同方式安排其许可与使用，但这并不意味着其法律属性已经得到明确。在训练数据方面，传统开源许可证脱胎于源代码的开放共享实践，其制度设计本身并未将训练数据纳入考量，存在先天性的制度空白。

可见，传统开源协议仅能覆盖代码层面的软件著作权开源问题，而大模型各技术要素的法律属性不同、权利来源不同、风险特征不同。采用著作权法体系下的传统开源许可证进行授权存在适配错位问题。

（二）开源AI场景下“衍生作品”认定的体系性困境

在传统开源场景下，衍生作品的界定是为了划定开源义务，尤其是许可义务向下游传导的边界。一旦下游作品被认定为原始开源作品的衍生作品，则通常触发相应的开源许可义务。但开源AI场景下，传统开源场景下“衍生作品”规则面临双重适用困难：一方面，开源AI的核心技术要素，特别是模型权重，是否能够被认定为著作权法意义上的“作品”存在争议；另一方面，开源模型的改进方式与传统软件存在本质差异，传统软件的改进直接作用于代码文本，而对开源AI模型的改进可能完全不涉及代码层面的变动，改进的载体由代码转变为数据与权重。上述原因都将导致传统开源“衍生作品”规则在AI开源场景下面临实质性的规则缺失。

1.开源AI的技术要素难以全部界定为“作品”

讨论是否构成开源标的之“衍生作品”的起点是开源标的本身应构成作品。如上分析，开源大模型中的模型权重、训练数据等技术要素的法律属性存在较大争议。在中国著作权法项下，“作品”通常要求系自然人基于智力活动创作形成的成果，并同时具备独创性以及能够以一定形式表现的特征。就模型权重而言，其本质是通过算法在海量数据训练过程中形成的参数集合，表现为大量数值化、结构化的技术结果，而非传统意义上由人直接完成并体现个性化表达的内容。在全国首例AI模型侵权案[18]中，法院就认为，模型训练阶段中优化模型结构和参数的行为属于为变身漫画成像创造生成工具的行为，非著作权法意义上的创作行为。在GEMA诉OpenAI案中，慕尼黑法院判决未采纳OpenAI主张的“模型并未‘存储’特定数据，而仅反映统计关联关系”的观点，法院认为，模型对训练数据的“记忆”构成版权意义上的复制行为[19]。在实质上，德国法院认可在特定条件下（即模型可近乎逐字再现原作的情况下），模型权重对受保护表达的储存行为构成版权法意义上的复制。美国版权局《版权与人工智能》报告第三部分有关生成式AI训练的内容也指出，若模型权重保留了或者记忆了作品的大量可保护表达，则模型权重可能触及作品衍生权。[20]

可见，模型权重是否能够被认定为著作权法意义上的“作品”或训练数据的“衍生作品”，在现行法及实践下存在较大不确定性。同时，训练数据的构成也较为复杂，其既可能包含受著作权保护的作品，也可能包含事实、公共领域内容或者其他不受著作权法保护的要素，难以作出一体化、概括性的“作品”认定。因此，开源AI所涉及的技术客体并不能像传统开源软件中的源代码那样，当然地整体纳入著作权法中“作品”框架，这也使得以著作权客体为核心展开的传统开源协议解释路径，在开源AI语境下面临适用困难。

2.开源AI场景下“衍生性”的判断与传统协议存在差异

在著作权法框架下,“衍生性”主要指“对原始表达进行创作性改编”。在传统软件中，改编通常表现为对原有源代码进行增删、重写或与其他代码合并，因此容易采用“是否基于原代码形成新的创造性表达”来判断衍生性。但大模型的微调、蒸馏、提示工程等操作，在技术层面与代码修改存在本质差异，直接套用现有规则将导致严重的适用困境。例如，对开源权重进行参数微调，是否构成传统协议下的“衍生”？通过知识蒸馏训练出的小模型，与原始权重在文件层面毫无关联，开源义务又该如何追溯？开源社区曾尝试应对这一挑战，例如在OSI讨论论坛上，有提案尝试定义“Derivative Materials”概念以覆盖知识蒸馏场景，但社区对其法律可执行性存在严重分歧[21]。在实践中，Meta的Llama 4社区许可协议试图通过合同条款来解决这一问题，其明确规定“使用Llama相关材料，或其任何输出、结果来创建、训练、微调或以其他方式改进一款会被分发或对外提供的AI模型，则必须在该AI模型名称的开头加入‘Llama’一词”。[22]

（三）使用场景限制的缺失

从实践需求来看，传统开源协议已无法回应AI大模型在使用场景方面的特殊伦理与安全需求。大模型具有强大的通用能力，其滥用风险远超传统软件——可被用于大规模监控、自主武器系统开发、深度伪造生成等高风险场景。然而，传统开源协议无法对下游使用场景和能力施加限制。因此，行业中已出现大量附带使用场景限制的自定义协议，如Meta的Llama系列通过Acceptable Use Policy禁止将模型用于军事用途、暴力犯罪策划等场景。这表明，AI开源社区已经意识到纯粹的“无条件开放”模式不适用于大模型。

四、大模型场景下的开源要件思考

（一）分层许可结构与衍生模型认定

基于大模型开源的边界要求，大模型开源范围至少应当包括代码、权重及训练数据说明等技术要素，故可建立分层许可结构，对代码、权重、训练数据以及配套文档等要素分别设立独立条款。具体而言，代码层可以沿用宽松型开源许可证，因为代码本身不直接承载模型能力，风险相对可控。权重层则需要引入更严格的使用条件，包括场景限制、安全义务和再分发规则。由于权利来源复杂，训练数据层应设置专门的开源声明要求，而非简单地以开源方式授权。这种分层设计，既能实现代码层面的充分开放，又能对真正承载风险的权重和数据加以合理规制。

在衍生模型认定方面，应摒弃“是否为衍生作品”的二元判断框架，考虑采用“实质性影响测试”作为触发开源义务的标准：如果衍生（下游）模型的核心功能或能力在实质程度上依赖于原始开源模型的权重、架构或训练成果，则应触发开源义务。这观点的依据在于，开源协议的制度目的是确保开源成果的延续性和可追溯性，其义务传导应以对原始贡献的实际利用程度为标尺，而非以著作权法意义上的 “修改”为判断标准；参数层面的直接依赖触发完整开源义务，能力层面的间接依赖触发较轻的披露和声明义务。例如，在继续预训练和全参数监督微调时，下游模型参数实质性地源自原始权重，应认定为衍生权重，触发开源或声明义务；在参数高效微调（如LoRA）时，附加参数在推理时与基模权重矩阵合并，构成参数层面的依赖，应触发开源义务；知识蒸馏属于间接影响，产物在参数层面与原始模型无直接关联，但原始模型输出被内化为蒸馏模型自身能力，至少需披露蒸馏来源并保留原始许可声明；对于RAG集成和API封装，原始权重既未被修改也未被内化，一般不触发开源义务。

（二）训练数据的权利披露与处理方案

传统开源协议在训练数据权利处理方面存在根本性缺失。面对这一制度真空，大模型的开源应对思路不是要求开发者对训练数据做出权利担保，而是通过披露机制将瑕疵风险显性化，建立合理的责任隔离规则。大模型的开源要件中应要求发布者随模型权重提供标准化的“数据开源声明”，内容包括数据来源类别（网络抓取、授权数据集、合成数据等）、已知权利瑕疵的如实告知（是否包含可能受版权保护的内容、是否包含个人信息），以及对下游用户的明确风险提示。

同时，还可以考虑确立风险分配原则。例如，发布者通过数据开源声明如实披露已知瑕疵后，因其未披露的权利瑕疵产生的第三方索赔，由发布者自行承担；下游用户在合理信赖开源声明的前提下使用模型，若因发布者故意隐瞒已知瑕疵而受到追索，有权向发布者追偿；而对于声明中已明确披露的风险，则由下游用户自行评估并承担使用后果。此外，还可考虑设置隐私合规条款，明确因训练数据含有个人信息而产生的数据主体权利请求的处理机制，例如，由数据的实际控制方负责响应，并设计开源上下游链条的通知配合等处理方式。

（三）大模型价值链的整体责任分配机制

有关开源软件的侵权问题，传统开源协议的标准做法是“按原样提供”[23]。这在传统软件时代基本可行，因为软件的功能边界相对明确，使用者对软件行为具有较高的可预见性和控制力。但大模型的输出具有直接影响现实应用场景的能力，其行为具有概率性、不可完全预见性，而且其价值链涉及多个主体，责任不能简单地全部推给使用者。

广州互联网法院审理的“奥特曼案”中，被告以“AI绘画功能是通过第三方服务商实现的，与被告无关”以及“被诉图片为原告主动制作生成”并以不存在直接获利证据等为由提出不侵权抗辩。而最终法院根据《生成式人工智能服务管理暂行办法》第22条第2款认定被告为“生成式AI服务提供者”，应当履行法定义务，即不得侵害他人依法享有的知识产权。此外，该案还从投诉举报机制欠缺、潜在风险提示欠缺、显著标识欠缺等角度论证被告具有主观上的过错，需要承担相应的赔偿。而在杭州互联网法院审理的“杭互奥特曼案”中，法院认定平台不是网络传播内容的提供者，未直接实施受信息网络传播权控制的行为，不构成直接侵权，但平台因未尽合理注意义务，主观上存在过错，应承担帮助侵权的间接侵权责任[24]。

上述案件的核心借鉴价值在于，法院已在实践中探索出“分类分层分别界定侵权责任”的裁判方法，即不是笼统地将责任归结于单一主体，而是根据各方在侵权链条中的具体行为和过错程度分别认定责任。基于上述司法实践的启示，大模型的开源要件应包含参与大模型价值链的各类主体作出清晰的角色定义：

1)原始开发者：完成预训练并首次发布权重的主体；

2)微调者：基于开源权重进行微调并再次发布的主体；

3)部署者：将模型集成于产品并向终端用户提供服务的主体；

4)终端用户：实际使用模型能力的自然人或组织。

在角色定义基础上，可以考虑对各方的核心义务可以考虑作出分项规定：

1)基础安全评估方面，原始开发者负主要责任，须在发布前完成基线安全测试；微调者须针对微调引入的新能力进行增量评估；部署者须针对具体应用场景进行适用性评估。

2)数据权利披露方面，由原始开发者承担主要责任，提供训练数据来源声明；微调者仅需披露微调数据来源即可。

3)有害输出治理方面，原始开发者须提供基础安全护栏并披露已知风险；微调者不得主动削弱原始安全护栏；部署者应对面向用户的实际输出承担主要责任。

4)监管合规方面，部署者承担属地监管合规的主体义务；原始开发者和微调者须提供必要的合规支持文档。

基于以上分析，需建立不同角色的责任分配机制：若部署者因原始开发者故意隐瞒的已知安全缺陷而遭受损害，有权向原始开发者追偿；若微调者明知原始权重存在特定安全风险，仍在高风险场景中部署且未采取防护措施，则不得就该风险向原始开发者追偿；因多方共同行为导致监管处罚的，按各方过错程度内部分担。上述责任分配框架可与主要司法管辖区的现行监管要求形成对应衔接。如中国《生成式人工智能服务管理暂行办法》第17条确立的大模型备案制度和安全评估要求[25]，这与原始开发者和微调者的基础安全评估义务相对应。欧盟《人工智能法案》中“提供者”的义务可对应协议中原始开发者和微调者的安全评估义务；“部署者”的义务可对应开源协议中部署者的属地合规要求。这种衔接既能使开源协议条款满足监管依据，也能帮助各方主体明确自身的合规责任。

小 结

大模型开源要件的重构，不仅是对许可证的技术性修订，更是对人工智能时代下“开源”制度理念的重新诠释。传统开源运动的核心精神——知识共享、协作创新、权利对等——在大模型语境下并未过时，但其实现路径必须随技术形态的根本性变革而进化。分层授权、实质性影响测试、数据披露机制与梯度责任分配，本质上是在回答同一个问题：当AI能力的载体不再是人类可读的代码，而是数以亿计的参数与海量数据的凝结，开源社区赖以运转的信任基础应当如何重建？这一问题的答案，将深刻影响未来全球AI创新生态的开放程度与治理边界。在这个意义上，新型大模型开源要件的设计，既是法律工程，也是对人工智能时代开放创新秩序的一次重要建构。

[注]

[1]参见DeepSeek-R1 GitHub仓库（https://github.com/deepseek-ai/DeepSeek-R1），明确声明“This code repository and the model weights are licensed under the MIT License”。

[2]参见DeepSeek-V3 GitHub仓库（https://github.com/deepseek-ai/DeepSeek-V3），代码部分采用MIT License。

[3]https://huggingface.co/deepseek-ai/DeepSeek-V3-0324.

[4]https://huggingface.co/deepseek-ai/DeepSeek-V3.

[5]https://github.com/meta-llama/llama-models/blob/main/models/llama4/LICENSE.

[6]https://www.llama.com/llama4/use-policy/.

[7]https://ai.google.dev/gemma/terms?

[8]https://ai.google.dev/gemma/apache_2.

[9]Open Source Initiative, “The Open Source AI Definition -- Version 1.0”, 2024年10月28日发布，参见https://opensource.org/ai/open-source-ai-definition。

[10]OSAID原文为“Sufficiently detailed information about the data used to train the system so that a skilled person can build a substantially equivalent system”。这一表述被批评为过于模糊，留有回旋余地。

[11]Lightning AI首席技术官Luca Antiga批评认为，OSAID未要求公开训练数据，留下了巨大的法律保障缺口。

[12]参见OSI官网“Open Source AI”页面（https://opensource.org/ai），列明了经验证通过的模型清单。Meta的Llama 2、X的Grok、Microsoft的Phi-2、Mistral的Mixtral均未通过验证。

[13]Meta, "Introducing Meta Llama 3: The Most Capable Openly Available LLM to Date", Meta AI Blog, April 18, 2024. 该文披露Llama 3使用了超过15万亿Token的训练数据。

[14]DeepSeek-AI, "DeepSeek-V3 Technical Report", arXiv:2412.19437, December 2024, p.5. 报告说明DeepSeek-V3的预训练语料为14.8万亿多样化、高质量Token。

[15]Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (AI Act), Art. 53(1)(d).

[16]European AI Office, "Template for a Summary about the Content Used for Training of General-Purpose AI Models", February 2025. 该模板要求提供者说明数据来源类型、收集方法、处理步骤及涉及版权和个人数据的处理措施等。https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models

[17]《生成式人工智能服务管理暂行办法》（2023年8月15日起施行）第十九条。

[18]（2023）京73民终3802号

[19]LG München I, Endurteil v. 11.11.2025 – 42 O 14139/24.慕尼黑地方法院在GEMA诉OpenAI案中逐一驳回OpenAI的技术抗辩，并认定OpenAI不符合《德国著作权法》第44b条项下文本与数据挖掘例外的适用条件.

[20]U.S. Copyright Office, Copyright and Artificial Intelligence, Part 3: Generative AI Training (Pre-Publication Version), May 9, 2025, pp.30-32。报告指出模型权重是否构成复制件或衍生作品取决于其是否“retained or memorized substantial protectable expression”。参见https://www.copyright.gov/ai/。

[21]OSI Discuss, “Distillation and OSS Licensing”, December 2025, https://discuss.opensource.org/t/distillation-and-oss-licensing/1333。该讨论尝试定义“Derivative Materials”概念以覆盖知识蒸馏场景，但社区对其法律可执行性存在严重分歧。

[22]Llama 4 Community License Agreement, 生效日为2025年4月5日，其中规定“If you use the Llama Materials or any outputs or results of the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama” at the beginning of any such AI model name”。参见https://github.com/meta-llama/llama-models/blob/main/models/llama4/LICENSE。

[23]如MIT License声明“THE SOFTWARE IS PROVIDED ‘AS IS’, WITHOUT WARRANTY OF ANY KIND”.https://mit-license.org/.

[24]杭州互联网法院（2024）浙0192民初1587号，杭州中级人民法院（2024）浙01民终10332号二审维持原判。

[25]《生成式人工智能服务管理暂行办法》第17条规定了算法备案要求；国家互联网信息办公室于2024年进一步发布了大模型备案的具体实施细则。