目 录

导言：开源问题为什么在大模型时代重新变热

过去几年，开源争议的焦点已经发生变化：法院在判断GPL条款能否执行、Copyleft效力是否扩张；Copilot诉讼在追问公开代码能否被用于训练模型；Llama、DeepSeek的差异则说明，开放权重并不等于传统开源。这些争议共同指向一个变化：开源许可正在影响权利归属、商业化路径和合规责任。

第一部分：制度底座——开源作者仍有权利，开放来自许可条件

开源软件之所以能够自由流通，并不是因为作者把版权、专利或商业控制全部交出去，而是因为作者先保有权利，再通过许可证设定他人使用、修改和分发的条件。GPL Copyleft效力、AI模型许可和企业合规，都是从这一起点展开的。

第二部分：AI变局——传统开源框架如何应对权重、数据和输出

传统开源许可的中心是源代码，而大模型的核心资产被拆成代码、权重、训练数据和输出。技术客体变了，许可协议能够覆盖的范围、权利保护的路径和下游使用的责任也随之改变。

第三部分：许可证谱系——从组件引入到产品发布，风险如何被触发

企业真正困惑的，往往不是某个许可证名称，而是同一产品链条中的具体行为：复制还是调用，修改还是原样使用，分发软件副本还是仅提供云服务，组件之间是独立组合还是形成紧密整体。GPL、AGPL、LGPL、MIT、Apache 2.0、SSPL和Elastic License，正是在这些不同触发点上给出不同答案。

第四部分：争议落地——法院和监管如何具体划定开源边界

许可证文本本身不能回答所有问题。先看美国案例，可以看到软件接口和AI训练如何把版权边界推到前台；再回到中国案例，则能看到法院如何判断GPL效力、模块独立性、权利主体和二次开发权利基础。

第五部分：商业与跨境——开源是竞争策略，也受国家监管约束

开源不是单纯的法律负担，也不是天然的公益选择。它可以用来挑战垄断、建立生态、降低采用门槛；但当技术跨境流动、模型权重公开下载、云服务全球部署时，许可证允许并不等于监管放行。

第六部分：落地治理——把开源合规从清单变成流程

企业面对开源风险，不能只在产品上线前补一份许可证清单。识别、审批、隔离、履约、留痕，以及采购、外包、并购和AI模型使用中的准入审查，都应进入常态化治理。

结语：开放与控制之间的制度重组

开源的下一阶段不是简单扩大开放，也不是重新闭源，而是在开放协作、商业控制、权利保护和监管责任之间重新设计制度边界。

摘 要

开源许可现已演变为企业布局知识产权、搭建技术生态、开拓国际市场、适配AI监管的基础制度。以往开源规则围绕源代码设立，可大模型时代权重、训练数据等已成核心资产，传统开源许可证无法适配全部场景。企业切勿混淆“开源”与免费使用、“开放权重”与传统开源，需在项目全流程审核许可权责、权属、专利、数据及出口管制风险。开源的价值不在于放弃控制，而是依托清晰规则平衡协作、商业化与责任划分。

点击可查看大图

导言：开源问题为什么在大模型时代重新变热

过去几年，开源争议的焦点已经发生变化：法院在判断GPL条款能否执行、Copyleft效力是否扩张；Copilot诉讼在追问公开代码能否被用于训练模型；Llama、DeepSeek的差异则说明，开放权重并不等于传统开源。这些争议共同指向一个变化：开源许可正在影响权利归属、商业化路径和合规责任。

从近期争议看：为什么开源突然变成法律和商业问题

点击可查看大图

过去很长一段时间，“开源”在许多人眼里只是工程师社区的协作方式。它意味着代码可以看见，可以下载，可以修改，也可以被其他项目继续使用。法务部门偶尔会在产品上线前看一眼许可证，判断是否需要保留版权声明、是否涉及GNU通用公共许可证（GNU General Public License，简称“GPL”），更多时候则把开源当作研发流程里的技术事项。

这个认知在近几年被迅速打破。

在中国，围绕GPL的司法案例已经不再停留在抽象讨论。数字天堂诉柚子案、不乱买案、罗盒系列案件、最高人民法院（2021）最高法知民终51号案，分别触及开源协议效力、GPL Copyleft（中文常译为“著佐权”或“版权左”，本文统一使用英文原文）效力边界、开源软件权利人主体资格、二次开发者权利基础等问题。这些案例共同说明：开源许可证并非单纯的社区倡议或技术协作惯例，而可能构成具有法律约束力的著作权许可或合同安排；使用者违反保留声明、提供源代码、传递相同许可等条件时，可能面临授权终止、停止侵权、赔偿损失，甚至被要求履行相应开源义务等法律后果。

与此同时，人工智能（Artificial Intelligence，简称“AI”）大模型又把开源问题推到新的层面。2025年，北京知识产权法院在亿睿科AI模型侵权案中，认定AI模型结构和参数所承载的竞争利益可以通过反不正当竞争法获得保护。法院没有简单把模型结构和参数纳入著作权作品保护，而是从投入、竞争优势、商业道德和市场秩序角度建立保护路径。这一案件提示我们：大模型时代的核心资产，未必是传统意义上的源代码，而可能是权重、参数、数据处理流程、训练方法、模型架构和工程经验。

在美国，AI代码相关诉讼则把开源代码与AI模型训练之间的紧张关系摆上台面。原告主张相关科技企业在训练代码生成模型时使用了大量公开仓库代码，模型输出又未保留版权声明和许可证信息，涉嫌违反开源许可证并触发美国《数字千年版权法》（Digital Millennium Copyright Act，简称“DMCA”）第1202条关于版权管理信息的规则。法院并未简单确认“AI训练一定合法”或“训练公开代码一定侵权”，而是要求原告提供更具体的输出实例和更明确的联系。这使案件的焦点从“模型是否接触过代码”，转向“输出是否与受保护表达存在足够具体的关系”。

