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

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

2026-04-22 · architecture · opensource · #opensource #gnu #linux #fsf #osi #openatom #openrail #llama #qwen #cncf

文章导航

分类入口
architectureopensource
标签入口
#opensource#gnu#linux#fsf#osi#openatom#openrail#llama#qwen#cncf

目录

开源已经不是一个哲学问题，而是一个工程、商业和法律交织的系统工程问题。把一份 GPL 代码静链进商用固件、把 AGPL 服务封装进 SaaS 对外卖 API、把 SSPL 的 MongoDB 托管成云数据库、把 LLaMA 2 的权重拿去训练商用客服机器人——每一件事背后都有一条可能触发的许可红线。理解这条红线从哪里来、为什么会在这里、未来会往哪里走，需要先把”开源世界”这张地图看清楚。

这篇文章是整个《开源许可与版权工程》系列的第一篇，也是一张导览图。后续文章会把其中每个节点展开成完整的工程指南，本篇的目标是让读者在读完后能回答三个问题：

  1. 自由软件（Free Software）、开源（Open Source）、Source Available、专有软件这四者到底是什么关系？
  2. 为什么 2018 年之后”开源协议”会出现一波集体变化，MongoDB、Elastic、HashiCorp、Redis 到底在反抗什么？
  3. 中国的开源生态走到 2026 年这一步，从”Linux 爱好者”到”开放原子开源基金会”，经历了哪些关键节点？

先放一张全景图，文章的叙事会围绕这四个象限展开：

开源许可证演进与分类全景

本文为工程与历史梳理，不构成法律意见。文中涉及的许可协议文本、基金会章程、企业公告以各自官方版本为准，阅读时请以最新版本核对。

一、自由软件运动：从打印机驱动到 GNU GPL

开源故事的起点不是一个协议，而是一台打印机。1980 年前后，麻省理工学院人工智能实验室（MIT AI Lab）的 Richard Stallman 想修改施乐（Xerox）实验室一台激光打印机的驱动程序，以便在打印任务卡纸时通知在排队的用户，但施乐拒绝提供源代码。这件事被后来几乎所有讲述开源历史的书反复引用，因为它让 Stallman 看到了一件事：当软件被闭源和专利锁死，程序员之间互相协作、互相学习、互相修复问题的传统——也就是 1960–1970 年代黑客文化中的默认设定——正在消失。

1.1 GNU 项目（1983）与 FSF（1985）

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 分歧的关键：自由软件是伦理运动，开源是工程方法论。

1.2 GNU GPL：Copyleft 的诞生

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”。

1.3 GPLv3（2007）：回应 Tivoization 与专利

进入 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 的工程边界 与 专利授权与商标 两篇中展开。

1.4 GNU/Linux 组合与 1990 年代早期生态

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 的忠诚。

1.5 LGPL 与图书馆问题

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 年的路线分裂

1998 年是开源运动的分水岭年。这一年发生了三件大事，彻底改变了”Free Software”这个词的命运。

2.1 Netscape 开源 Navigator

1998 年 1 月 22 日，Netscape Communications 宣布将其 Navigator 浏览器源码公开发布。Netscape 此举的直接动机是抵御 Microsoft Internet Explorer 的免费捆绑策略——Microsoft 通过 Windows 95 / 98 捆绑 IE，正在抽干 Navigator 的市场份额。Netscape 认为，唯一能反制的方式是动员全球程序员共同开发一个开放的浏览器引擎，这就是后来的 Mozilla 项目。

Netscape 的决定让硅谷第一次意识到：“开放源码”可以是一个商业战略，而不仅仅是 Stallman 式的伦理立场。

2.2 OSI 成立与”Open Source”命名

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），这份定义后来成为判断”一个协议是否真的是开源”的全球事实标准。

2.3 开源定义（OSD）十条

