老园丁培育了一袋无比珍贵的传家种子。有人上门求种子，他满口答应，心里却翻涌着一连串问号：种子送出去后，对方能拿去卖钱吗？能改良一下说是自己的新品种吗？对方要是把种子锁进保险柜不让邻居种，该怎么办？种出的庄稼出了虫害，自己要不要担责？这一串问题，正是每一位开源作者发布代码前都要面对的“协议选型”。种子就是源代码，而 MIT、Apache、GPL 这三张“纸面约定”，就是老园丁写给不同求种人的三套规则。本文用花园里的故事，把“开源”这件看似浪漫的事，还原成一条条可预期的法律与商业条款——让你既能把代码大大方方送出去，又不把主动权稀里糊涂交出去。

岗位关联

对 AI 从业者而言，开源协议选型是工程落地与商业化的“隐形基建”：选错了，代码送出去还背法律风险；选对了，社区生态和商业变现才能双赢。

目录
  1. 可视化演示
  2. 协议本质：种子袋上的“使用说明书”
  3. MIT宽松：路边散种，拿走不谢
  4. Apache专利：带专利防弹衣的散种
  5. GPL传染：传家宝，种出来还得传
  6. 商用合规：商业模式的“锁链定律”
  7. AGPL云限制：云端之上的第三只眼
  8. 选型决策：照着地图走不迷路
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示MIT、Apache、GPL的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

MIT、Apache、GPL：MIT协 MIT协议的核心特征与适用场景 Apache 2.0协议的专利 核心机制可视化 MIT、Apache、GPL整体架构与关键组件

协议本质：种子袋上的“使用说明书”

老园丁把种子递给邻居时，并没有把“品种权”也一并扔掉。种子还是他的，他只是用一张说明书，许诺邻居可以种、可以收、可以杂交、可以把收成再送人——但这张说明书上写了哪些许可、哪些禁区，就是开源许可证的全部秘密。很多新手以为“开源等于免费等于随便拿”，实际上开源的内核是“自由”而非“免费”：代码开放、允许修改、允许分发，但这一切都必须建立在明确的授权之上。没有授权，法律默认“保留所有权利”，你用了别人的代码就是侵权。

在开源世界里，许可证就是那把打开权利的钥匙。它一般会授予使用者“五件套”：使用软件、复制代码、修改代码、分发副本、以及在分发时允许下游继续按相同条款再许可。宽松型协议（MIT、Apache）把这五件套大方地送出去；强版权型协议（GPL）则在这五件套上追加一条“你改了我的作品，你的作品也得开源”的回馈义务。理解这五件套，是读懂一切协议纠纷的地基。

老园丁想清楚了：种子可以白送，但“送”本身要写成规矩。这份规矩就是许可证，而规矩的宽严，决定了邻居们能否放心大胆地拿种子去做生意。接下来我们逐一拆解三种“规矩”。

Grant=Use+Copy+Modify+Distribute+Sublicense\displaystyle \mathrm{Grant} = \mathrm{Use} + \mathrm{Copy} + \mathrm{Modify} + \mathrm{Distribute} + \mathrm{Sublicense}
这个式子表示：开源许可证本质上就是“授权”的集合。等号右边五项，是使用者获得的五类权利；哪一项被拿走或被加条件，就构成不同协议的差别。
  1. Grant（授权）整个式子代表许可证授予使用者的权利总和，不同类型的许可证就是在这五项上做加减法。
    Grant\displaystyle \mathrm{Grant}
  2. 五项权利相加Use（使用）、Copy（复制）、Modify（修改）、Distribute（分发）、Sublicense（再许可）共同组成“完整授权”，五者缺一不可，否则代码只能看不能用。
    Use+Copy+Modify+Distribute+Sublicense\displaystyle \mathrm{Use} + \mathrm{Copy} + \mathrm{Modify} + \mathrm{Distribute} + \mathrm{Sublicense}

MIT宽松：路边散种，拿走不谢

