开源 AI 模型许可证：工程合规与发布门禁

核心摘要

AI 模型不能因为仓库写着「Open」、权重可以下载，或模型卡标注 apache-2.0 就直接获准生产使用。团队必须审查准确发布版本、每一类受覆盖的资产和每一个计划执行的行为。应归档控制性条款，追踪父模型与 Adapter 血缘，把义务转换为可执行控制，并让所有歧义进入人工审批。本文提供工程合规方法，不构成法律意见。

目录

• 开源 AI、开放权重与源码可用的区别
• 绘制完整 AI 资产图
• 如何正确理解许可证家族
• 建立许可证证据优先级
• 按行为审查，而不是按标签判断
• 建立版本化许可证清单
• 增加确定性发布门禁
• 单独评估 EU AI Act 义务
• 批准后的持续运营
• 常见问题
• 总结

核心要点

• 开放权重描述的是交付状态，不是一组许可权利。
• **许可证只覆盖被定义的资产。**代码、权重、数据、Tokenizer、Adapter、输出、文档和托管 API 可能使用不同条款。
• **商用不是一个单一动作。**内部评测、SaaS 推理、权重再分发、微调、发布 Adapter、合成数据和蒸馏都需要独立判断。
• **模型家族名称不能作为证据。**必须固定仓库、Revision、文件 Hash、许可证文本、附加政策和审查日期。
• 自动化可以阻止缺证据或明确禁止的状态，但不能作出法律批准。

开源 AI、开放权重与源码可用的区别

这些标签回答不同问题，不能互换使用。

开放权重模型术语提供了简明定义。最重要的工程边界是：「开放权重」本身不能说明适用的许可权。

OSI 定义将修改机器学习系统所需的首选形式拆成三部分：

1. 数据说明（Data Information）：足够详细地说明训练数据的来源、选择、标注、处理方式，以及可获取数据的位置。
2. 代码（Code）：用于处理数据、训练、验证、测试和运行系统的代码。
3. 参数（Parameters）：权重及其他配置。

当原始训练数据因法律原因无法再分发时，该定义并不要求一律公开全部原始数据，但要求提供规定的数据说明。因此，「数据集必须永远可以下载」和「只有权重也属于开源 AI」都不是对 OSAID 1.0 的准确概括。

绘制完整 AI 资产图

模型合规应从资产图开始，因为一个仓库很少只受一份文件控制。

每个节点都要独立审查：

Hugging Face 元数据标签只适合发现线索。控制性证据是准确发布版本对应的许可证、附加条款和上游资产约束。

如何正确理解许可证家族

许可证家族名称只用于路由审查，不能代替最终判断。

MIT 与 Apache 2.0

MIT 对其覆盖的软件或资产授予广泛版权许可，条件通常包括保留版权和许可声明。MIT 没有明示专利授权，不能把这一点改写为「MIT 隐含授予专利」；任何默示许可论证都取决于法域和具体事实。

Apache License 2.0授予广泛版权许可，并包含贡献者明示专利许可，但只覆盖该贡献者有权许可、且由其贡献单独或与作品组合时必然实施的专利权利要求。再分发条件包括提供许可证、标记已修改文件、保留相关声明，以及当原作品包含 NOTICE 时继续提供其中的署名信息。

两种许可证都不能授予许可方不拥有的权利。权重文件即使采用宽松许可证，也不会自动解决：

• 第三方训练数据或输出权利；
• 第三方专利；
• 名称和商标；
• 隐私、出口管制、消费者、就业或行业法规；
• 不同条款的依赖与父模型。

GPL 与 AGPL

GPL 和 AGPL 是针对软件的 Copyleft 许可证。模型权重、Adapter、生成文件或更大的服务是否属于 Covered Work，不能仅根据许可证家族名称判断。

GNU AGPL v3专门处理通过网络使用修改后受覆盖软件的场景。第 13 条要求运营方为远程交互用户提供该修改版本的 Corresponding Source。这不等于「任何使用 AGPL 代码的 API 都必须公开全部技术栈」。需要记录受覆盖程序是否被修改、用户与什么交互、组件如何组合，再进行专业审查。

RAIL 与 OpenRAIL

RAIL Initiative 官方说明将 RAIL 定义为带有用途限制的许可证类别；OpenRAIL 是其子类，目标是在保留指定用途限制的同时允许免费访问和商业复用。RAIL 可以分别覆盖数据、应用、模型或源码，而且不同变体并不相同。

RAIL Initiative 明确说明 OpenRAIL 因限制用途，不属于 OSI 定义下的开源许可证。不要自建一份所谓「通用 RAIL 禁止清单」，也不要从家族名称推断所有变体允许相同商业行为。应归档准确文本，把每个条款映射到产品控制和下游条款。

社区、研究和定制条款