OSD 的十条标准，每一条都可以对应到后来真实发生过的一次商业冲突。把它完整列出来有助于后面章节对照：

  1. 自由再分发（Free Redistribution）：不得限制任何人销售或赠与该软件。
  2. 源代码（Source Code）：程序必须包含源代码，或提供公开获取源代码的渠道。
  3. 衍生作品（Derived Works）：必须允许修改和衍生作品，并允许以相同条款分发。
  4. 作者源代码完整性（Integrity of The Author’s Source Code）：可以要求衍生作品换名字或版本号，但不得完全禁止修改后的分发。
  5. 不得歧视任何个人或团体（No Discrimination Against Persons or Groups）。
  6. 不得歧视任何应用领域（No Discrimination Against Fields of Endeavor）：不能写”本软件不得用于核武器研究”或”不得用于商业用途”。
  7. 许可证的分发（Distribution of License）：许可证必须随软件自动授予所有接收者，无需再签协议。
  8. 许可证不得专属于某个产品（License Must Not Be Specific to a Product）。
  9. 许可证不得限制其他软件（License Must Not Restrict Other Software）：不能要求同发行光盘上的其他软件也必须开源。
  10. 许可证必须技术中立（License Must Be Technology-Neutral）：不得依赖特定技术或接口（比如强制签署电子合同）。

OSD 第 5、第 6 条后来成为判断 SSPL、BUSL、OpenRAIL、LLaMA 社区许可等”新式协议”是否为”OSI 开源”的关键——只要带有”不得用于 X 用途”的条款，就违反了第 6 条；只要带有”某类用户不得使用”（比如”月活超过 7 亿的竞争对手除外”），就违反了第 5 条。

2.4 Free Software vs Open Source：一个分叉点的哲学差异

自由软件和开源在协议文本上有很高的重合度——几乎所有 FSF 认可的自由软件许可证都同时是 OSI 认证的开源许可证，反之亦然。但两个阵营的基本价值观不同：

Stallman 在多次公开演讲中明确反对使用”Open Source”这个词，他认为这个词淡化了”自由”的伦理含义，把一场社会运动简化成了工程技巧。Eric Raymond 则通过《大教堂与集市》（The Cathedral and the Bazaar, 1997 / 1999 书籍版）论证开源开发模式的工程优越性。

这场哲学之争到今天仍未结束，但在工程实践中，大多数团队更习惯用”开源”一词，而把”自由软件”视为开源的一个子集 + 哲学源头。

2.5 Mozilla 基金会的诞生与 MPL

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 等项目模仿。

2.6 Debian Free Software Guidelines 与 OSD 的关系

OSD 在起草时几乎全文借鉴了 Debian 自由软件指南（Debian Free Software Guidelines, DFSG）。DFSG 由 Bruce Perens 在 1997 年起草，作为 Debian 社区判断”一个软件是否可以进入 main 仓库”的标准。1998 年 Perens 与 Raymond 把 DFSG 删去”Debian”字样、做少量措辞调整后成为 OSD。这种”从发行版规则升格为行业标准”的路径，是开源治理史上一个有趣的模式——类似模式后来在 CNCF（从 Google 内部规则升为云原生行业标准）、OCI（从 Docker 私有格式升为容器运行时标准）中反复出现。

三、基金会时代：1999–2016 的治理爆炸

如果说 1983–1998 是个人与社区主导的时代，那 1999 之后就是基金会主导的时代。基金会解决了几个关键问题：商标归属、版权集中、中立托管、合规审计、赞助资金流。

3.1 Apache 软件基金会（ASF，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 文件机制。

3.2 Linux 基金会（2000→2007）

Linux 基金会（Linux Foundation, LF）的直接前身是 2000 年成立的 Open Source Development Labs（OSDL），2007 年 OSDL 与 Free Standards Group 合并形成今天的 Linux 基金会。它最初的定位是雇佣 Linus Torvalds 等核心内核开发者，让他们不必依附于任何单一商业公司。

从 2014 年开始，Linux 基金会陆续孵化出一系列子基金会与项目，形成”基金会中的基金会”格局：

3.3 Eclipse 基金会（2004）

Eclipse 基金会源于 IBM 2001 年将 Eclipse IDE 代码开源的动作，2004 年 2 月正式独立成基金会。Eclipse 基金会和 ASF 的一个显著区别在于：ASF 使用 Apache 2.0，Eclipse 使用 EPL（Eclipse Public License）——一种弱 Copyleft 协议。2020 年 Eclipse 基金会把总部从美国迁往比利时布鲁塞尔，在很大程度上也是为了回应欧洲企业对”数据主权”和”供应链独立性”的诉求。

3.4 OpenStack 基金会（2012）与 OpenInfra（2021）

