开源许可证的世界长期被「软件许可证」一词所垄断：MIT、Apache、GPL、BSD，这些名字在工程师圈子里几乎是常识。但当一个项目里同时出现 README、文档站、配套数据集、预训练模型权重、微调脚本、评测集，一个「按 MIT 发布」的声明就已经无法覆盖全部资产了。
2022 年以后，随着大规模语言模型（Large Language Model，LLM）与生成式 AI 的爆发，这种错配尤为突出：发布方必须同时回答四类问题——代码以什么协议发布？文档以什么协议发布？训练 / 评测数据以什么协议发布？模型权重以什么协议发布？它们的组合决定了下游用户能做什么、不能做什么。
本文尝试把非代码资产的许可证体系讲清楚，包括：Creative Commons（CC）家族、开放数据库许可证（ODbL / ODC-BY / PDDL）、AI 模型的 OpenRAIL 家族、以 LLaMA 为代表的「开放权重但非开源」的社区协议、以及 Mistral / Qwen / DeepSeek / InternLM / 百川等中国与欧洲团队对 Apache 2.0 与 MIT 的选择。最后用一节来讲开源倡议组织（Open Source Initiative，OSI）在 2024 年 10 月发布的开源 AI 定义（Open Source AI Definition，OSAID）1.0，以及它对现有「开源模型」带来的冲击。
本文不是法律意见，是工程参考。它的目标是让一个发布模型或数据的工程师，能在读完之后做出下面这种判断：「我这个数据集适合
CC-BY 4.0 还是 ODbL 1.0？」「我把 LLaMA 3.1
微调之后发布，命名要不要带 Llama
前缀？」「我要不要申请 OSAID 认证？」
在讨论 CC、ODbL、OpenRAIL 之前，必须先把一件事讲清楚：MIT / Apache / GPL 这些软件许可证，从法理上讲，作用对象就不是文档、数据或模型权重。
大多数国家的著作权法（Copyright Law）以 1886 年《保护文学和艺术作品伯尔尼公约》为底板，加上 TRIPS、WIPO 版权条约逐步演化。它保护的是「作品」——即「具有独创性并以某种有形形式表达」的文学、艺术、科学成果。它不保护：事实、思想、方法、算法本身。
这一条原则在不同类型的对象上带来了非常不同的后果：
Feist 案确立了美国立场：单纯的事实收集不具独创性，汗水劳动原则（sweat-of-the-brow doctrine）不能成为版权基础。
欧盟的选择不同。1996 年《数据库指令》（Directive 96/9/EC）在著作权之外，为数据库设立了一项「特殊权利」（sui generis database right），保护对数据库内容的「实质性投入」。这项权利与独创性无关，持续 15 年，每次实质性更新重新起算。
这套差异直接导致：一份在美国可以随意复用的数据库，在欧盟可能构成侵权。 Open Database License（ODbL）正是为了同时覆盖这两种制度而设计的——即便你在的司法区不承认 sui generis database right，也通过合同约束（contract law）达到类似效果。
主流观点有三派：
美国版权局在 2023 年 3 月《版权登记指南》和后续意见中给出的口径是：没有实质性人类创作介入的 AI 生成物，不能登记版权。 但这说的是 AI 生成的「输出」，不是权重本身。权重是否可版权保护，目前仍是开放问题。
工程实践中，大多数模型发布者选择用「许可证 + 服务条款」的组合来约束使用——不论权重本身是否可版权保护，只要你下载了它，就等同于接受了协议。 这是一种合同法层面的约束，而非版权法层面的。这正是 RAIL 家族最核心的法律设计。
OSI 在 1998 年成立时，其开源定义（Open Source Definition，OSD）只针对软件源代码。它的十条标准中多次出现「program」「source code」「compilation」等措辞，完全没有考虑数据、文档、训练权重。
在 2022 年之前，这并不是大问题——Creative Commons 处理文档图片、Open Knowledge Foundation 处理数据库、各家自行发布模型权重，各管一段。2022 年以后，随着 Stable Diffusion、BLOOM、LLaMA、Qwen 的相继开放，OSI 发现自己必须直接面对「开源 AI 是什么」的问题。OSAID 1.0 的难产（18 个月以上的社区协商）反映了定义非代码资产的开源身份有多难。
工程上更务实的做法是按资产类型分别给协议：
/project-root
├── src/ # Apache-2.0
├── docs/ # CC-BY-4.0
├── datasets/train.csv # ODbL-1.0 / CC-BY-4.0 / CC0
├── models/ # OpenRAIL-M / Apache-2.0 / LLaMA-Community-3.1
├── LICENSE # Apache-2.0 (代码)
├── LICENSE-docs # CC-BY-4.0
├── LICENSE-data # ODbL-1.0
└── LICENSE-weights # OpenRAIL-M / LLaMA-CommunityHugging Face 模型仓库的 tags.license
字段就是为这种场景设计的。PyPI 在新版元数据（PEP
639）中也允许 SPDX 表达式同时覆盖多个许可证。
Creative Commons（知识共享）是 2001 年由劳伦斯·莱斯格（Lawrence Lessig）等人在美国创立的非营利组织，目标是为文学、艺术、科学类作品提供一套标准化的开放许可证。它并不是一个法律实体的集合，而是标准化的许可证模板——真正生效的是作者在作品上附加的那个 CC 许可证声明。
CC 通过四个模块化的要素组合出 6 种主要许可证：
| 要素 | 缩写 | 含义 |
|---|---|---|
| 署名（Attribution） | BY | 必须署原作者名、来源、许可证 |
| 相同方式共享（ShareAlike） | SA | 衍生作品必须使用相同的许可证 |
| 非商业性使用（NonCommercial） | NC | 不得用于主要为商业利益的用途 |
| 禁止演绎（NoDerivatives） | ND | 不得修改、改编、重混 |
从这四个要素可以组合出 6 种有效组合（SA 与 ND 互斥，因为 SA 要求允许演绎并要求演绎以相同协议发布，而 ND 禁止演绎，放在一起没有意义）：
CC BY = 仅署名
CC BY-SA = 署名 + 相同方式共享
CC BY-NC = 署名 + 非商业
CC BY-NC-SA = 署名 + 非商业 + 相同方式共享
CC BY-ND = 署名 + 禁止演绎
CC BY-NC-ND = 署名 + 非商业 + 禁止演绎此外还有一个特殊的「CC0」，它不是 CC 许可证，而是著作权放弃声明。
从工程视角看，可以把这 7 种按「宽松度」排成一条线：
宽松 ───────────────────────────────────────────── 限制
CC0 < CC BY < CC BY-SA < CC BY-ND < CC BY-NC < CC BY-NC-SA < CC BY-NC-NDCC-BY 4.0 是最常见、最推荐的「开放内容」许可证。它允许：
唯一的要求是：署名。署名的具体要求在 CC-BY 4.0 第 3 条中规定，工程界通常用「TASL」四元组概括：
一个标准的署名示例：
"快速排序" by Tony Hoare, from https://en.wikipedia.org/wiki/Quicksort,
licensed under CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/)CC-BY 4.0 在功能上非常接近软件界的 MIT 与 BSD-3-Clause：允许商用、允许修改、只要求署名。它是目前文档、教程、博客类作品的默认推荐协议。
SA（ShareAlike，相同方式共享）本质上是「文化作品的 copyleft」。它要求衍生作品必须以相同或兼容的协议重新发布。这种「感染力」与 GPL 的机制完全一致。
最知名的 CC-BY-SA 使用者就是维基百科（Wikipedia）。维基媒体基金会 2009 年从 GFDL 迁移到 CC-BY-SA 3.0，然后在 2023 年 6 月把条款更新到 CC-BY-SA 4.0。这意味着：
CC-BY-SA 4.0 与 GPL 并不兼容。它们的条款来自不同的法律基础：GPL 是软件代码的版权协议，CC-BY-SA 是创作作品的版权协议。CC 组织明确指出：不建议把 CC-BY-SA 用于软件源代码，请用 GPL；也不建议把 GPL 用于文档，请用 CC-BY-SA。
NC（NonCommercial）是最让工程界头疼的要素。CC-BY-NC 4.0 第 1(k) 条把「非商业」定义为「not primarily intended for or directed towards commercial advantage or monetary compensation」，中文大致是「非主要为商业利益或获取金钱补偿」。
这个定义有多模糊，看一下现实的边界案例：
Wikimedia 基金会、Debian 项目、开放获取期刊（Open Access Journal）都不建议使用 NC 条款，原因正是其模糊性使下游无法明确合规边界。
ND（NoDerivatives）禁止演绎。它的典型用法：
注意两点：
CC0（读作「CC Zero」）是 2009 年引入的工具，用于把作品献入公共领域（public domain）。它的口号是「No Rights Reserved」。
CC0 不是一个许可证，而是一个三层法律结构：
工程上，CC0 类似于软件的 0BSD 或 Unlicense。它被大量用于：
对数据集而言，CC0 是最少摩擦的选择，但它不处理 sui generis database right——在欧盟，如果你想放弃数据库特殊权利，应当使用 PDDL（见第三节）。
CC 许可证到目前已经迭代过 4 个版本：1.0、2.0、2.5、3.0、4.0。在工程中需要注意：
新项目请一律用 4.0。 已经在 3.0 下发布的内容可以维持，但如果升级或重发，升级到 4.0 是常见做法。
Creative Commons 中国大陆分部曾由中国人民大学法学院承担 affiliate 工作，后来 CC 国际在 2016 年取消了国家分部体系，统一以 CC 4.0 International 为核心。
在中国司法实践中，多个判决明确认定 CC 许可证的条款在合同法下是有效的：
中国的开放数据实践中使用 CC 协议的例子：
对国内开发者而言，最安全的选择是：文档、教程、博客默认 CC-BY 4.0；希望维持开放生态的采用 CC-BY-SA 4.0；尽量避免 NC 与 ND，除非有明确理由。
前面提到，单纯事实不受版权保护，但事实的汇编可能受保护。进一步，欧盟的数据库特殊权利（sui generis database right）还保护「对数据库内容取得、核实、呈现的实质性投入」。
于是一份数据库在不同法域会有不同的权利结构：
用 CC-BY / CC0 许可一份数据库，在欧盟会留有 sui generis 缺口（CC 4.0 修复了这个缺口，3.0 没有修复）。这正是 Open Data Commons 系列协议存在的原因：它们明确覆盖数据库权利。
ODbL 1.0 由开放知识基金会（Open Knowledge Foundation）在 2009 年发布。它有三个核心要求：
ODbL 区分两个概念，非常重要：
OpenStreetMap（OSM） 从 2012 年 9 月起全面采用 ODbL 1.0。这意味着：
工程上常见的 ODbL 署名：
© OpenStreetMap contributors, licensed under the Open Database License
https://www.openstreetmap.org/copyrightODC-BY 1.0 是「仅署名」的数据库协议。它对应软件界的 BSD / MIT：
适合那些希望数据尽可能被广泛使用（包括闭源产品）、但又希望保留署名的机构。
使用 ODC-BY 的典型案例：
PDDL 1.0 是数据库版本的 CC0：把所有著作权、数据库权利放弃到公共领域的极限状态。与 CC0 类似，它采用三层结构，在不允许放弃权利的法域退化为无条件许可。
PDDL 常用于：
中国在数据许可层面的现状是：国家层面的法律框架（《数据安全法》《个人信息保护法》《生成式人工智能服务管理暂行办法》）关注的是数据合规与安全分级，而非许可证标准化。
工程上落到许可证层面的现实：
| 场景 | 推荐协议 |
|---|---|
| 希望最大范围使用，放弃所有权利 | PDDL 1.0（或 CC0） |
| 仅要求署名 | ODC-BY 1.0（或 CC-BY 4.0） |
| 要求衍生数据库继续开放 | ODbL 1.0 |
| 数据有隐私或受限因素 | 自定义协议 + 访问审批 |
| 欧盟用户为主 | 选 ODbL / ODC-BY / PDDL，避免单独用 3.0 以下的 CC |
模型权重是否受著作权保护？这是 2023 年以后迅速成为焦点的问题。目前可以确定的只有几件事：
正因为法律地位不清晰，模型许可证通常同时提供两种路径：
RAIL 家族和 LLaMA Community License 都采用这种双轨写法。
RAIL（Responsible AI License）由 BigScience / Hugging Face / Licenses for AI 等社区力量推动，2022 年前后成型。核心理念是：
传统的 MIT / Apache 2.0 是「任何人、任何目的」；而 RAIL 在保留前者精神的同时，通过使用限制（Use Restrictions）禁止某些具体的有害用途。这在传统软件开源精神中是一个重大背离——OSI 不接受任何「use field restriction」（使用领域限制），因此 RAIL 协议在 OSI 的定义下不算开源。
基础 RAIL 协议允许使用、分发、修改，但附加「使用限制」（Attachment A）。
「Open」意味着：源代码与模型权重可自由分发、允许商业化、允许演绎。在此基础上保留使用限制。OpenRAIL 有多个变体：
最知名的用户是 Stable Diffusion v1（2022 年 8 月发布），采用 CreativeML Open RAIL-M。它允许：
它禁止（节选）：
注意：Stable Diffusion 之后的 SDXL 0.9 / 1.0 采用 SAI Non-Commercial License（SAI 非商业研究协议），后来 Stable Diffusion 3 又回到 SAI Community License，再到 2024 年底 Stability 进入财务困境后协议变动更为频繁。模型协议会随组织商业化策略而变——这是 AI 协议世界的一个重要结构性事实。
BLOOM（1760 亿参数，2022 年 7 月发布）采用 BigScience OpenRAIL-M。Attachment A 列出了 15 类禁止用途，包括（节选）：
使用者必须在下游传递这些限制。即便你只是基于 BLOOM 微调一个 7B 的中文模型，你的发布协议也必须包含同样的使用限制。
RAIL 类协议的法律创新之处在于「use restriction」。它带来的工程挑战：
Meta 的 LLaMA 系列是 2023 年以后大模型开放运动的关键事件，也是理解「开放权重但非开源」的典型范本。
LLaMA 1 采用「Research-Only License」：
LLaMA 1 不是开源，甚至不算「开放权重」；它更接近「有限研究访问」。但 2023 年 3 月的权重泄漏事件直接改变了局面——从此「封闭的研究协议」不再现实。
LLaMA 2 的协议（2023 年 7 月 18 日发布）是一次明显的让步，也是一次精心的法务设计：
两个条款值得重点看：
这两条让 LLaMA 2 不可能得到 OSI 开源认证——OSD 第 5 条「不得歧视个人或团体」、第 6 条「不得歧视特定使用领域」都被违反。
LLaMA 3 与 3.1 延续了 Community License 的结构，做了几处调整：
LLaMA 3.1 405B 的发布（2024 年 7 月 23 日）让这套协议影响到更大规模的生态——包括中国的 Llama-3.1-Chinese 系列、llama.cpp 兼容链路。
把 LLaMA 2/3 与 OSI 的 OSD 十条并排看：
| OSD 条款 | LLaMA Community License |
|---|---|
| 1. 自由再发布 | ✓ 允许 |
| 2. 源代码可获得 | ○ 权重可下载，训练代码未公开 |
| 3. 允许派生作品 | ✓ 允许 |
| 4. 作者源代码完整性 | ✓ |
| 5. 不歧视个人或团体 | ✗ 排除 700M MAU 以上组织 |
| 6. 不歧视特定使用领域 | ✗ 排除「用于改进其它 LLM」的用途 |
| 7. 协议随附作品 | ✓ |
| 8. 协议不针对具体产品 | ✓ |
| 9. 协议不限制其它软件 | ✓ |
| 10. 协议技术中立 | ✓ |
LLaMA 在 5 和 6 两条上违反 OSD。这就是为什么社区更准确地把它叫做「open weights」而不是「open source」。
Mistral AI（法国，2023 年创立）在 2023 年 9 月发布 Mistral 7B，协议直接选了 Apache 2.0。这是第一款真正「开源级别」的主流 LLM：
2023 年 12 月，Mixtral 8x7B（MoE 架构，47B 激活参数）同样以 Apache 2.0 发布。2024 年 7 月 Mistral NeMo 12B（与 NVIDIA 合作）也是 Apache 2.0。
Mistral 的商业模式是「开放权重 + 商业 API + 企业版」：
对比 LLaMA，Mistral 的策略更干净：要么真的 Apache 2.0，要么就是商业模型。中间没有「看起来开源但限制一大堆」的灰色地带。这种二分法在社区中赢得了相当的信任感。
阿里巴巴通义千问（Qwen）的许可证策略是理解中国大模型协议演变的关键样本。
这个走向非常清楚：在 Mistral 用 Apache 2.0 抢占开发者心智的压力下，阿里把 Apache 2.0 作为「中小型号」的默认选择，以最大化生态采纳；而在旗舰模型上保留商业护城河。
深度求索（DeepSeek，2023 年成立）自始至终走的是「权重协议尽量宽松」的路线：
R1 的 MIT + 鼓励蒸馏的组合让它在 2025 年第一季度迅速成为社区最热门的开放权重旗舰模型。它的协议策略和 LLaMA 2/3 形成强烈对照：不在协议上设门槛，把护城河建立在产品与服务之上。
清华大学 KEG 实验室 / 智谱 AI：
| 模型 | 机构 | 首发协议 | 最新代表协议 | 关键限制 |
|---|---|---|---|---|
| LLaMA 1 | Meta | Research-Only | 已停更 | 仅研究 |
| LLaMA 2 | Meta | LLaMA 2 Community | 同上 | 700M MAU、反训练 |
| LLaMA 3.1 | Meta | LLaMA 3.1 Community | 同上 | 700M MAU、命名披露 |
| Mistral 7B | Mistral AI | Apache 2.0 | Apache 2.0 | 无 |
| Qwen2-7B | 阿里 | Tongyi Qianwen License | Apache 2.0 | 小号无；72B 有 MAU |
| DeepSeek-V2 | DeepSeek | DeepSeek License | DeepSeek License / MIT（R1） | 少 |
| DeepSeek-R1 | DeepSeek | MIT | MIT | 无 |
| InternLM2 | 上海 AI Lab | Apache 2.0 / 免费商业 | Apache 2.0 | 无 |
| BGE | BAAI | MIT | MIT | 无 |
| Baichuan2 | 百川 | Community License | Community License | 登记制 |
| ChatGLM3 | 智谱 | Model License | GLM-4 Community | 商用需登记 |
| Stable Diffusion v1 | Stability AI | CreativeML Open RAIL-M | 已停更 | 使用限制 |
| BLOOM | BigScience | BigScience OpenRAIL-M | 同上 | 15 项使用限制 |
这张表揭示的趋势：2024 年后，中国大陆新一代旗舰模型更愿意用 Apache 2.0 / MIT；LLaMA 和部分商业闭源模型保留定制 Community License；RAIL 家族则在开源社区作为「负责任 AI」的旗帜继续使用，但在工业界的采纳率不高。
2022 年 Stable Diffusion、2023 年 LLaMA 2 的发布，让「开源 AI」成为热词。但如前所述：
这造成一个词语危机——「开源 AI」到底指什么？是像 MIT 一样任何人任何用途？还是像 LLaMA 一样「大多数人免费用」？还是像 Stable Diffusion 一样「商业可以但不能做有害应用」？
OSI 从 2022 年启动 OSAID 研究项目，经过 18 个月左右的全球协商，2024 年 10 月 28 日在 All Things Open 大会上发布 OSAID 1.0。
OSAID 1.0 为「开源 AI 系统」设定了四项自由：
要实现这些自由，OSAID 要求发布方提供三类「优先形式」（preferred form）：
OSAID 1.0 发布时，OSI 没有给出官方认证清单，但社区普遍认为当前符合的模型很少：
也就是说：目前多数「开放权重」模型在 OSAID 口径下不是开源 AI。
中国 AI 团队面临的挑战与西方类似，但有几个独特点：
对国内模型团队的现实路径：
最常见的误用：开发者把 Wikipedia 的一段解释粘贴到代码注释里，整个代码仓库按 MIT 发布。
严格意义上，这段文本仍然要求以 CC-BY-SA 4.0 发布，且要求下游以同一协议分发。MIT 与 CC-BY-SA 并不兼容——MIT 没有 copyleft 要求，整个仓库用 MIT 相当于违反 SA 条款。
解决方案：
docs/
目录，docs/ 目录单独声明 CC-BY-SA 4.0；NC 条款的边界争议在实务中每几年都会冒出来。一个经典案例：德国广播电台 Deutschlandradio 在 2013 年使用了一张 CC-BY-NC 的自行车选手照片，法院判决该电台作为公营媒体接受民众赞助，「即使不直接营利，整体运作具有商业属性」，构成违反 NC。
工程判断的底线：
实务建议：能避免 NC 就避免。如果必须用 NC 素材，提前与作者协商商业授权。
Fine-tune 一个 LLaMA 3.1 微调模型：
Llama
前缀，除非符合豁免条件；Fine-tune 一个 Stable Diffusion 模型（CreativeML Open RAIL-M）：
很多 Hugging Face 上「开源微调模型」没有把这些限制显式传递，技术上属于违约状态。一旦上游发现并主张救济，下游处境会相当被动。
这是 2023 年以后最活跃的法律焦点。要点：
工程建议：
当一个模型用上百个数据集训练，每个数据集协议不同，就需要一份「AI BOM」。相关标准：
modelCard、dataCard、consideration
字段。license、license_name、license_link、dataset_info
等字段。这些标准都不具备强制力，但在企业 AI 合规体系中逐渐成为基础设施。工程上推荐做法：
datasets API
时检查 .dataset_info.json 的 license
字段；| 场景 | 推荐协议 |
|---|---|
| 教程、博客、API 文档 | CC-BY 4.0 |
| 希望维持开放衍生的社区百科 | CC-BY-SA 4.0 |
| 固定形态的官方声明 | CC-BY-ND 4.0 |
| 完全献入公共领域 | CC0 |
不推荐：CC-BY-NC 系列——NC 条款的模糊性往往给下游带来合规负担，反而降低传播效率。
| 场景 | 推荐协议 |
|---|---|
| 需要最大范围复用 | PDDL 1.0 或 CC0 |
| 只要求署名 | ODC-BY 1.0 或 CC-BY 4.0 |
| 希望衍生数据库保持开放 | ODbL 1.0 |
| 涉及个人信息或受监管数据 | 自定义协议 + 访问审批 |
欧盟用户多的场景，优先选 ODC 系列（PDDL / ODC-BY / ODbL），因为它们明确处理 sui generis database right。纯美国场景下，CC0 / CC-BY 也可以接受。
| 目标 | 推荐协议 |
|---|---|
| 追求最广泛采纳，不设置门槛 | Apache 2.0（Mistral、Qwen2、InternLM2）或 MIT（DeepSeek-R1、BGE） |
| 希望保留反竞争条款 | 自定义 Community License（参考 LLaMA 2/3） |
| 希望设置负责任使用限制 | OpenRAIL-M（注意：会失去 OSI 开源身份） |
| 要 OSI 官方开源 AI 认证 | 需要完整公开训练代码和数据信息（OSAID） |
一个推荐的默认组合：
代码 Apache-2.0
文档 CC-BY-4.0
数据集 CC-BY-4.0 或 ODbL-1.0
模型权重 Apache-2.0这个组合覆盖了 99% 的开源项目需求，下游使用阻力最小，合规成本最低。
下表整理了国内具有代表性的大模型及其许可证演变（数据来自 Hugging Face 模型卡与官方仓库 README，截止 2025 年上半年公开信息）：
| 模型 | 机构 | 首发时间 | 首发协议 | 最新代表协议 | 关键限制 |
|---|---|---|---|---|---|
| 通义千问 Qwen 1 | 阿里巴巴 | 2023-08 | Tongyi Qianwen License | — | 100M MAU 门槛 |
| 通义千问 Qwen 2 | 阿里巴巴 | 2024-06 | Apache 2.0（≤57B）/ Qwen License（72B） | Apache 2.0（多数） | 72B 仍有 MAU 条款 |
| 通义千问 Qwen 2.5 | 阿里巴巴 | 2024-09 | Apache 2.0（多数） | Apache 2.0 | — |
| DeepSeek-Coder | DeepSeek | 2023-11 | DeepSeek License（权重）+ MIT（代码） | — | 允许商业使用 |
| DeepSeek-V2 / V3 | DeepSeek | 2024-05 / 2024-12 | DeepSeek License | 同前 | 宽松 |
| DeepSeek-R1 | DeepSeek | 2025-01 | MIT | MIT | 无 |
| 书生·浦语 InternLM | 上海 AI Lab | 2023-06 | InternLM License | — | 商业需申请 |
| InternLM2 / 2.5 | 上海 AI Lab | 2024-01 起 | Apache 2.0（多数） | Apache 2.0 | — |
| InternLM3 | 上海 AI Lab | 2025 | Apache 2.0 | Apache 2.0 | — |
| BGE embedding | BAAI | 2023-08 | MIT | MIT | 无 |
| Aquila | BAAI | 2023-06 | BAAI Aquila License | Apache 2.0（部分） | 早期禁止输出训练他 LLM |
| 百川 Baichuan-7B | 百川智能 | 2023-06 | Apache 2.0 | Apache 2.0 | 无 |
| 百川 Baichuan2-13B | 百川智能 | 2023-09 | Baichuan Community License | 同前 | 登记制商用 |
| ChatGLM-6B | 清华/智谱 | 2023-03 | Model License | — | 非商业免费，商业申请 |
| ChatGLM3-6B | 清华/智谱 | 2023-10 | Model License | — | 商业申请 |
| GLM-4-9B | 智谱 | 2024-06 | GLM-4 License | — | 简化登记制 |
总体趋势（2023 - 2025）：
这种趋势与国际生态同步——LLaMA 2/3 的 Community License 虽然名义上「可商用」，但在开发者心智里，干净的 Apache 2.0 / MIT 比任何带门槛的协议都更受欢迎。这也是 Mistral、DeepSeek 在 2024 年快速上位的重要原因。
很多工程师在实际项目里被 CC 协议绊住脚，往往是对 4.0 版本几个关键条款缺少细读。以下按 CC-BY-SA 4.0 官方法律代码的结构做精要解读，不替代原文，仅便于工程理解。
CC-BY-SA 4.0 第 1 条定义了 13 个核心术语，其中对工程实践最关键的：
第 2(a) 条以全球、免版税、非独占、不可撤销的方式，授予下游：
注意不可撤销（irrevocable）三个字的分量。作者一旦发布，就不能单方面收回协议——这是 CC 家族作为「开放许可证」的骨架。如果你需要未来回收作品权利，不应选 CC。
第 2(b) 条处理例外与限制：协议不干涉各司法区已有的合理使用、合理引用、教学使用等例外。换言之，即使协议没有明说，法定合理使用仍然成立。
这是最常被下游忽视的一节。
下游在分发作品或改编作品时，必须：
「合理方式」（reasonable manner）的具体实践：
下游分发改编作品（不是原作品）时，必须：
第 3 项含义：你不能在你的 CC-BY-SA 衍生作品上加一条「禁止商业用户使用」——那会实质削弱 CC-BY-SA 允许的商业用途。
4.0 版本在第 4 条单独处理欧盟数据库特殊权利：
这个设计让 CC-BY-SA 4.0 能够单独作为数据集协议用在欧盟——虽然 Open Data Commons 的协议在这个场景下更常见。
与大多数开源协议一致：明示无担保、不负瑕疵担保责任、不负间接损失责任。但各司法区强行法会覆盖部分条款——比如中国《民法典》下因故意或重大过失造成损害的责任不能通过协议排除。
第 6(a) 条提供自动恢复机制：如果下游首次违反协议，只要在 30 天内发现并纠正，许可自动恢复。这是 CC 4.0 相对 3.0 最重要的改进之一——3.0 下一旦违反就永久失去许可。这一机制类似 GPLv3 的 cure 条款。
SPDX（Software Package Data Exchange）是一套标准化的许可证标识符体系，由 Linux Foundation 维护。对非代码资产同样适用。
| 资产类别 | 协议 | SPDX ID |
|---|---|---|
| 代码 | MIT | MIT |
| 代码 | Apache 2.0 | Apache-2.0 |
| 代码 | GPLv3 | GPL-3.0-or-later |
| 文档 | CC BY 4.0 | CC-BY-4.0 |
| 文档 | CC BY-SA 4.0 | CC-BY-SA-4.0 |
| 文档 | CC0 | CC0-1.0 |
| 数据 | ODbL 1.0 | ODbL-1.0 |
| 数据 | ODC-BY 1.0 | ODC-By-1.0 |
| 数据 | PDDL 1.0 | PDDL-1.0 |
| 模型 | OpenRAIL-M | 暂未标准化 |
| 模型 | LLaMA Community | 暂未标准化 |
多协议组合用操作符表示：
# 二选一（用户可任选其一）
"MIT OR Apache-2.0"
# 共同生效（用户必须同时满足）
"Apache-2.0 AND CC-BY-4.0"
# 带例外
"GPL-3.0-or-later WITH Classpath-exception-2.0"
# 复杂嵌套
"(Apache-2.0 OR MIT) AND CC-BY-SA-4.0"Hugging Face Hub 的 README.md YAML header 支持：
license: apache-2.0 # 单一 SPDX ID
license_name: llama3.1 # 自定义名称（用于未进入 SPDX 的协议）
license_link: https://llama.meta.com/llama3_1/license
datasets:
- mlfoundations/dclm-baseline-1.0
model-index:
- name: MyFineTunedModel
language:
- zh
- en当 license 不在 SPDX 清单中时，使用
license_name + license_link。
一份 ML-BOM 的核心结构（缩略）：
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"metadata": {
"timestamp": "2025-12-01T00:00:00Z",
"component": {
"type": "machine-learning-model",
"name": "MyFineTunedQwen2-7B",
"version": "v0.1",
"licenses": [
{"license": {"id": "Apache-2.0"}}
]
}
},
"components": [
{
"type": "machine-learning-model",
"name": "Qwen2-7B",
"version": "1.0",
"licenses": [{"license": {"id": "Apache-2.0"}}]
},
{
"type": "data",
"name": "wikipedia-zh-20240801",
"licenses": [{"license": {"id": "CC-BY-SA-4.0"}}]
},
{
"type": "data",
"name": "internal-sft-corpus",
"licenses": [{"license": {"name": "internal-proprietary"}}]
}
]
}此类 BOM 文件配合 Sigstore / Rekor 等透明日志基础设施，可以为模型发布建立一条可审计的证据链。
下表展示几种常见协议之间的「单向兼容性」——即能否把 A 协议的内容纳入 B 协议的作品中。「是」意味着可以，「否」表示存在协议冲突，「条件」意味着在特定条件下可以。
| A → B | MIT | Apache-2.0 | GPL-3.0 | CC-BY-4.0 | CC-BY-SA-4.0 | CC0 | ODbL-1.0 |
|---|---|---|---|---|---|---|---|
| MIT | — | 是 | 是 | — | — | — | — |
| Apache-2.0 | 是 | — | 条件* | — | — | — | — |
| GPL-3.0 | 否 | 否 | — | — | — | — | — |
| CC-BY-4.0 | 是 | 是 | 是 | — | 是 | 否 | 是 |
| CC-BY-SA-4.0 | 否 | 否 | 否 | 否 | — | 否 | 否 |
| CC0 | 是 | 是 | 是 | 是 | 是 | — | 是 |
| ODbL-1.0 | 条件 | 条件 | 否 | 条件 | 否 | 否 | — |
*Apache-2.0 向 GPL-3.0 的兼容是单向的：Apache-2.0 代码可纳入 GPL-3.0 工程，反向不可。
「—」表示协议适用对象不同，不构成典型兼容场景。
关键观察：
给一个完整的中文 LLM 项目加协议的推荐布局：
my-llm-project/
├── LICENSE # Apache-2.0（代码）
├── LICENSE-DOCS # CC-BY-4.0（文档）
├── LICENSE-DATA # ODbL-1.0 或数据集列表
├── LICENSE-MODEL # Apache-2.0 或自定义
├── NOTICE # Apache-2.0 要求的通知文件
├── THIRD_PARTY_LICENSES.md # 依赖清单
├── DATA_LICENSES.md # 训练数据协议清单
├── MODEL_CARD.md # Hugging Face 风格模型卡
├── DATA_CARD.md # Data Information for OSAID
├── sbom.cdx.json # CycloneDX ML-BOM
├── src/ # 代码
├── docs/ # 文档
│ └── LICENSE # CC-BY-4.0
├── datasets/
│ ├── corpus-zh-clean/
│ │ └── LICENSE # 子数据集协议
│ └── eval-benchmark/
│ └── LICENSE # 子数据集协议
└── weights/
├── base-7b/
│ └── LICENSE # 模型权重协议
└── sft-7b/
└── LICENSE每个子目录都能被独立识别出对应协议，符合 SPDX 的
FILES 声明规范，也方便自动化工具（如
ORT、FOSSology、ScanCode）扫描。
Q1：把公司内部文档改写后以 CC-BY 4.0 发布，是否构成「公开发行」？
在中国著作权法下，这构成发行与信息网络传播行为，应经过公司知识产权部门审批。CC 协议只是授权文本，不改变原始著作权归属；若公司为职务作品的著作权人，未经授权的对外发布构成侵权。
Q2：LLaMA 2 的 700M MAU 条款，MAU 具体怎么计算？
协议第 2 条约定：「If, on the Llama 2 version release date, the monthly active users of the products or services… is greater than 700 million monthly active users」。这是一个快照口径——以发布当日计算一次。之后的月活涨到 7 亿并不自动触发，但新版本发布时会再快照。这对大厂的长期策略影响很大——他们可以在一个较小的基础上用 LLaMA，但若要把它嵌入旗舰产品线，仍需要和 Meta 谈。
Q3：CC-BY-SA 4.0 的维基百科内容能否嵌入 Apache 2.0 的开源软件？
代码本身维持 Apache 2.0；嵌入的文本（例如 help string、README 节选）作为「作品」单独受 CC-BY-SA 4.0 约束，且要求衍生作品维持同样协议。工程上的常见做法：
Q4：OpenRAIL 的「使用限制」是否在中国法下可执行？
合同条款在中国法下一般有效，但违反协议的救济途径较窄：许可人可以依合同法主张损害赔偿，但很难申请禁令。现实中，更常见的做法是：通过下架、举报、平台侧执行（Hugging Face / Modelscope 等会对违反协议的模型采取下架措施）来实现协议的事实执行。
Q5：CC0 之后，我还可以对自己的作品主张版权吗？
CC0 是不可撤销声明。一旦发布，作者放弃所有可放弃的权利；即便在不允许放弃的法域，也给出了不可撤销的许可。你不能事后收回。如果未来需要商业化某个特定版本，请为每次发布保留原始「未 CC0」版本作为后续授权基础。
Q6：OLMo 这种全开放模型为什么依然需要做数据过滤？
OSAID 要求的是「训练数据信息」——可以是数据本身，也可以是充分详细的描述。即便要发布完整数据集，仍需过滤：
OLMo 背后的 Dolma 数据集就经历了严格的过滤流水线。过滤后的数据才能在 AI2 Impact License（一种开放数据协议）下发布。
Q7：LLaMA 3 要求下游模型命名带 Llama
前缀，是否等同商标授权？
更像是一种「披露义务」而非商标授权。LLaMA 3
的协议允许你使用 Llama
这个字样仅用于识别衍生作品的来源，不赋予任何其它商标使用权利。把
Llama 用于与 Meta
无关的产品宣传仍属侵权。工程上：微调模型命名
Llama-3.1-Chinese-8B-Instruct 合规，但不能用
Llama Enterprise Suite 之类商品化名字。
Q8：我把 Stable Diffusion 的 RAIL 协议下的权重再以 Apache 2.0 发布，可以吗？
不可以。RAIL 协议要求下游分发保留同样的 use restriction，Apache 2.0 没有此类限制。把 RAIL 模型直接以 Apache 2.0 发布会违反 RAIL 原协议。类似地，LLaMA 权重也不能被重新以 Apache 2.0 发布。
Q9：OSAID 1.0 是不是强制要求模型公开训练数据本身？
不是。OSAID 1.0 接受「数据信息」的多种形式，包括详细描述、数据卡、可复现方法。但这些描述必须让「技能娴熟的人员」能够复现一个功能等效的系统——这是一项非常高的要求，许多「只公开权重」的模型无法达到。
Q10：中国版权法下，AI 生成的图片能否被视为作品？
2023 年「AI 生成图片案」一审判决（北京互联网法院）支持作品属性。但该判决基于用户在生成过程中做了「精心的参数调节、prompt 设计、选择组合」的事实。若是直接调用模型 API、不加任何人工干预生成，目前主流观点仍倾向于不构成作品。该问题尚未经过最高人民法院明确表态，工程实务中仍建议在对外使用 AI 生成内容时做好人工干预记录。
| 中文 | 英文 | 缩写 / SPDX |
|---|---|---|
| 知识共享 | Creative Commons | CC |
| 署名 | Attribution | BY |
| 相同方式共享 | ShareAlike | SA |
| 非商业性使用 | NonCommercial | NC |
| 禁止演绎 | NoDerivatives | ND |
| 公共领域 | Public Domain | PD |
| 开放数据库许可证 | Open Database License | ODbL |
| 开放数据共享署名许可证 | Open Data Commons Attribution License | ODC-BY |
| 公共领域贡献与许可 | Public Domain Dedication and License | PDDL |
| 数据库特殊权利 | sui generis database right | — |
| 汇编作品著作权 | Compilation Copyright | — |
| 负责任 AI 许可证 | Responsible AI License | RAIL |
| 开放负责任 AI 许可证 | Open Responsible AI License | OpenRAIL |
| 模型许可证变体 | OpenRAIL for Models | OpenRAIL-M |
| 使用限制 | Use Restriction | — |
| 月活跃用户 | Monthly Active Users | MAU |
| 开源倡议组织 | Open Source Initiative | OSI |
| 开源定义 | Open Source Definition | OSD |
| 开源 AI 定义 | Open Source AI Definition | OSAID |
| 大语言模型 | Large Language Model | LLM |
| 通用目的人工智能 | General-Purpose AI | GPAI |
| 软件成分清单 | Software Bill of Materials | SBOM |
| 机器学习成分清单 | Machine Learning Bill of Materials | ML-BOM |
| 数据卡 | Data Card | — |
| 模型卡 | Model Card | — |
| 合理使用 | Fair Use | — |
| 字面拷贝 | Verbatim Copy | — |
为方便整体把握，把本文涉及的重要历史事件按时间排开：
从时间线可以看到一个清晰的趋势：2022-2023 年是协议创新的爆发期（RAIL 家族、LLaMA Community），2024-2025 年是开放与合规框架逐步收敛的稳定期（Apache 2.0 成主流、OSAID 出炉、欧盟 AI 法生效）。工程团队在协议选型时，应当把这个大趋势作为背景判断：「开放权重 + 宽松协议 + 数据信息披露」正在成为新常态。
本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。
上一篇：木兰许可证与国产开源许可
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / opensource
一篇写给中国工程团队的开源世界地图：从 1983 年 Richard Stallman 发起 GNU 项目、1998 年 OSI 成立、2018 年 MongoDB 更改 SSPL，到 2020 年开放原子开源基金会成立、再到 2024 年大模型时代的 OpenRAIL 与 LLaMA 许可，把四十年的关键事件、基金会、协议演进和中国线索串成一张可直接指导选型的全景图。
2026-04-22 · architecture / opensource
面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。
2026-04-22 · architecture / opensource
深入对比 MIT、BSD 家族与 Apache 2.0 的条款差异：NOTICE 文件义务、专利授权、重新授权权利；BSD advertising clause 的历史与废除；ISC 许可证的关系；以及阿里、腾讯、字节内部为何强烈推荐 Apache 2.0 的工程原因。
2026-04-22 · architecture / opensource
深入解析 GPLv2 到 GPLv3 的条款变化、Tivoization 反规避与 DRM 条款、专利终止条款；LGPL 链接例外的工程边界；以及 Linus Torvalds 拒绝升级到 v3 的真实原因与嵌入式生态影响。包含路由器厂商、国内 Android 设备的 GPL 合规真实案例。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。