老园丁对关系最铁的老邻居说：“这袋种子你拿去，爱种哪儿种哪儿，卖钱也行，杂交改良也行，我不问你一个字。唯一的要求是，你转送给下一个人时，袋子上得留着我的名字。”这套规则就是 MIT 协议——开源世界里最宽松、最无拘无束的许可证。它的义务集合只有一个元素：保留原版权声明和许可声明。除此之外，使用者可以闭源、可以商用、可以把代码改成面目全非再卖钱，作者的免责声明“按现状提供，不担任何责任”也写在了纸上。

正因为 MIT 几乎没有门槛，它成为无数知名项目的首选：React、jQuery、Go 语言的前身、Node.js 的很多核心模块都采用 MIT。对 AI 从业者来说，如果你想快速放大一个工具的影响力，让大公司放心地把它合并进商业产品，MIT 是最好的“社交货币”——它连“你必须把改进告诉我”都不要求，完全信任使用者。但宽松的另一面是：作者放弃了要求回馈的权利，如果别人改了你的代码闭源赚钱，你在 MIT 下没有立场说“不”。

老园丁挥挥手：“种子你拿走，标签别撕。”这就是 MIT 的全部人情世故——信任拉满，责任归零。但有些邻居不满足于此，他们希望连“这袋种子有没有专利地雷”都得到保障，于是老园丁拿出第二套规矩。

OMIT={Cnotice}\displaystyle O_{\mathrm{MIT}} = \{ C_{\mathrm{notice}} \}
这个式子描述了“义务集合”：使用 MIT 协议时，你唯一必须做的事，是在分发副本时保留版权声明。花括号里只有一项，所以 MIT 是最轻的协议。
  1. O 表示义务集合$O$ 代表该协议强加给使用者的全部“必须做”事项，花括号里有哪些元素，就表示有哪些义务。
    OMIT\displaystyle O_{\mathrm{MIT}}
  2. C 表示版权声明$C_{\mathrm{notice}}$ 指原作者的版权标记和许可文本，它是 MIT 协议唯一留在使用者身上的“标签”。
    Cnotice\displaystyle C_{\mathrm{notice}}

Apache专利：带专利防弹衣的散种

第二位邻居是做生物科技公司的，他开口便问：“种子是优良品种，但如果它牵涉到别人的专利权，我种下去会不会被起诉？”老园丁于是写下 Apache 2.0：在 MIT 的宽松基础上，明文加入了“专利授权”条款——每一位代码贡献者，自动将自己的、覆盖该代码的专利权免费授予使用者，且不可撤销；但你若拿这个项目去反诉别人专利侵权，这份授权就会立刻终止。这就是著名的“专利反诉即终止”条款，像一把双刃剑，既保护使用者，又防止使用者滥用专利武器。

此外，Apache 2.0 还多了两道“紧箍咒”：一是商标限制，你不能用原作者的名字或 logo 为自己的产品背书；二是 NOTICE 文件要求，如果你分发的是修改版，必须附带项目自带的 NOTICE 文件，把归属和来源说清楚。所以 Apache 2.0 的义务集合比 MIT 多了两项，但它换来了极其明确的专利保护。Hadoop、Kubernetes、Spark、TensorFlow 都采用 Apache 2.0——它们大多是数据基础设施，处于商业世界的兵家必争之地，把专利授权写清楚，巨头们才敢放心部署。

Apache 的种子包装上多了一行小字：“本袋种子不附带隐藏专利陷阱，但请勿冒用我方招牌。”这让它在商业氛围浓厚的项目里格外受欢迎。然而还有第三位邻居，他不关心赚钱，只关心一件事——“种出来的种子，能不能不让别人锁进保险柜？”老园丁于是亮出了 GPL 这张底牌。