OpenStack 基金会成立于 2012 年 9 月，由 Rackspace 与美国国家航空航天局（NASA）主导捐赠；2021 年重命名为 Open Infrastructure Foundation（OpenInfra），以覆盖 Kata Containers、StarlingX、Zuul 等更广泛的基础设施项目。

3.5 CNCF（2016）：云原生时代的中心化

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 个，成为企业架构决策的实质性标准库。

3.6 中国在基金会时代的角色

中国企业大规模参与国际基金会的时间点主要集中在 2016 年之后：

这些节点的意义是：中国企业已经不只是开源软件的”消费者”，而开始深度参与国际基金会的治理结构，这和本文第六节将讨论的”中国自己的基金会”形成双循环。

3.7 基金会治理的四种典型模式

综合 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 式）
  - 在本国民政注册、业务主管部门明确
  - 项目治理兼顾本地合规（公司法、税法、数据出境）
  - 优点：规避跨境制裁风险、可接本地政府资源
  - 缺点：跨境协作仍需双向认证

3.8 版权集中 vs 版权分散

基金会治理的另一个关键维度是版权归属。两种极端：

CLA 与 DCO 会专门讨论这两种模式在中国企业实践中的操作要点。

四、Source Available 反攻：2018–2024 的协议重写

2018 年前后，“开源”一词开始遇到一个它此前没有遇过的对手：公有云。

4.1 云厂商白嫖问题

Amazon Web Services、Microsoft Azure、Google Cloud 等公有云厂商把开源数据库和中间件封装为托管服务（DBaaS / Managed Service），直接对外收取服务费。这种做法在法律上完全合规——Apache 2.0、MPL、BSD 等协议都不禁止托管运营——但在商业上对原始项目公司是致命的：原公司承担全部 R&D 成本，云厂商几乎零边际成本转手赚钱。

这个矛盾在 2018 年左右集中爆发。

4.2 MongoDB 与 SSPL（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 从其发行版中移除。

4.3 Elastic 的 2021 协议切换

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。

4.4 HashiCorp BSL（2023）

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 争议再次被重提：工程界普遍意识到，单一公司控制的”商业开源”项目存在被收购后许可条款随时变化的风险。

4.5 Redis 的 2024 协议切换与回流

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 所显示的，社区一旦分叉就很难合流。

4.6 Fair Source 运动

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 时代的单一厂商项目提供一种可持续商业模式。

4.7 四象限图重读

把以上事件叠加到最初的四象限图上，可以看出过去六年的整体趋势：

这是一个持续博弈的过程，而不是一次性迁移，具体协议层面的比较见 AGPL、SSPL 与 BSL：网络 Copyleft 与”伪开源”之争。

4.8 更早的先例：2013 MariaDB BSL 与 2015 Confluent CCL

“Source Available”并不是 2018 年才出现的概念。可以追溯的标志性事件：

4.9 Cockroach Labs 与 BSL 的改造

另一个值得记录的 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 的”延迟开源承诺”并非不可撤销。

4.10 为什么 OSI 对这些协议保持保守

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）让”开源”这个词进入了一个新的语义区。源代码、模型权重、训练数据、微调脚本——谁算”作品”？谁要开放？如何合规？

5.1 权重开放不等于开源

一个训练好的大模型至少有四层产物：

  1. 训练代码（预训练、微调、RLHF）。
  2. 数据集（预训练语料、指令数据、偏好数据）。
  3. 模型权重（.safetensors、.bin 等）。
  4. 推理代码与工具链。

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 标准。

5.2 OpenRAIL：有条件开放

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 变体。

5.3 LLaMA 的三次许可变化

Meta 的 LLaMA 系列提供了一条完整的”从非开源到越来越开源”的路径：

Llama Community License 因违反 OSD 第 5 条（歧视特定主体）和第 6 条（限制使用领域），不属于 OSI 开源。但 Meta 在宣传中坚持使用”open source”一词，这一直是 OSI 与 Meta 之间公开的措辞冲突。

5.4 中国大模型的许可取向

中国主要大模型在许可上大致呈现几种风格：

