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

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

开源与闭源的商业竞争：从Red Hat到DeepSeek

开源和闭源不是纯粹技术选择，而是商业模式选择。

早期开源商业模式以支持服务为主。Red Hat通过Linux发行版、企业订阅、安全更新、认证和技术支持实现收入。这证明了软件本身免费并不意味着无法商业化。

随后，双许可和开放核心模式兴起。企业可以提供社区版开源，同时通过企业版、高级功能、管理工具、安全功能、商业授权获得收入。MySQL、MongoDB、Elastic、GitLab等项目都在不同程度上采用过类似策略。

云计算又改变了关系。云厂商可以基于开源软件提供托管服务，快速获得收入，却未必向原项目公司付费。这催生了SSPL、Elastic License等反云厂商许可证，也引发社区分叉和“伪开源”争议。

AI大模型领域正在重演类似博弈。闭源模型通过API、订阅、企业授权和高性能模型形成壁垒；开放权重模型通过本地部署、微调、社区评测和衍生模型扩大影响力。DeepSeek-R1采用MIT License开放权重和代码，降低了全球开发者部署和蒸馏门槛，也迅速推动生态扩散。Meta Llama则通过开放权重吸引开发者，同时保留月活门槛、命名要求和使用政策，以平衡开放和商业控制。

这些案例说明，开源与闭源并不是二选一的价值判断，而是围绕项目属性、商业模式和生态关系作出的制度安排。进入具体许可证选择时，关键不在于给项目贴上“开放”或“封闭”的标签，而在于判断哪些资产适合开放、哪些能力需要保留、下游是否应当回流贡献，以及企业能否承受相应的合规和竞争后果。

企业如何选择许可证：项目属性决定答案

许可证选择没有万能答案。企业可以从四个维度判断。

第一，项目是否为核心竞争力。如果项目是通用工具、基础库、示例代码或生态吸引组件，宽松许可证更利于采用。如果项目是核心产品或差异化算法，可能不适合开源，或仅适合开放部分。

第二，是否希望衍生作品回流。如果希望所有下游修改持续开源，可以考虑GPL或AGPL。如果更重视商业采用和行业标准化，则MIT、BSD、Apache 2.0更合适。

第三，是否涉及专利。如果项目涉及关键技术专利，Apache 2.0通常比MIT/BSD更稳健，因为其专利授权和终止机制更清楚。

第四，是否为AI模型。AI项目往往不适合一个许可证覆盖全部资产。代码可以用MIT或 Apache 2.0；模型权重可采用模型专用许可或标准许可；训练数据需另行确认数据许可；文档、模型卡、商标和输出使用政策也可能需要单独安排。

尤其对AI模型，企业应避免“许可证错配”。例如，用MIT License发布代码不等于开放权重；开放权重不等于开放训练数据；即便公开训练数据集或训练数据清单，也不当然说明其中包含的文字、图片、音频、代码等第三方作品已经获得原权利人授权；许可证允许商业使用，也不等于免除出口管制、隐私合规和高风险应用责任。

出口管制：许可证允许，不代表国家允许

点击可查看大图

开源许可解决的是权利人是否授权的问题；出口管制解决的是国家是否允许特定技术、软件、物项或技术资料跨境流动的问题。二者不是同一套规则。

美国《出口管理条例》（Export Administration Regulations，简称“EAR”）对已公开发布的技术和软件设有不受EAR管制的规则，这对开源软件具有重要意义。但加密软件需要特别分析。美国商务部工业与安全局（Bureau of Industry and Security，简称“BIS”）官方说明显示，公开可得的加密源代码在满足相应通知要求后才不受EAR管制；公开可得的加密目标代码、mass market软件、出口管制分类号（Export Control Classification Number，简称“ECCN”）、加密项目许可例外（Encryption Commodities, Software and Technology，简称“ENC”）等也有不同规则。如果企业把开源加密组件集成到专有产品中，产品整体仍可能受EAR规制。

