土法炼钢兴趣小组的算法知识备份

【开源许可与版权工程】模型许可证深度解析：OpenRAIL-M、LLaMA、Apache 2.0 在大模型场景的真实区别

2026-04-22 · architecture · opensource · #model-license #openrail #llama #gemma #apache2 #bloom #stablelm #mistral #qwen #deepseek #ai-license #responsible-ai #use-based-restriction

文章导航

分类入口
architectureopensource
标签入口
#model-license#openrail#llama#gemma#apache2#bloom#stablelm#mistral#qwen#deepseek#ai-license#responsible-ai#use-based-restriction

目录

如果你今天打开 HuggingFace，随便点开一个热门模型，把 README.md 顶部的 license: 字段抽出来，大概率会看到这几种值：apache-2.0、mit、llama3.1、gemma、openrail、other。再点进去，发现每个都不完全一样——有的多出一份《Acceptable Use Policy》，有的要求商用超过某个用户量门槛必须去申请单独的协议，有的明确禁止做军事用途，有的允许蒸馏但禁止生成训练数据。

所谓「开源模型」在 2024—2025 年已经变成了一个光谱：一端是真正的 Apache 2.0 / MIT 纯宽松，一端是「下载免费、条款密密麻麻」的 source-available。工程团队在选型、微调、商用分发时，必须把这个差异看清楚，否则随时会踩到「你以为是开源、其实是有限使用许可」的陷阱。

本系列第十篇已经从文档、数据、模型三个客体的角度把 CC、ODbL、OpenRAIL、LLaMA 做了一个全景概览。本文聚焦「模型权重」这一个客体，把八类主流模型许可证逐条拆开，配合条款比较表、工程决策清单、真实事件，回答下面几个问题：

本文不是法律意见，是工程参考。所有条款引用以官方发布文本为准；对 2025—2026 年的条款变动会明确标注出处。

一、模型权重的法律客体定性问题

在讨论任何模型许可证之前，必须先问一个基础问题：模型权重到底是什么？ 这个问题不解决，许可证的法律基础就是空中楼阁。

1.1 权重的三种定性候选

主流学界和立法机关讨论的候选至少有三种。

候选一：软件（Software）。 权重文件（.safetensors、.gguf、.bin）是计算机可读的二进制数据，加载到 PyTorch / Transformers 里就能执行推理，从功能上讲「像软件」。在这种定性下，著作权法把它当作「计算机程序」（computer program）保护，软件许可证——MIT、Apache 2.0——可以直接适用。

候选二：数据库（Database）。 权重本质是由训练数据通过梯度下降「压缩」出来的几十亿到几千亿个浮点参数。它不是人类写出来的，也不是一段能独立执行的指令，而是一种「参数化的知识表示」。按照欧盟 1996 年《数据库指令》（Directive 96/9/EC）的框架，它更像一个「具有实质性投入的数据库」，适用 sui generis database right（数据库特别权利）。

候选三：无著作权客体（Non-copyrightable Subject Matter）。 如果权重的产生完全由训练算法自动完成，没有人类作者的「独创性表达」参与，那么在美国 Feist 案和 Thaler 案（Thaler v. Perlmutter, 2023）的原则下，它可能根本不受著作权法保护。在这种定性下，任何「模型许可证」都不是著作权许可，只能靠合同法（contract law）与商标法（trademark law）约束下游。

1.2 三地的倾向

不同司法区的倾向目前还不一致。

司法区 主流学说倾向 实际影响
美国 偏「合同法 + 商标」。USCO 2023—2024 的报告明确，纯 AI 生成内容不享有版权；权重是否可版权化未下定论，但保守派主张不可版权化 发布方倾向用商标（模型名）+ 服务条款（ToS）+ 合同约定约束下游，而不是单纯依赖著作权
欧盟 更接受 sui generis database right 或「计算机程序」解释，因为欧盟立法对「机器生成的实质性投入」已有保护传统 OpenRAIL-M 在欧盟语境下更像真正的版权许可；AI Act 对通用 AI 模型有披露义务
中国 著作权法保护「作品」，强调独创性。模型权重是否构成作品无司法先例。实践中发布方多采用合同约束 + 注册商标 企业发布方更愿意使用「社区协议」形式，同时借助不正当竞争法、反不正当竞争法兜底

1.3 实际意义：为什么这件事关工程决策

这个定性问题看起来是法学院的争论，但它会直接影响你能否在某个权重上主张权利、能否起诉下游、能否把协议强制执行。

举三个工程上真实会遇到的场景：

场景 A：你发布了 Apache 2.0 的模型，发现下游没有保留你的 NOTICE 文件。 如果权重不是「作品」，Apache 2.0 的著作权许可基础就不成立；你只能诉诸商标（若你注册了模型名）或合同（若下游点击接受过 ToS）。