定制模型许可证可能包含用户或收入阈值、署名、命名、可接受使用政策、地区限制、再分发条件或训练限制。研究或非商用许可证也未必允许销售 Demo、客户试点或支持营收的内部流程。

不要维护一张声称整个模型家族永远使用同一许可证的表格。不同 Checkpoint、模态、蒸馏变体和仓库 Revision 都可能不同。

建立许可证证据优先级

许可证证据应按以下顺序使用：

1. 准确资产 Revision 随附的 LICENSE 文件。
2. 被引用并纳入的附件、可接受使用政策和模型专属条款。
3. 该版本引用的父模型与数据集条款。
4. 同版本、同分发渠道的官方提供方文档。
5. 仓库元数据和模型卡。
6. 只用于发现线索的第三方摘要。

证据冲突时应阻止发布，不能静默选择最宽松解释。

归档内容至少包括：

• 原始文本或 PDF；
• 来源 URL 和获取时间；
• Repository Commit 或不可变 Revision；
• 加密摘要；
• 条款与各资产之间的关系；
• 审查人、决定、假设、有效期和复核触发器。

这样才能证明团队当时审查了什么。只保存一个可能变化或失效的在线 URL 不足以形成审计证据。

按行为审查，而不是按标签判断

每一种计划行为都应有独立决策记录。

「衍生作品」和「输出归属」是法律结论，不是由 Tensor Shape 决定的技术属性。LoRA 大小、量化精度或能否脱离 Base 运行可能是相关事实，但都不能提供统一法律答案。

建立版本化许可证清单

模型许可证清单是采购、法务、算法、数据和发布系统之间的可审查契约。

schemaVersion: ai-license-manifest/v1
artifact:
  id: example-org/example-model
  revision: 4f3c2b1
  sha256: sha256:replace-with-real-digest
  sourceUrl: https://example.org/model/revision/4f3c2b1
lineage:
  baseModels:
    - id: example-org/base-model
      revision: a19d6e0
  adapters: []
terms:
  licenseId: LicenseRef-Example-Model
  licenseSnapshot: legal/licenses/example-model-4f3c2b1.txt
  licenseSha256: sha256:replace-with-license-digest
  additionalPolicies:
    - legal/policies/example-acceptable-use-2026-08-23.pdf
intendedActions:
  - internal-evaluation
  - hosted-inference
  - fine-tuning
prohibitedActions:
  - public-weight-redistribution
  - output-training
controls:
  outputTrainingDataset: blocked
  artifactExport: approval-required
  tenantAuthorization: required
review:
  status: approved-with-conditions
  owner: ai-governance
  approvedBy: legal-review-ticket-1842
  expiresOn: 2026-11-23
  recheckOn:
    - revision-change
    - terms-change
    - lineage-change
    - use-case-change
    - distribution-change

这些值只用于展示结构，不构成许可建议。生产系统应使用内部 LicenseRef-* 标识定制条款，并保存真实文本，不能为了方便而把它强行映射成不准确的 SPDX ID。

增加确定性发布门禁

自动化应该证明证据完整，并执行已经批准的政策，而不是根据模型名称猜测法律许可。

type Manifest = {
  artifact: { id: string; revision: string; sha256: string };
  terms: { licenseId: string; licenseSnapshot: string; licenseSha256: string };
  intendedActions: string[];
  prohibitedActions: string[];
  review: {
    status: "pending" | "approved" | "approved-with-conditions" | "rejected";
    approvedBy?: string;
    expiresOn: string;
  };
};

export function assertReleaseAllowed(
  manifest: Manifest,
  requestedAction: string,
  now = new Date(),
): void {
  const required = [
    manifest.artifact.revision,
    manifest.artifact.sha256,
    manifest.terms.licenseSnapshot,
    manifest.terms.licenseSha256,
  ];

  if (required.some((value) => !value.trim())) {
    throw new Error("License evidence is incomplete");
  }
  if (!manifest.intendedActions.includes(requestedAction)) {
    throw new Error(`Action is outside reviewed scope: ${requestedAction}`);
  }
  if (manifest.prohibitedActions.includes(requestedAction)) {
    throw new Error(`Action is prohibited: ${requestedAction}`);
  }
  if (!manifest.review.status.startsWith("approved")) {
    throw new Error("Human approval is missing");
  }
  if (!manifest.review.approvedBy) {
    throw new Error("Approval evidence is missing");
  }
  if (now >= new Date(`${manifest.review.expiresOn}T00:00:00Z`)) {
    throw new Error("License review has expired");
  }
}

预期行为：

缺少快照或 Hash       -> 阻止
行为未纳入审查范围     -> 阻止
行为被明确禁止         -> 阻止
审批待定或已过期       -> 阻止
已批准且在范围内       -> 继续执行其他发布门禁

