开源软件许可证详解：MIT、Apache、GPL 到底差在哪？ ​

撰稿时间：2026年9月。许可证条款会随版本变化，文中结论均为当时情况，商用决策前请以项目当前的 LICENSE 原文为准。

你从魔当下载安装的每一个 AI 应用，都带着一个 LICENSE 文件。大多数时候你不需要关心它——但一旦你想改点代码、把某个功能集成到自己的产品里，或者拿它去做对外收费的服务，这份文件就突然变得非常重要了。

先纠正三个最常见的误解：

• "开源就是免费随便用"——不对。 开源只是公开源码，绝大多数开源许可证都附带条件，只是条件轻重不同。
• "开源就是可以闭源卖钱"——要看是哪个许可证。 MIT 可以，GPL 让你在分发时必须交出源码。
• "GitHub 上的代码反正没人管"——错得最离谱。 一个仓库如果没有 LICENSE 文件，默认是"保留所有权利"，你复制其中一行代码在法律上就是侵权。没有许可证 ≠ 没有版权，恰恰相反。

一、用五个问题给任何许可证定位 ​

许可证种类多到让人眼晕，但本质上只在回答几个问题。拿到任何一个许可证，问这五句就清楚了：

围绕第 2、3 两个问题的答案，开源许可证分成两大阵营：

• 宽松型（Permissive）：MIT、BSD、Apache-2.0、ISC。几乎不问第 2 和第 3 题——你想怎么改、想闭源、想卖钱都行，只要把原作者的版权声明留在里面。
• 著佐权型（Copyleft）：GPL、AGPL、LGPL、MPL。核心诉求就一条：你用了我的自由，就必须把同样的自由传下去。 一旦分发，涉及的那部分代码必须以同样许可证开源。

"传染"到底怎么触发的？关键在"分发"两个字。 GPL 系义务的触发点是你把程序给了别人（分发、发布、随产品出货）。只在自己电脑上跑、只在公司内部用、甚至部署成自己对外提供的网络服务（注意，是 GPL 不是 AGPL），都不构成分发，也就不触发开源义务。 这是最多人事前不知道的一条。

二、宽松型：风险最低，优先选这一类 ​

MIT ​

全文不到 200 字。你可以自由使用、复制、修改、合并、出版发行、再授权乃至出售副本，唯一义务是在软件的所有副本或主要部分中保留原始版权声明和这段许可文本。

• 注意：MIT 没有明示的专利授权。如果作者或某个贡献者对里面的技术持有专利，理论上仍存在被主张的可能。对普通用户无所谓，对做产品的要留个心眼。

BSD-2-Clause / BSD-3-Clause ​

BSD-2 与 MIT 基本等价。BSD-3 多了一条禁止背书：未经事先书面许可，不得用原作者或机构的名义为你的衍生产品做推广或背书。

• 实践影响：你不能在自己的产品页上写"本功能由 XXX 团队提供支持"来抬高自己，除非拿到许可。

Apache-2.0 ​

本地 AI 项目里出场率极高（含 audio.cpp）。它在 MIT 的基础上多做对了两件事，也正是它更值得推荐的原因：

1. 显式专利授权。 每个贡献者都自动把相关专利授予你。而且带一个反制条款：如果你就该作品对任何人提起专利诉讼，你获得的专利授权自动终止。这一条让 Apache-2.0 比 MIT 在多专利的大项目里安全得多。
2. NOTICE 文件义务。 如果原项目附带 NOTICE 文件，你分发时必须保留其中的归属声明。这不是可选项，漏掉是常见的合规事故。

另外 Apache-2.0 明确要求你标注自己做过修改。

兼容性地雷：GPL-2.0（仅"或later"版本除外）与 Apache-2.0 不兼容。也就是说，你不能把 Apache-2.0 的代码合并进一个 GPLv2 项目里发布。GPLv3 没有这个问题。

ISC / CC0 / The Unlicense ​

• ISC：功能上等价 MIT，措辞更简洁，欧洲项目常见。
• CC0 / Unlicense：直接放弃版权、进入公有领域，连署名都不要求。
• 但要注意：放弃版权不等于放弃专利权，也不影响该仓库里捆绑的模型、数据集、商标等其他权利。 "CC0 的代码"仍可能因为依赖或附带资源而有其他限制。