场景 B：你自己训练了一个基模，想「开源免费、但禁止军事用途」。 如果权重不是作品，你的「禁止军事」条款就不是版权许可的限制，而是合同限制——合同只对签约方有约束力，不能约束「任意第三方」。这就是为什么 OpenRAIL-M 要求下游再分发时必须传递协议文本（后面会细讲）。

场景 C：你下载了 LLaMA 3，做了微调，微调权重里还剩多少是 Meta 的「表达」？ 法律上没有定论；工程上通常保守假设「微调权重仍属衍生作品」，受原协议约束。

本文后续章节会反复提醒：模型许可证的法律基础尚未完全确定，工程上应当采取「协议叠加」策略（著作权 + 合同 + 商标 + 服务条款），而不是把全部希望寄托在某一条著作权主张上。

二、开源、开放权重、源可得：三个概念的精确区分

「开源模型」这四个字，在 2023—2024 年被用得极其混乱。Meta 管 LLaMA 叫「open-source」，Mistral 早期坚称自己是「open-weights」，Stability AI 用「open access」，智谱 GLM 用「开源社区协议」。这些词到底什么区别？

2.1 三个概念的定义

开源（Open Source）：在 OSI 定义下，必须满足《开源定义》（The Open Source Definition，OSD）的 10 条准则。2024 年 10 月 28 日 OSI 正式发布《开源 AI 定义》（Open Source AI Definition，OSAID）1.0，把 OSD 扩展到 AI 系统。OSAID 要求一个模型同时公开：

  1. 训练所用的完整源代码（训练、推理、评估）；
  2. 「数据信息」——足以让有相当技能的人复现一个功能等效的模型的训练数据描述，包括来源、筛选、处理步骤；
  3. 模型权重与关键参数。

并且这三项都要以允许「使用、研究、修改、分享」自由的许可证发布。注意 OSAID 没有要求训练数据本身必须公开——这是一个经过激烈讨论后的妥协，被 Software Freedom Conservancy 等组织批评为「不够严格」。

开放权重（Open Weights）：只公开模型权重文件，允许下载、推理，但训练代码、训练数据、训练日志可以不公开。LLaMA、Gemma、Qwen 基模权重基本都是这种状态。

源可得（Source Available）：协议可能对使用、商用、再分发有限制（比如 BSL、Commons Clause），但源码/权重可以下载。LLaMA Community License、Gemma Terms of Use 属于这一类——你可以看、可以改，但商用有门槛、有禁用场景。

2.2 OSAID 与主流模型的碰撞

2024 年 10 月 OSAID 发布当天，一个有趣的现象是：大多数被称作「开源」的大模型，都不满足 OSAID 1.0。

模型 权重协议 训练代码 训练数据信息 是否符合 OSAID 1.0
LLaMA 3.1 LLaMA 3.1 Community License（自定义） 部分公开 未完整披露 否（协议限制 + 数据不透明）
Gemma 2 Gemma Terms of Use（自定义） 部分公开 未完整披露 否
Mistral 7B Apache 2.0 推理代码公开 未披露 否（数据信息不足）
Qwen2.5 Apache 2.0 推理代码公开 未完整披露 否（数据信息不足）
DeepSeek-R1 MIT 推理代码公开 技术报告披露部分管线 部分符合
BLOOM BigScience RAIL 完整公开 完整披露 接近符合（协议自由度争议）
OLMo 2 (AI2) Apache 2.0 完整公开 完整公开（Dolma 数据集） 符合
Pythia (EleutherAI) Apache 2.0 完整公开 完整公开（The Pile） 符合

结论非常直接：真正满足 OSAID 的是 AI2、EleutherAI 这类研究机构发布的模型；商业公司发布的「开源模型」几乎都只是「开放权重」或「源可得」。

2.3 为什么 Meta 坚持 LLaMA 是「开源」

Meta 一直把 LLaMA 称为「open-source」，这在 OSI 看来是误用。Meta 的立场有两点：

  1. LLaMA Community License 允许几乎所有研究、开发、商业使用（除非你是 7 亿月活以上的巨头），在「实际效果」上接近开源；
  2. OSI 的定义是 OSI 的，不是法律定义；Meta 没有义务遵守。

这场争论在 2024 年 Q4 很激烈，Linux Foundation 的 OpenMDW（Open Model Definition Working）工作组也在推动自己的定义。工程团队在沟通时，建议避免使用「开源模型」一词表达模糊含义；明确说「Apache 2.0 模型」「LLaMA 协议模型」「OpenRAIL 模型」会减少误会。

三、八类模型许可证逐条拆解

本节把当前主流的八类模型许可证逐一过一遍，每一类给出：一句话判断、条款要点、工程影响、真实案例。