OApache={Cnotice, Nnotice, Ttrademark},Pgrant=1\displaystyle O_{\mathrm{Apache}} = \{ C_{\mathrm{notice}},\ N_{\mathrm{notice}},\ T_{\mathrm{trademark}} \},\quad P_{\mathrm{grant}} = 1
这个式子的意思是：Apache 2.0 的义务有三项——保留版权声明、保留 NOTICE 文件、不使用原作者商标；同时专利授权参数 $P$ 为 1，代表“有明确的专利授权”。对比 MIT 的 $P=0$，这就是两者最核心的分野。
  1. 义务三项$C_{\mathrm{notice}}$ 是版权声明，$N_{\mathrm{notice}}$ 是通知文件，$T_{\mathrm{trademark}}$ 是商标限制，三者在分发副本时必须逐条满足。
    OApache={Cnotice, Nnotice, Ttrademark}\displaystyle O_{\mathrm{Apache}} = \{ C_{\mathrm{notice}},\ N_{\mathrm{notice}},\ T_{\mathrm{trademark}} \}
  2. 专利授权参数$P_{\mathrm{grant}}=1$ 表示该协议附带了不可撤销的专利许可；若 $P=0$（如 MIT），则代码中隐含的专利风险必须由使用者自己承担。
    Pgrant=1\displaystyle P_{\mathrm{grant}} = 1

GPL传染：传家宝，种出来还得传

“我把种子送你，是希望园子越来越大，而不是被你独占。”GPL（GNU 通用公共许可证）是所有强版权协议的鼻祖，它用“copyleft“机制实现了这个理念：你可以使用、修改、分发 GPL 代码，甚至可以收费卖副本；但只要你把 GPL 代码或其衍生作品对外分发，整个衍生作品就必须以 GPL 许可证开源——这就是工程师口中”传染性“。判断传染的核心是”衍生作品”：整段复制、修改源码、静态链接通常都构成衍生；而完全独立的程序之间仅通过命令行或网络接口通信，一般不算衍生，但这在动态链接等场景下仍有法律争议。

GPL 有两个版本需要区分：GPLv2 经典但老旧，Linux 内核至今坚守；GPLv3 增加了对“防 Tivo 化”（禁止通过硬件锁阻止用户改造）、专利保护等现代条款，但代价是和部分厂商决裂。对项目维护者来说，GPL 的“传染”是把双刃剑：它能阻止别人闭源你的成果，但也让纯商业闭源的集成方望而却步。Git、Linux、MySQL（双授权模式）都是 GPL 阵营的代表。

老园丁的传家宝规则很简单：“你可以用我的种子发财，但新种子必须传下去。”这一条让软件世界的“公有领域”不断扩大。但若有人把种子种在云端、不给邻居看，GPL 就鞭长莫及了——于是 AGPL 登场。

∀f∈GPL, g=Derived(f)  ⇒  g∈GPL\displaystyle \forall f \in \mathrm{GPL},\ g = \mathrm{Derived}(f) \;\Rightarrow\; g \in \mathrm{GPL}
这个式子描述传染规则：只要一个程序 $f$ 属于 GPL，那么任何由它派生的作品 $g$ 也必须属于 GPL。箭头"$\Rightarrow$“读作”必然导致“，这就是”传染"的数学表达。
  1. 前件 f 属于 GPL$f \in \mathrm{GPL}$ 表示你的代码中引入了 GPL 组件，$f$ 是那个被感染的“原种子”。
    f∈GPL\displaystyle f \in \mathrm{GPL}
  2. 衍生关系$g = \mathrm{Derived}(f)$ 表示 $g$ 是从 $f$ 衍生出来的作品，比如复制代码、静态链接或深度修改。
    g=Derived(f)\displaystyle g = \mathrm{Derived}(f)
  3. 结论 g 必须属于 GPL只要前件成立，$g$ 就必须同样采用 GPL 许可证，这就是“传染”的闭环。
    g∈GPL\displaystyle g \in \mathrm{GPL}

商用合规：商业模式的“锁链定律”

回到三位邻居的生意经：他们都能用种子赚钱吗？答案是都能。MIT 和 Apache 的商用几乎零负担——闭源、收费、卖服务都没问题；GPL 也允许商用，你甚至可以把 GPL 软件打包收费出售，但买你软件的人有权把它再免费转送，所以“靠卖 GPL 副本发财”的纯软件销售模式很难走通。于是 GPL 项目的商业落点变成了双授权（如 MySQL 同时提供 GPL 版和商业版）、卖技术支持（如 Red Hat）、或把核心闭源、周边开源（虽然有争议）。