在欧盟，《人工智能法案》（Artificial Intelligence Act，常称“AI Act”）一方面强调风险监管，另一方面又为免费开源AI系统留下例外空间。其逻辑并不复杂：开源有助于透明、审查和创新，如果监管过重，可能压制基础研究和社区协作。但欧盟同时设置边界，高风险AI系统、被禁止用途、深度伪造透明度义务，以及通用AI模型的部分义务，并不会因为“开源”二字完全消失。

产业层面的争议更加直接。Meta的Llama系列常被媒体称为“开源模型”，但Llama许可证并非传统开源定义下的认证开源许可证。以Llama 3.3为例，其许可文本设有署名、命名、使用政策、贸易合规、超大规模用户商业许可门槛等要求。相比之下，DeepSeek-R1的模型卡明确写明代码仓库和模型权重采用MIT License（MIT许可证），支持商业使用、修改、衍生作品和蒸馏。二者都“开放”，但开放的法律含义和商业边界并不相同。

这就是今天讨论开源许可协议的真正背景：开源不再只是“免费代码”的问题，而是知识产权配置、技术生态组织、AI治理、平台竞争和跨境合规共同交织的制度问题。

第一部分：制度底座——开源作者仍有权利，开放来自许可条件

开源软件之所以能够自由流通，并不是因为作者把版权、专利或商业控制全部交出去，而是因为作者先保有权利，再通过许可证设定他人使用、修改和分发的条件。GPL Copyleft效力、AI模型许可和企业合规，都是从这一起点展开的。

从自由软件到开源软件：许可协议为何成为制度工具

点击可查看大图

要理解今天的争议，仍需回到开源许可的历史。

早期计算机产业中，软件常常随硬件一并提供，并未作为独立商品被充分区分。1969年前后，IBM等企业开始推进软硬件分离，软件逐渐成为可以单独交易、单独授权、单独保护的商品。1980年，美国版权法修订将计算机程序纳入版权保护范围，为软件版权化提供了重要基础。

自由软件运动在这一背景下兴起。1983年，Richard Stallman发起GNU项目，希望开发一套完全自由的操作系统。1985年，自由软件基金会（Free Software Foundation，简称“FSF”）成立，系统推动“运行、研究、修改、分享”软件的四项自由。1989年，GPL v1发布，Copyleft 机制正式成型。Copyleft的英文原意带有对copyright的反向使用意味，在自由软件和开源语境中通常指利用版权许可条件，要求下游在分发修改版或衍生作品时继续传递相同开放条件；中文可译为“著佐权”或“版权左”，但本文为避免译名歧义，统一使用英文原文。其精妙之处在于，它并没有否定版权，反而利用版权：作者通过著作权排他权设定条件，要求下游在分发修改版或衍生作品时保持同样的自由。

这与“公共领域”不同。公共领域意味着权利人不再以版权控制作品；GPL则意味着权利人仍然控制作品，只是把控制方式从“禁止他人复制”改成“要求他人按开放规则复制、修改和分发”。

1998年，“Open Source”一词被提出，Open Source Initiative（简称“OSI”）成立并发布Open Source Definition（开源定义）。相比自由软件运动更强调伦理和用户自由，开源运动更强调商业可接受性、协作效率和技术创新。OSI的开源定义要求许可证满足若干标准，包括自由再发布、源代码可获得、允许衍生作品、不得歧视任何个人或群体、不得歧视任何使用领域、不得限制其他软件、技术中立等。

2000年以后，开源运动快速扩张，同时出现许可证激增问题。不同企业、项目和组织出于品牌、商业策略或特定风险控制需要，创建了大量自定义许可证。有些许可证与既有许可证差别不大，却增加了兼容性成本；有些则加入商业用途限制、云服务限制或行为限制，导致其是否仍属“开源”产生争议。OSI此后推动许可证精简，MIT、BSD、Apache 2.0、GPL、LGPL、AGPL等少数许可证逐步成为主流。

这段历史表明，开源许可并不是简单把代码“放出来”，而是在版权保护已经确立的前提下，用许可证预先安排复制、修改、分发、署名、再许可和源代码提供等事项。自由软件运动借此保障下游继续开放，商业开源借此降低协作成本、吸引企业采用；许可证选择也因此会影响一个项目能否扩散、能否被商业产品吸收，以及能否在云服务时代维持原有的价值回流。

换言之，与其把开源许可看成一套静止的授权模板，不如把它放回软件产业变化中观察：软件商品化、自由软件运动、商业开源、云计算和AI大模型，每一次变化都会把新的利益结构带入许可证文本。下面先沿着这条线索展开，再回到开源协议的法律性质和司法实践。

回到历史：开源许可协议的每一次变化，都对应一次产业结构变化

开源许可协议不仅仅是法律文本，其背后还包含软件产业组织方式、商业利益分配和技术协作边界的变化。回看开源许可的发展脉络可以发现，许可证文本的每一次重要调整，往往都不是孤立发生的，而是与软件产业结构的变化相互呼应。

第一阶段是软件商品化。早期软件随硬件提供，代码共享更像工程师之间的习惯，而不是稳定的许可制度。IBM软硬件分离之后，软件开始成为独立商品，版权法也逐步确认计算机程序可以作为作品保护。此时，软件的默认秩序逐渐从工程共享，转向以版权排他、商业授权和源代码控制为基础的分发模式。这一变化为自由软件运动的兴起提供了背景。