3.1 Apache 2.0 / MIT：宽松派

一句话判断：除了专利条款（Apache）和署名要求（两者都有），几乎没有任何使用、分发、商用限制；对工程团队最友好。

条款要点（Apache 2.0）：

条款要点（MIT）：

工程影响：

下游可以无条件商用、闭源私有化部署、再许可甚至换协议重发（MIT 与 Apache 2.0 协议互相兼容，向 Apache 2.0 合并无障碍）。对企业微调、商业 SaaS、本地部署都最友好。

真实案例：

从 HuggingFace card 读取协议：

from huggingface_hub import HfApi, ModelCard

def get_license(repo_id: str) -> str:
    card = ModelCard.load(repo_id)
    return getattr(card.data, "license", None) or "unknown"

for m in ["Qwen/Qwen2.5-7B", "deepseek-ai/DeepSeek-R1",
          "mistralai/Mistral-7B-v0.1", "meta-llama/Llama-3.1-8B"]:
    print(m, get_license(m))

Apache / MIT 的模型会直接返回 apache-2.0 / mit；LLaMA / Gemma 会返回 llama3.1 / gemma，提示你需要点击接受单独协议。

3.2 OpenRAIL-M 家族：责任 AI 派

一句话判断：权重可以免费商用，但必须传递一份「禁用场景清单」（Use-Based Restrictions），下游微调者也要把这份清单传下去。

协议谱系：

条款要点（以 BigScience OpenRAIL-M 为例）：

  1. 第 II.1 节：授予「不可撤销、全球、非独占、免版税、可再许可」的许可（只要遵守附件 A）；
  2. 第 IV 节 Distribution and Redistribution：下游再分发（无论修改与否）必须：
    • 包含原协议完整副本；
    • 让最终用户看到附件 A 的 Use-Based Restrictions；
    • 将 Use-Based Restrictions 作为 enforceable provisions 加入下游自己的协议；
  3. 第 V 节 Derivatives：微调、蒸馏、量化产生的衍生模型仍受本协议约束；
  4. 附件 A Use-Based Restrictions：13 条禁用场景（见下节）；
  5. 无担保 + 有限责任；
  6. 模型卡（Model Card）要求：发布者应提供模型卡，披露已知偏见、限制、预期用途。

工程影响：

真实案例：

注意 SDXL 的协议变化：Stability AI 在 2023 年 7 月发布 Stable Diffusion XL（SDXL）时，把协议从 OpenRAIL-M 换成了自己的 Stability AI Non-Commercial License + Stability AI Community License（2024 年），商用必须满足年收入低于 100 万美元的门槛，高于此必须购买 Enterprise License——这已经不是 OpenRAIL-M 了，工程团队必须注意版本差异。

3.3 LLaMA 系列自定义协议：巨头护城河派

一句话判断：对绝大多数公司免费商用开放，但用 LLaMA 输出训练其他模型、以及「巨头用户」有额外限制；不是真正的开源。

协议版本演变：

版本 发布时间 协议名 核心特征
LLaMA 1 2023-02 仅研究许可 禁止商用；靠 Torrent 泄露进入社区
LLaMA 2 2023-07 LLaMA 2 Community License 允许商用，月活 7 亿门槛；禁用政策（Acceptable Use Policy）挂外链
Code LLaMA 2023-08 LLaMA 2 Community License（沿用） 同上
LLaMA 3 2024-04 LLaMA 3 Community License 结构与 LLaMA 2 类似；增加「命名要求」（Llama 前缀）
LLaMA 3.1 2024-07 LLaMA 3.1 Community License 新增：用 LLaMA 输出训练其他 LLM 时，衍生模型名称必须以 Llama 开头
LLaMA 3.2 2024-09 LLaMA 3.2 Community License 对多模态 11B/90B，在欧盟地区用户被排除
LLaMA 3.3 2024-12 LLaMA 3.3 Community License 延续 3.1 条款

7 亿月活门槛原文（LLaMA 2 Community License §2）：

If, on the Llama 2 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion, and you are not authorized to exercise any of the rights under this Agreement unless or until Meta otherwise expressly grants you such rights.

关键细节：

命名与归因要求（LLaMA 3 / 3.1）：

工程影响：

真实案例：

3.4 Gemma：Google 的自定义 Terms of Use

一句话判断：条款结构类似 LLaMA，允许商用、有禁用政策，但没有 MAU 门槛；多模态和新版本频繁微调条款。

协议名：Gemma Terms of Use（https://ai.google.dev/gemma/terms）

条款要点：

禁用政策（Gemma Prohibited Use Policy）涉及：生成 CSAM、暴力极端、未经授权的医疗 / 法律 / 金融建议（在不符合专业审查时）、关键基础设施攻击、特定人群的歧视性系统、故意规避安全机制等。