商用合规里最容易踩坑的是“依赖兼容性”。你的项目可能同时引用了多种协议的第三方库，此时必须遵守“锁链定律”：项目整体许可证的强度，不得低于任何一个依赖的强度。MIT 代码可以并进 GPL 项目，GPL 代码绝不能并进 MIT 项目；Apache 2.0 兼容 GPLv3，却与 GPLv2 冲突。专业做法是发版前用扫描工具审计全量依赖，并让法务签字确认；否则一旦被你依赖的 GPL 代码“传染”，整个项目被迫开源，商业计划就会瞬间崩塌。

老园丁嘱咐邻居：“你的篮子能装多重，取决于你放进去的最重的那包种子。”商业合规不是道德问题，是算术问题——算清强度，才能不踩红线。

Strengthproject≥max⁡d∈depsStrengthd\displaystyle \mathrm{Strength}_{\mathrm{project}} \ge \max_{d \in \mathrm{deps}} \mathrm{Strength}_{d}
这个式子是合规的底线：项目自身许可证的“强度”必须不小于所有依赖项中强度最大的那个。“强度”在这里指协议要求义务的严格程度，MIT 最弱，AGPL 最强。
  1. Strength 强度函数$\mathrm{Strength}$ 给每个协议打一个“严格度”分数，从弱到强大致是 MIT < Apache < GPL < AGPL。
    Strength\displaystyle \mathrm{Strength}
  2. 取依赖的最大强度$\max_{d \in \mathrm{deps}}$ 表示在所有第三方依赖 $d$ 中找出强度最高者，它是锁链上最粗的一环。
    max⁡d∈depsStrengthd\displaystyle \max_{d \in \mathrm{deps}} \mathrm{Strength}_{d}
  3. 项目强度不小于依赖$\mathrm{Strength}_{\mathrm{project}} \ge \max$ 是必须满足的不等式，违背它就意味着协议冲突、侵权风险。
    ≥\displaystyle \ge

AGPL云限制：云端之上的第三只眼

如果老园丁的种子被某家公司种进玻璃温室，游客只能在线观看却拿不到种子，GPL 的“分发”条款就失效了——因为温室从未向任何人发送过种子。这正是云时代的漏洞：SaaS 公司把 GPL 代码跑在自己的服务器上，用户通过网络使用却拿不到源码，传统 copyleft 就此失灵。AGPL（Affero GPL）就是为了封堵这个漏洞而生：它把“通过网络提供服务”也视同“分发”，只要你的用户能通过网络使用到修改后的 AGPL 代码，你就必须把完整源码提供给对方。

这一条让云厂商非常紧张，所以 AGPL 通常被视为“反云白嫖”利器。Nextcloud、RethinkDB 采用 AGPL，MongoDB 早期也用 AGPL，后来为了避免云厂商免费拿它做托管服务，干脆自创了更激进的 SSPL（服务器端公共许可）——连“提供托管服务本身”都要求开源，不过 SSPL 并未被 OSI 认可为开源协议。如果你的项目商业模式是“向企业出售 SaaS 许可”，AGPL 是绝佳的谈判筹码；但若你希望被各大云平台默认集成，AGPL 则会吓退很多潜在合作者。

老园丁于是在温室外加了一只监控眼：“不把种子递出去？那用户在线看一眼也算分发。”这条规则让云端的代码不再是法外之地，但也让 AGPL 成为商业合作中必须谨慎触碰的“烫手协议”。

Usenetwork(AGPL)≡Distribute\displaystyle \mathrm{Use}_{\mathrm{network}}(\mathrm{AGPL}) \equiv \mathrm{Distribute}
这个式子把“通过网络使用”和“传统分发”画上等号：在 AGPL 的规则里，用户连到你的服务器并远程使用，等价于你把代码副本分发给了用户，因此传染条款被触发。
  1. Use_network（网络使用）$\mathrm{Use}_{\mathrm{network}}$ 表示用户通过网络访问你的服务，并没有获得代码副本，但这在 AGPL 中同样算“分发”。
    Usenetwork(AGPL)\displaystyle \mathrm{Use}_{\mathrm{network}}(\mathrm{AGPL})
  2. 等价符号$\equiv$ 表示两条行为在法律责任上等价，这是 AGPL 的核心创新，也是它与其他 GPL 家族的显著区别。
    ≡Distribute\displaystyle \equiv \mathrm{Distribute}