第二阶段是自由软件运动。GNU、FSF和GPL的出现，回应的正是限制用户运行、研究、修改和分享软件的非自由或专有软件模式。这里的“专有软件”（proprietary software）更多是自由软件和开源社区中的对照概念，并非我国成文法上的专门法律概念。GPL的价值不是“反版权”，而是改变版权的使用方式：作者仍然依靠版权设定许可条件，但目的不是排除一切后续使用，而是要求下游分发修改版或衍生作品时，把相同自由继续传给后手。它以法律强制力保护社区协作，避免开放成果被单向吸收后闭源。

第三阶段是商业开源。1998年“Open Source”概念出现后，开源不再只是一种自由软件伦理，也成为企业可接受的研发和商业策略。Linux、Apache、MySQL、Mozilla、Android等项目证明，开放源代码可以带来开发者社区、事实标准和生态扩张。MIT、BSD、Apache 2.0等宽松许可证在这一阶段广泛流行，因为它们更容易被商业公司采纳。

第四阶段是云计算冲击。SaaS和云托管使开源项目的价值捕获发生变化。云厂商可以将开源数据库、中间件、搜索引擎直接包装成托管服务，而原项目公司可能难以获得收入。SSPL、Elastic License、Business Source License等由此出现，试图堵住云服务商的“免费搭车”。但这些许可证又因限制特定商业模式而偏离传统开源定义，引发“伪开源”争议。

第五阶段是AI大模型。软件的核心价值从源代码延伸到权重、数据和算力。只开放推理代码未必足以复现模型；只开放权重未必披露训练数据；只披露模型卡，也未必足以证明训练数据已经获得授权，或充分揭示模型的安全限制和适用边界。开源许可协议原本围绕源代码设计，而大模型的“源”可能是数据、架构、训练流程、权重和评测体系的组合。OSI发布Open Source AI Definition 1.0（开源AI定义 1.0），正是试图在这一阶段重建“开源”的定义。

这里先作一个概念区分。推理代码通常是指让模型在部署环境中运行、接收输入并生成输出的程序代码，它解决的是“如何调用和执行模型”的问题；模型权重则是模型训练后形成的大量参数，集中承载模型能力，但并不当然包含训练数据、训练代码或完整训练方法；模型卡则更接近一份说明文件，用来描述模型来源、用途、限制、评测表现、许可证、训练数据摘要和安全注意事项。三者都可能出现在“开放模型”的发布材料中，但开放其中任何一项，都不能自动推出其他部分也已开放、训练数据权利已经清理完毕，或模型在特定场景下可以安全使用。

因此，今天的开源争议并不是旧问题的简单延续，而是产业结构变化带来的制度再适配。企业如果仍以传统软件时代的合规清单处理AI模型，很容易遗漏真正的风险。

开源协议的法律性质：合同、许可，还是二者兼有

围绕开源许可证的法律性质，长期存在“合同说”和“许可说”的争议。

合同说认为，开源许可证是著作权人与使用者之间通过行为达成的合同。作者公开发布软件并附加许可条款，可以被理解为向不特定公众发出的要约；使用者下载、复制、修改、分发软件，可以被理解为以行为作出承诺。使用者因此获得权利，也承担相应义务。若其违反义务，权利人可以主张违约责任；在授权终止后继续复制、分发，则可能构成著作权侵权。

许可说则强调，开源许可证首先是著作权许可。作者允许使用者在一定条件下复制、修改和分发软件。使用者若不遵守条件，结果不是“违约”，而是许可范围之外的使用，构成侵权。许可说的优势是更贴近版权法的授权结构，但在处理源代码公开、版权声明保留、许可证传递等义务时，可能不如合同说灵活。

在实践中，许多法域并不会把二者截然分开。美国联邦巡回上诉法院在Jacobsen v.Katzer案中处理的，是Artistic License下的开放源码使用争议；虽然该案并非GPL案件，但其分析路径具有参考意义：当许可证以条件性语言限定复制、修改、分发授权范围，而署名、保留许可文本、说明修改等义务又服务于开源协作和下游可得性时，违反这些条件可能使使用行为超出授权范围，由此触发版权法上的救济，而不只是合同违约后果。

德国法兰克福地区法院2006年处理的D-Link GPL违反案，也常被用来说明GPL的可执行性。该案由Linux内核开发者Harald Welte及其创设的gpl-violations.org项目推动，争议源于D-Link Germany GmbH在网络存储设备中使用受GNU GPL约束的Linux内核及相关软件，却未按GPL要求履行合规义务。公开资料显示，法院支持了基于GPL的著作权主张，并确认GPL在德国法下可以作为有效许可安排被执行。它说明，GPL不只是项目社区内部的协作规则；在特定法域和个案事实下，其许可条件可能被法院作为著作权许可安排加以执行，违反条件也可能引发实际的司法后果。

中国司法实践则越来越倾向于承认开源协议的合同属性，尤其是GPL这类具有明确权利义务结构的许可证。广州知识产权法院在罗盒诉玩友案，即（2019）粤73知民初207号案中，认为GPLv3协议具有合同性质，是授权方和用户订立的格式化著作权协议；使用者可以在 GPLv3条件下复制、修改和分发软件，但也必须履行相应义务。若其违反GPLv3使用条件，授权可能终止，后续复制、发布行为因失去权利来源而可能构成侵权。该案还涉及开源软件权属、贡献者授权、GPLv3 Copyleft效力范围、商业使用限制条款效力等问题，不能被简化为“只要违反开源协议就当然构成侵权”。

但承认合同属性，并不意味着所有开源争议都可以被简单处理。开源协议的效力仍受到著作权法基本原则、合同法格式条款规则、强制性法律规定、法律适用和管辖规则的限制。例如，很多开源许可证未明确约定适用法律；不同法域对精神权利、免责声明、格式条款解释、消费者保护、专利授权的理解也可能不同。跨境分发软件时，企业不能只看许可证文本，还要考虑目标市场的强制性规则。