中国则通过《出口管制法》《技术进出口管理条例》和《中国禁止出口限制出口技术目录》管理相关技术出口。2023年新版目录取代2020年调整内容，列明若干禁止或限制出口技术。对于AI大模型而言，模型权重、训练方法、数据处理技术、网络安全能力、深度包检测、战略预警等是否落入具体控制要点，需要结合技术内容判断。

中美技术博弈使问题更复杂。高性能GPU、先进计算芯片、半导体制造设备、电子设计自动化（Electronic Design Automation，简称“EDA”）工具、加密技术、网络安全技术和特定AI能力都可能触发出口管制或制裁。一个模型即使用MIT License发布，如果其跨境提供涉及受管制技术资料、受限最终用户或敏感用途，仍可能需要出口管制审查。

企业在发布重要开源项目或AI模型前，应至少完成三项检查：上游许可证是否允许发布；模型、代码、数据、商标、专利和商业秘密是否存在第三方权利障碍；目标法域出口管制、制裁、数据出境和AI监管是否适用。

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

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

中欧AI监管：开源例外、应用端治理与透明义务

AI模型开源不能只从许可证角度判断，还要放入监管框架中观察。中国目前并没有一部专门的“开源软件法”，开源协议效力主要依赖民法典合同编、著作权法、计算机软件保护条例、反不正当竞争法等一般规则解释适用；AI应用端则会叠加生成式AI 服务、个人信息、数据安全、内容标识和行业监管要求。也就是说，企业面对的不是单一许可证问题，而是知识产权、数据、内容安全、网络安全和商业秘密共同构成的治理问题。

中国政策层面对开源的重视正在提升。“十四五”规划提出完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务；2025 年《国务院关于深入实施“人工智能+”行动的意见》也提出促进开源生态繁荣，并在全球合作部分提出推动人工智能技术开源可及。对企业而言，这并不意味着“政策鼓励开源”即可替代合规审查，而是意味着开源会更深地进入研发、产业协作和AI产品发布流程，合规体系也必须同步前移。

欧盟《人工智能法案》则从风险监管角度处理开源。其风险分级结构包括被禁止AI、高风险AI、透明度义务和通用AI模型义务等。对于开源，法案设置了一定例外：免费开源许可下发布的AI系统一般不适用该法案，除非其被投放市场或投入使用为高风险AI系统、被禁止AI系统，或触发特定透明度义务。对于通用AI模型，免费开源发布的提供者可在某些义务上获得减轻，但如果模型具有系统性风险，或者涉及版权合规政策、训练内容摘要等义务，仍可能受监管约束。

中欧规则的共同启示是：开源可以成为创新、透明、安全审查和产业协作的工具，但不能自动排除监管责任。中国企业如果面向境内公众提供生成式AI服务，需要关注知识产权、个人信息、内容安全和标识义务；如果模型面向欧盟市场发布或供欧盟用户使用，还要看模型用途、风险分类、是否作为通用AI模型、训练数据版权政策、文档透明度和下游部署者合规支持。

企业开源合规体系：从“上线前看一眼”到全流程治理

点击可查看大图

成熟企业不能依赖上线前临时审查开源许可证。开源合规应嵌入研发、采购、模型训练、产品发布和售后流程。

第一，识别。通过软件成分分析（Software Composition Analysis，简称“SCA”）工具识别代码库中的开源组件、版本、许可证、安全漏洞和传递依赖。AI项目还应识别模型基座、微调数据、评测数据、合成数据、蒸馏来源、模型卡和第三方API。

第二，分类。将许可证按风险分级：MIT、BSD、Apache 2.0多数情况下为低至中风险；LGPL需关注库修改和链接方式；GPL、AGPL需关注分发、网络交互和衍生范围；SSPL、Elastic License、OpenRAIL、Llama License等自定义许可证需逐条审查商业限制、用途限制和兼容性。

第三，审批。建立开源组件引入审批、对外开源审批、员工社区贡献审批、AI模型发布审批和出口管制审查机制。高风险许可证、核心产品依赖、商业发布和跨境发布应纳入法务、知识产权、信息安全和研发部门共同审查。