三、Copyleft 型：传染性的边界在哪（最容易踩坑） ​

这一节是全文最硬核的部分，但也恰恰是闭源集成事故的高发区。

GPL-2.0 / GPL-3.0 ​

规则：只要你分发这个程序，或基于它衍生的程序（哪怕只是其中一个可执行文件），你就必须向接收者提供完整的对应源码，并且整体继续以 GPL 授权。你可以收费，但不能闭源。

GPLv2 和 GPLv3 的差别，实际影响你的有三点：

• GPLv3 有明确的专利授权条款，v2 没有。
• GPLv3 有反 Tivoization 条款：嵌入消费类硬件时，必须允许用户重新刷入修改后的固件（当年 TiVo 靠这个卡住了 Android）。纯软件场景不用管。
• 兼容性：如上面所说，v2 不兼容 Apache-2.0，v3 兼容。

例子：你在自己的桌面音频工具里链接了一个 GPL-3.0 的库，然后把这个工具发给用户下载。此时你的整个程序都落入 GPL-3.0 约束，必须对外提供可编译的完整源码。如果只是在你自己的电脑上用、或者在公司内网部署给同事用——不分发，就不触发。

AGPL-3.0：填上"网络服务"这个漏洞 ​

GPL 的义务靠"分发"触发，于是有人想到了完美的规避方式：我一分发，只把它跑在服务器上对外提供服务。 AGPL 就是为了堵这条路而生的。

AGPL 第 13 条：用户通过网络与程序交互时，你就算完成了源码提供义务——必须给他们一个获取对应源码的明显入口。

严格来说这条针对的是"你修改后的版本"，跑一个原封不动的 AGPL 程序在字面上不一定触发。但实践中你几乎不可能不触发：只要你把 AGPL 代码链接、整合进自己的项目，你的项目就成了那个"被修改的程序"，联网一对外提供服务，整个项目的对应源码都要交出去。

例子：某个 AI 项目的 WebUI 是 AGPL-3.0，你把它改造成自己的在线配音平台收费运营，一个二进制都没分发。GPL 下这是安全的，AGPL 下你必须向每个用户提供改造后的完整源码。

所以：做对外服务，看到 AGPL 必须先停下来。

LGPL：本地 AI 工具链里最常见的"中间态" ​

LGPL 存在的意义就是让专有软件也能用上库文件。区别只在怎么用：

• 动态链接（.dll / .so，运行时加载）→ 你的主程序可以保持闭源，只需：随附 LGPL 文本、声明你使用了该库、并且保证用户能替换这个库（所以不能静态打进去）、以及如果你修改了库本身则那部分要开源。
• 静态链接（编译进你的可执行文件）或把它的源码复制进你的项目 → 你的程序就变成了衍生作品，必须提供完整可编译源码，LGPL 的保护伞消失。

例子：你闭源发布一个 TTS 桌面应用，运行时加载 LGPL 的音频解码库 → 合法，闭源即可，前提是你没改那个库，并且用户拿一个自己编译的同版本 .dll 覆盖进去后你的程序还能正常跑。 但如果你为了省事把那个库的 .c 文件拷进自己的工程一起编译 → 对不起，整个程序都要按 LGPL 提供源码。

这就是"动态链接"和"静态链接"为什么值得单独讲：它是很多闭源产品踩坑的直接原因。

MPL 2.0：文件级的弱 Copyleft ​

MPL 是 GPL 和宽松型之间的折中，对商用友好得多：

• 只传染到你修改的那些文件本身，且以 MPL 授权，而不是像 GPL 那样传染整个作品。
• 新增的、独立的文件可以保持闭源，MPL 文件可以作为你更大作品的组件存在。
• 义务是：告诉别人去哪儿能拿到那些 MPL 文件的源码。

一句话记法：GPL 是"沾我一下、全盘开源"；MPL 是"改哪个文件、开源哪个文件"。

四、这些"看起来像开源"的，其实不是（本文和本项目最相关） ​

AI 领域大量项目用的根本不是标准开源许可证。这一节是认知盲区最集中的地方。