开源协议的效力边界：代码表达、功能接口与合理使用

开源许可证并非无限延伸的控制工具。其效力首先取决于权利人到底拥有什么权利：权利人可以通过许可安排他人复制、修改、分发受保护表达的条件，但不能借许可证把本不受版权控制的思想、功能、操作方法或技术效果扩张为专有权。

对于软件而言，著作权通常保护源代码、目标代码及具有独创性的结构性表达，而不保护功能目标、算法思想、操作方法、数学公式、业务规则或技术效果本身。这一边界对开源生态尤其重要。否则，一个开源项目只要率先实现某项功能，作者就可能通过版权控制整个功能领域，反而妨碍后续的技术共享、互操作和竞争。

这里所说的“净室开发”，是指用隔离化研发流程实现同一功能：一组人员只根据公开资料、功能规格或接口说明整理需求，另一组未接触原代码的人员据此独立编写新代码。它的法律意义不在于创造一项特殊免责事由，而在于证明新代码来源于独立创作，没有复制原代码中的受保护表达。因此，只要新的实现确由独立开发完成，通常不会仅因功能相同而当然构成著作权侵权；但如果开发者实际接触并复制了受保护代码，或者在新实现中保留了原代码的表达性结构，就不能仅以“功能相同”“重新实现”或名义上的净室流程排除侵权和许可证义务。

但实践中，需要考虑的因素往往更加复杂。例如，在构建软件接口时，接口既承担功能调用作用，又可能通过命名、层级和组织方式表现为一定代码表达；企业为了实现互操作或降低开发者迁移成本，可能需要沿用既有接口体系。美国科技巨头API版权纠纷案正是这种边界问题的典型案例。

在该案中，Java SE应用程序接口（Application Programming Interface，简称“API”）可以粗略区分为三层：方法调用，是程序员输入的命令；声明代码，是对外说明“可以调用什么”的接口签名，包括方法名称、参数、返回值及所属类和包等；实现代码，则是实际执行计算或操作步骤的程序。换言之，声明代码本身通常不完成具体任务，而是把开发者输入的调用指令连接到相应功能和后续实现代码。G公司为开发Android，并没有复制Java SE API中承担具体任务的实现代码，而是自行编写了Android的实现程序；真正发生争议的，是G公司复制了37 个Java API包中约11,500行声明代码及相应组织结构，使熟悉Java的开发者可以在Android平台上沿用既有调用方式。

因此，该案既不是标准意义上的净室开发，也不是完整复制Java程序。美国最高法院没有最终裁定API声明代码是否当然受版权保护，而是在假定其可以受保护的前提下审查合理使用。法院认为，G公司复制的内容主要用于让开发者在新的智能手机平台上调用已经熟悉的任务，Android的任务实现代码由G公司自行编写；结合使用目的的转换性、声明代码的功能性、复制范围与使用目的之间的关系及市场影响，G公司的使用构成合理使用，因而不承担版权侵权责任。

法院并不是说复制接口代码天然合法。该案结论建立在特定事实和合理使用分析之上：即便将声明代码视为可保护表达，G公司的使用仍被认定落入合理使用。换到其他事实中，例如复制范围更大、替代原有市场更明显、复制内容更接近实现代码，或者所在法域没有类似合理使用规则，结论都可能不同。

回到开源语境，这一边界意味着许可证只能对受保护表达及基于该表达形成的改编、复制、分发等行为施加约束。若他人通过净室开发独立实现相同功能，通常不会仅因功能相同而受 GPL、MIT或Apache等许可证约束。反过来，如果他人直接复制、修改或紧密集成开源代码，即使最终产品外观、商业模式或上层功能不同，也可能触发许可证义务。

开源与版权：不是对立，而是共生

开源常被误解为放弃版权保护，或者不再主张版权中的排他性利益。事实上，开源并不是放弃权利，而是在版权制度框架内选择一种开放条件下的权利行使方式。

传统版权逻辑强调排他性：权利人可以禁止未经授权的复制、改编、分发和信息网络传播。开源许可则将这种排他性转化为开放条件：你可以自由使用，但必须遵守许可证要求。GPL 的核心机制正是前文所说的Copyleft机制，也可以理解为“相同方式共享”机制；其基本含义是，使用者可以复制、修改和分发软件，但在分发修改版或衍生作品时，应当把同样的开放条件传递给下游。例如，企业将GPL程序改写后作为产品分发，通常不能只交付闭源二进制文件，而需要按许可证要求提供相应源代码并保留GPL条件。

MIT、BSD、Apache 2.0等宽松许可证则选择另一种路径：它们通常不要求下游以相同许可证开放整体项目，而是通过保留版权声明、免责声明、专利授权等较少义务，降低商业采用和二次开发的谈判成本。比如，企业在商业软件中使用MIT组件，通常不必公开自身全部源代码；使用Apache 2.0组件时，还可在满足声明保留等义务的同时取得较明确的专利授权安排。这种低义务设计有利于快速集成、广泛传播和商业生态扩张。

因此，开源不是版权制度的外部反叛者，而是版权制度框架内的一种创造性安排。没有版权，GPL难以强制执行；没有许可条件，开源作品可能被直接闭源吸收，社区贡献无法回流。

但版权也不是开源项目的全部保护工具。对于软件而言，版权不保护功能思想，也不当然覆盖算法、接口规则、业务方法和技术效果；对于AI模型而言，模型权重是否构成著作权法意义上的作品，在不同法域和不同事实下仍存在不确定性。也就是说，开源许可证能够安排的，首先是许可人有权处分的版权表达和相关权利，不能自动替代专利、商业秘密、数据合规、反不正当竞争和合同安排。