最后一种状态被刻意写成「继续」，而不是「法律合规」。它只说明当前门禁找到了该行为此前获批的有效证据；安全、质量、隐私、出口和产品监管门禁仍需独立通过。

单独评估 EU AI Act 义务

许可证审查与 EU AI Act 评估回答的是不同问题。

根据 European Commission 的 GPAI 提供方指南，GPAI 提供方义务从 2025 年 8 月 2 日起适用，Commission 执法权从 2026 年 8 月 2 日起适用，而在 2025 年 8 月 2 日前进入市场的模型提供方需要在 2027 年 8 月 2 日前合规。

指南描述了符合条件的自由开源 GPAI 提供方有限豁免。在规定条件下，可以免除向主管机关维护技术文档、向下游提供文档，以及非欧盟提供方指定欧盟代表等部分义务。版权政策和训练内容摘要义务不会因此消失，具有系统性风险的 GPAI 也不适用该豁免。

不能把这些规则简化成「Apache 许可证等于 EU 豁免」。还需要判断：

• 该资产是否属于 GPAI Model；
• 哪个实体是 Provider；
• 是否以及如何在欧盟市场投放；
• 发布物是否满足法规中的开源条件；
• 模型是否具有系统性风险；
• 修改行为是否让另一个主体成为 Provider；
• 下游 AI System 与 Deployer 还承担哪些独立义务。

Commission 指南本身不具有法律约束力，最终权威解释属于欧盟法院。生产判断应核对当前 consolidated Regulation (EU) 2024/1689 并获取当前法律意见。

系统级控制可继续参考 EU AI Act 技术合规指南和开发者安全清单。

批准后的持续运营

许可证合规是持续变化的发布属性。

复核触发器

发生以下变化时，应自动使批准失效或暂停：

• 模型、Adapter、Tokenizer、Container 或数据集 Revision 变化；
• 许可证、政策或托管 API 条款变化；
• 产品从内部使用转为外部服务或分发；
• 输出开始进入评测、分析或训练流水线；
• 所有权、关联方范围、地区、用户规模或收入口径变化；
• 引入新的模型合并、格式转换、量化或蒸馏。

运行时控制

将条款连接到系统：

• 禁止受限来源的输出进入训练数据集。
• 导出权重、Adapter 或镜像前要求审批。
• 在模型注册表中携带许可证和来源元数据。
• 在可下载包与 Container 中保留必要声明。
• 在模型外执行可接受使用和授权策略。
• 按稳定 Artifact ID、行为、Policy Revision 与审批编号记录决定。

事件响应

当血缘或权限变得不确定时：

1. 停止新部署和再分发。
2. 隔离受影响输出与派生数据集。
3. 通过 Artifact Digest 定位发布版本和客户。
4. 保留条款与决策证据。
5. 升级给法务和安全负责人。
6. 修复、替换、取得许可或撤回资产。
7. 把该失败模式加入发布测试。

常见问题

Apache 2.0 模型是否自动属于开源 AI？

不是。Apache 2.0 可以为其覆盖资产提供符合要求的许可条款，但 OSAID 1.0 还审查修改系统所需的首选形式，包括数据说明、训练与运行代码和参数。必须检查完整发布物，而不是只看权重文件的 License Tag。

自托管是否可以避开许可证义务？

自托管会改变数据流，也可能不再适用托管提供方的 API 条款，但下载资产的条款仍然适用。内部使用、外部服务和再分发可能触发不同条件，隐私、出口、安全和产品法规也仍然存在。

模型卡能否覆盖 LICENSE 文件？

不能直接假定。模型卡可能摘要或引用条款，但一旦冲突，就需要核对许可证、被纳入的政策、仓库 Revision 与发布主体权限。控制性证据未解决前应阻止发布。

CI 扫描器能否判断模型可以安全商用？

不能。它可以校验 Hash、证据、已批准行为、有效期、声明和显式策略，但不能仅凭元数据判断版权属性、衍生作品、专利清理、合同解释或监管角色。

团队是否应该永远选择 MIT 或 Apache 2.0 模型？

不是。宽松许可证可以减少许可摩擦，但模型质量、安全、数据权利、专利风险、支持、隐私、出口管制和行业监管仍然存在。应选择完整能力与风险画像满足工作负载的准确版本。

总结

AI 模型许可证应被视为供应链与发布控制问题。团队需要固定准确资产，映射代码、权重、数据、输出、派生物和服务条款，再逐项审查计划行为。自动化只负责阻止证据不完整或超范围的发布，条款解释仍由人工审批；EU AI Act 与其他法规也必须独立于许可证标签进行评估。

相关资源

• 开放权重模型术语
• 大语言模型术语
• 模型服务术语
• LLM 微调指南
• 小语言模型部署指南
• EU AI Act 技术合规指南
• OSI《开源 AI 定义 1.0》
• Apache License 2.0
• GNU AGPL v3
• RAIL Initiative FAQ