2024–2025 年的一个明显趋势是”向 Apache 2.0 回归”：一方面是为了便于企业合规采纳，另一方面也是国际竞争下”开源话语权”的战略需要。具体在国产开源协议部分，木兰协议（MulanPSL/PubL） 会进一步讨论与 Apache 2.0 的对比。

5.5 数据集与 Creative Commons

模型训练离不开数据，但数据本身不是软件。Creative Commons（CC）系列协议（CC0、CC BY、CC BY-SA、CC BY-NC 等）成为数据集许可的默认选择。常见的数据集许可陷阱包括：

这些问题会在 数据集、模型权重与 Creative Commons：AI 时代的”作品”边界 展开。

5.6 BLOOM、Mistral、Gemma：三条不同路径

大模型开放程度的光谱非常宽。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   不公开

从这张表可以看出：

5.7 大模型许可判断四要素

工程上评估一个模型是否”可商用”不能只看一条条款，而要按四个要素打分：

  1. 权重许可文本本身（重点看月活门槛、禁止用途、关联方定义）。
  2. 代码仓库许可（通常更宽松，但要看是否独立适用）。
  3. 数据集许可（CC BY、CC BY-NC、CC BY-SA、不同数据集可能冲突）。
  4. 模型输出归属（LLaMA 2 一度禁止用输出训练竞品；Llama 3.1 放开）。

四要素任何一个不通过，都要视作”不可无条件商用”。详细表格在 数据集、模型权重与 Creative Commons 展开。

六、中国线索：从 Linux 爱好者到开放原子基金会

开源的中国故事有一条相对独立的演化线，值得单独拉出来讲。

6.1 1990s：Linux 进中国

6.2 2000s：商业公司开始参与

6.3 2010s：深度介入国际项目

6.4 开放原子开源基金会（2020）

开放原子开源基金会（OpenAtom Foundation）于 2020 年 6 月在北京民政部登记成立，是中国第一家专注于开源的国家级非营利基金会，业务主管单位为工业和信息化部。首批理事单位包括华为、阿里、百度、腾讯、浪潮、招商银行、中兴、360 等。

根据 openatom.org 官方公开信息，首批正式捐赠并孵化的项目包括：

此后陆续孵化/捐赠的项目包括 TencentOS Tiny（腾讯物联网 RTOS）、MindSpore（华为 AI 框架，2022）、Kata Containers 中国镜像、AtomGit（代码托管）等。

到 2026 年，开放原子基金会的项目池已经覆盖操作系统、AI 框架、区块链、RTOS、开发工具链、数据库等核心基础设施。其意义不仅是一个中立托管机构，更在于它创造了一种新的法律载体：国内企业捐赠的开源项目可以归属到一个国内注册的法人实体，避免了”境外基金会风险”（例如 Apache 被美国出口管制影响、openSUSE/SUSE 被美国实体清单间接影响等）。

6.5 国产开源许可协议：木兰

木兰宽松许可证（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）。木兰系列协议的主要设计动因是：

具体条款分析见 木兰协议：中国开源许可的工程视角。

6.6 OpenChain（ISO/IEC 5230）与中国企业

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：把开源治理写进组织架构 讨论。

6.7 中国开源会议与社区

6.8 真实案例：红芯浏览器与 CentOS 停服

有两个与”中国开源”紧密相关的真实事件非常值得一提（详细内容在后续案例文章中）：

6.9 国内数据库与中间件的开源策略演化

2015 年之后国内基础软件公司开始批量开源，可以分三代观察：

6.10 真实事件时间线：开放原子开源基金会首批捐赠

根据 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 / 数据库项目完成捐赠

这一时间线说明：开放原子开源基金会不是一个象征性机构，而是一个具备持续运营能力的本土开源治理实体。对中国企业而言，它提供了”把开源项目捐赠到国内注册法人”这一选项，在数据跨境和实体清单两端都有现实意义。

6.11 国内开源合规浪潮：从红芯事件到 OpenChain

2018 年红芯浏览器事件之后，国内对”开源合规”话题的关注明显上升。2019–2022 年间出现几类关键事件：

这一轮合规浪潮的工程意义是：开源合规从”个别技术总监的坚持”变成”投融资必过的体检项”，OSPO 成为大中型科技企业的标准组织。

6.12 国内社区与自治项目

除了基金会托管的项目，中国还有大量”社区自治”的开源项目，典型代表：