训练数据问题尤其需要单独看待。一个模型或数据集标注为“开源”或采用某种许可证，并不当然意味着其中所有训练材料都已经完成权利清理。原因在于，训练数据可能包含大量第三方作品，例如代码、文章、图片、音乐、视频或网页内容；发布者对模型、代码或数据集作出的授权，通常只能覆盖其自身有权授权的部分，不能自动代表每一位第三方权利人同意其作品被收集、复制、训练、再分发或用于商业模型。因此，企业在使用开源模型或公开数据集时，不能只看模型卡或许可证名称，还需要审查数据来源、抓取方式、权利保留、使用限制、投诉机制和输出控制。

开源与商业秘密：公开性与保密性的张力

商业秘密保护的核心是秘密性、商业价值和保密措施，而开源软件的核心则是公开性。二者在同一技术客体上存在天然张力：如果源代码已经向不特定公众公开，或者任何人都可以从公共仓库获取，该代码本身通常很难继续满足商业秘密所要求的秘密性。但是，这并不意味着企业一经开源就失去全部商业秘密保护。未公开的算法细节、训练流程、运维参数、客户数据处理方案、内部工具链、产品路线和商业策略，仍可能在采取合理保密措施的前提下受到商业秘密保护。

企业面临的风险主要有三类。

第一，因不当引入强Copyleft组件导致被动开源。如果商业软件中复制、修改或紧密集成GPL代码，并在分发时未履行GPL义务，企业可能面临停止侵权、赔偿、提供源代码等风险。若被要求公开的部分原本被企业作为商业秘密管理，其秘密性可能受到破坏。

第二，员工对外贡献代码时误披露商业秘密。研发人员参与开源社区时，可能将内部算法、业务逻辑、性能优化方案、客户数据处理方式或尚未公开的产品路线写入公共仓库。即使没有GPL风险，也可能造成商业秘密灭失。

第三，开源代码提升竞争对手反向分析能力。开源本身允许他人阅读、修改和分叉代码。即使竞争对手最终通过独立开发形成替代产品，开源项目也可能暴露企业技术路线和架构选择。

解决之道不是拒绝开源，而是分层治理。企业可以将基础框架、工具链、接口、SDK、推理代码、部分模型权重等开放，以换取生态、标准和开发者采用；同时将核心算法、训练数据配比、数据清洗流程、训练基础设施、业务数据、客户画像和工程化经验作为商业秘密管理。

Google Android即体现了这种分层策略：Android开源项目扩大系统生态，Google Mobile Services等关键组件和服务则保持专有。AI企业也常采取类似路径：开放模型权重或推理代码，但保留训练数据、训练策略、算力调度、数据工程和安全对齐细节。

开源与专利：免费代码不等于免费专利

企业使用开源软件时，另一个常见误区是认为“代码可以免费用，相关专利也可以免费用”。但这并不成立。

许多开源许可证主要处理著作权授权，不当然提供专利授权。MIT、BSD通常没有明确专利授权条款；GPLv2也没有完整的现代专利授权机制。GPLv3和Apache 2.0对专利问题处理更充分，但其覆盖范围主要限于贡献者拥有并因贡献代码而必然被实施的专利权利要求。

Apache 2.0因其明确的贡献者专利授权和专利反诉终止条款，被广泛认为更适合企业级开源项目。贡献者授予使用者永久、全球、非独占、免费、不可撤销的专利许可；如果使用者反过来主张该软件或贡献构成专利侵权，其专利许可可能终止。这种机制可以降低贡献者与使用者之间的专利风险，但不能消除第三方专利风险。

AI场景下，专利问题更复杂。模型压缩、推理加速、芯片协同、通信协议、图像处理、编码解码、语音识别等领域都可能存在专利布局。一个模型或框架即使采用MIT License，也不代表所有相关专利都已被授权。因此，对于核心产品，企业仍需做专利自由实施分析、供应链专利审查，必要时加入防御性专利池或取得商业许可。

第二部分：AI变局——传统开源框架如何应对权重、数据和输出

传统开源许可的中心是源代码，而大模型的核心资产则被拆成代码、权重、训练数据和输出。技术客体变了，许可协议能够覆盖的范围、权利保护的路径和下游使用的责任也随之改变。

AI时代的结构性错位：从源代码到权重、数据和输出

传统开源许可协议的设计前提是：软件的核心价值载体是源代码。只要源代码开放，使用者就能阅读、修改、编译、运行并进一步分发软件。

大模型改变了这一前提。一个AI模型系统至少包含四类关键资产。

第一，模型代码。包括训练代码、推理代码、微调代码、部署脚本、评测工具和样例接口。

第二，模型权重。即训练后形成的大规模参数矩阵，往往是模型能力的直接载体。

第三，训练数据。包括语料、图像、音频、代码、标注数据、合成数据、过滤规则、数据配比和清洗流程。

第四，模型输出。包括生成文本、代码、图像、视频、推理过程、合成数据和可用于蒸馏的回答。

传统开源许可证主要围绕受版权保护的软件表达设计，因此对模型代码这类资产最容易适用；但当客体转向模型权重、训练数据和模型输出时，其适用边界就会变得不确定。MIT许可证可以允许使用、复制、修改和销售“软件及相关文档”，但该授权并不能当然清除训练数据中第三方作品、个人信息、商业秘密或受限数据的风险，因为这些材料可能并不属于模型发布者有权处分的“软件及相关文档”。GPL可以要求分发衍生代码时提供源代码，但模型权重是否属于GPL语境中的“源代码”或“目标代码”、权重开放是否足以满足可修改性要求，都不能直接从传统GPL文本中得到稳定答案。Apache 2.0可以处理贡献者就其代码贡献授予的专利许可，但不能自动安排训练数据授权、模型输出权属、蒸馏数据使用或高风险应用责任。