工程影响：

真实案例：

3.5 Mistral：从 Apache 2.0 到「部分闭源」的漂移

一句话判断：Mistral 的基模一开始全部 Apache 2.0，但从 2024 年起，「旗舰模型」逐渐转向非开放协议；同一品牌下存在多种协议。

协议版本：

2024 年的争议：

2024 年 2 月 Mistral 与微软签订战略合作协议，同时把旗舰产品 Mistral Large 设为闭源。社区大量批评「Mistral 偷偷闭源」，Mistral 的回应是：「我们继续开放社区模型（Mistral 7B、Mixtral 系列），但旗舰级别模型需要商业化支撑研究」。

工程影响：

真实案例：

3.6 BigScience OpenRAIL、OpenMDW（2025）与 ML-at-scale 协议

一句话判断：BigScience 系的协议强调责任 AI 传递义务；2025 年 Linux Foundation 的 OpenMDW 尝试做「更中立、更工程化」的定义。

BigScience 系：

OpenMDW（Open Model Definition and Weights）：

Linux Foundation 在 2025 年 6 月宣布的新协议框架，目标是让「权重、模型卡、训练配置」三件套以统一方式发布。当前仍在草案阶段，尚未大规模采用；值得关注的是 OpenMDW 明确：

真实案例：

3.7 Falcon 与 TII：中东派

一句话判断：Falcon 7B/40B Apache 2.0，Falcon 180B 用自定义 TII Falcon License（带使用限制）。

TII Falcon License 要点：

真实案例：

3.8 中国特色协议：Tongyi Qianwen、GLM、Baichuan、Yi、DeepSeek

一句话判断：中国模型厂商 2023—2024 年普遍使用「社区协议」，2024 年以后大多转向 Apache 2.0 / MIT。

Tongyi Qianwen License Agreement（通义千问许可协议）：

GLM License（智谱）：

Yi License（零一万物）：

Baichuan License：

DeepSeek Model License：

中国模型协议演化规律：

  1. 2023 年：多数采用自定义「社区协议」，商用需申请；
  2. 2024 年：主流厂商（阿里、深度求索、零一万物）逐步转 Apache 2.0 / MIT，对标国际主流；
  3. 2025 年：Apache 2.0 / MIT 成为中国旗舰开源模型的标配；部分专用模型（视觉生成、特定垂域）仍保留自定义协议。

这个转向的背后原因很现实：社区协议的法律效力在跨境场景下存疑，而 Apache 2.0 / MIT 有全球司法认可度。企业想让自己的模型被海外开发者、云厂商大规模使用，最简单的办法就是选 Apache 2.0。

四、条款要点纵向比较表

下表把主流模型协议在工程团队最关心的 10 个维度上横向对比。所有信息以本文撰写时官方发布文本为准；条款可能随版本变化，生产环境使用前请复核。

维度 Apache 2.0 MIT OpenRAIL-M LLaMA 3.1 Gemma Mistral MRL Qwen License DeepSeek ML
商用 可 可 可 可（有 MAU 门槛） 可 仅研究 可（部分有 MAU 门槛） 可
再分发 可 可 可（须传协议 + UBR） 可（须命名带 Llama） 可（须传禁用政策） 受限 可（须保留协议） 可
修改 / 微调 可 可 可（衍生继承协议） 可（衍生继承） 可（衍生继承） 研究目的可 可 可
衍生模型协议继承 无 无 强制继承 UBR 强制继承 + 命名 强制继承禁用政策 强制 部分继承 不强制
禁用场景 无 无 附件 A 13 条 AUP 外链 Prohibited Use Policy 有 有 少量
专利授权 有（§3） 无 有 有 有 有 有 有
商标授权 无（§6） 无 无 有限：强制 Llama 前缀 有限：Gemma 是商标 有限 有限 有限
MAU 商用门槛 无 无 无 7 亿月活 无 无 早期有（1 亿） 无
下游披露要求 NOTICE 文件 版权声明 模型卡 + UBR “Built with Llama” + 模型卡 禁用政策链接 + 归因 归因 归因 归因
出口管制 无 无 无 AUP 含 隐含（Google 合规） 隐含 中国法域适用 中国法域适用

几个关键观察：

  1. 只有 OpenRAIL-M 家族的「禁用场景传递」是协议文本硬约束。LLaMA / Gemma 也有禁用政策，但 OpenRAIL-M 把它写成「下游分发必须加入可执行条款」——这是最严的责任 AI 落地方式。
  2. 只有 LLaMA 有硬性 MAU 门槛写在协议正文。Qwen 早期版本也有类似条款，但 Qwen2.5 以后已转 Apache 2.0。
  3. Apache 2.0 是唯一「专利条款 + 无其他限制」的协议。这是它在工程团队中最受欢迎的原因。
  4. 商标约束（名字必须含某前缀）是 LLaMA 3.1 之后的新特色，标志模型协议从「版权约束」向「商标 + 合同约束」迁移。