这些项目在许可证选择上呈现”宽松协议为主、木兰为辅”的格局。

七、核心差异：四类”开源”一次说清

到这里可以回答开头的第一个问题了：自由软件、开源、Source Available、专有软件的关系。

7.1 自由软件 ⊂ 开源（几乎）

FSF 维护的”自由许可证列表”和 OSI 认证的”开源许可证列表”高度重合但不完全相同。FSF 认可、OSI 未认证或有异议的例子包括：

7.2 开源 ≠ Source Available

Source Available 是一个光谱，从”完全闭源”到”几乎开源”之间有无数刻度。判断一个协议是”开源”还是”Source Available”的官方标准只有一个：是否通过 OSI 认证（https://opensource.org/licenses）。凡是 OSI 列表里没有的，严格说都不是”开源”。

7.3 “开源”四象限的工程含义

本文开头图的四象限对应工程实践里四种使用心态：

象限 代表 可以做什么 主要风险
真正开源（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），工程团队必须按”实际选择的那一条”评估风险，不能混用。

7.4 真正开源 vs 开源但非标准：例如 BUSL

BUSL 是一个有趣的边界例子：HashiCorp 的 Terraform 在 BUSL 1.1 下源码可下载、可自用、可非生产测试，但生产使用就要商业许可；4 年后自动转为 MPL 2.0。严格按 OSI 标准，BUSL 时期的 Terraform 不是开源，尽管很多人习惯这么叫。正确的说法是”延迟开源”或”Source Available with delayed open source release”。这种措辞上的精确性在合规审计（尤其是投融资尽调）里会被反复追问。

7.5 一张对照表：14 个代表协议的分类

把本文涉及的主要协议集中对比一次：

协议                 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、数据集社区广泛用作内容许可。

7.6 “双许可 / 多许可”策略

一个项目可以采用多种许可并行：

双许可/多许可的核心前提是”足够的版权控制”：项目公司必须有能力汇总全部版权（通过 CLA），才能在任何时候重新决定许可。Linux 内核这种分散版权的项目无法采用双许可模式，而 MySQL、MongoDB、HashiCorp 等都建立了完整的 CLA 流程。

八、工程落地：常见坑点清单

下面是工程团队在 2026 年采用开源时几种反复出现的坑。后续文章会逐一展开。

8.1 把 GPL 代码静链进闭源固件

这是最经典的 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 解耦。

8.2 AGPL 与 SaaS 的边界

AGPL 第 13 条把”通过网络向用户提供服务”也当作分发。常见误解包括：

具体判断边界在 Copyleft 的工程边界 展开。

8.3 Apache 2.0 的 NOTICE 与专利反诉条款

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 的专利许可自动终止。这对有”专利池战略”的公司是一个需要理解的边界。

8.4 “开源但又不开源”的大模型权重

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     ✅

工程上，每一次”拉起一个新项目”时必须把上述表格”按自己的用例”过一遍，而不是默认”开源模型都能商用”。

8.5 依赖层次中的协议传染

真实项目依赖图经常跨越几百个库，每个都有自己的协议。常见陷阱：

工具层面需要 Software Composition Analysis（SCA）工具，具体见 SCA 与 SBOM 工具链。

8.6 CLA/DCO 签署缺失

合规团队经常在投融资尽调时遇到的问题：员工把内部代码推到了 GitHub 公开仓库，但未签 CLA/DCO，法律上的版权归属状态不清晰。公司若被收购，买方通常要求完成历史贡献者 CLA 回签（retrospective CLA），这在有前员工的项目里可能耗数月。详见 CLA 与 DCO：贡献协议与版权归集。

8.7 出海与出口管制

2020 年代之后的一个新维度：美国 EAR、BIS 实体清单、OFAC 制裁名单会直接波及开源协作。Apache 基金会 2019 年起禁止来自被制裁国家的贡献者在某些密码学项目中提交；GitHub 曾短暂对伊朗用户限制；Linux 基金会 2024 年 10 月的 Kernel 维护者”移除俄罗斯关联维护者”事件也引发广泛讨论。对中国企业，具体影响见 出海合规：EAR、ECCN 与基金会治理。

8.8 基金会中立性的风险评估