第四，隔离。对GPL、AGPL等高风险组件采用清晰架构边界，包括独立进程、独立服务、容器化部署、API调用、动态链接、双仓库、模块分层等。但隔离必须真实反映功能独立性，而不是形式包装。

第五，履约。保留版权声明、许可证文本、NOTICE文件，按要求提供源代码或获取方式，记录修改内容，确保下游接收者获得相应权利。对AI模型，还应随附模型卡、使用限制、安全说明、训练数据摘要和基座模型许可证说明。

第六，留痕。建立软件物料清单（Software Bill of Materials，简称“SBOM”），记录组件名称、版本、许可证、引入时间、审批记录、替换记录和发布范围。AI项目还应建立数据来源清单、训练日志、权重版本、模型评测、红队测试、输出相似性检测和权利投诉处理记录。

第七，响应。开源合规不是一次性工作。组件漏洞、许可证变更、上游项目转向SSPL或Elastic License、模型许可更新、监管规则变化，都可能改变风险状态。企业需要定期审计和更新。

企业开源治理的两个身份：引入使用与对外发布

开源治理首先要分清企业所处的位置。企业可能是开源项目的使用方，把外部代码、组件、模型、数据集引入自己的产品或服务；也可能是开源成果的发布方，把自研代码、模型权重、数据集、文档或接口对外开放。前者关注“拿来用”是否合规，后者关注“放出去”是否有权、是否合适、是否会改变商业边界。许多风险之所以难处理，正是因为同一项目会同时发生这两件事：先引入外部开源组件，再对外发布产品、插件、模型或衍生成果。

先看使用方。企业引入外部开源项目时，风险并不只来自许可证文本，通常可以分为六类。

第一是著作权风险。最典型情形是未遵守许可证义务，例如未保留版权声明、未提供许可证文本、未提供源代码、未传递相同许可证、删除上游署名信息、超出授权范围修改或分发。著作权风险的严重性在于，授权终止后继续使用可能构成侵权，产品分发越广，风险敞口越大。

第二是专利风险。开源许可证不当然授予所有专利。企业使用开源组件实现某一技术标准或功能时，仍可能落入第三方专利。AI框架、推理优化、音视频编解码、通信协议和加密算法尤其需要关注。

第三是商业秘密风险。员工对外贡献代码、引入GPL组件导致源代码公开、开源项目暴露技术路线、第三方通过开源代码进行反向分析，都可能影响商业秘密保护。

第四是数据和隐私风险。AI模型和开源数据集可能包含个人信息、敏感个人信息、未授权作品、商业秘密、爬取数据或受限数据。即使模型代码开源，数据使用仍可能违反个人信息保护、数据安全或平台条款。

第五是安全风险。开源组件可能存在漏洞、后门、供应链投毒、依赖混淆、恶意维护者接管、签名失效等问题。SBOM和漏洞响应机制不仅是法律合规，也是网络安全和产品责任管理。

第六是出口管制和制裁风险。加密软件、网络安全工具、先进计算能力、AI模型权重、受限技术资料、受制裁主体访问，都可能使开源项目进入出口管制和制裁规则视野。

再看发布方。企业主动对外开源时，问题不是“能不能公开”这样简单。对外发布一旦发生，许可文本、权利范围、下载对象、商业安排和下游再利用方式都会影响后续生态，至少应回答五个问题。

第一，开源目的是什么。是为了吸引开发者、建立标准、提升品牌、推动生态、降低维护成本，还是为了商业产品导流？不同目的决定不同许可证。如果目的是最大化采用，MIT或 Apache 2.0更合适；如果目的是确保社区贡献回流，GPL、AGPL或MPL可能更合适；如果目的是开放模型但控制超大商业使用，自定义模型许可可能更符合商业策略，但不宜轻易称为OSI意义上的开源。