五、OpenRAIL-M 的 Use-Based Restrictions 工程化

OpenRAIL-M 最独特的机制是使用场景限制（Use-Based Restrictions，UBR）。本节把这 13 条落地到实际工程系统。

5.1 附件 A 的 13 条

以 BigScience OpenRAIL-M 附件 A 为基础，Use-Based Restrictions 涵盖（原文为英文，此处中文摘要以工程落地为目的）：

  1. 违反任何适用法律或法规的方式使用；
  2. 以造成或促成未成年人受伤害的方式使用；
  3. 生成或传播经过验证的虚假信息，且有伤害意图；
  4. 生成或传播涉及他人的个人身份信息（PII），用于伤害该个人；
  5. 诽谤、贬低或以其他方式骚扰他人；
  6. 在没有明确法律权利的情况下，用于或代替完全自动化的决策，对个人法律权利产生不利影响；
  7. 基于在线或离线社会行为或已知 / 预测个人或人格特征，对自然人进行歧视或伤害；
  8. 利用特定人群（年龄、残疾、社会 / 经济情况）的脆弱性，实质性扭曲行为并致身心伤害；
  9. 基于受法律保护的特征进行歧视；
  10. 用于提供医疗建议、医疗结果解释——除非符合法律合规；
  11. 用于生成或传播用于司法、执法、移民或庇护程序的信息，且产生不准确结果；
  12. 用于预测犯罪或犯罪嫌疑人的概率（predictive policing）；
  13. 用于未经授权 / 违反任何适用法规的生物识别类别化系统。

OpenRAIL-M 规定，发布者可以增加限制条款，但不能删除已有的 13 条。也就是说，13 条是「禁用基线」，衍生协议可以更严但不能更松。

5.2 在 API Gateway 层的落地

如果你提供 OpenRAIL-M 协议模型的推理服务（无论是对外还是对内），工程上至少要做以下三层：

第一层：服务条款（ToS）硬编码

把 UBR 13 条写入你的 API Terms of Service，明确「用户在调用本 API 时承诺不用于上述场景」。ToS 点击同意是合同法层面的约束。

第二层：Gateway 侧的输入 / 输出分类器

对高风险场景做分类器拦截。典型做法：

# pseudo-code: gateway rail filter
class RailFilter:
    def __init__(self, policies: list[str]):
        self.classifier = load_policy_classifier(policies)

    def check_input(self, prompt: str) -> dict:
        scores = self.classifier.score(prompt)
        for policy in self.policies:
            if scores[policy] > self.threshold[policy]:
                return {"allow": False, "policy": policy, "score": scores[policy]}
        return {"allow": True}

    def check_output(self, text: str) -> dict:
        return self.check_input(text)

# in request handler
pre = rail.check_input(req.prompt)
if not pre["allow"]:
    audit_log(user=req.user, policy=pre["policy"], stage="input")
    return 451, {"error": "use-based-restriction", "policy": pre["policy"]}

resp = llm.generate(req.prompt)
post = rail.check_output(resp)
if not post["allow"]:
    audit_log(user=req.user, policy=post["policy"], stage="output")
    return 451, {"error": "use-based-restriction", "policy": post["policy"]}

return 200, {"text": resp}

分类器本身可以是一个小模型（比如 Llama Guard、Granite Guardian、ShieldGemma 等），也可以是规则式拦截。重点是拦截事件要记录审计日志，这是事后合规可追溯的基础。

第三层：事后审计与事故响应

5.3 模型卡（Model Card）的合规要求

OpenRAIL-M 要求发布者提供 Model Card，披露至少以下维度（细节按协议条款）：

HuggingFace 的 README.md frontmatter + Model Card 章节已经成为行业标准，Meta、Google、BigScience 都在用：

---
license: bigscience-openrail-m
tags:
  - text-generation
model-index:
  - name: example-model
    results: []
intended_use: "研究与对话生成"
out_of_scope_use:
  - "医疗诊断"
  - "司法判决辅助"
  - "未成年人单独使用"
---

5.4 与 Llama Guard / ShieldGemma 的组合

一个常见的工程简化做法：同一个 Guard 模型同时服务多个协议。

工程落地时把每个 Guard 输出的 label 映射到协议要求的具体条款。比如 Granite Guardian 输出 harm、social_bias、violence、sexual_content 等 label，你在 gateway 侧配置「哪些 label 对应 OpenRAIL-M 附件 A 的哪条」——这个映射表是下游 policy engine 的核心配置，会随协议版本更新。

一个典型的三层协议-Guard 对应表：