选型决策：照着地图走不迷路

讲完所有条款，老园丁终于摊开一张选型地图。选协议，本质是先回答三个问题：你的目标是什么？你的依赖是什么？你的商业模式是什么？如果你的目标是最大化传播、吸引大公司采用、允许别人闭源集成，那么 MIT 或 Apache 2.0 是首选，前者的代码出现在任何商业产品里都毫无压力，后者额外给商业伙伴吃下“专利定心丸”；如果你的目标是防止衍生品闭源、守护软件自由，GPL 是把守大门的卫兵；如果你想做 SaaS 且不允许云厂商白嫖，AGPL 则是你的护城河。

决策时必须先盘点依赖：你的项目已经引用了哪些第三方库？它们的许可证决定了你的选择空间。一个 GPL 依赖就足以把整个项目推向 GPL，而一个 Apache 2.0 依赖则可能把你从 GPLv2 挤向 GPLv3。最后，不要忘记公司内部的法务评审——开源合规审计应当写进 CI/CD 流程，每次引入新依赖都触发检查。选型没有绝对正确，只有与目标匹配的“合约”。

地图在手，老园丁终于可以安心地把种子一袋袋送出去。协议不是束缚，而是让代码在明确规则下走得更远的桥梁——希望你的每一次开源选择，都像这袋种子一样，种下去的是自由，长出来的是信任。

---

Licensefinal=min⁡{  L  ∣  Strength(L)≥max⁡d∈depsStrengthd,  L∈Goals  }\displaystyle \mathrm{License}_{\mathrm{final}} = \min\{\; L \;|\; \mathrm{Strength}(L) \ge \max_{d \in \mathrm{deps}} \mathrm{Strength}_{d},\; L \in \mathrm{Goals}\; \}
这个式子把选型形式化：最终许可证 $L$，是在满足“强度不低于所有依赖”这个硬约束的前提下，从你的目标集合中挑一个强度最小的——够用就好，别给自己加戏。
  1. min 最小值$\min$ 表示在两个条件下选出“压力最小”的许可证，避免不必要的义务负担。
    min⁡\displaystyle \min
  2. 硬约束不等式$\mathrm{Strength}(L) \ge \max_{d}$ 保证选出的协议不会被任何依赖“传染”或冲突。
    Strength(L)≥max⁡d∈depsStrengthd\displaystyle \mathrm{Strength}(L) \ge \max_{d \in \mathrm{deps}} \mathrm{Strength}_{d}
  3. 目标集合 Goals$L \in \mathrm{Goals}$ 表示最终选择还要符合你的商业与社区目标，例如“允许闭源”或“防止云白嫖”。
    L∈Goals\displaystyle L \in \mathrm{Goals}

AI 应用场景

场景一：开源项目维护者发布前选型

阶段：开源发布准备

解决的问题：AI 工程师训练好的模型工具链想开源，但不知道该选哪种协议。传统方式是凭直觉选“看起来火”的协议，结果要么因为用了 GPL 依赖而被迫整体开源，要么因为选了 Apache 却漏掉 NOTICE 文件被用户投诉。AI 的方式是用“依赖扫描 + 强度匹配”自动生成候选协议清单，再结合项目目标（是否允许闭源商用）确定最终协议。

具体案例：某团队训练了一个轻量级 NLP 模型推理框架，计划开源并吸引企业用户。技术负责人先扫描全部依赖，发现底层有一个 Apache 2.0 的向量库，于是把协议锁定在 Apache 2.0，并在仓库中正确放置 LICENSE 和 NOTICE 文件，企业客户放心接入。

场景二：商业化团队做第三方依赖合规审计

阶段：产品交付前合规检查

解决的问题：AI 产品上线前，法务最怕的是代码库里的“协议地雷”。传统方式是人工翻阅每个依赖的 LICENSE 文件，效率低且易漏。AI 的方式是用自动化工具扫描依赖树，逐项比对协议兼容性矩阵，标注出 GPL 传染风险与 AGPL 云服务风险，输出合规报告。

具体案例：一家做企业级 AI 客服 SaaS 的公司，在产品上线前发现测试框架引入了 AGPL 依赖。合规工具立即标红并提示“网络使用触发传染”，团队随即替换为 MIT 替代库，避免了一次价格高昂的法律危机。