第二，开源对象是什么。开源代码、开放权重、开放数据、开放文档、开放API、开放评测集，是完全不同的法律动作。代码可以用软件许可证；数据可能需要Creative Commons、Open Data Commons或自定义数据许可；模型权重可能需要模型专用许可；商标和品牌不应随代码许可一并无限开放。

第三，权利是否干净。企业需确认拟开源代码是否包含第三方代码、员工个人代码、外包交付物、客户代码、商业秘密、专利敏感技术、个人信息、受限数据和违反上游许可证的内容。对外开源后再撤回，往往难以完全消除影响。

第四，是否影响商业模式。开源可能带来生态，也可能降低产品差异化。企业应明确哪些部分开放，哪些部分保留，如何通过云服务、企业版、认证、支持、数据、模型服务或增值功能实现商业化。

第五，是否涉及跨境。若开源项目面向全球发布，可能涉及出口管制、加密通知、制裁名单、数据出境、模型安全和目标市场监管。尤其是AI模型权重，一旦公开下载，传播范围很难控制。

因此，引入使用和对外发布应放在同一套开源治理流程中处理：引入阶段确认上游义务和技术边界，发布阶段确认企业自身权利基础和向下游授权的范围，并在代码、模型、数据和文档层面分别留痕。开源治理不应由法务部门单独完成，而需要研发、法务、知识产权、信息安全、合规、采购、产品和业务部门共同参与。

企业使用开源或开放权重模型：准入审查与许可链条

企业使用开源或开放权重模型时，至少要建立一套模型准入审查。

第一，确认模型来源。模型是否来自官方仓库，是否为第三方镜像、量化版、微调版、合并版或蒸馏版。不同版本可能适用不同许可证，第三方上传者未必有权重新授权。

第二，确认基座模型。很多模型是基于Llama、Qwen、Mistral、DeepSeek、Phi等基座微调而成。上游基座许可证可能继续约束下游模型。若模型卡只写“MIT”，但实际基座是Llama，企业需进一步确认许可链条是否一致。

第三，确认权重许可和代码许可是否一致。某些项目代码采用Apache 2.0，但权重采用自定义许可；有些项目权重开放但训练代码不开放；有些项目模型卡允许研究用途但限制商业用途。

第四，确认输出使用规则。是否允许将模型输出用于商业产品、是否允许用于训练其他模型、是否允许蒸馏、是否要求标识来源，以及是否限制特定场景。

第五，确认数据和隐私风险。模型是否披露训练数据来源，是否可能记忆个人信息、版权文本、商业秘密或敏感内容。企业在高风险行业部署模型时，还需做输出测试和安全评估。

第六，确认部署场景。内部辅助工具、面向公众服务、医疗、金融、教育、招聘、信用评估、司法、公共治理等场景的监管要求不同。开源模型本身不等于部署服务合规。

第七，确认出口和制裁风险。模型权重跨境下载、提供给境外主体、向受制裁地区开放API、使用加密功能或网络安全能力等行为，都可能触发额外审查。

企业场景一：商业APP使用GPL框架

假设一家企业开发商业APP，为实现沙盒、插件化、虚拟化运行或图像处理功能，引入一个GPLv3框架。研发团队认为该框架只是辅助功能，APP的核心商业价值是视频美颜、社交运营或会员服务，因此无需开源。

这个判断可能过于乐观。法律风险不取决于企业主观上认为哪个功能“核心”，而要看GPL框架与商业APP的技术关系。如果商业APP复制、修改或嵌入GPL框架，并通过该框架实现关键功能，二者形成紧密整体，则分发APP时可能触发GPL义务。即使APP另有大量自主代码，也不能当然排除GPL影响。

更稳妥的方案是在项目早期就做架构隔离：尽量避免将GPL框架直接嵌入闭源主程序；若必须使用，考虑是否存在LGPL、Apache 2.0、MIT等替代组件；如无法替代，评估是否可以接受整体GPL发布；若采用服务化或进程隔离，也应保留架构独立性证据。

企业场景二：SaaS服务使用AGPL组件