2022 年俄乌冲突后，一系列基金会出现”政治化治理”信号：ASF 曾短暂讨论对被制裁国家贡献者的处理，Linux 基金会 2024 年 10 月移除部分俄罗斯籍内核维护者。对中国企业而言，“基金会中立性”已不能简单默认。

实战建议：

1. 核心资产不完全依赖单一基金会托管
2. 关键项目在境内保留一份镜像和维护团队
3. 对等参与国内基金会（开放原子）与国际基金会（ASF/LF）
4. 专利和商标的注册地考虑多法域布局
5. CLA 条款加入"主管法域"以应对跨境诉讼

8.9 “开源”作为品牌的商标风险

工程上，许可证允许使用源码不等于允许使用项目名称。许可证与商标是两条平行的法律线。详细讨论见 专利授权与商标。

8.10 国内合规特有坑点

国内工程实践还有几个国际项目很少提及的坑：

8.11 SBOM 与合规流水线的最小落地

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 工具链 展开。

8.12 贡献流程的合规检查点

给内部贡献者的最小检查清单：

提交前：
  □ 新文件顶部有 SPDX-License-Identifier 标签
  □ 不引入未审批的第三方依赖
  □ 不直接复制其他项目代码（即使是 MIT 也需记录来源）
  □ 如为公司员工贡献外部项目，走 OSPO 审批

提交时：
  □ Commit message 带 Signed-off-by（DCO）
  □ CI 合规扫描通过
  □ 如为首次贡献，完成 CLA 签署

合并后：
  □ 更新 NOTICE / THIRDPARTY 文件
  □ 更新 SBOM
  □ 如引入新许可证类型，通知法务

九、选型建议：一张决策地图

面对一个新项目，工程团队如何决定使用哪些开源软件、以什么协议发布自己？

9.1 使用侧决策流

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 年案例）

9.2 发布侧决策流

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. 你的产品包含大模型？
   ├─ 是 → 评估权重 / 代码 / 数据集分别使用的协议
   └─ 否 → 按常规项目

9.3 组织侧建议

1. 建立 OSPO（Open Source Program Office），哪怕只有一个人。
2. 采纳 ISO/IEC 5230 OpenChain 基线。
3. 持续维护 SBOM。
4. 参加一家中立基金会（开放原子 / ASF / LF / Eclipse）提升治理经验。
5. 法务与工程团队每季度同步一次"协议变化动态"。
6. 对核心产品做"2018-2024 式协议切换"的情景演练。

9.4 典型场景的推荐组合

下面给出几类国内常见项目的推荐配置，供快速参考：

场景一：国内 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 年协议变更影响评估（被收购的项目、切协议的项目）

9.5 什么时候拒绝开源而选择专有

开源是默认选项，但并非所有场景都合适：

判断原则是：“开源是一种投资，不是一种美德”——需要算 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 年之后仍在快速演化，请以最近一次官方发布为准。

11.1 全景图小结

把开源四十年放在一个句子里：从”自由软件”的伦理运动，到”开源”的工程方法论，再到”Source Available / Fair Source”的商业对抗，再到”开源 AI”的语义扩展——每一次变化都是在回答”谁为开源付费、谁承担开源风险”这个根本问题。 这个问题没有终极答案，因此下一次协议浪潮一定还会到来。

2018 年的 SSPL、2023 年的 BUSL、2024 年的 OpenRAIL 和 Valkey/OpenTofu 分叉，只是这条长周期博弈中的几个节点。到 2026 年，可以预见的未来议题至少包括：大模型权重的”可复现性”是否会被 OSI 纳入新版 OSD；AI 生成代码的许可兼容（被训练语料是 GPL 的情况下，生成代码的许可属性如何判断）；跨境开源在地缘冲突下的分叉风险如何缓释。

11.2 从这张地图到下一步

本文是一张总览图，后续十九篇会把每一个细节做成可执行的工程指南。对于马上要做选型的读者，有三条建议路径：

在真实业务里，开源许可不是孤立问题，它与版权、专利、商标、数据、出口管制、投融资尽调、生成式 AI 合规交织在一起。“看懂一张地图”是第一步，“把地图落到工程流水线”才是 OSPO 的真正任务。