场景三：CTO 制定公司开源战略

阶段：技术战略规划

解决的问题：公司决定把内部 AI 平台的一部分开源以建立生态，但不确定哪一层该用哪种协议。传统方式是管理层拍脑袋，导致社区贡献少、竞对白嫖。AI 的方式是基于项目模块边界画出“分层许可图”：核心算法层用 Apache 2.0 吸引贡献，企业插件层用闭源商用协议，云服务封装层用 AGPL 防止云厂商直接托管。

具体案例：某 AI 公司的特征平台采用“Apache 2.0 核心 + 闭源企业版”的双层策略，既收获了大厂贡献，又保住了企业版收入，半年内社区 PR 数量翻了三倍。

Python 演示

python41 行
# -*- coding: utf-8 -*-"""许可证兼容性检查器：给定第三方依赖的协议，推导项目应采用的最弱合法许可证。""" STRENGTH = {    'MIT': 0,    'Apache-2.0': 1,    'GPL-2.0': 2,    'GPL-3.0': 3,    'AGPL-3.0': 4,} CONFLICT_PAIRS = {('Apache-2.0', 'GPL-2.0'), ('GPL-2.0', 'Apache-2.0')}  def choose_license(deps):    """输入依赖协议列表，返回项目必须采用的许可证。"""    current = 'MIT'    for dep in deps:        if dep not in STRENGTH:            raise ValueError('未知协议: ' + dep)        if (current, dep) in CONFLICT_PAIRS or (dep, current) in CONFLICT_PAIRS:            current = 'GPL-3.0'        elif STRENGTH[dep] > STRENGTH[current]:            current = dep    return current  def explain(deps):    try:        result = choose_license(deps)        print('依赖: {0} -> 项目应使用: {1}'.format(', '.join(deps), result))    except ValueError as err:        print('依赖: {0} -> 错误: {1}'.format(', '.join(deps), err))  if __name__ == '__main__':    explain(['MIT'])    explain(['MIT', 'Apache-2.0'])    explain(['MIT', 'GPL-3.0'])    explain(['Apache-2.0', 'GPL-2.0'])    explain(['GPL-3.0', 'AGPL-3.0'])
目的：模拟文章中的“锁链定律”，当你的项目引入多个不同协议的第三方库时，自动推导出整个项目应该采用的许可证。
  1. STRENGTH = {...}给五种常见协议按义务严格度打分，从 MIT 的 0 分到 AGPL 的 4 分，这是判断“谁传染谁”的依据。
  2. CONFLICT_PAIRS = {...}记录 Apache 2.0 与 GPLv2 这对“水火不容”的组合，一旦遇到就强制升级到 GPLv3。
  3. current = 'MIT'从最宽松的协议出发，就像默认你是“散种”老园丁，遇到强约束再逐步升级。
  4. (current, dep) in CONFLICT_PAIRS先检查冲突再比强度，避免 Apache 被错误地并入 GPLv2 造成违法合并。
  5. elif STRENGTH[dep] > STRENGTH[current]锁链定律的落地：只要某个依赖更强，项目整体协议就必须被“抬升”到同样强。
  6. explain(['Apache-2.0', 'GPL-2.0'])演示最经典的坑：项目先选了 Apache，再引入 GPLv2，最终被强制推入 GPLv3 的路径。

常见误区

误区我以为开源代码就是公共财产，拿来就用，不用管什么协议，反正免费的。“开源”嘛，就是没有版权的意思。

正解开源不等于放弃版权，更不等于没有限制。每份开源代码仍然受版权法保护，只是作者通过许可证授予了你某些权利。MIT 要求保留版权声明，GPL 要求衍生作品开源，违反协议同样构成侵权。就像种子是老园丁的，他送你播种，但你撕掉标签或反告他，他就有权收回许可。

为何常见：大家习惯把“free“翻译成”免费“，而忽略了它本意是”自由“，于是把”开源“简单粗暴地等同为”白嫖”。

误区我觉得 GPL 是“病毒协议”，谁碰谁倒霉；MIT 才是“高级”的协议，所有好项目都该用 MIT。用 GPL 显得很落后。