协议 Guard 模型 触发 label → 协议条款映射 拦截动作
OpenRAIL-M Granite Guardian violence → 附件 A §1, social_bias → §7/§9 返回 451 + 审计
LLaMA 3.1 Llama Guard 3 S1-S14 分类 → AUP 对应段落 拒绝 + 记录
Gemma ShieldGemma dangerous/harassment/hate/sexual → Gemma PUP 降级改写 或 拒绝

这一层配置应当随协议更新而 bump 版本，并在模型卡中注明「本服务执行 OpenRAIL-M 附件 A v1.0 + LLaMA AUP 2024-07 版」这类可追溯的时间戳。

5.5 下游微调者的义务传递

这是 OpenRAIL-M 工程落地里最容易忽视的一点：你微调 BLOOM / StarCoder 得到的衍生模型，上传 HF 时必须保留 OpenRAIL-M 协议 + 附件 A。

常见违规姿势：

HuggingFace 在 2024 年以后加强了 license 元数据校验，但仍无法自动检测协议文本篡改。工程团队在内部发布前，应该用自动化脚本比对协议文件与基模协议是否一致。

六、四个工程场景的决策清单

本节把前面的条款拆解，映射到工程团队最常见的四个场景。

6.1 场景 A：自研基模，选 Apache 2.0 还是 OpenRAIL-M

决策维度：

一般建议：

情形 推荐
通用基模，面向开发者生态 Apache 2.0（最大化采纳）
面向特定敏感领域（医疗、法律） OpenRAIL-M（强化禁用场景）
视觉生成 / 声音生成模型 CreativeML Open RAIL-M 或自定义 + UBR
企业 + 想保留商业化空间 双协议：开源版 + Commercial License（Mistral、Stability 模式）
研究性发布，不希望商业化 CC BY-NC、Mistral Research License

一个朴素的判断：如果你希望你的模型像 transformers 一样被海量 clone，选 Apache 2.0；如果你更在意「这个模型不被滥用」，选 OpenRAIL-M。

6.2 场景 B：微调商用，从 LLaMA / Gemma / Qwen 出发

核心问题：

  1. 你所属实体的 MAU 是否超过门槛？
  2. 下游分发（app、SaaS、on-prem）怎么满足归因要求？
  3. 微调权重上传 HF 还是内部私有化？

LLaMA 3.1 微调商用工作流：

  1. 准入核查：MAU < 7 亿？（绝大多数公司满足）；欧盟机构用户？（3.2 多模态受限）；
  2. 命名检查：衍生模型名带 Llama 前缀（比如 Llama-3.1-MedChat-v1）；
  3. 归因展示：App 底部 / 模型卡 / 文档中显著标注「Built with Llama」；
  4. 模型卡完备：保留 LLaMA 3.1 License 链接，说明基模、微调数据、评测；
  5. ToS 同步更新：把 LLaMA AUP 条款纳入下游用户协议；
  6. 上传 HF：license: llama3.1，附 LICENSE.txt 副本。

阿里云 ModelScope 的托管模式（有代表性）：

ModelScope 把 Qwen、LLaMA、百川等多协议模型托管在一个平台。当用户下载这类模型时，平台会弹出协议接受 UI，用户必须勾选「我已阅读并同意」。这一层是合同法强化：即便底层著作权不成立，合同关系也已建立。工程团队自己在企业内部搭建模型仓库（MLOps 平台）时，也应该复用这一思路——给下载加 ToS gate。

6.3 场景 C：内部使用与私有化部署

「内部使用」场景下，大多数协议的约束都会变弱：

私有化部署给客户算不算分发？——算。你交付给客户的容器镜像、on-prem 安装包，已经离开你的控制范围，是明确的 convey / distribution。你必须履行所有再分发义务。

工程做法：

6.4 场景 D：二次分发（merge / 量化 / 蒸馏）的许可溯源

这是近年最容易出事的场景。

量化版本：权重的数值表示变化（FP16 → INT8 / INT4），但语义权重一一对应——公认为衍生作品，继承原协议。上传 HF 时要在模型卡中注明量化来源与原协议。

蒸馏版本：学生模型用老师模型的输出训练——协议的允许与否，要看原协议：

Merge 模型：把两个或多个模型的权重加权合并（task arithmetic、TIES、DARE、SLERP）——许可证必须同时兼容：

HuggingFace 的 model tree / base_model 元数据是溯源的官方机制。上传 merge / 量化模型时，frontmatter 应该写：

---
base_model:
  - meta-llama/Llama-3.1-8B-Instruct
  - Qwen/Qwen2.5-7B-Instruct
tags:
  - merge
license: other
license_name: llama3.1-and-apache-2.0
license_link: LICENSE.txt
---

这样 HF 的 UI 会显示一个 model tree，点击可以追溯全部祖先。工程团队在选用 merge 模型进生产前，务必沿树追溯每个叶子的协议。