假设一家云服务企业在后端使用AGPL许可的数据库、知识库系统、模型服务框架或监控工具，并对外提供API。研发团队认为公司并没有把软件副本分发给用户，因此不需要提供源代码。

这个判断对GPL可能有讨论空间，但对AGPL就很危险。AGPL的设计正是为了覆盖网络交互场景。如果企业修改AGPL程序并通过网络让用户与其交互，通常需要向交互用户提供对应源代码访问方式。

因此，企业在SaaS场景中应将AGPL组件设为高风险。常见控制措施包括：禁止在核心闭源服务中引入 AGPL；使用商业许可替代 AGPL；将 AGPL 组件作为独立开源服务提供并履行源代码义务；或采用许可证风险更低的替代方案。

企业场景三：基于开放权重模型做行业应用

假设一家企业下载Llama、DeepSeek、Qwen或Mistral模型，在本地微调后用于法律、医疗、金融或教育场景。企业认为模型“开源”，因此可以直接商业化。

此时至少要分四层审查。

第一，许可证是否允许商业用途。DeepSeek-R1主模型的MIT许可相对宽松；Llama 3.3则存在月活门槛、命名、署名、使用政策等要求；某些模型仅允许研究用途或非商业用途。

第二，基座模型和蒸馏模型是否存在不同许可。一个模型可能标注为MIT，但其某个蒸馏版本基于Llama，仍可能带有Llama许可链条。企业不能只看模型名称或页面标签。

第三，行业应用是否触发监管。医疗辅助诊断、金融风控、招聘筛选、教育评分等场景可能在欧盟构成高风险AI，在中国也可能涉及个人信息、算法备案、生成式AI服务、行业监管和内容安全。

第四，输出和数据是否合规。模型可能生成侵权内容、泄露训练数据片段、产生虚假信息或歧视性结果。企业需要通过提示词策略、输出过滤、人工复核、日志留存和投诉机制控制风险。

企业场景四：对外发布自研大模型

假设一家中国AI企业准备在全球发布自研模型权重，并计划用MIT License吸引开发者。这个策略有明显优势：采用门槛低、社区反馈快、便于建立行业影响力。但发布前仍需完成完整审查。

首先是权利审查。训练数据是否包含未经授权的版权作品，是否包含个人信息或敏感个人信息，是否包含第三方商业秘密；同时核查数据来源是否违反平台条款，以及数据清洗和标注外包合同是否约定权利归属。

其次是模型资产审查。模型权重是否完全自研，是否基于第三方基座模型继续训练，是否使用其他模型输出进行蒸馏，是否存在上游许可证限制，是否使用第三方专利技术。

再次是发布材料审查。模型卡是否准确描述能力和限制，是否夸大性能，是否说明训练数据摘要，是否提示禁止用途和安全风险，是否保留商标控制，是否避免把非OSI许可称为“开源”。

最后是跨境审查。模型能力是否涉及受限制出口技术，权重跨境下载是否构成技术资料出口，是否向受制裁主体开放，是否涉及加密、网络安全或先进计算能力。即使许可证允许全球使用，国家出口管制规则也可能另行限制。

企业开源政策：哪些组件可以直接用，哪些必须升级审批

一份可执行的企业开源政策，不能只写“遵守开源许可证”。它应当把许可证和使用场景结合起来。

对于MIT、BSD、Apache 2.0等宽松许可证，企业可以设置为一般准入，但仍需满足保留版权声明、许可证文本、NOTICE文件和专利风险评估等要求。若组件用于核心商业产品、嵌入硬件设备或涉及专利敏感领域，即使许可证宽松，也应提升审批层级。

对于LGPL、MPL等弱Copyleft许可证，企业可以设置为条件准入。审批重点是是否修改了库或文件、是否静态链接、是否能够满足重新链接或文件级开源义务，以及是否会与专有代码形成不可分割整体。

对于GPL、AGPL、SSPL、Elastic License、Commons Clause、OpenRAIL、自定义模型许可证等，应设置为高风险准入。研发团队不能自行引入到商业产品中，必须由法务、知识产权和架构团队共同判断。尤其是AGPL和SSPL，在云服务场景中可能影响整个服务栈或服务端代码开放义务。