正解协议没有高低贵贱，只有是否匹配目标。Linux 内核用 GPLv2 守护了自由，React 用 MIT 实现了最大传播，两者都极其成功。GPL 的“传染”不是 bug 而是 feature——它的设计目的就是让衍生作品保持开源。选 MIT 还是 GPL，取决于你想让代码成为“公共道路”还是“公有花园”。

为何常见：商业公司天然厌恶传染性条款，网上大量“GPL 避坑”的文章放大了恐惧，让新手误以为 GPL 是垃圾协议。

误区MIT 是最宽松的，那我用了 MIT 库就万事大吉，代码就算有专利问题也跟我无关。

正解MIT 不包含任何专利授权条款！它的免责声明只针对“代码质量”，不覆盖“专利权”。如果 MIT 代码实现了某个专利算法，使用者在商业化时可能被专利持有人起诉。而 Apache 2.0 显式授予了覆盖代码的专利许可，并且用“反诉终止”机制约束双方，这才是真正给了专利层面的保护。

为何常见：很多人把“免责”和“免专利”混为一谈，看到 MIT 文本短、限制少，就觉得它一切都包了。

误区公司在产品里加了一个 GPL 的日志库，老板说完了，我们整个系统都要开源了。

正解传染的范围是“衍生作品”，不是“整个公司”。如果你的软件被认定为 GPL 代码的衍生作品，那么这部分作品必须以 GPL 开源，而不是公司所有代码都公开。但实践中，模块划分不清时法院很可能认定整个程序是衍生作品。所以最安全的做法是：GPL 依赖要么彻底不用，要么严格隔离成独立进程。公开的是“被感染的种子长出的庄稼”，不是“整个农场”。

为何常见：把“衍生作品”误解为“项目所有代码”，导致要么过度恐慌，要么过度侥幸。

误区我给 Linux 内核提了一个补丁，这个补丁是我独立写的，所以著作权在我，我可以随意用在闭源项目里。

正解当你把代码提交给 GPL 项目并被合并后，你的补丁通常被视为该项目的衍生作品，必须以 GPL 授权，不能再以专有许可使用。像 Linux 内核项目有明确的 DCO（开发者原创证书）机制：提交即表示你同意以 GPL 授权。这相当于你把种子嫁接到传家宝树上，结出的果实必须按传家宝的规矩来。

为何常见：人们习惯用“物理世界所有权”思维理解“代码贡献”，没意识到开源社区有自己的一套贡献者许可规则。

面试题

Q1. MIT 协议要求使用者在分发副本时必须满足下列哪项条件？

单选题 · easy

  • A.保留原版权声明和许可声明← 正确答案
  • B.将全部衍生作品开源
  • C.向原作者支付许可费用
  • D.获得原作者的书面批准

答案：A。MIT 的唯一义务就是保留版权声明和许可声明，相当于“袋子上留着老园丁的名字”。选项 B 是 GPL 的传染义务，C 和 D 在 MIT 中完全不存在。

Q2. Apache 2.0 与 MIT 相比，最核心的区别是什么？

单选题 · easy

  • A.Apache 有显式专利授权与商标限制← 正确答案
  • B.Apache 要求衍生作品全部开源
  • C.Apache 禁止商业使用
  • D.MIT 比 Apache 更严格

答案：A。Apache 2.0 在 MIT 的宽松基础上增加了专利授权、专利反诉终止、商标限制和 NOTICE 文件等条款，这些在 MIT 中都没有。选项 B 是 copyleft 的特征，C 完全错误，D 方向反了。

Q3. 以下哪些行为会触发 GPL 的“传染性”，导致衍生作品必须 GPL 开源？

多选题 · mid

  • A.将 GPL 代码整段复制进自己的项目← 正确答案
  • B.修改 GPL 代码后重新分发← 正确答案
  • C.在自己的程序旁边独立运行 GPL 程序，仅通过命令行传参
  • D.将 GPL 代码静态链接进自己的程序并发布← 正确答案

答案：ABD。复制、修改、静态链接通常都被认定为衍生作品，触发传染；而独立的进程间通信（命令行传参）一般不构成衍生作品，相当于两袋种子分开种，不传染。