七、微调模型的许可继承

微调是大模型时代最常见的工程操作，也是协议继承最复杂的场景。

7.1 全量微调：无争议继承

Full-parameter SFT / DPO 产生的权重是对原权重的直接修改，无争议地构成衍生作品，继承原协议。

7.2 QLoRA / LoRA：adapter 权重是否衍生

LoRA / QLoRA 把微调参数隔离在 low-rank adapter 中，原始权重不动。严格从二进制角度看，adapter 文件本身不包含原权重的拷贝。但：

具体条款：

7.3 合并两个不同许可证模型的冲突

合并（merge）操作把多个基模的权重按某种运算合并。此时权重空间同时包含多份基模的「表达」，协议继承采取「并集」原则：

工程上：不要 merge 许可证不兼容的模型。典型不兼容案例：

7.4 HuggingFace model tree 与 tag 机制

HuggingFace 在 2023—2024 年逐步加强模型溯源机制：

工程团队建立内部模型仓库时，也应该复制这一机制：

CREATE TABLE model_registry (
    model_id     TEXT PRIMARY KEY,
    base_models  JSON,              -- ["meta-llama/Llama-3.1-8B"]
    relation     TEXT,              -- finetune | merge | quantized | distilled | adapter
    license      TEXT,
    license_file TEXT,              -- 本地路径或 URL
    use_based    JSON,              -- UBR 清单
    registered   TIMESTAMP
);

有了这张表，合规审计只要一句 SQL 就能找出「所有基于 LLaMA 的模型」「所有受 UBR 约束的模型」。

八、真实事件复盘

本节挑选 2023—2025 年有代表性的真实事件，看协议在真实商业场景下的执行情况。

8.1 Stability AI SDXL 协议变更

事件：2023 年 7 月 Stability AI 发布 SDXL 1.0，初期采用 CreativeML Open RAIL++-M（较 SD 1.x 略有增强的 OpenRAIL-M 变体）；2024 年 Stability AI 财务危机，推出 Stability AI Community License（年收入 < 100 万美元可免费商用，高于需购买 Enterprise License），把 SDXL、SD3 纳入其中。

工程影响：

教训：下载权重时要同时下载当期协议文本。如果你基于某个日期的 SDXL 做了商用，你的授权就是那一天的协议文本，后续升级不自动适用。

8.2 Mistral 被指责「偷偷闭源」

事件：2024 年 2 月 Mistral 与微软合作后，旗舰 Mistral Large 闭源。社区（尤其是欧洲开源社区）激烈批评。Mistral 澄清：Mistral 7B、Mixtral 系列仍 Apache 2.0。

工程影响：

8.3 Databricks DBRX 条款

事件：Databricks 在 2024 年 3 月发布 DBRX（132B MoE），协议名 Databricks Open Model License。

条款特点：

工程影响：

8.4 Meta LLaMA 对「商用超 7 亿」条款的实际执行

Meta 很少公开执行过这一条款。已知的案例：

教训：MAU 门槛的实际价值不是「收费」，而是「排除竞争对手」。它的威慑作用比实际执行更重要。

8.5 DeepSeek-R1 的 MIT 与合成数据生态

事件：2025 年 1 月 20 日，DeepSeek 以 MIT 发布 R1，显式允许蒸馏、允许用输出训练其他模型。

连锁反应：

教训：协议选择就是生态战略。DeepSeek 选 MIT 不是偶然，是在 LLaMA 商标限制下，用最松的协议抢占蒸馏生态。

8.6 Tongyi Qianwen License 的演化

通义团队在协议问题上的轨迹也值得复盘：

协议放宽的商业逻辑：云厂商（阿里云 PAI / 百炼平台）通过托管服务变现，权重本身的协议对企业战略影响已经有限；Apache 2.0 换来全球开发者采纳，长期 ROI 更高。

8.7 Meta LLaMA 3.2 的欧盟排除

2024 年 9 月 Meta 发布 LLaMA 3.2 多模态（11B / 90B）时，单方面在协议中排除欧盟机构用户与欧盟居民，原因是 Meta 对欧盟 AI Act 的合规成本评估不确定。这一做法在欧盟开源社区引起强烈反弹。

工程影响：

教训：协议可以单方面对地理区域做裁剪；企业在选用某个基模时，要确认当期协议对你所在司法区的可用性。

九、决策树：从零开始选模型许可证

下面这个决策树可以帮你快速定位合适的协议。