十二、参考资料

  1. Richard Stallman，《Initial announcement of GNU》，net.unix-wizards / net.usoft，1983-09-27。
  2. Free Software Foundation，《What is Free Software》，https://www.gnu.org/philosophy/free-sw.html 。
  3. Free Software Foundation，《GNU General Public License, version 2》，1991-06。
  4. Free Software Foundation，《GNU General Public License, version 3》，2007-06-29。
  5. Open Source Initiative，《The Open Source Definition (Annotated)》，https://opensource.org/osd 。
  6. Open Source Initiative，《Licenses》，https://opensource.org/licenses 。
  7. Open Source Initiative，《OSI statement on SSPL》，2019-01-16。
  8. Open Source Initiative，《The Open Source AI Definition 1.0》，2024-10。
  9. Eric S. Raymond，《The Cathedral and the Bazaar》，O’Reilly，1999。
  10. Netscape Communications，《Netscape Announces Plans to Make Next-Generation Communicator Source Code Available Free on the Net》，1998-01-22。
  11. Apache Software Foundation，《Apache License, Version 2.0》，2004。
  12. Apache Software Foundation，《How the ASF works》，https://www.apache.org/foundation/how-it-works.html 。
  13. The Linux Foundation，《Projects》，https://www.linuxfoundation.org/projects 。
  14. Cloud Native Computing Foundation，《CNCF Graduated and Incubating Projects》，https://www.cncf.io/projects 。
  15. MongoDB, Inc.，《Server Side Public License FAQ》，https://www.mongodb.com/licensing/server-side-public-license 。
  16. Elastic B.V.，《Doubling down on open, Part II》，2021-01-14。
  17. Elastic B.V.，《Elasticsearch is Open Source, Again》，2024-08-29。
  18. HashiCorp, Inc.，《HashiCorp adopts Business Source License》，2023-08-10。
  19. OpenTofu，《OpenTF Announcement》，2023-08-25；《OpenTofu 1.6 General Availability》，2024-01-10。
  20. Redis Ltd.，《Redis Adopts Dual Source-Available Licensing》，2024-03-20。
  21. The Linux Foundation，《Linux Foundation Launches Open Source Valkey Community》，2024-03-28。
  22. Fair Source，《Fair Source Definition》，https://fair.io 。
  23. MariaDB Corporation，《Business Source License》，https://mariadb.com/bsl11 。
  24. Meta Platforms, Inc.，《Llama 2 Community License Agreement》，2023-07-18；《Llama 3 Community License》，2024-04-18；《Llama 3.1 Community License》，2024-07-23。
  25. Hugging Face & BigScience，《BigScience OpenRAIL-M License》，2022。
  26. Alibaba Cloud，《Qwen License Agreements》，https://github.com/QwenLM 。
  27. DeepSeek，《DeepSeek License》，https://github.com/deepseek-ai 。
  28. 开放原子开源基金会（OpenAtom Foundation），《基金会章程》与《项目捐赠公告》，https://www.openatom.org 。
  29. OpenHarmony，《OpenHarmony 源代码仓库与治理说明》，https://www.openharmony.cn 。
  30. openEuler 社区，《openEuler 技术白皮书》，https://www.openeuler.org 。
  31. 中国工业和信息化部软件与集成电路促进中心（CSIP），《木兰宽松许可证（MulanPSL-2.0）》，2020-01；https://license.coscl.org.cn/MulanPSL2 。
  32. Linux 基金会 OpenChain 项目，《ISO/IEC 5230:2020 Information technology — OpenChain Specification》，2020-12。
  33. 开源社 KAIYUANSHE，《中国开源年度报告》，2017–2025 各年度版。
  34. 开源中国（OSCHINA）与码云（Gitee），https://www.oschina.net 、https://gitee.com 。
  35. Software Freedom Conservancy，《Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide》，https://copyleft.org/guide 。

上一篇：开源许可与版权工程

下一篇：中国法下的软件著作权与开源

同主题继续阅读

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

2026-04-22 · architecture / opensource

【开源许可与版权工程】木兰许可证与国产开源许可

深入解读木兰宽松许可证 v2（OSI 认证）与木兰公共许可证 v2（弱 Copyleft）的条款：专利明示授权、中英双语法律效力、中国管辖条款；openEuler、openGauss、OpenHarmony、PaddlePaddle 的使用情况；以及与 Apache 2.0 的对比选择建议。

By .