这就是AI开源许可的结构性错位：传统协议以版权保护的源代码表达为中心，而AI模型的核心价值越来越集中在法律属性不明的权重、数据和输出之中。

模型权重的法律属性：作品、技术事实，还是竞争利益

模型权重是一组在训练过程中形成的参数。它们可能包含数十亿、数千亿甚至更多浮点数。问题在于，这些数值本身是否具有著作权法意义上的独创性表达？

一种观点认为，权重是训练数据、模型结构和优化算法共同作用的结果，其中可能编码了训练数据中的模式，因此在一定条件下可能与训练数据存在派生关系。另一种观点则认为，权重是数学参数和技术事实，并非人类可感知的表达，不能简单纳入传统著作权法作品范畴。

中国亿睿科AI模型侵权案提供了一个务实路径。法院没有简单确认模型结构和参数构成著作权作品，而是认为其承载了经营者投入大量资源形成的竞争利益。被告直接使用他人模型结构和参数，节省训练数据和模型训练投入，短时间内打破原告竞争优势，并在相近场景中竞争流量和用户，可以构成不正当竞争。

这一裁判思路对开源模型同样有启示：如果模型权重本身的著作权属性不明，单纯依赖MIT、GPL或Apache等版权许可证约束下游，可能存在执行不确定性。企业如果希望保护模型权重，除许可文本外，还应通过访问控制、下载记录、模型水印、版本管理、合同约束、商业秘密管理和反不正当竞争路径共同构建保护体系。

模型许可证的光谱：完全开源、开放权重、负责任开放与闭源

点击可查看大图

AI模型的许可实践并非二元对立，而是一条光谱。

一端是尽可能开放的模式。DeepSeek-R1的模型卡显示，代码仓库和模型权重采用MIT License，支持商业使用、修改、衍生作品，包括蒸馏其他大模型。这种策略降低了企业采用和社区改造的成本，也迅速提升生态扩散速度。但它也意味着发布者较少通过许可文本控制下游用途和竞争行为，并且训练数据、第三方权利、出口管制等问题仍需另行处理。

另一端是闭源模型。闭源模型通常通过API提供能力，权重、训练数据、训练代码和模型架构不公开。OpenAI、Anthropic、Google等闭源或半闭源模式可以更好保护商业秘密和安全策略，也便于集中控制输出风险、收费模式和产品体验，但会引发透明度、可审计性、技术垄断和用户依赖等批评。

中间是开放权重模式。Meta Llama系列就是代表。用户可以下载、部署、微调模型，但许可证保留若干商业和行为边界。Llama 3.3许可证要求随附许可协议、展示“Built with Llama”、保留Notice文件中的版权声明；若使用Llama材料或输出创建、训练、微调或改进并对外分发AI模型，还需在模型名称开头包含“Llama”；若许可接受方及其关联方在版本发布日前一个自然月已有产品或服务月活超过7亿，则需向Meta申请额外许可。这些限制使其与传统OSI开源定义存在距离。

在开放权重与闭源控制之间，还存在OpenRAIL等“负责任开放”许可。它们通常保留模型开放使用、复制、修改和分发的一面，同时通过可接受使用政策或许可证条款限制高风险用途。放在许可光谱中看，这类安排的意义在于说明：AI模型许可已经不只是在“是否开放源代码”上作选择，而是在开放程度、用途限制和责任分配之间重新组合。

由此可见，“开放”不是一个法律结论，而需要拆解：代码是否开放、权重是否开放、数据是否开放、训练过程是否可复现、下游商业用途是否受限、竞争用途是否受限、高风险用途是否受限，以及是否符合OSI开源定义或Open Source AI Definition（开源 AI 定义）。下一节再以Llama、DeepSeek-R1和OpenRAIL类许可证为例，展开这些差异在具体文本中的表现。

AI模型许可：Llama、DeepSeek、OpenRAIL与标准许可证的差异

以Llama 3.3、DeepSeek-R1和OpenRAIL类许可证为例，可以看到AI时代许可证已经从“源代码授权”扩展为“模型生态控制”。

Llama 3.3的许可文本首先定义了Llama Materials，包括基础大语言模型、软件和算法、机器学习模型代码、训练后的模型权重、推理代码、训练代码、微调代码和其他相关要素。Meta授予用户非独占、全球、不可转让、免版税的有限许可，允许使用、复制、分发、创建衍生作品和修改。但该授权附带多个条件：分发时需提供许可协议；相关网站、用户界面、博客或产品文档需展示“Built with Llama”；分发副本中需保留Notice文件；使用需遵守可接受使用政策和贸易合规规则。

其中最具有商业控制意味的是7亿月活门槛。按照Llama 3.3许可文本，如果在该版本发布日，许可接受方或其关联方提供的产品或服务，在此前一个自然月的月活用户超过7亿，使用者必须向Meta申请额外许可，并且只有在Meta明确授予后才可行使相关权利。这里限制的并不是Llama模型本身的下载量、调用量或采用后的用户规模，而是以采用方及其关联方既有产品或服务的用户规模作为准入门槛。换言之，普通开发者、研究机构或中小企业通常不会因为使用Llama触发该条款；真正受到影响的是已经拥有超大规模用户基础的平台型企业。该设计使Llama既可以通过开放权重扩大生态，又保留对超大平台商业化使用的单独谈判空间。

这类许可的商业逻辑很清楚：Meta希望通过开放权重扩大生态、吸引开发者和研究者，同时避免超大平台无成本利用其模型建立竞争性业务。它不是传统闭源，也不是传统OSI开源，而是“开放权重+商业控制”的组合。