flowchart TD
    A[我要发布一个模型] --> B{是基模还是微调?}
    B -->|基模| C{是否希望最大化生态采纳?}
    B -->|微调| M{基模是什么协议?}

    C -->|是| D{是否有强烈的伦理责任诉求?}
    C -->|否 想商业化| E{想不想同时开放研究版?}

    D -->|无| F[Apache 2.0 / MIT]
    D -->|有| G[OpenRAIL-M 或 BigCode OpenRAIL-M]

    E -->|想| H[双协议: 社区版 + Commercial License]
    E -->|不想| I[完全闭源 + API]

    M -->|Apache 2.0 / MIT| N[衍生可按原协议 或 更严]
    M -->|LLaMA 3.x| O[必须保留 LLaMA 协议<br/>名字带 Llama<br/>MAU 门槛]
    M -->|Gemma| P[必须保留 Gemma 协议<br/>传递禁用政策]
    M -->|OpenRAIL-M| Q[必须保留协议<br/>传递 UBR 13 条]
    M -->|Mistral MRL| R[仅研究 不能商用]

    F --> Z[发布]
    G --> Z
    H --> Z
    I --> Z
    N --> Z
    O --> Z
    P --> Z
    Q --> Z
    R --> Z

    style F fill:#3fb950,stroke:#2d333b,color:#2d333b
    style G fill:#a371f7,stroke:#2d333b,color:#ffffff
    style H fill:#388bfd,stroke:#2d333b,color:#ffffff
    style I fill:#f85149,stroke:#2d333b,color:#ffffff
    style N fill:#3fb950,stroke:#2d333b,color:#2d333b
    style O fill:#f0883e,stroke:#2d333b,color:#2d333b
    style P fill:#f0883e,stroke:#2d333b,color:#2d333b
    style Q fill:#a371f7,stroke:#2d333b,color:#ffffff
    style R fill:#f85149,stroke:#2d333b,color:#ffffff

用法：

十、license-check 自动化脚本

最后给一段可以直接嵌入 CI 的脚本，检测项目所使用的所有模型是否符合内部白名单。

#!/usr/bin/env python3
# ai-license-check.py
# 扫描 HuggingFace 缓存与 YAML 配置，列出所有用到的模型与协议。
from pathlib import Path
from huggingface_hub import ModelCard, HfApi
import yaml, sys

WHITELIST = {
    "apache-2.0", "mit", "bsd-2-clause", "bsd-3-clause",
    "bigscience-openrail-m", "openrail", "creativeml-openrail-m",
}
# 有限放行:需要走合规流程
REQUIRES_REVIEW = {
    "llama3.1", "llama3.2", "llama3.3", "llama3",
    "gemma", "bigcode-openrail-m", "other",
}

def check_model(repo_id: str) -> tuple[str, str]:
    try:
        card = ModelCard.load(repo_id)
        lic = (getattr(card.data, "license", None) or "").lower()
        lic_name = (getattr(card.data, "license_name", None) or "").lower()
        tag = lic or lic_name or "unknown"
    except Exception as e:
        tag = f"error:{e.__class__.__name__}"
    if tag in WHITELIST:
        return "pass", tag
    if tag in REQUIRES_REVIEW:
        return "review", tag
    return "block", tag

def main(config: str):
    cfg = yaml.safe_load(Path(config).read_text())
    models = cfg.get("models", [])
    fail = 0
    for m in models:
        status, lic = check_model(m)
        print(f"{status:7s} {m:50s} {lic}")
        if status == "block":
            fail += 1
    sys.exit(1 if fail else 0)

if __name__ == "__main__":
    main(sys.argv[1])

配套 models.yaml：

models:
  - Qwen/Qwen2.5-7B-Instruct
  - deepseek-ai/DeepSeek-R1
  - meta-llama/Llama-3.1-8B-Instruct
  - google/gemma-2-9b-it
  - mistralai/Mistral-7B-v0.1
  - bigscience/bloom-7b1

把它挂到 CI 的每次合并请求上，加一个审批节点：状态为 review 的模型必须由法务 / OSPO 签字，状态为 block 的直接拒绝。配合 SCA、SBOM 与软件成分分析中的 ML-BOM 机制，可以把模型合规纳入与软件成分一致的流水线。

十一、与本系列其他文章的交叉引用

十二、参考资料

许可证官方文本

定义与标准

法律与政策

模型页面（可用于溯源）

报告与分析

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。

上一篇：AI 训练数据的版权

下一篇：中国 AIGC 司法案例集

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / opensource

【开源许可与版权工程】开源世界全景：从 GNU 到大模型的四十年

一篇写给中国工程团队的开源世界地图：从 1983 年 Richard Stallman 发起 GNU 项目、1998 年 OSI 成立、2018 年 MongoDB 更改 SSPL，到 2020 年开放原子开源基金会成立、再到 2024 年大模型时代的 OpenRAIL 与 LLaMA 许可，把四十年的关键事件、基金会、协议演进和中国线索串成一张可直接指导选型的全景图。

By .