社区许可（Community License） ​

Stability AI、bilibili、FunASR、MiniMax 等都有自定版本。典型条款组合：

• 可免费商用，但年营收有上限（常见门槛：100 万美元），超过须购买商业授权；
• 需要在官网注册才生效；
• 要求署名或声明；
• 禁止转售、再分发模型权重本身；
• 禁止用于训练竞品基础模型。

这类许可证必须由人逐条读原文，无法靠 SPDX 标签推断——这也是为什么模型许可文档里它们全部落在"⚠️ 有条件商用"而不是"✅"。

研究 / 非商业许可 ​

CC BY-NC 系列、各家的 *-research-license。用途限定在研究与非商业，商用一律禁止，没有营收上限可谈。

双许可（Dual Licensing） ​

同一份代码给两个版本：GPL 版（免费但要求你开源）+ 商业版（付费可闭源）。Qt、MySQL、iText 是这个模式的代表。

• 判断方法：如果你在项目里看到"许可证为 GPL，商业授权请联系 XX"，说明闭源使用需要付钱，没有第三条路。

Source-available：不是开源 ​

BSL（Business Source License）、Elastic License、SSPL。它们公开源码，但 OSI 明确不承认其为开源许可证。

• BSL：限制商用，通常在数年后（Terraform 是 4 年）自动转为 MPL 等开源许可证。买之前先看当前版本的限制条款和转换日期。
• SSPL（MongoDB 提出）：如果你把该数据库作为服务对外提供，就必须开源整个服务栈——包括监控、编排、备份、日志这一整套基础设施。商用成本极高，效果等同于劝退云厂商。

五、实操：30 秒判断一个项目的许可证 ​

1. 按顺序找：根目录 LICENSE / COPYING / LICENSE.txt → README 的 License 一节 → 源文件头部注释 → pyproject.toml / package.json 里的 license 字段。
2. 冲突时以 LICENSE 文件正文为准。 GitHub 右上角那个 License 标签只是自动识别，会出错。真实案例：audio.cpp 和 audio.cpp-webui 的 LICENSE 正文都是完整的标准 Apache-2.0，GitHub 却识别成 NOASSERTION（"其他/未识别"）。看到 NOASSERTION 别慌，去看文件本身。
3. 认 SPDX 标识符，别认名字。 写 Apache-2.0、GPL-3.0-only、MIT 而不是"Apache 许可证"，避免版本歧义。
4. 叠加原则：取最严的那个。 一个可分发产品的合规边界，由依赖树里最严格的那条许可证决定——而不是由主项目的许可证决定。软件代码、依赖库、模型权重、训练数据、字体、图标，各有各的许可，要分别核。
5. 容易漏的三条：
   • 翻译版没有法律效力。 中文译文仅供参考，条款以英文原文为准（多数许可证会明写这一点）。
   • 商标不在授权范围内。 开源许可证给你代码，不给项目名和 Logo 的使用权。不能把你的改版叫作原名去发布。
   • 版本会变。 同一项目在不同版本换许可证是常事（Redis、Elastic 都干过）。以你实际使用的那个版本为准。

六、按你的角色看结论 ​

七、别忘了：软件许可证 ≠ 模型许可证 ​

这一层区分是本文最需要你带走的东西，也是 audio.cpp 那篇文档的全部前提：

• 你装的软件是 Apache-2.0，意味着代码你可以自由改、自由商用。
• 但软件加载的模型权重遵循各自的许可证，可能写着"禁止商用"。
• 两层是叠加关系，取交集——只有两边都允许，你的用途才允许。
• 而且量化、转换格式、LoRA、微调产出的都是衍生作品，原模型许可继续适用。"我用的不是官方原版"不是规避许可的理由。

模型逐个的许可分类，见 👉 audio.cpp 模型许可与商用说明

附录 A：许可证速查对照表 ​

附录 B：一句话结论 ​

免责声明：本文是我们对公开资料的整理，不构成法律意见，也不保证所有条款描述在当前版本下仍然准确。任何涉及真实商业利益的决策，请咨询专业法务，并始终以项目当前的 LICENSE 原文为准。