DeepSeek-R1的路径更接近标准开源。其模型卡明确称代码仓库和模型权重采用MIT License，支持商业使用，允许任何修改和衍生作品，包括但不限于用于训练其他大模型的蒸馏。这里所说的“许可证摩擦”，是指下游在部署、微调、蒸馏、二次开发和商业化过程中，因为许可证限制而需要额外承担的审批、谈判、命名标识、源代码披露、用途限制、衍生模型传递义务或兼容性处理成本。MIT License的义务较少，一般不限制商业使用，也不要求下游整体继续开源，因此相较Llama式社区许可或OpenRAI式负责任使用许可，DeepSeek-R1在下游商业采用中的许可证摩擦较低。其风险则更多转向许可证之外：训练数据来源、第三方权利、模型输出合规、个人信息和出口管制仍需自行评估。

OpenRAIL类许可证试图在二者之间引入“负责任使用”条款。它们通常允许使用、复制、修改和分发模型，但要求不得用于特定危害性场景，并要求衍生模型继续传递这些限制。其优势是回应AI安全和滥用风险；需要注意的是，这类用途限制与传统开源定义并不完全一致。按照OSI的开源定义，许可证不得歧视任何特定使用领域；而OpenRAIL类许可证恰恰会限制某些用途。因此，它们更适合被理解为“负责任开放”或“带用途限制的开放模型许可”，不宜直接等同于传统OSI意义上的开源许可证。

Gemma、Phi、Qwen、Mistral等模型也体现不同策略。Mistral 7B、Qwen若干版本、Phi若干版本采用Apache 2.0或MIT等较标准许可，更便于企业采用；Gemma Terms等自定义条款则更强调使用限制和责任边界；Llama则通过社区许可保留商业规模控制。企业不能只看模型排行榜或性能指标，也不能只看Hugging Face页面上的“license”标签，而应阅读完整许可证、模型卡、使用政策、基座模型许可和衍生模型说明。

尤其要注意蒸馏模型的指代层次。首先，DeepSeek-R1是主模型，模型卡称其代码仓库和模型权重采用MIT License。其次，“蒸馏模型”是一个通用概念，通常是指利用能力更强模型的输出、推理轨迹或合成数据，训练或微调较小的学生模型，使其获得相近能力；它不是主模型本身，也不只是主模型的“小尺寸版本”。再次，DeepSeek-R1-Distill-* 是DeepSeek发布的一组蒸馏模型，其中既有基于Qwen的版本，也有基于Llama的版本。以 DeepSeek-R1-Distill-Llama为例，其基座来自Llama，DeepSeek模型卡也提示相关来源模型原本适用Llama许可证。因此，DeepSeek-R1主模型采用MIT，并不当然意味着所有 DeepSeek-R1-Distill模型都只受MIT约束；企业如果将蒸馏模型用于商业产品，需要逐一确认具体模型文件、基座模型来源以及相应许可链条。

训练数据版权：开源代码被训练以后，义务是否跟着走

AI训练数据版权是目前最不确定的问题之一。

以前述美国AI代码相关诉讼为例，原告的核心关切在于：代码平台上公开可见的代码并不等于无条件可用。很多代码受GPL、MIT、Apache、BSD等许可证约束，使用者需要遵守保留版权声明、提供许可证文本、公开源代码、传递相同许可等义务。如果AI模型训练使用了这些代码，模型输出又未提供来源和许可信息，是否构成对开源许可义务的规避？

从技术上看，模型训练并不等同于传统复制分发。训练过程通常会复制数据、提取统计关联、更新参数，但模型最终输出未必逐字复制训练代码。从法律上看，训练阶段是否构成复制、是否可被合理使用或类似例外覆盖、许可证义务是否因训练触发、输出阶段是否构成实质性相似，都需要分开判断。

美国法下，AI开发者常援引合理使用（fair use），强调训练是转换性使用，不替代原作品市场，且促进创新。权利人则强调，大规模未经授权复制作品用于商业模型训练，可能侵害复制权，并替代许可市场。美国版权局（U.S. Copyright Office）2025年关于生成式AI训练的报告没有给出“一律合法”或“一律侵权”的结论，而是主张结合使用目的、作品性质、使用量、市场影响等因素个案判断。例如，面向非商业研究、输出不替代原作品也不明显影响授权市场的训练使用，可能更容易支持合理使用抗辩；但如果商业模型大规模复制特定类型作品，并在同一市场生成可替代内容，或者削弱权利人本可开发的训练数据授权市场，合理使用结论就会更不确定。

欧盟通过《单一数字市场版权指令》设置文本和数据挖掘规则，并允许权利人以适当方式保留权利；欧盟《人工智能法案》又要求通用AI模型建立遵守欧盟版权法的政策，并提供训练内容摘要。中国《著作权法》第24条尚未明确列入AI模型训练的合理使用情形，《生成式人工智能服务管理暂行办法》要求提供者尊重知识产权、商业秘密和商业道德，但没有全面回答训练数据授权问题。

因此，企业不能简单认为“公开仓库即可训练”或“开源许可证天然允许训练”。更稳妥的合规路径包括：识别训练数据来源，记录许可证类型，过滤禁止商业使用或用途受限内容，识别权利保留声明，建立输出相似性检测机制，对代码生成工具提供许可证提示和重复片段拦截，并为权利人投诉设置处理流程。

训练数据版权：不同法域给出的不同答案

前一节讨论的是“开源代码被训练以后，许可证义务是否跟着走”。但训练数据争议并不只发生在开源代码场景中；只要模型训练涉及受版权保护的文本、图像、音频、视频或代码，就会进入更广泛的版权授权、例外和监管问题。不同法域对此给出的答案并不相同。