Q4. 一个 MIT 项目引入了一段 Apache 2.0 代码，整个项目的许可证应该如何选择？

单选题 · mid

  • A.必须立即升级为 Apache 2.0
  • B.必须坚持使用 MIT
  • C.可以继续使用 MIT 或升级为 Apache 2.0← 正确答案
  • D.必须变为 GPL

答案：C。MIT 和 Apache 2.0 都是宽松协议且彼此兼容，MIT 项目吸收 Apache 代码后，只要满足保留 NOTICE 等义务，整个项目仍可保持 MIT。选项 A “必须升级”过于绝对。

Q5. 一个计划闭源商业化的项目，最不应该选择哪种许可证？

单选题 · mid

  • A.MIT
  • B.Apache 2.0
  • C.GPL-3.0← 正确答案
  • D.自定义专有协议

答案：C。GPL 的传染性要求衍生作品开源，与闭源商业模式直接冲突。MIT 和 Apache 都是宽松协议，允许闭源商用；自定义专有协议更是完全可控。

Q6. 关于 GPLv2 与 Apache 2.0 的兼容性，以下说法正确的有哪些？

多选题 · extreme

  • A.GPLv2 与 Apache 2.0 不兼容，无法直接合并← 正确答案
  • B.将 Apache 代码并入 GPLv2 项目会违反 GPLv2← 正确答案
  • C.可以把项目升级到 GPLv3 以兼容 Apache 2.0← 正确答案
  • D.Apache 代码可以自由并入任何 GPL 版本

答案：ABC。Apache 2.0 与 GPLv2 不兼容，因为 GPLv2 的条款无法覆盖 Apache 的专利授权要求；但 Apache 2.0 与 GPLv3 兼容，所以升级到 GPLv3 是合法出路。选项 D 忽略了 GPLv2 的冲突。

Q7. AGPL 与 GPL 在“传染性”上最大的区别是什么？

单选题 · hard

  • A.AGPL 把“通过网络提供服务”也视同分发并触发传染← 正确答案
  • B.AGPL 禁止任何商业使用
  • C.AGPL 只能用于 Web 前端项目
  • D.AGPL 比 GPL 更加宽松

答案：A。AGPL 的核心创新是第 13 条：用户通过网络远程使用软件也等同于拿到副本，因此 SaaS 场景下修改过的 AGPL 代码必须开源。B、C、D 都是误解。

Q8. Apache 2.0 中的“专利反诉终止”条款，准确含义是什么？

单选题 · hard

  • A.使用者若拿该软件相关专利起诉其他用户，其专利授权自动失效← 正确答案
  • B.作者承诺不追究使用者的任何专利问题
  • C.Apache 项目不可能包含任何专利
  • D.使用者必须为使用 Apache 代码支付专利费

答案：A。该条款是双向保护：贡献者授予专利许可，但如果使用者反过来利用专利起诉其他用户，则这份授权自动终止。它防止“吃免费午餐还打厨子”的行为，而非无条件豁免。

Q9. 以下哪一项属于宽松型（permissive）开源许可证？

单选题 · easy

  • A.GPL-3.0
  • B.AGPL-3.0
  • C.MIT← 正确答案
  • D.SSPL-1.0

答案：C。MIT 只要求保留版权声明，不要求衍生作品开源，是典型宽松协议。GPL、AGPL 都是强版权协议，SSPL 甚至被开源促进会（OSI）认定为非开源协议。

Q10. 在选择开源许可证时，以下哪些考量是合理的？

多选题 · mid

  • A.希望吸引巨头闭源集成，优先考虑 MIT 或 Apache← 正确答案
  • B.希望防止别人闭源衍生品，优先考虑 GPL← 正确答案
  • C.希望阻止云厂商免费托管你的 SaaS 代码，考虑 AGPL← 正确答案
  • D.无论场景如何，一律选择自定义协议最安全

答案：ABC。选型必须匹配目标：追求传播选宽松，守护自由选 GPL，防云白嫖选 AGPL。自定义协议既不产生开源生态信任，也无法享受主流协议的法律验证与社区共识，不是“最安全”选项。