对于未知许可证、无许可证项目、仅在README中写“free to use”的项目，应设置为禁止或特殊审批。没有许可证并不等于自由使用。默认情况下，著作权仍由作者保留，复制、修改和分发都可能缺乏授权。

对于AI模型，还应设置单独准入规则：仅允许研究用途的模型不得用于商业产品；限制特定行业或用途的模型不得进入相应业务线；基座许可证不清晰的微调模型不得上线；训练数据来源不明的模型不得用于高风险场景；输出权属和蒸馏规则不清晰的模型不得用于再训练。

开源合同条款：采购、外包和并购中不能遗漏

开源风险不仅发生在企业内部研发，也会通过采购、外包和并购进入企业。

在软件采购合同中，采购方应要求供应商披露产品中使用的开源组件、许可证类型、版本号、是否修改、是否触发源代码提供义务、是否存在已知许可证冲突和安全漏洞。供应商应承诺其使用开源软件符合许可证要求，并在因开源违规导致第三方索赔时承担相应责任。

在软件外包合同中，应明确外包方不得未经委托方书面同意引入GPL、AGPL、SSPL等高风险组件；如需使用开源组件，应提供清单并经审批。外包成果交付时，应随附SBOM、许可证文本、NOTICE文件、源代码提供说明和开源合规声明。

在AI模型采购或合作开发合同中，条款应进一步覆盖训练数据来源、模型基座、权重权属、微调数据权属、输出使用权、是否允许蒸馏、是否使用第三方模型输出、是否存在用途限制、是否符合目标市场监管要求。传统软件采购条款不足以覆盖这些内容。

在投融资和并购尽调中，开源合规应作为知识产权尽调重点。被投企业若核心产品大量使用GPL/AGPL组件却未履约，或核心模型基于限制性模型许可训练，可能影响估值、交割条件、赔偿条款甚至交易可行性。对于AI公司，还应审查训练数据授权、模型权重来源、数据标注合同、GPU云服务合规、模型卡披露和对外开源记录。

常见误区：开源合规里最容易踩的坑

第一个误区是“放在GitHub上就是开源”。GitHub是代码托管平台，不是许可证。没有明确许可证的代码，通常不能被当然复制、修改和商业使用。企业使用无许可证仓库代码，风险反而更高。

第二个误区是“MIT就没有任何风险”。MIT义务少，但仍需保留版权声明和许可证文本；MIT不提供明确专利授权，也不处理训练数据、个人信息、商标和出口管制。对AI模型而言，MIT也不能自动清除第三方权利风险。

第三个误区是“GPL禁止商用”。GPL不禁止收费，不禁止商业服务，也不禁止企业使用。它要求的是在触发条件下传递相同自由并提供源代码。把GPL理解为“不能商用”，会导致企业既误判风险，也错失可合规使用的场景。

第四个误区是“只要动态链接就安全”。动态链接通常比静态链接风险低，但不是绝对安全。若主程序与库之间功能高度依赖、接口并非标准接口、分发方式使二者形成一个整体，仍可能产生争议。

第五个误区是“模型开放权重就是开源”。开放权重只是AI开放的一种形式。训练数据、训练代码、模型架构、权重许可、输出规则、蒸馏规则、使用政策和商业门槛都会影响其是否符合开源定义。

第六个误区是“内部使用不用管”。某些许可证义务确实主要在分发时触发，但内部使用仍可能涉及安全漏洞、专利、商业秘密、数据合规和员工贡献风险。若内部系统未来转为对外服务或嵌入产品，早期忽视会变成上线障碍。

第七个误区是“开源合规是法务的事”。开源合规需要研发识别依赖、架构设计隔离、信息安全管理漏洞、采购控制供应商、法务解释许可证、知识产权评估专利和商业秘密、业务决定商业策略。任何单一部门都无法独立完成。