在美国，核心概念是合理使用（fair use）。法院通常从四个因素判断：使用目的和性质、受版权作品性质、使用量和实质性、对潜在市场的影响。AI公司倾向于强调训练具有转换性，模型学习的是统计关系而非表达，输出不替代训练作品。权利人则强调，训练过程本身需要复制作品，大规模商业训练可能替代授权市场，并且输出在某些情形下会与原作品竞争。美国版权局（U.S. Copyright Office）2025年报告没有给出绝对答案，而是强调个案判断：例如，非商业研究或安全测试中的训练使用，如果输出不替代原作品、也不影响现实或潜在授权市场，合理使用抗辩可能更有空间；相反，如果商业模型集中复制某类作品，并生成可与原作品竞争的内容，或削弱权利人许可训练数据的市场，合理使用风险就会显著上升。

在欧盟，文本和数据挖掘（Text and Data Mining，简称“TDM”）例外提供了更明确但也更制度化的路径。科研机构和文化遗产机构享有较强的TDM例外；商业主体也可在一定条件下进行文本和数据挖掘，但权利人可以通过适当方式保留权利。欧盟《人工智能法案》进一步要求通用AI模型提供训练内容摘要，并建立遵守欧盟版权法的政策。欧盟制度的重点不是简单允许或禁止训练，而是通过透明度、权利保留和合规政策重新分配信息义务。

在中国，现行著作权法合理使用条款没有明确列入AI模型训练，司法实践中对AI训练数据的系统性裁判仍有限。《生成式人工智能服务管理暂行办法》要求提供者尊重知识产权，不得侵害他人合法权益，但这更多是监管义务和原则性要求。未来中国可能在合理使用、法定许可、数据挖掘例外、权利保留机制或行业授权市场中选择路径。

英国法下，计算机生成作品曾有特殊规则，AI生成内容的版权问题较其他法域更具历史基础。不过，训练数据挖掘和商业AI训练仍在政策争议中。英国曾讨论扩大文本和数据挖掘例外，后又因创意产业反对而调整方向。

日本法在文本和数据挖掘方面相对宽松，允许在不以享受作品表达为目的的情况下进行一定信息解析。这使日本常被AI企业视为训练数据规则较友好的法域。但即便如此，若训练用途与原作品表达市场发生直接替代，仍可能产生争议。

对跨国企业而言，训练数据合规不能只选择一个最宽松法域作为全部依据。模型训练地、数据来源地、模型提供地、用户所在地、输出使用地都可能影响法律适用。尤其是面向欧盟和中国提供服务时，训练数据版权、个人信息、数据出境、内容安全和透明度义务需要综合判断。

模型输出进入开源生态：版权归属与许可链条

模型输出的版权问题，看似属于AI作品保护问题，实则会直接影响开源许可链条。开源许可证能够稳定运行，至少依赖两个前提：第一，贡献者对提交的代码、文档或数据拥有可以处分的权利，能够把它们纳入MIT、GPL、Apache 2.0等许可证体系；第二，被贡献内容本身没有夹带不兼容的上游权利或模型使用限制。AI输出进入开源生态后，这两个前提都会变得不那么当然。

第一层问题是权利基础。若AI生成代码被提交进开源仓库，项目维护者需要确认贡献者是否有权授权该代码。如果使用者在提示词设计、参数设置、生成结果筛选、后期修改等环节体现了足够人类智力投入，部分法域和个案可能承认相关输出构成受著作权保护的作品，贡献者也更容易将其作为自己的贡献按项目许可证提交。反之，如果人的贡献只是简单输入、机械选择或完全无创作性，输出可能难以满足独创性要求；这时，把许可证标签贴在输出上，并不一定能产生与普通原创代码相同的授权效果。

第二层问题是上游限制。即使输出本身可以被贡献者处分，也还要看它是否与训练数据中的开源代码、受版权保护作品或模型输出规则发生联系。若AI生成代码与上游开源代码构成实质性相似，可能带入保留版权声明、传递许可证、提供源代码等义务；若输出来自特定模型，还要检查模型许可是否限制输出的再训练、蒸馏、命名或商业使用。例如，Llama 3.3对使用Llama材料或输出创建、训练、微调或改进并对外分发AI模型设置命名要求；DeepSeek-R1则明确允许包括蒸馏在内的衍生使用。不同模型许可证对输出和蒸馏的处理并不一致，不能只用“AI生成”四个字概括。

第三层问题是不同法域对“人的贡献”的判断并不完全一致。美国版权局（U.S. Copyright Office）长期强调人类作者要件，纯AI生成内容通常不能登记为作品，但包含足够人类创作贡献的选择、编排、修改或具体表达部分，仍可能获得保护。中国已有判例也倾向于关注人的智力投入程度，例如提示词设计、参数选择、结果筛选和后期修改是否共同形成可识别的创作贡献。共同点在于：不能把AI输出一概视为当然有版权，也不能一概视为当然无版权。

因此，这一问题对开源项目并不边缘。较稳妥的治理方式，是在贡献者许可协议（CLA）、开发者原创声明（DCO）或项目贡献指南中说明是否允许AI辅助贡献；要求贡献者确认其有权提交相关内容；对AI生成代码进行相似性检测和许可证扫描；记录使用的模型、提示词、人工修改和审查过程；对用于再训练或蒸馏的输出，单独审查模型许可和数据来源。只有这样，模型输出进入开源项目时，才不至于把版权归属、上游许可证和模型使用限制一起带成隐性风险。

中篇预告：

在中篇，我们将继续深入探讨开源许可证的完整谱系，系统拆解不同许可证在组件引入､产品发布、云服务部署等场景下的风险触发机制，并结合司法实践中的典型判例，初探法院如何具体划定开源边界与Copyleft 效力范围｡