2026-04-22 · architecture / opensource
【开源许可与版权工程】文档、数据、模型的许可：CC、ODbL、OpenRAIL、LLaMA 协议
系统梳理文档（CC 家族）、数据库（ODbL/PDDL）与 AI 模型（OpenRAIL、LLaMA、Mistral、Qwen、DeepSeek）的许可框架；OSI 2024 年开源 AI 定义（OSAID 1.0）；以及书生·浦语、智源、百川、通义千问、DeepSeek 在中国的协议演变。
开源已经不是一个哲学问题，而是一个工程、商业和法律交织的系统工程问题。把一份 GPL 代码静链进商用固件、把 AGPL 服务封装进 SaaS 对外卖 API、把 SSPL 的 MongoDB 托管成云数据库、把 LLaMA 2 的权重拿去训练商用客服机器人——每一件事背后都有一条可能触发的许可红线。理解这条红线从哪里来、为什么会在这里、未来会往哪里走，需要先把”开源世界”这张地图看清楚。
这篇文章是整个《开源许可与版权工程》系列的第一篇，也是一张导览图。后续文章会把其中每个节点展开成完整的工程指南，本篇的目标是让读者在读完后能回答三个问题：
先放一张全景图，文章的叙事会围绕这四个象限展开：
本文为工程与历史梳理，不构成法律意见。文中涉及的许可协议文本、基金会章程、企业公告以各自官方版本为准，阅读时请以最新版本核对。
开源故事的起点不是一个协议，而是一台打印机。1980 年前后，麻省理工学院人工智能实验室（MIT AI Lab）的 Richard Stallman 想修改施乐（Xerox）实验室一台激光打印机的驱动程序，以便在打印任务卡纸时通知在排队的用户，但施乐拒绝提供源代码。这件事被后来几乎所有讲述开源历史的书反复引用，因为它让 Stallman 看到了一件事：当软件被闭源和专利锁死，程序员之间互相协作、互相学习、互相修复问题的传统——也就是 1960–1970 年代黑客文化中的默认设定——正在消失。
1983 年 9 月 27 日，Richard Stallman 在 Usenet 的 net.unix-wizards 和 net.usoft 新闻组发了一篇题为《new UNIX implementation》的公告，宣布启动 GNU（GNU’s Not Unix）项目，目标是写出一个完全自由、与 UNIX 兼容的操作系统。这篇公告的措辞已经带有明显的”运动”色彩：他邀请程序员贡献时间、金钱、机器和代码，并承诺所有结果都将自由分发。
1984 年，Stallman 从 MIT 辞职，全职投入 GNU。1985 年 10 月 4 日，他注册成立自由软件基金会（Free Software Foundation, FSF），作为 GNU 的法律与资金载体，总部设于马萨诸塞州波士顿。FSF 的核心主张后来被提炼为软件应给予用户的”四项自由”：
值得注意的是，这里的”Free”从一开始指的就是”自由”而非”免费”，Stallman 本人反复强调”free as in freedom, not free as in beer”。这是理解后来 FSF 与 OSI 分歧的关键：自由软件是伦理运动，开源是工程方法论。
1985 年前后，GNU Emacs 先后使用过若干版本的”GNU Emacs General Public License”。这些协议是后来 GPL 的前身，但只适用于 Emacs 本身。1989 年 1 月，Stallman 发布了 GNU 通用公共许可证（GNU General Public License, GPL）第一版，把”只适用于 Emacs 的协议”抽象成一份通用的许可证，供整个 GNU 项目使用。GPLv1 的核心创意是”著佐权”（Copyleft）：利用著作权法本身来强制要求衍生作品继续以同样的许可证开放。这是一种”以子之矛攻子之盾”的法律巧思。
1991 年 6 月，GPLv2 发布。这一版本的措辞更严谨、在”分发触发”条件的描述上更清晰，并加入了著名的”自由或死亡”条款（Liberty or Death clause，协议第 7 条）：如果法院命令、专利限制等外部约束使你无法同时满足 GPL 和自由分发的要求，那么你不得分发该软件。GPLv2 后来成为 Linux 内核、Git、GCC、GNU Coreutils 等基础设施的许可证，是二十年间事实上的”开源默认协议”。
1991 年也是 Linus Torvalds 在芬兰赫尔辛基大学发布 Linux 0.01 的年份。1992 年，Linux 正式切换到 GPLv2，自此”GNU 工具链 + Linux 内核”的组合开始成型，后来被 Stallman 坚持称为”GNU/Linux”。
进入 2000 年代，GPLv2 遇到两类它当年没预见到的问题：
2007 年 6 月 29 日，FSF 发布 GPLv3，明确要求”可安装信息”（Installation Information），对抗 Tivoization；加入明确的专利授予与专利报复条款；加入对 DRM 的限制。Linus Torvalds 公开表态 Linux 内核不会升级到 GPLv3，理由之一是反对 Anti-Tivoization 条款，认为这超出了”软件许可”应有的范围。这件事让 GPLv2 与 GPLv3 在接下来十余年中并存，并深刻影响了后来 Apache 2.0、MPL 2.0 与 GPLv3 的兼容关系——具体分析会在 Copyleft 的工程边界 与 专利授权与商标 两篇中展开。
1990 年代初期 GNU 项目已经完成了大量用户态工具（GCC、Bash、Coreutils、Make、Binutils、Emacs 等），但缺一个真正可用的内核。GNU Hurd 自 1990 年起开发，却始终未能达到生产级稳定度。1991 年 Linus Torvalds 在 comp.os.minix 发帖公布 Linux 0.01 时，本意是”a free MINIX-like kernel for 386 machines”，他并未打算写出一个对标商用 UNIX 的系统。但到 1992 年 Linus 把 Linux 切换为 GPLv2 后，Linux 和 GNU 工具链的结合立刻释放了巨大的工程势能：一套可编译运行的完整类 UNIX 系统在 1993–1995 年之间快速成熟。
这一段历史对理解”许可证为什么重要”至关重要：
这也是为什么后来 Linus 本人虽然反对 GPLv3，却从未动摇对 GPLv2 的忠诚。
1991 年 GPLv2 发布时同时发布的 GNU Library General Public License（LGPL）也值得一提。Stallman 很快意识到”函数库”和”应用程序”的许可策略必须分开：如果 Glibc 用 GPL，那么任何链接 Glibc 的专有程序都将被要求以 GPL 开源，这显然会让 GNU 生态在商业世界里自我封闭。
1999 年，FSF 将 LGPL 更名为 Lesser General Public License（LGPLv2.1），明确其定位不是”默认选择”，而是仅用于”事实标准库”——即如果不用 LGPL，市场会转向专有替代品的情况。2007 年 LGPLv3 随 GPLv3 同步发布。LGPL 是弱 Copyleft 的典型代表，其工程含义在 GPL 与 LGPL 的工程差异 中展开。
1998 年是开源运动的分水岭年。这一年发生了三件大事，彻底改变了”Free Software”这个词的命运。
1998 年 1 月 22 日，Netscape Communications 宣布将其 Navigator 浏览器源码公开发布。Netscape 此举的直接动机是抵御 Microsoft Internet Explorer 的免费捆绑策略——Microsoft 通过 Windows 95 / 98 捆绑 IE，正在抽干 Navigator 的市场份额。Netscape 认为，唯一能反制的方式是动员全球程序员共同开发一个开放的浏览器引擎，这就是后来的 Mozilla 项目。
Netscape 的决定让硅谷第一次意识到：“开放源码”可以是一个商业战略，而不仅仅是 Stallman 式的伦理立场。
1998 年 2 月 3 日，在加州 Palo Alto 举行的一次战略会议上，一群自由软件社区的意见领袖决定启用一个更”对商业友好”的新词：“Open Source”。这个提议由 Christine Peterson 首先提出，得到了 Eric Raymond、Bruce Perens、Todd Anderson、Larry Augustin、Jon Hall、Sam Ockman 等人的支持。
1998 年 2 月底，Eric Raymond 与 Bruce Perens 共同发起开放源代码促进会（Open Source Initiative, OSI），作为”Open Source”这一术语的维护者与认证机构。OSI 很快发布了开源定义（The Open Source Definition, OSD），这份定义后来成为判断”一个协议是否真的是开源”的全球事实标准。
OSD 的十条标准，每一条都可以对应到后来真实发生过的一次商业冲突。把它完整列出来有助于后面章节对照：
OSD 第 5、第 6 条后来成为判断 SSPL、BUSL、OpenRAIL、LLaMA 社区许可等”新式协议”是否为”OSI 开源”的关键——只要带有”不得用于 X 用途”的条款，就违反了第 6 条；只要带有”某类用户不得使用”（比如”月活超过 7 亿的竞争对手除外”），就违反了第 5 条。
自由软件和开源在协议文本上有很高的重合度——几乎所有 FSF 认可的自由软件许可证都同时是 OSI 认证的开源许可证，反之亦然。但两个阵营的基本价值观不同：
Stallman 在多次公开演讲中明确反对使用”Open Source”这个词，他认为这个词淡化了”自由”的伦理含义，把一场社会运动简化成了工程技巧。Eric Raymond 则通过《大教堂与集市》（The Cathedral and the Bazaar, 1997 / 1999 书籍版）论证开源开发模式的工程优越性。
这场哲学之争到今天仍未结束，但在工程实践中，大多数团队更习惯用”开源”一词，而把”自由软件”视为开源的一个子集 + 哲学源头。
Netscape 开源 Navigator 的直接法律后果是需要一份新的协议。Netscape Public License（NPL）与 Mozilla Public License（MPL）双许可在 1998 年 3 月前后推出，由 Mitchell Baker 起草。MPL 引入了一个新概念：“基于文件的弱 Copyleft”——只有被修改的 MPL 许可文件本身需要继续以 MPL 开源，新增的、独立的文件可以使用专有许可。这种设计后来影响了 CDDL（Sun 2005）、EPL（IBM/Eclipse）等一系列”文件级 Copyleft”协议。
2003 年 7 月 AOL 解散 Netscape 之后，Mozilla 基金会独立成立，接管 Mozilla 代码库。2005 年 Mozilla 公司成立作为商业主体（负责 Firefox 商业化），形成”基金会+公司”双层结构，这一结构后来被 Automattic / WordPress、GitLab 等项目模仿。
OSD 在起草时几乎全文借鉴了 Debian 自由软件指南（Debian Free Software Guidelines, DFSG）。DFSG 由 Bruce Perens 在 1997 年起草，作为 Debian 社区判断”一个软件是否可以进入 main 仓库”的标准。1998 年 Perens 与 Raymond 把 DFSG 删去”Debian”字样、做少量措辞调整后成为 OSD。这种”从发行版规则升格为行业标准”的路径，是开源治理史上一个有趣的模式——类似模式后来在 CNCF（从 Google 内部规则升为云原生行业标准）、OCI（从 Docker 私有格式升为容器运行时标准）中反复出现。
如果说 1983–1998 是个人与社区主导的时代，那 1999 之后就是基金会主导的时代。基金会解决了几个关键问题：商标归属、版权集中、中立托管、合规审计、赞助资金流。
Apache 软件基金会（Apache Software Foundation, ASF）成立于 1999 年 3 月，前身是 1995 年成立的 Apache Group——最初是一群志愿者维护 NCSA HTTPd 的补丁集合（“a patchy server”是一个流传甚广但 ASF 官方并未完全确认的名字来源）。ASF 以”Apache Way”闻名：严格的 Meritocracy（贡献者逐步晋升为 committer 再到 PMC 成员）、完整的 IP Clearance 流程、要求贡献者签署 ICLA（Individual Contributor License Agreement）。
Apache 许可证 2.0（Apache License 2.0）于 2004 年发布，至今是宽松协议中引用最广的一份，后面 MIT/BSD/Apache 2.0 三大宽松协议对比 会专门分析其专利条款与 NOTICE 文件机制。
Linux 基金会（Linux Foundation, LF）的直接前身是 2000 年成立的 Open Source Development Labs（OSDL），2007 年 OSDL 与 Free Standards Group 合并形成今天的 Linux 基金会。它最初的定位是雇佣 Linus Torvalds 等核心内核开发者，让他们不必依附于任何单一商业公司。
从 2014 年开始，Linux 基金会陆续孵化出一系列子基金会与项目，形成”基金会中的基金会”格局：
Eclipse 基金会源于 IBM 2001 年将 Eclipse IDE 代码开源的动作，2004 年 2 月正式独立成基金会。Eclipse 基金会和 ASF 的一个显著区别在于：ASF 使用 Apache 2.0，Eclipse 使用 EPL（Eclipse Public License）——一种弱 Copyleft 协议。2020 年 Eclipse 基金会把总部从美国迁往比利时布鲁塞尔，在很大程度上也是为了回应欧洲企业对”数据主权”和”供应链独立性”的诉求。
OpenStack 基金会成立于 2012 年 9 月，由 Rackspace 与美国国家航空航天局（NASA）主导捐赠；2021 年重命名为 Open Infrastructure Foundation（OpenInfra），以覆盖 Kata Containers、StarlingX、Zuul 等更广泛的基础设施项目。
2015 年 7 月 21 日，Google 在 OSCON 大会上发布 Kubernetes 1.0，同时宣布将 Kubernetes 捐赠给 Linux 基金会下新成立的 CNCF。CNCF 的意义不只是”Kubernetes 的家”，更在于它建立了一个”图形化成熟度阶梯”：Sandbox → Incubating → Graduated，以及一整套 TOC（Technical Oversight Committee）治理机制。2018 年 Kubernetes 毕业，成为 CNCF 第一个 Graduated 项目。
到 2026 年，CNCF 生态图谱中的项目已超过 200 个，成为企业架构决策的实质性标准库。
中国企业大规模参与国际基金会的时间点主要集中在 2016 年之后：
这些节点的意义是：中国企业已经不只是开源软件的”消费者”，而开始深度参与国际基金会的治理结构，这和本文第六节将讨论的”中国自己的基金会”形成双循环。
综合 ASF、LF、Eclipse、CNCF、OpenAtom 等基金会的治理结构，可以归纳出四种典型模式，工程团队在决定把项目捐给哪个基金会时可以参考：
模式 A：单点孵化（ASF 式）
- 所有项目遵循统一的 Apache Way
- 统一 IP 审查、统一 CLA（ICLA / CCLA）
- 统一许可证：Apache 2.0
- 治理层：Incubator PMC → 顶级 PMC → Board
- 优点：合规一致，社区风格可预期
- 缺点：成长节奏固定，创新项目可能受限
模式 B：伞式组织（LF 式）
- LF 是多个子基金会的组合
- 每个子基金会可选独立的许可证、章程、会员费
- 适合规模化运营大型生态
- 优点：治理灵活，可按业务线切分
- 缺点：协议不一致，需要项目级 CLA/DCO
模式 C：成熟度阶梯（CNCF 式）
- Sandbox → Incubating → Graduated
- 每一层有明确"毕业标准"
- 搭配 Landscape 地图、TOC 评议
- 优点：对采纳方提供明确信号
- 缺点：阶梯规则本身需要不断调整
模式 D：国家/主权驱动（OpenAtom 式）
- 在本国民政注册、业务主管部门明确
- 项目治理兼顾本地合规（公司法、税法、数据出境）
- 优点：规避跨境制裁风险、可接本地政府资源
- 缺点：跨境协作仍需双向认证基金会治理的另一个关键维度是版权归属。两种极端：
CLA 与 DCO 会专门讨论这两种模式在中国企业实践中的操作要点。
2018 年前后，“开源”一词开始遇到一个它此前没有遇过的对手：公有云。
Amazon Web Services、Microsoft Azure、Google Cloud 等公有云厂商把开源数据库和中间件封装为托管服务（DBaaS / Managed Service），直接对外收取服务费。这种做法在法律上完全合规——Apache 2.0、MPL、BSD 等协议都不禁止托管运营——但在商业上对原始项目公司是致命的：原公司承担全部 R&D 成本，云厂商几乎零边际成本转手赚钱。
这个矛盾在 2018 年左右集中爆发。
2018 年 10 月 16 日，MongoDB 宣布把 MongoDB Community Server 的许可从 AGPLv3 切换到 Server Side Public License（SSPL）。SSPL 的关键区别在第 13 条：如果你把 MongoDB 作为服务对外提供，不仅要把 MongoDB 本身的源码开源，还必须把”提供该服务所需的所有程序”——包括管理软件、监控软件、备份软件、用户界面等——全部以 SSPL 开源。
这条规定实际上把”SaaS 分发”纳入了 Copyleft 触发范围，比 AGPL 更进一步。2019 年 1 月 16 日，OSI 正式声明 SSPL 不符合 OSD，因此不是”开源许可证”。红帽、Debian 等随后将 MongoDB 从其发行版中移除。
2021 年 1 月 14 日，Elastic 宣布 Elasticsearch 和 Kibana 从 Apache 2.0 切换到”双许可”：Elastic License v2（ELv2）+ SSPL。ELv2 的核心限制是：不得将该软件作为托管服务对外提供，不得规避许可证密钥或其他内建限制。
这次切换的直接对手是 AWS 的 Amazon Elasticsearch Service。AWS 的回应是在三个月内 fork 出 OpenSearch（基于 Apache 2.0），并于 2021 年 9 月发布 1.0 版本。2024 年 9 月，Elastic 进一步宣布 Elasticsearch 8.16 增加 AGPLv3 选项，形成”AGPL / ELv2 / SSPL 三选一”的格局——这被 Elastic 自己描述为”open source, again”，但围绕 OpenSearch 的分叉生态已经无法回头，2024 年 OpenSearch 被 AWS 进一步捐赠给 Linux 基金会下的 OpenSearch Software Foundation。
2023 年 8 月 10 日，HashiCorp 宣布旗下 Terraform、Vault、Consul、Nomad、Packer、Boundary、Waypoint 等核心产品从 MPL 2.0 切换到 Business Source License 1.1（BUSL / BSL）。BSL 是 MariaDB 公司 2013 年创立的一种”延迟开源”协议：源码可见、非生产性使用可自由修改，但生产性使用需要商业许可；在”变更日期”（Change Date，通常为 4 年后）后自动转换为指定的开源协议（HashiCorp 指定为 MPL 2.0）。
HashiCorp 这次切换触发了 Terraform 社区的直接分叉：2023 年 8 月 25 日，OpenTF 宣言发布；2023 年 9 月 20 日，Linux 基金会宣布成立 OpenTofu 项目（原 OpenTF），基于 Terraform 1.5.6（最后一个 MPL 版本）继续发展；2024 年 1 月 10 日，OpenTofu 1.6 GA。
2024 年，HashiCorp 被 IBM 以约 64 亿美元收购的公告发布（2024 年 4 月 24 日），这使 BSL 争议再次被重提：工程界普遍意识到，单一公司控制的”商业开源”项目存在被收购后许可条款随时变化的风险。
2024 年 3 月 20 日，Redis Ltd. 宣布 Redis 从 BSD-3-Clause 切换到”RSALv2 + SSPLv1”双许可。第二天，Linux 基金会宣布成立 Valkey 项目，由 AWS、Google Cloud、Oracle、Ericsson、Snap 等联合赞助，从 Redis 7.2.4 fork 出来继续以 BSD-3-Clause 开发。Valkey 8.0 于 2024 年 9 月发布。
2025 年 5 月，Redis Ltd. 宣布 Redis 8 再次加入 AGPLv3 选项——和 Elastic 的路径类似，“回到开源”成为 2024–2025 年的一个共同叙事。但正如 OpenSearch 与 Valkey 所显示的，社区一旦分叉就很难合流。
2024 年 9 月 5 日，Sentry、PowerSync、Keygen 等公司联合发起 Fair Source 倡议（fair.io），给”对普通开发者自由、对直接竞争对手有限制”的许可证一个统一品牌。目前 Fair Source 认可的协议包括 FSL（Functional Source License，2 年后转为 MIT/Apache 2.0）、BSL（Business Source License）和 FCL（Fair Core License）等。
Fair Source 承认自己不是 OSD 意义上的”开源”，而是一个”第三条道路”：在完全专有和完全开源之间，为 SaaS 时代的单一厂商项目提供一种可持续商业模式。
把以上事件叠加到最初的四象限图上，可以看出过去六年的整体趋势：
这是一个持续博弈的过程，而不是一次性迁移，具体协议层面的比较见 AGPL、SSPL 与 BSL：网络 Copyleft 与”伪开源”之争。
“Source Available”并不是 2018 年才出现的概念。可以追溯的标志性事件：
另一个值得记录的 BSL 采用者是 Cockroach Labs。2019 年 6 月，CockroachDB 从 Apache 2.0 切换到 BSL 1.1，变更日期 3 年，未来许可为 Apache 2.0。2024 年 8 月 Cockroach Labs 进一步把 CockroachDB 从 BSL 切到纯商业许可 CockroachDB Software License，不再承诺 3 年后转开源。这一动作比 HashiCorp 的 BUSL 更激进，是”Source Available → 专有”的直接迁移，也说明 BSL 的”延迟开源承诺”并非不可撤销。
OSI 拒绝把 SSPL、BUSL、ELv2、Llama Community 等协议纳入开源认证，理由集中在 OSD 第 5、6、9 三条上：
OSI 的保守在 2020s 社区中一度引发反弹：“你的十条标准是 1998 年制定的，还不足以覆盖云计算与大模型时代。”OSI 回应包括 2024 年发布的 OSAID（专门针对 AI）和持续讨论中的”OSD 修订”动议。但到 2026 年，OSD 原文仍未修订，OSI 列表仍然是判断”真正开源”的基准。
大模型（Large Language Model, LLM）让”开源”这个词进入了一个新的语义区。源代码、模型权重、训练数据、微调脚本——谁算”作品”？谁要开放？如何合规？
一个训练好的大模型至少有四层产物：
Meta、阿里、DeepSeek 等公司发布的”开源模型”大多只开放第 3、4 层，第 1、2 层要么保密要么部分保密。这让”开源大模型”本质上是一种混合产物：权重可自由下载、微调、再分发，但训练语料几乎不会公开。在严格意义上，这甚至不符合 OSD 第 2 条”源代码必须是修改该程序的首选形式”——因为模型权重是训练脚本 + 数据 + 算力的产物，修改权重的”首选形式”是重新训练，而数据不公开。
OSI 在 2024 年 10 月发布了开源 AI 定义（Open Source AI Definition, OSAID）1.0，尝试给这种混合产物划一条新线：训练代码、模型参数、“充分详细的数据信息”（data information）必须公开，而未必要求原始训练数据本身完全公开。这份定义在社区内仍有争议，Llama 等项目明确不符合 OSAID 1.0 标准。
Responsible AI License（RAIL）起源于 2022 年 BigScience 的 BLOOM 模型发布。BigScience 是一个由 HuggingFace 主导、全球数百位研究者参与的多语言大模型合作项目，BLOOM（1760 亿参数）于 2022 年 7 月发布，采用 BigScience RAIL License（BigScience OpenRAIL-M）。
OpenRAIL 的核心是”使用限制附录”（Use-based Restrictions），禁止一系列用途，例如：
从 OSD 第 6 条看，OpenRAIL 违反了”不得歧视任何应用领域”，因此不是 OSI 意义上的开源协议。但它表达了一种真实的伦理诉求：在模型能力突破法律滞后期的现实下，许可证成了唯一可操作的约束手段。
后来的 Stable Diffusion（CreativeML OpenRAIL-M，2022 年 8 月）、Starcoder（BigCode OpenRAIL-M，2023 年 5 月）都采用了 OpenRAIL 变体。
Meta 的 LLaMA 系列提供了一条完整的”从非开源到越来越开源”的路径：
Llama Community License 因违反 OSD 第 5 条（歧视特定主体）和第 6 条（限制使用领域），不属于 OSI 开源。但 Meta 在宣传中坚持使用”open source”一词，这一直是 OSI 与 Meta 之间公开的措辞冲突。
中国主要大模型在许可上大致呈现几种风格：
2024–2025 年的一个明显趋势是”向 Apache 2.0 回归”：一方面是为了便于企业合规采纳，另一方面也是国际竞争下”开源话语权”的战略需要。具体在国产开源协议部分，木兰协议（MulanPSL/PubL） 会进一步讨论与 Apache 2.0 的对比。
模型训练离不开数据，但数据本身不是软件。Creative Commons（CC）系列协议（CC0、CC BY、CC BY-SA、CC BY-NC 等）成为数据集许可的默认选择。常见的数据集许可陷阱包括：
这些问题会在 数据集、模型权重与 Creative Commons：AI 时代的”作品”边界 展开。
大模型开放程度的光谱非常宽。BLOOM、Mistral、Gemma 各自代表一种取向，放在一起对比很有意思：
模型 发布方 权重许可 代码许可 训练数据开放
BLOOM-176B BigScience/HF BigScience OpenRAIL-M Apache 2.0 高（ROOTS 语料部分公开）
Mistral 7B Mistral AI Apache 2.0 Apache 2.0 不公开
Mistral 8x22B Mistral AI Apache 2.0 Apache 2.0 不公开
Gemma 2 Google Gemma Terms of Use Apache 2.0 不公开
Gemma 3 Google Gemma Terms of Use Apache 2.0 不公开
StarCoder 2 BigCode BigCode OpenRAIL-M Apache 2.0 较高（The Stack v2）
Falcon 180B TII UAE Falcon-180B TII License Apache 2.0 不公开
Grok-1 xAI Apache 2.0（权重） Apache 2.0 不公开从这张表可以看出：
工程上评估一个模型是否”可商用”不能只看一条条款，而要按四个要素打分：
四要素任何一个不通过，都要视作”不可无条件商用”。详细表格在 数据集、模型权重与 Creative Commons 展开。
开源的中国故事有一条相对独立的演化线，值得单独拉出来讲。
开放原子开源基金会（OpenAtom Foundation）于 2020 年 6 月在北京民政部登记成立，是中国第一家专注于开源的国家级非营利基金会，业务主管单位为工业和信息化部。首批理事单位包括华为、阿里、百度、腾讯、浪潮、招商银行、中兴、360 等。
根据 openatom.org 官方公开信息，首批正式捐赠并孵化的项目包括：
此后陆续孵化/捐赠的项目包括 TencentOS Tiny（腾讯物联网 RTOS）、MindSpore（华为 AI 框架，2022）、Kata Containers 中国镜像、AtomGit（代码托管）等。
到 2026 年，开放原子基金会的项目池已经覆盖操作系统、AI 框架、区块链、RTOS、开发工具链、数据库等核心基础设施。其意义不仅是一个中立托管机构，更在于它创造了一种新的法律载体：国内企业捐赠的开源项目可以归属到一个国内注册的法人实体，避免了”境外基金会风险”（例如 Apache 被美国出口管制影响、openSUSE/SUSE 被美国实体清单间接影响等）。
木兰宽松许可证（Mulan Permissive Software License, MulanPSL）由北京大学受工信部软件与集成电路促进中心（CSIP）委托起草，于 2019 年 8 月发布 1.0 版本，2020 年 1 月发布 2.0 版本。MulanPSL-2.0 于 2020 年 2 月 14 日通过 OSI 认证，成为第一个由中国主导、获得 OSI 认证的许可证。
同系列还包括木兰公共许可证（MulanPubL-2.0，弱 Copyleft）。木兰系列协议的主要设计动因是：
具体条款分析见 木兰协议：中国开源许可的工程视角。
OpenChain 项目 2016 年在 Linux 基金会下成立，目标是为”组织开源合规流程”建立一套标准。2020 年 12 月，OpenChain 规范 2.1 版正式成为 ISO/IEC 5230:2020，是全球第一个开源合规管理体系国际标准。
中国企业较早完成 ISO/IEC 5230 认证的包括华为（2021）、招商银行（2022）、中兴通讯（2022）、蚂蚁集团（2023）等。OpenChain 中文工作组（OpenChain China Work Group）长期在社区运营，形成了国内企业开源合规体系建设的重要对标参考，对 OSPO 的搭建尤其重要，具体会在 OSPO：把开源治理写进组织架构 讨论。
有两个与”中国开源”紧密相关的真实事件非常值得一提（详细内容在后续案例文章中）：
2015 年之后国内基础软件公司开始批量开源，可以分三代观察：
根据 openatom.org 及工业和信息化部官方新闻稿，2020 年 6 月以来的关键节点可以整理为：
2020-06-15 开放原子开源基金会在北京成立，首批发起方 9 家
2020-09-10 OpenHarmony 1.0 发布（捐赠方：华为）
2020-12-xx XuperChain 正式捐赠（捐赠方：百度）
2021-04-07 OpenHarmony 2.0 Canary
2021-09-22 OpenHarmony 3.0 LTS
2021-11-09 openEuler 捐赠完成并启动社区治理（捐赠方：华为）
2022-03-30 OpenHarmony 3.1 Release
2022-04-xx MindSpore 捐赠（捐赠方：华为）
2022-09-xx 腾讯 TencentOS Tiny 捐赠
2023-06-xx AtomGit 代码托管平台公测
2023-10-xx OpenHarmony 4.0 Release
2024-xx-xx 多款 AI / RTOS / 数据库项目完成捐赠这一时间线说明：开放原子开源基金会不是一个象征性机构，而是一个具备持续运营能力的本土开源治理实体。对中国企业而言，它提供了”把开源项目捐赠到国内注册法人”这一选项，在数据跨境和实体清单两端都有现实意义。
2018 年红芯浏览器事件之后，国内对”开源合规”话题的关注明显上升。2019–2022 年间出现几类关键事件：
这一轮合规浪潮的工程意义是：开源合规从”个别技术总监的坚持”变成”投融资必过的体检项”，OSPO 成为大中型科技企业的标准组织。
除了基金会托管的项目，中国还有大量”社区自治”的开源项目，典型代表：
这些项目在许可证选择上呈现”宽松协议为主、木兰为辅”的格局。
到这里可以回答开头的第一个问题了：自由软件、开源、Source Available、专有软件的关系。
FSF 维护的”自由许可证列表”和 OSI 认证的”开源许可证列表”高度重合但不完全相同。FSF 认可、OSI 未认证或有异议的例子包括：
Source Available 是一个光谱，从”完全闭源”到”几乎开源”之间有无数刻度。判断一个协议是”开源”还是”Source Available”的官方标准只有一个：是否通过 OSI 认证（https://opensource.org/licenses）。凡是 OSI 列表里没有的，严格说都不是”开源”。
本文开头图的四象限对应工程实践里四种使用心态：
| 象限 | 代表 | 可以做什么 | 主要风险 |
|---|---|---|---|
| 真正开源（OSI 认证） | Linux、Kubernetes、PostgreSQL、OpenHarmony、openEuler | 商用、修改、再分发均允许 | Copyleft 传染性（GPL/AGPL）、归属义务（BSD/Apache） |
| Source Available（含 BSL/SSPL/OpenRAIL/Llama） | MongoDB、Elastic、Redis、Terraform、LLaMA 2/3 | 通常允许商用但有额外限制 | 某类”商业竞争”禁止；月活门槛；用途限制 |
| 自由软件哲学源头 | GNU Hurd、GNU Coreutils、Emacs | 同象限一，附带伦理要求 | 无额外工程风险，但文化敏感（FSF 反对 tivoization） |
| 专有 | Windows、Oracle DB、核心大模型 API | 只能按 EULA / API ToS 使用 | 合规、许可费、供应链依赖 |
如果一个项目跨越多个象限（比如 Elastic 同时提供 AGPL / ELv2 / SSPL 三条许可线，LLaMA 同时提供权重 Community License 和代码 MIT），工程团队必须按”实际选择的那一条”评估风险，不能混用。
BUSL 是一个有趣的边界例子：HashiCorp 的 Terraform 在 BUSL 1.1 下源码可下载、可自用、可非生产测试，但生产使用就要商业许可；4 年后自动转为 MPL 2.0。严格按 OSI 标准，BUSL 时期的 Terraform 不是开源，尽管很多人习惯这么叫。正确的说法是”延迟开源”或”Source Available with delayed open source release”。这种措辞上的精确性在合规审计（尤其是投融资尽调）里会被反复追问。
把本文涉及的主要协议集中对比一次：
协议 OSI 认证 类型 主要特点 代表项目
---------------------------------------------------------------------------------------------
GPLv2 是 强 Copyleft 分发触发、源码义务 Linux、Git
GPLv3 是 强 Copyleft 加入 Anti-Tivoization、专利条款 GCC、Bash、Samba
AGPLv3 是 网络 Copyleft SaaS 也要开源 MongoDB（2018 前）
LGPLv2.1 / 3 是 弱 Copyleft 链接库可闭源 Glibc、Qt（部分）
MPL 2.0 是 文件级 Copyleft 只改的文件需开源 Firefox、Thunderbird
EPL 2.0 是 弱 Copyleft 可选 GPL-兼容 Eclipse IDE、Jetty
Apache 2.0 是 宽松 专利授予 + 专利反诉 大量 ASF 项目
MIT 是 宽松 最短协议之一 Node.js、Rails
BSD 3-Clause 是 宽松 不得借名背书 FreeBSD、LLVM（前期）
BSD 0-Clause 是 宽松 几乎无任何义务 部分玩具项目
MulanPSL-2.0 是 宽松 中文优先、专利授予 openEuler、龙蜥
SSPL 否 Source Avail. 服务化需全链路开源 MongoDB（2018 后）
BUSL 1.1 否 延迟开源 生产使用需商业许可 Terraform、Vault
ELv2 否 Source Avail. 禁止托管竞争 Elasticsearch（2021-2024）
Llama Community 否 有限制发布 7 亿月活 + 商标限制 LLaMA 2 / 3 / 3.1
OpenRAIL-M 否 Responsible 禁止特定用途 BLOOM、StarCoder
CC BY 4.0 否* 数据/内容 署名即可 Wikipedia、多数数据集
CC BY-SA 4.0 否* 数据/内容 署名 + 相同方式分享 Wikipedia
CC BY-NC 4.0 否* 数据/内容 署名 + 非商业 受限数据集
CC0 1.0 否* 数据/内容 公有领域奉献 部分数据集注：Creative Commons 系列协议本身不在 OSI 管辖范围内（OSI 只认证软件许可），但 CC BY 4.0 被 Wikimedia、OpenStreetMap、数据集社区广泛用作内容许可。
一个项目可以采用多种许可并行：
双许可/多许可的核心前提是”足够的版权控制”：项目公司必须有能力汇总全部版权（通过 CLA），才能在任何时候重新决定许可。Linux 内核这种分散版权的项目无法采用双许可模式，而 MySQL、MongoDB、HashiCorp 等都建立了完整的 CLA 流程。
下面是工程团队在 2026 年采用开源时几种反复出现的坑。后续文章会逐一展开。
这是最经典的 Copyleft 事故。嵌入式、路由器、IoT 设备厂商最常犯。典型场景：用 BusyBox、U-Boot、Linux 内核构建路由器固件，但不向终端用户提供源码。2007–2012 年 Software Freedom Conservancy 多次以 BusyBox 为主体在美国发起诉讼；2020 年代开始，Christoph Hellwig 个人在德国对 VMware、Vizio 等发起 GPL 诉讼。中国国内的”数字天堂诉柚子科技”案是国内首例 GPL 诉讼，2018 年立案、2022 年有公开判决信息（不在此文猜测具体判决金额），更多讨论见 中国法下的软件著作权与开源。
实战建议：
1. 维护一份 SBOM（Software Bill of Materials），记录每个依赖的许可证与来源。
2. 对 GPL/AGPL 依赖建立"允许清单 / 禁止清单"。
3. 固件发布时附带书面要约（written offer）或源码镜像 URL。
4. 容器化产品：把 GPL 组件放到独立进程/容器，用标准 IPC 解耦。AGPL 第 13 条把”通过网络向用户提供服务”也当作分发。常见误解包括：
具体判断边界在 Copyleft 的工程边界 展开。
Apache 2.0 的 NOTICE 文件机制常被忽视。NOTICE 文件是由上游作者准备的”必须随二进制一同分发的声明”，例如 Hadoop、Kafka 的 NOTICE 文件中包含 Apache Software Foundation 的归属声明和特定第三方声明。如果你把 Hadoop 打进自己的发行包却漏掉 NOTICE，严格说违反了 Apache 2.0 第 4 条第 (d) 项。
此外，Apache 2.0 第 3 条包含专利授予和专利反诉终止条款：如果你对任何使用 Apache 2.0 作品的人发起专利诉讼，你自己基于 Apache 2.0 的专利许可自动终止。这对有”专利池战略”的公司是一个需要理解的边界。
2024 年之后最频繁的合规问题是：“这个模型能不能商用？”简单对照几个代表：
模型 商用 月活/特殊限制 训练输出可再训练
Llama 3.1 Community ✅ 7 亿月活以上需申请 ✅（从 Llama 3.1 起）
Llama 2 Community ✅ 7 亿月活以上需申请 ❌（禁止用于训练其他模型）
Qwen2.5 / Qwen3（多数） ✅ 无月活（Apache 2.0） ✅
DeepSeek License ✅ 保留禁止用途清单 ✅
Mistral 7B / 8x7B（Apache 2.0） ✅ 无 ✅
Gemma 2 Community ✅ Google Prohibited Use ✅工程上，每一次”拉起一个新项目”时必须把上述表格”按自己的用例”过一遍，而不是默认”开源模型都能商用”。
真实项目依赖图经常跨越几百个库，每个都有自己的协议。常见陷阱：
工具层面需要 Software Composition Analysis（SCA）工具，具体见 SCA 与 SBOM 工具链。
合规团队经常在投融资尽调时遇到的问题：员工把内部代码推到了 GitHub 公开仓库，但未签 CLA/DCO，法律上的版权归属状态不清晰。公司若被收购，买方通常要求完成历史贡献者 CLA 回签（retrospective CLA），这在有前员工的项目里可能耗数月。详见 CLA 与 DCO：贡献协议与版权归集。
2020 年代之后的一个新维度：美国 EAR、BIS 实体清单、OFAC 制裁名单会直接波及开源协作。Apache 基金会 2019 年起禁止来自被制裁国家的贡献者在某些密码学项目中提交；GitHub 曾短暂对伊朗用户限制；Linux 基金会 2024 年 10 月的 Kernel 维护者”移除俄罗斯关联维护者”事件也引发广泛讨论。对中国企业，具体影响见 出海合规：EAR、ECCN 与基金会治理。
2022 年俄乌冲突后，一系列基金会出现”政治化治理”信号：ASF 曾短暂讨论对被制裁国家贡献者的处理，Linux 基金会 2024 年 10 月移除部分俄罗斯籍内核维护者。对中国企业而言，“基金会中立性”已不能简单默认。
实战建议：
1. 核心资产不完全依赖单一基金会托管
2. 关键项目在境内保留一份镜像和维护团队
3. 对等参与国内基金会（开放原子）与国际基金会（ASF/LF）
4. 专利和商标的注册地考虑多法域布局
5. CLA 条款加入"主管法域"以应对跨境诉讼工程上，许可证允许使用源码不等于允许使用项目名称。许可证与商标是两条平行的法律线。详细讨论见 专利授权与商标。
国内工程实践还有几个国际项目很少提及的坑：
SBOM 不是”给法务打印的一张表”，而是贯穿构建、发布、运行的活数据。一个最小可用的 SBOM 流水线结构：
stages:
- name: build
steps:
- run: make build
- run: syft packages dir:. -o spdx-json > sbom.spdx.json
- name: scan
steps:
- run: grype sbom:sbom.spdx.json --fail-on high
- run: scancode --license --copyright --json-pp licenses.json .
- name: policy
steps:
- run: opa eval -i sbom.spdx.json -d policy.rego "data.license.allow"
- name: publish
steps:
- run: cosign attest --predicate sbom.spdx.json artifact
- run: oras push registry/sbom:tag sbom.spdx.json其中 policy.rego 是以 Rego
表达的许可证策略，例如”禁止 AGPL、GPL
仅限内部服务”等。上述工具链的工程细节在 SCA 与 SBOM 工具链
展开。
给内部贡献者的最小检查清单：
提交前：
□ 新文件顶部有 SPDX-License-Identifier 标签
□ 不引入未审批的第三方依赖
□ 不直接复制其他项目代码（即使是 MIT 也需记录来源）
□ 如为公司员工贡献外部项目，走 OSPO 审批
提交时：
□ Commit message 带 Signed-off-by（DCO）
□ CI 合规扫描通过
□ 如为首次贡献，完成 CLA 签署
合并后：
□ 更新 NOTICE / THIRDPARTY 文件
□ 更新 SBOM
□ 如引入新许可证类型，通知法务面对一个新项目，工程团队如何决定使用哪些开源软件、以什么协议发布自己？
1. 这个依赖在 OSI 列表里吗？
├─ 是 → 进入 2
└─ 否 → 视为 Source Available，按商业风险评估
2. 这个依赖的协议是什么类型？
├─ 宽松（MIT/BSD/Apache 2.0） → 只需做归属与 NOTICE
├─ 弱 Copyleft（LGPL/MPL/EPL） → 注意动态链接/独立文件传染性
├─ 强 Copyleft（GPL） → 评估是否"分发"
└─ 网络 Copyleft（AGPL） → 评估 SaaS 边界
3. 这个依赖属于供应链安全关键层吗？
├─ 是（加密、身份、内核、容器运行时） → 加入 OSS 资产清单
└─ 否 → 进入常规审计
4. 这个依赖所属项目稳定吗？
├─ 基金会托管（ASF/LF/Eclipse/OpenAtom） → 治理风险较低
└─ 单一公司控制 → 警惕未来协议变化（参考 2018-2024 年案例）1. 想要别人如何使用你的代码？
├─ 任何方式都行（最大传播） → MIT / Apache 2.0
├─ 允许商用但要求改进回流 → MPL 2.0 / LGPL
├─ 禁止闭源衍生 → GPL
├─ SaaS 也要开源 → AGPL
└─ 禁止云厂商托管为竞争服务 → BUSL / SSPL / ELv2（非 OSI）
2. 你是否有专利？
├─ 是 → 选择带专利条款的协议（Apache 2.0 / GPLv3 / MPL 2.0）
└─ 否 → MIT / BSD 也可
3. 你是否希望获得 OSI 认证标签？
├─ 是 → 在 OSI 列表中挑
└─ 否 → 可用 BUSL / FSL / OpenRAIL 等
4. 你的目标社区在中国？
├─ 是 → 考虑 MulanPSL-2.0 / MulanPubL-2.0
└─ 否 → 国际主流协议
5. 你的产品包含大模型？
├─ 是 → 评估权重 / 代码 / 数据集分别使用的协议
└─ 否 → 按常规项目1. 建立 OSPO（Open Source Program Office），哪怕只有一个人。
2. 采纳 ISO/IEC 5230 OpenChain 基线。
3. 持续维护 SBOM。
4. 参加一家中立基金会（开放原子 / ASF / LF / Eclipse）提升治理经验。
5. 法务与工程团队每季度同步一次"协议变化动态"。
6. 对核心产品做"2018-2024 式协议切换"的情景演练。下面给出几类国内常见项目的推荐配置，供快速参考：
场景一：国内 SaaS 产品，核心是后端 API
核心代码 专有（不开源）
接入 SDK MIT / Apache 2.0（客户友好）
客户端工具 Apache 2.0
开源组件选择 避免 AGPL（除非已做 SaaS 合规评估）
供应链管理 SCA + SBOM + OSPO场景二：数据库/中间件公司，走商业开源路线
社区版本 Apache 2.0 或 MulanPSL-2.0
企业版本 专有或 BSL（延迟开源）
CLA 必须，便于未来双许可
基金会托管 进入 ASF 或开放原子，以换取品牌与中立
客户案例 明确"社区版边界"，避免云厂商托管竞争场景三：大模型发布，既要采纳又要变现
权重 自定义社区许可 + 月活阈值（可参考 Llama 3.1）或 Apache 2.0（参考 Qwen 2.5）
训练代码 Apache 2.0 / MIT
推理工具链 Apache 2.0
数据集 分子集标明许可（CC BY 4.0 / CC BY-SA）
商标 保留"核心名称 + 版本号"为注册商标
责任条款 明确禁止特定用途（如儿童有害内容、深度伪造无授权）场景四：嵌入式 / IoT 固件
底层内核 Linux（GPLv2），必须提供源码获取渠道
用户态工具 BusyBox / Alpine，注意 GPL 合规
BSP 驱动 尽量采用 Apache 2.0 或厂商提供的 LGPL
固件签名 设计机制时注意不违反 Anti-Tivoization（如要兼容 GPLv3）
合规发布 SBOM + 书面要约 + 源码镜像场景五：投融资尽调准备
1. 完整 SBOM（JSON / SPDX / CycloneDX 格式）
2. 依赖协议统计（宽松 / 弱 Copyleft / 强 Copyleft / 其他）
3. CLA/DCO 覆盖率（全部贡献者是否签署）
4. 商业许可采购记录（专有依赖的合法性证明）
5. 合规诉讼筛查（内部团队与外部律师共同复核）
6. 过去 3 年协议变更影响评估（被收购的项目、切协议的项目）开源是默认选项，但并非所有场景都合适：
判断原则是：“开源是一种投资，不是一种美德”——需要算 ROI。
一张紧凑的时间线备忘，供复习：
1983-09 GNU 项目宣告
1985-10 FSF 成立
1989-01 GPLv1
1991-06 GPLv2
1991-09 Linux 0.01
1998-01 Netscape 开源 Navigator
1998-02 OSI 成立，"Open Source"一词启用
1999-03 Apache 软件基金会成立
2000-xx Linux 基金会前身 OSDL 成立
2001-11 Eclipse 开源
2004-02 Eclipse 基金会独立
2004-xx Apache License 2.0 发布
2007-06 GPLv3 发布
2008-08 OSChina（开源中国）上线
2012-09 OpenStack 基金会成立
2013-xx MariaDB BSL 1.0
2015-07 Kubernetes 1.0
2016-01 CNCF 成立
2018-10 MongoDB 改用 SSPL
2019-01 OSI 声明 SSPL 非开源
2019-08 木兰 MulanPSL-1.0
2020-01 MulanPSL-2.0
2020-02 MulanPSL-2.0 通过 OSI 认证
2020-06 开放原子开源基金会成立
2020-09 OpenHarmony 1.0
2020-12 OpenChain 成为 ISO/IEC 5230
2021-01 Elastic 切 ELv2 + SSPL
2021-04 AWS OpenSearch 1.0 发布（9 月 GA）
2022-07 BLOOM 发布，OpenRAIL-M
2022-08 Stable Diffusion，CreativeML OpenRAIL-M
2023-07 Llama 2 Community License
2023-08 HashiCorp 切 BUSL
2023-09 OpenTofu 立项
2024-01 OpenTofu 1.6 GA
2024-03 Redis 切 RSALv2 + SSPL，Valkey 成立
2024-04 Llama 3，HashiCorp 被 IBM 收购公告
2024-07 Llama 3.1，许可显著宽松
2024-09 OSI 发布 OSAID 1.0 草案→正式
2024-09 Fair Source 运动（fair.io）
2024-09 Elasticsearch 8.16 加入 AGPLv3 选项
2024-09 Valkey 8.0
2025-05 Redis 8 再加入 AGPLv3 选项
2025-04 Llama 4回到开头的三个问题，本文已经分别回答：
本系列的后续文章会分专题展开：
建议的第一遍阅读路径：本篇 → 03 → 06 → 07 → 08 → 02 → 09 → 13。
本文为工程与历史梳理，不构成法律意见。文中引用的协议变更、基金会公告、许可证文本、判例说明均以各自官方版本为准，读者在做合规判断时应结合当前最新文本与专业法律顾问意见。特别是大模型权重与数据集许可，2024 年之后仍在快速演化，请以最近一次官方发布为准。
把开源四十年放在一个句子里：从”自由软件”的伦理运动，到”开源”的工程方法论，再到”Source Available / Fair Source”的商业对抗，再到”开源 AI”的语义扩展——每一次变化都是在回答”谁为开源付费、谁承担开源风险”这个根本问题。 这个问题没有终极答案，因此下一次协议浪潮一定还会到来。
2018 年的 SSPL、2023 年的 BUSL、2024 年的 OpenRAIL 和 Valkey/OpenTofu 分叉，只是这条长周期博弈中的几个节点。到 2026 年，可以预见的未来议题至少包括：大模型权重的”可复现性”是否会被 OSI 纳入新版 OSD；AI 生成代码的许可兼容（被训练语料是 GPL 的情况下，生成代码的许可属性如何判断）；跨境开源在地缘冲突下的分叉风险如何缓释。
本文是一张总览图，后续十九篇会把每一个细节做成可执行的工程指南。对于马上要做选型的读者，有三条建议路径：
在真实业务里，开源许可不是孤立问题，它与版权、专利、商标、数据、出口管制、投融资尽调、生成式 AI 合规交织在一起。“看懂一张地图”是第一步，“把地图落到工程流水线”才是 OSPO 的真正任务。
上一篇：开源许可与版权工程
下一篇：中国法下的软件著作权与开源
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / opensource
系统梳理文档（CC 家族）、数据库（ODbL/PDDL）与 AI 模型（OpenRAIL、LLaMA、Mistral、Qwen、DeepSeek）的许可框架；OSI 2024 年开源 AI 定义（OSAID 1.0）；以及书生·浦语、智源、百川、通义千问、DeepSeek 在中国的协议演变。
2026-04-22 · architecture / opensource
模型权重到底是代码、数据、还是全新的客体？为什么 Meta 的 LLaMA、Google 的 Gemma、Stability 的 StableLM、BigScience 的 BLOOM 选了完全不同的许可证？OpenRAIL-M 的 'Use-Based Restrictions' 在工程上如何落地？本文逐条解析 8 类主流模型许可证，给出企业自研、微调、商用、二次分发四个场景的决策清单。
2026-04-22 · architecture / opensource
深入解析 GPLv2 到 GPLv3 的条款变化、Tivoization 反规避与 DRM 条款、专利终止条款；LGPL 链接例外的工程边界；以及 Linus Torvalds 拒绝升级到 v3 的真实原因与嵌入式生态影响。包含路由器厂商、国内 Android 设备的 GPL 合规真实案例。
2026-04-22 · architecture / opensource
深入解读木兰宽松许可证 v2（OSI 认证）与木兰公共许可证 v2（弱 Copyleft）的条款：专利明示授权、中英双语法律效力、中国管辖条款；openEuler、openGauss、OpenHarmony、PaddlePaddle 的使用情况；以及与 Apache 2.0 的对比选择建议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。