标准与工具：SBOM、SCA和开源AI定义的意义

开源合规正在从人工审查走向标准化工具链。

SCA工具可以扫描代码库，识别开源组件、许可证、版本、安全漏洞和传递依赖。它不能替代法律判断，但可以解决“企业不知道自己用了什么”的基础问题。没有组件识别，后续所有合规判断都没有对象。

SBOM则是软件物料清单。它记录产品中包含哪些组件、版本、供应商、许可证和依赖关系。SBOM在供应链安全、漏洞响应、政府采购和企业审计中越来越重要。发生Log4j类漏洞时，企业能否快速判断自身产品是否受影响，很大程度取决于是否维护准确SBOM。

对AI项目而言，传统SBOM还不够。企业可能需要模型物料清单（Model BOM）或AI物料清单（AI BOM），记录模型基座、权重版本、训练数据来源、微调数据、评测数据、许可证、模型卡、安全测试和部署环境。未来AI监管和采购审计很可能要求类似清单。

OSI发布的Open Source AI Definition（开源 AI 定义）意义也在于此。它试图把传统开源的“可使用、可研究、可修改、可分享”原则迁移到AI系统中，并要求提供足以理解和修改系统的信息。即使产业界尚未完全接受该定义，它也为判断“开放权重”“开源AI”“开放模型”之间的差异提供了参照。

从法律实践角度看：开源审查速查表

开源审查速查表：节点、问题与留痕

点击可查看大图

从法律实践角度看，开源审查不应只形成一份抽象法律意见，而应在项目关键节点留下可复核的判断依据。软件、模型和数据项目越复杂，越需要把许可证审查、权利来源审查、架构审查、安全审查和跨境审查放进同一套流程。

使用速查表时，应注意两个原则。第一，表格只能提示审查入口，不能替代个案判断。例如 GPL义务是否触发，仍要结合复制、修改、链接、分发和模块关系分析。第二，审查结论应当证据化。代码来源、组件版本、许可证文本、审批记录、模型训练记录、数据来源、访问权限、员工贡献记录和对外发布记录，都可能在争议、融资、采购、并购或监管问询中成为关键材料。

如果企业暂时无法建立完整系统，至少应先做到三件事：建立开源组件和模型来源台账；对 GPL、AGPL、SSPL、Elastic License、自定义模型许可、未知许可证和跨境发布设置升级审批；在每次产品发布时同步生成许可证清单、NOTICE文件、SBOM或AI BOM、源代码提供说明、模型卡、数据摘要、安全说明和用户使用限制。

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

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

结语：开源的下一阶段，是开放与控制之间的制度重组

开源许可协议走到今天，已经不只是软件行业内部的协作工具。它同时连接著作权、专利、商业秘密、反不正当竞争、出口管制、AI监管和平台竞争。

在传统开源语境下，争议通常集中在代码使用授权和Copyleft义务的触发条件：企业能否复制、修改、集成或分发特定代码，以及在何种情况下需要公开修改部分或衍生作品的源代码。

进入AI时代后，问题被进一步拆解为更复杂的权利链条和责任链条：公开代码或受版权保护作品能否用于模型训练，模型权重是否具有可保护利益，模型输出的权利归属如何判断，许可证能否约束蒸馏模型和合成数据，开放权重能否称为开源，模型发布是否触发出口管制，下游高风险应用又应由谁承担责任。

这些问题目前没有一个统一答案。更准确的判断是：开源许可正在从“源代码许可”走向“技术系统治理”。它不会替代著作权、专利、商业秘密和监管合规，也不会自动化解AI训练数据和模型输出的法律不确定性。但它会继续作为企业组织生态、争夺标准、降低采用门槛和塑造竞争格局的重要工具。

对企业而言，最稳健的态度不是害怕开源，也不是迷信开源，而是把开源放进完整的知识产权和合规战略中：该开放的开放，该隔离的隔离，该保密的保密，该审查的审查。只有这样，开源才不会只是风险来源，而能成为真正的竞争资产。