老王在小区门口的“共享厨房”墙上贴了一张纸，上面是他祖传三代的红烧肉菜谱。他本可以不贴——这张菜谱在他手里，法律默认“保留所有权利”，谁抄谁侵权。但老王想让它造福邻里，于是贴了出去，并附上一张“使用须知”。这张须知，就是开源世界的许可证。 开源许可证（license）解决一个根本问题：一份代码从诞生就受版权保护，作者如何授权他人使用、修改、再分发？选错“使用须知”，轻则被要求下架，重则整条产品线面临诉讼。本文带你读懂最主流的四份协议——MIT、Apache-2.0、GPL、BSD，学会像老王一样，既把菜谱传出去，又把规矩立明白。

岗位关联

对 AI 从业者而言，开源协议选型是“法律基建”：模型、框架、数据集几乎离不开开源组件，一次错误的协议选择就可能让整个商用计划归零。掌握这份知识，相当于给自己的 AI 项目上了第一道保险。

目录
  1. 可视化演示
  2. 协议本质解析：一张“使用须知”的诞生
  3. MIT协议细节：最省心的“一句话授权”
  4. BSD协议细节：MIT 的“加强版”
  5. Apache协议细节：宽松型里的“专利保险单”
  6. GPL协议机制：会“传染”的共享雪球
  7. 协议横向对比：四张须知贴在一起
  8. 选型决策指南：给项目定一条路
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

对比MIT、Apache-2.0、GPL、BSD四大开源协议的自由度、专利保护、传染性和商用友好度，展示协议兼容性矩阵，帮助选择合适许可。

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

四大协议维度对比 自由度：MIT/BSD最宽松 专利保护：Apache-2.0独有 score = free + patent + commercial - copyleft GPL传染性最强，商用限制大；MIT/BSD最自由，适合商用产品。

协议本质解析：一张“使用须知”的诞生

贴菜谱前，老王先想清楚了：菜谱贴出去不等于白送。他只是在墙上声明了“可按须知使用”——哪些行为允许、哪些必须附带，全写在这张纸上。开源许可证就是代码世界的“使用须知”。

代码是《著作权法》自动保护的作品，作者不表态时，用户复制、修改、分发都构成侵权。许可证的本质，是在版权之上开一个“授权窗口”：声明允许做的事（授权集合 P）和必须做的事（义务集合 O）。开源促进会（OSI）对“开源”还有十条定义，核心是允许自由再分发。所以，开源 ≠ 放弃版权。

主流协议分两大阵营：宽松型（permissive）——MIT、BSD、Apache-2.0，允许闭源商用，义务集中在“署名”；强保护型（copyleft）——GPL，要求衍生作品同样开源。选协议，先分清阵营。

老王把这张须知念给邻居们听，大家立刻懂了：不是菜谱不能碰，而是“怎么碰”写清楚了。接下来，我们逐张看这四份须知。

L=(P,O),P∩O=∅\displaystyle L = (P, O),\qquad P \cap O = \varnothing
这份“使用须知”可以抽象成一个二元组：左边是授予的权利，右边是附加的义务，两者互不重叠、泾渭分明。
  1. 建立二元组把任何许可证抽象成“授权集合 + 义务集合”两部分，左边是用户被允许的动作，右边是必须遵守的附加条件。
    L=(P,O)\displaystyle L = (P, O)
  2. 互斥原则授权与义务两个集合没有交集，说明“允许做的事”和“必须做的事”是两个独立维度，互不混淆。
    P∩O=∅\displaystyle P \cap O = \varnothing
  3. 代入实例以 MIT 为例，P 涵盖使用、复制、修改、再分发与商用，O 只有“保留版权声明”一项。
    LMIT=({使用,修改,再分发,商用},{保留版权声明})\displaystyle L_{\text{MIT}} = (\{\text{使用},\text{修改},\text{再分发},\text{商用}\}, \{\text{保留版权声明}\})

MIT协议细节：最省心的“一句话授权”

老王说：菜谱你可以拿，改也行，开店卖也行，只在菜单上印一行“此菜源自老王”。这就是 MIT——开源界最简短的许可证，正文不到 200 个英文单词。

MIT 是“宽松型”的代表。它只要求再分发时保留原版权与许可声明，其余一概不管。你可以把 MIT 代码改成闭源商业软件、定价出售、加入自己的产品线——前提是那份声明还在。

MIT 还附带免责条款：代码“按现状”提供，作者不对任何损害负责。它与 GPL 不冲突，可以放心地作为依赖被 GPL 项目引用：MIT 代码并入 GPL 项目后，整体按 GPL 分发，MIT 部分保留声明即可。这也是大量 AI 工具库（如许多训练框架的附属组件）选择 MIT 的原因。

老王补了一句：只想让大家用得更方便，这已经够了。但有些邻居追问：要是有人拿我的菜谱开连锁店，还打着我旗号说“老王亲传”，怎么办？这就引出下一张须知。

OMIT={保留版权与许可声明},∣OMIT∣=1\displaystyle \mathbb{O}_{\text{MIT}} = \{\text{保留版权与许可声明}\},\qquad |\mathbb{O}_{\text{MIT}}| = 1
MIT 的义务集合里只有一项——保留版权与许可声明。集合的势为 1，意味着它是最“轻”的许可证。
  1. 列出义务MIT 的义务集合只有一项——再分发时保留版权与许可声明。
    OMIT={保留版权与许可声明}\displaystyle \mathbb{O}_{\text{MIT}} = \{\text{保留版权与许可声明}\}
  2. 数义务个数集合的势为 1，说明义务数量最少，是所有主流协议里“最轻”的。
    ∣OMIT∣=1\displaystyle |\mathbb{O}_{\text{MIT}}| = 1
  3. 推出商业自由度义务唯一时，商用和闭源的阻碍趋近于零，因此 MIT 是工具库、教程代码、个人项目的第一选择。
    商用障碍(L)∝∣OL∣  ⇒  MIT 最受商业欢迎\displaystyle \text{商用障碍}(L) \propto |\mathbb{O}_L| \;\Rightarrow\; \text{MIT 最受商业欢迎}

BSD协议细节：MIT 的“加强版”

BSD 和 MIT 是“近亲”，常被混为一谈。老王的加强版规则是：菜谱随你用，但门店招牌不能写“老王亲传”。这一条在协议里叫禁止代言（endorsement clause）。

BSD 有三个常见版本：BSD-2 条款与 MIT 义务几乎等价；BSD-3 条款额外禁止用原作者或机构的名义推广衍生品；BSD-4 条款因广告条款过于繁琐已基本废弃。开源社区用得最多的是 BSD-3。

以 PyTorch（BSD-3）为例：任何人都可以用它做商业产品，但不能暗示“Meta 官方认可”。这类条款保护的是作者的“名”而非“利”，特别适合高校与科研机构发布成果。

邻居们纷纷点头：这条确实防坑。但很快有人追问：如果有人拿菜谱做了新菜还申请了专利，反过来限制老王自己用，怎么办？“专利保险单”来了——这就是 Apache。

OBSD-3=OMIT∪{禁止代言},OBSD-2≈OMIT\displaystyle \mathbb{O}_{\text{BSD-3}} = \mathbb{O}_{\text{MIT}} \cup \{\text{禁止代言}\},\quad \mathbb{O}_{\text{BSD-2}} \approx \mathbb{O}_{\text{MIT}}
BSD-3 的义务是 MIT 义务与“禁止代言”的并集；BSD-2 与 MIT 几乎等价。两者最大的区别，就是那一条“禁代言”。
  1. 并集扩展BSD-3 的义务是 MIT 义务与“禁止代言”的并集，即在署名之外多出一条。
    OBSD-3=OMIT∪{禁止代言}\displaystyle \mathbb{O}_{\text{BSD-3}} = \mathbb{O}_{\text{MIT}} \cup \{\text{禁止代言}\}
  2. 对比 BSD-2BSD-2 的义务集近似等于 MIT，说明两者在日常使用中几乎可以互换。
    OBSD-2≈OMIT\displaystyle \mathbb{O}_{\text{BSD-2}} \approx \mathbb{O}_{\text{MIT}}
  3. 保护对象新增的义务保护的是“名”而非“利”，防止衍生品借原作者或机构的名号做背书。
    衍生品不得暗示得到原作者或其机构背书\displaystyle \text{衍生品不得暗示得到原作者或其机构背书}

Apache协议细节：宽松型里的“专利保险单”

Apache-2.0 是“最像合同”的宽松协议。老王的这版须知不光说“随便用”，还附送一张专利保险单：每位贡献者向使用者授予必要的专利许可，同时使用者也不能拿自己的专利反制项目。

与 MIT 相比，Apache-2.0 多了三块内容：明确的专利授权、商标条款（不得用项目 Logo 暗示背书）、修改文件需在 NOTICE 中披露变更。前者是“保险”，后两者是“透明”。

技术细节上，Apache-2.0 与 GPL-3.0 兼容（GPL-3 明确允许组合），因此大量企业级框架选择它，如 TensorFlow、Hadoop、Kubernetes。对大厂而言，“专利授权”意味着生态内互相免于专利诉讼，这是 AI 基础设施项目的黄金选择。

看到这里，三份“随便用”的须知都读完了。老王又发问：那要是就是不想让菜谱被人拿去开连锁店、还不共享改良配方呢？GPL 登场。

PApache=PMIT∪{专利授权,商标保护},OApache={署名,变更披露}\displaystyle P_{\text{Apache}} = P_{\text{MIT}} \cup \{\text{专利授权}, \text{商标保护}\},\quad O_{\text{Apache}} = \{\text{署名}, \text{变更披露}\}
Apache 的授权集合在 MIT 基础上补上专利授权与商标保护，义务从一项变为两项：保留署名，并对修改内容做变更披露。
  1. 授权扩展Apache 的授权集合在 MIT 基础上补上专利授权与商标保护，形成商业闭环。
    PApache=PMIT∪{专利授权,商标保护}\displaystyle P_{\text{Apache}} = P_{\text{MIT}} \cup \{\text{专利授权}, \text{商标保护}\}
  2. 义务更新义务从一项变为两项——保留署名声明，并对修改内容做变更披露。
    OApache={署名,变更披露}\displaystyle O_{\text{Apache}} = \{\text{署名}, \text{变更披露}\}
  3. 生态效应专利授权消除了商业集成时最大的顾虑，这正是大厂青睐它的原因。
    商业采用意愿∝专利安全度  ⇒  大厂场景下 Apache≻MIT\displaystyle \text{商业采用意愿} \propto \text{专利安全度} \;\Rightarrow\; \text{大厂场景下 Apache} \succ \text{MIT}

GPL协议机制：会“传染”的共享雪球

GPL 是“强保护”的旗帜。老王的规则变成：菜谱可以拿、可以改、可以卖，但只要你把改良菜端出去给别人（分发），就必须把改良菜谱也贴到同一面墙上，让所有人继续改进。这就是传染性（copyleft）。

技术要点在于两个边界。第一，仅内部使用、不对外分发，不触发；第二，通过网络提供服务（只运行不交付代码），普通 GPL 也不触发——那是 AGPL 的管辖范围。商用并不禁止，收费也可以，但收了钱也必须同时提供源码。

因此，GPL 是“病毒式分享”：每个衍生作品都被锁定在同协议之下，商业闭源公司通常避而远之，除非专门做开源生意。Linux 内核就是 GPL 的一面旗帜。

老王问自己：这雪球滚得越快越远，但也把可能合作开店的商家吓跑了。“菜谱是想传广，还是想防偷？”想清楚这个问题，才能选中那张须知。

(修改∧分发衍生作品)⇒衍生作品须以 GPL 再分发\displaystyle (\text{修改} \land \text{分发衍生作品}) \Rightarrow \text{衍生作品须以 GPL 再分发}
GPL 的传染条件是“修改”且“分发”同时发生；条件一旦成立，衍生作品必须采用 GPL 并提供完整源码。
  1. 写出触发条件GPL 的传染条件是“修改”且“分发”两个事件同时发生，缺一不可。
    修改∧分发衍生作品\displaystyle \text{修改} \land \text{分发衍生作品}
  2. 蕴含结论一旦条件成立，结论强制生效——衍生作品必须采用 GPL，并提供完整源码。
    ⇒衍生作品须以 GPL 再分发\displaystyle \Rightarrow \text{衍生作品须以 GPL 再分发}
  3. 反例对比 AGPLAGPL 把触发条件从“分发”放宽到“提供网络服务”，因此云厂商也难逃开源义务。
    AGPL:  提供网络服务⇒同等开源\displaystyle \text{AGPL}:\; \text{提供网络服务} \Rightarrow \text{同等开源}

协议横向对比：四张须知贴在一起

把四张“使用须知”并排贴在墙上，邻居们一眼看出差别。核心就看四条义务线：署名、专利授权、禁止代言、开源衍生。

义务矩阵：署名四者都要；专利授权 Apache 独有；禁止代言 BSD-3 独有；开源衍生 GPL 独有。商业友好度：MIT ≈ BSD-3 ≈ Apache > GPL。对 AI 场景尤其微妙——模型权重与训练代码多选 MIT/Apache 以便商用；若想防止被闭源复刻，则选 GPL。

一个常见误区是“越宽松越好”。对个人小项目，MIT 当然省事；但面向企业客户、希望生态健康时，Apache 的专利保护反而更优。义务不是越少越好，而是“匹配目标”。

老王看着这张对比表笑了：“没有最好，只有最合适。”最后一节，我们把“最合适”翻译成一张决策路线图。

S(L)=1⋅I署名+2⋅I专利+1⋅I禁代言+3⋅I开源衍生,I∈{0,1}\displaystyle S(L) = 1 \cdot I_{\text{署名}} + 2 \cdot I_{\text{专利}} + 1 \cdot I_{\text{禁代言}} + 3 \cdot I_{\text{开源衍生}},\qquad I \in \{0, 1\}
给四种义务赋权：开源衍生最重（权重 3），专利其次（权重 2），署名与禁代言各 1。代入四份协议，得到义务强度 MIT 1、BSD-3 2、Apache 3、GPL 4。
  1. 定义义务强度把协议的义务强度定义为四项义务的加权和，权重体现义务的“杀伤力”。
    S(L)=1⋅I署名+2⋅I专利+1⋅I禁代言+3⋅I开源衍生\displaystyle S(L) = 1 \cdot I_{\text{署名}} + 2 \cdot I_{\text{专利}} + 1 \cdot I_{\text{禁代言}} + 3 \cdot I_{\text{开源衍生}}
  2. 0-1 指示变量某项义务存在取 1，不存在取 0，四个协议代入后得到不同的强度值。
    I∗∈{0,1}\displaystyle I_{\ast} \in \{0, 1\}
  3. 代入四协议MIT 得 1，BSD-3 得 2，Apache 得 3，GPL 得 4——与本文开头的“义务强度图”完全一致。
    S(MIT)=1,  S(BSD-3)=2,  S(Apache)=3,  S(GPL)=4\displaystyle S(\text{MIT}) = 1,\; S(\text{BSD-3}) = 2,\; S(\text{Apache}) = 3,\; S(\text{GPL}) = 4

选型决策指南：给项目定一条路

老王最后决定：这道传家菜谱按哪张须知贴，取决于三件事——他想要什么（项目目标）、开店时怕什么（公司合规）、邻居们期待什么（社区期望）。

典型场景建议：个人小工具、教程、论文代码 → MIT；企业级 SDK、云产品、需要专利保护 → Apache-2.0；高校或机构出品、在乎名誉背书 → BSD-3；强社区项目、严防闭源 → GPL-3.0。内部使用不对外分发时，GPL 依赖也可以放心用，因为触发条件未满足。

落地流程：先盘点全部依赖的许可证 → 逐项核对义务 → 检查组合兼容性（GPL 依赖与 MIT 主项目冲突时，主项目必须升级为 GPL）→ 补充 LICENSE 与 NOTICE 文件 → 法务复核。后文的 Python 演示就是一个最小合规检查器。

老王最终贴了两张纸：主菜谱用 MIT 传广，秘制酱料用 GPL 防偷。他说：“规矩立得好，菜谱才能既传得远，又停在对的地方。”选协议，本质上就是选择一种“分享的边界”。

推荐(x)={MIT,x=个人 / 工具 / 论文代码Apache-2.0,x=企业 SDK / 云产品BSD-3,x=机构背书 / 学院派GPL-3.0,x=强社区 / 防闭源\displaystyle \text{推荐}(x) = \begin{cases} \text{MIT}, & x = \text{个人 / 工具 / 论文代码} \\ \text{Apache-2.0}, & x = \text{企业 SDK / 云产品} \\ \text{BSD-3}, & x = \text{机构背书 / 学院派} \\ \text{GPL-3.0}, & x = \text{强社区 / 防闭源} \end{cases}
选型本质上是一张“场景 → 协议”的对应表：先明确项目目标，再逐分支匹配，最后用合规审查兜底。
  1. 建立输入变量把“项目场景”抽象为变量 x，先判断项目属于哪一类。
    x=项目场景\displaystyle x = \text{项目场景}
  2. 逐个分支匹配四个分支对应个人、企业、机构、社区四种典型画像，分支内一一对应。
    {MIT,x=个人Apache-2.0,x=企业BSD-3,x=机构GPL-3.0,x=社区\displaystyle \begin{cases} \text{MIT}, & x = \text{个人} \\ \text{Apache-2.0}, & x = \text{企业} \\ \text{BSD-3}, & x = \text{机构} \\ \text{GPL-3.0}, & x = \text{社区} \end{cases}
  3. 用法律审查兜底选型完成后必须走合规流程——依赖清单、义务核对、兼容检查、声明落盘，四步缺一不可。
    合规=依赖清单→义务核对→兼容检查→声明落盘\displaystyle \text{合规} = \text{依赖清单} \to \text{义务核对} \to \text{兼容检查} \to \text{声明落盘}

AI 应用场景

场景 1：自研 AI 服务引入开源推理库

阶段：模型部署与合规审查

解决的问题：团队想在商用闭源的推理服务里使用第三方开源库，却不清楚 GPL 与宽松协议的边界，担心“代码被传染”，导致整个产品被迫开源。

具体案例：某 AIGC 公司在内部推理服务中集成了一个 GPL 优化库。法务评估后发现：只要修改并对外分发 SDK，就必须公开对应源码；若仅以 API 形式提供服务、不分发代码，则不触发。团队据此保留 GPL 库用于服务端，同时把对外分发的客户端 SDK 换成 Apache-2.0 等价库，既保住速度又守住闭源底线。

场景 2：开源大模型与训练代码发布

阶段：开源生态建设

解决的问题：模型权重、训练代码、评测脚本该如何选择许可证？如何既扩大影响力、吸引社区贡献，又保护团队商业利益？

具体案例：某团队发布文生图模型：训练代码采用 Apache-2.0，吸引企业贡献并附带专利保险；模型权重采用 MIT，允许任意商用与微调。次年该模型被多家云厂商集成，由于 Apache 的专利授权条款，全程未发生专利纠纷，社区贡献量翻了四倍。

场景 3：企业级组件选型合规审查

阶段：技术架构评审

解决的问题：人工核对几十个依赖的许可证容易漏项，尤其 GPL 的传染性往往在集成之后才暴露，返工成本极高。

具体案例：某金融科技公司使用文中的 Python 演示脚本，把 80 个 Python 依赖的元数据批量解析，自动标红 GPL 类组件，并给出主项目协议调整建议，提前规避了监管审查风险，评审周期从两周缩短到一天。

Python 演示

python64 行
# -*- coding: utf-8 -*-# 开源协议义务对比, 组合兼容性检查与选型建议# 运行: python license_checker.pyimport sys # 四种主流协议的核心属性# obligation: 再分发时必须做的事# copyleft: 衍生作品是否必须同协议开源# patent: 是否附带专利授权PROTOCOLS = {    'MIT':        {'obligation': ['keep copyright notice'],                   'copyleft': False, 'patent': False},    'BSD-3':      {'obligation': ['keep copyright notice',                                  'no endorsement'],                   'copyleft': False, 'patent': False},    'Apache-2.0': {'obligation': ['keep copyright notice',                                  'state changes'],                   'copyleft': False, 'patent': True},    'GPL-3.0':    {'obligation': ['keep copyright notice',                                  'open derivative code'],                   'copyleft': True, 'patent': True},}  def show_obligations(license_name):    # 打印指定协议的全部义务    info = PROTOCOLS.get(license_name)    if info is None:        raise ValueError('unknown license: ' + license_name)    print('== %s ==' % license_name)    for idx, item in enumerate(info['obligation'], start=1):        print('  obligation%d: %s' % (idx, item))    print('  copyleft: %s' % ('yes' if info['copyleft'] else 'no'))    print('  patent grant: %s' % ('yes' if info['patent'] else 'no'))  def check_compat(self_license, dep_license):    # 判断在 self_license 项目里能否使用 dep_license 依赖    dep = PROTOCOLS[dep_license]    if dep['copyleft'] and self_license != 'GPL-3.0':        return 'CONFLICT: dep is GPL, project must use GPL-3.0'    return 'OK: keep the copyright notice of the dependency'  def recommend(scene):    # 按正文选型表把场景映射到协议    table = {        'internal': 'MIT',        'sdk':      'Apache-2.0',        'guard':    'GPL-3.0',        'paper':    'MIT',    }    return table.get(scene, 'MIT')  if __name__ == '__main__':    print('== recommendation ==')    for scene in ['internal', 'sdk', 'guard', 'paper']:        print('  %-10s -> %s' % (scene, recommend(scene)))    print()    show_obligations('Apache-2.0')    print()    print(check_compat('MIT', 'Apache-2.0'))    print(check_compat('MIT', 'GPL-3.0'))
目的：打印四份协议的核心义务，检查“我的项目协议 + 依赖协议”的兼容性，并按照正文选型表给出场景建议。
  1. PROTOCOLS = {...}用字典建模四份协议：义务列表、是否传染、是否含专利授权，三个字段足够支撑日常合规判断。
  2. def show_obligations(license_name)遍历义务列表逐条打印，把抽象的“义务强度”变成可核对清单。
  3. if dep['copyleft'] and self_license != 'GPL-3.0':兼容性判断的核心：依赖是 GPL 而你不愿意改用 GPL，就返回冲突。
  4. def recommend(scene)把正文的选型对应表翻译成查表函数，输入场景，输出协议。
  5. if __name__ == '__main__':演示四种场景的推荐结果，以及两组兼容性判断的差异。

常见误区

误区很多人以为代码标了开源就等于“公有领域”，复制粘贴改个名就是自己的，作者根本管不着。

正解恰恰相反，许可证是在版权之上的“有条件授权”。作者让渡的是“使用权”，但保留“著作权”与“商标权”。MIT 也要保留声明，GPL 更要求衍生作品开源。类比：老王把菜谱贴墙上，不等于你可以在菜谱上签“本人原创”。

为何常见：中文语境里“开源”听上去像“共享、免费”，叠加“免费”标签，让人误以为所有权一并放弃了。

误区初学者常认为 GPL 禁止商业收费，用了就会被起诉，因此对 GPL 项目避之不及。

正解GPL 明确允许收费——无论是卖拷贝还是提供技术支持，只要同时把源码提供给对方并维持 GPL 再分发即可。它禁止的不是“赚钱”，而是“闭源”。老王的 GPL 菜谱可以卖收费课程，但学员必须能拿到菜谱本身。

为何常见：把“copyleft（版权左派）”误读成“禁商”，又被“自由软件”里的 free（免费）一词双重误导。

误区有人把 MIT 代码改几十行就宣称“全新自研”，顺手删掉注释和版权声明，觉得反正协议很宽松。

正解MIT 唯一的硬性义务就是再分发时保留原版权与许可声明。删声明就是违约，即使代码已经大改。MIT 授权的核心是“署名传递”，删除声明等于切断作者对你的授权，法律风险立刻拉满。

为何常见：宽松协议“少管闲事”的错觉，让开发者忽略了那唯一的义务。

误区认为 Apache 只是 MIT 的长一点版本，选谁都行，条款无需细看。

正解Apache 多出专利授权、商标保护与变更披露三条硬内容。对 AI 公司而言，专利授权条款直接影响你是否会被生态内其他贡献者起诉；忽略 NOTICE 义务同样构成违约。MIT 项目可以用 Apache 依赖，但反向集成时要保留 Apache 的 NOTICE 文件。

为何常见：两者都是宽松型、都允许商用，表面差异被“宽松”二字掩盖了。

误区把四份协议都等同于“零成本白嫖”，看不到协议背后的维护与合规成本。

正解许可证解决的是“授权”而非“价格”。MIT 可以商用收费，GPL 也可以收费；但若用了 GPL 组件就必须接力开源，那部分代价可能远高于授权费。选型要看长期义务，而不是短期价格。

为何常见：开源生态里“免费”的宣传声量太大，“义务”从没有被讲清楚。

面试题

Q1. 使用并再分发 MIT 协议的代码，唯一必须做的事情是？

单选题 · easy

  • A.将衍生代码完全开源
  • B.保留原版权与许可声明← 正确答案
  • C.向原作者支付使用费用
  • D.获得原作者书面许可

答案：B。MIT 的义务集合只有一个元素——保留版权与许可声明，这是“署名传递”的底线。A 是 GPL 的义务；C、D 与 MIT 的免费授权属性相悖。就像老王贴菜谱，唯一要求就是“菜单上写一行出处”。

Q2. 以下哪一项不属于开源许可证？

单选题 · easy

  • A.MIT 许可证
  • B.GPL 许可证
  • C.Windows 用户协议← 正确答案
  • D.Apache 2.0 许可证

答案：C。MIT、GPL、Apache-2.0 都是开源界主流许可证，而 Windows 用户协议是专有软件的最终用户许可协议（EULA），禁止用户修改与再分发。许可证的本质是“有条件地开放权利”，EULA 恰恰相反。

Q3. 开发者在 GitHub 公开代码但未声明许可证，法律上默认是？

单选题 · easy

  • A.自动进入公有领域
  • B.保留所有权利← 正确答案
  • C.自动采用 MIT 协议
  • D.自动采用 GPL 协议

答案：B。代码一经创作就受著作权保护，不声明许可证就等于“保留所有权利”，他人复制、修改、分发均侵权。开源是“明确授权”的结果，而不是“未声明”的默认状态。这也是老王贴菜谱前必须先贴“使用须知”的原因。

Q4. GPL 协议的“传染性”触发条件是什么？

单选题 · mid

  • A.阅读了 GPL 源码
  • B.修改并分发衍生作品← 正确答案
  • C.在内部服务器运行
  • D.为软件提供服务支持

答案：B。GPL 触发是“修改”且“分发”同时发生。只读源码、内部运行、提供收费服务都不触发。类比老王的 GPL 菜谱：只有你把改良菜端给客人，才必须把改良菜谱贴回墙上。

Q5. BSD-3 条款协议比 MIT 多出的义务是？

单选题 · mid

  • A.必须公开衍生源码
  • B.禁止借作者名义代言← 正确答案
  • C.授予使用者专利许可
  • D.必须保留变更记录

答案：B。BSD-3 的额外义务是“禁止代言”——不得用原作者或机构名义推广衍生品。A 是 GPL 的义务；C 是 Apache 的特征；D 是 Apache 的变更披露义务。BSD 与 MIT 的差异只有那一条“护名”条款。

Q6. Apache-2.0 相比 MIT 的关键差异是？

单选题 · mid

  • A.具备强传染性
  • B.附带专利授权条款← 正确答案
  • C.禁止任何商业用途
  • D.无需保留版权声明

答案：B。Apache-2.0 在宽松授权基础上增加了专利授权、商标保护与变更披露。它并不传染（排除 A），允许商用（排除 C），同样要求署名（排除 D）。专利授权如同老王附的那张“专利保险单”，是商业集成的定心丸。

Q7. 在遵守各自义务的前提下，允许闭源商用分发的协议有哪些？

多选题 · mid

  • A.MIT 许可证← 正确答案
  • B.Apache 2.0 许可证← 正确答案
  • C.BSD-3 条款许可证← 正确答案
  • D.GPL 3.0 许可证

答案：ABC。MIT、Apache-2.0、BSD-3 都属于宽松型，允许闭源商用，只需履行署名等义务。GPL 允许商用收费，但分发衍生作品时必须开源，因此不符合“闭源分发”的条件。宽松协议就像“随用随走”，GPL 则是“吃了必须回吐菜谱”。

Q8. 关于 GPL 3.0，下列说法正确的有哪些？

多选题 · hard

  • A.衍生作品必须同协议开源← 正确答案
  • B.可以收费并提供服务← 正确答案
  • C.AGPL 覆盖网络服务场景← 正确答案
  • D.使用即可免除全部义务

答案：ABC。GPL 的衍生作品必须同协议开源（A 对）；GPL 允许收费和提供服务，但必须同时提供源码（B 对）；AGPL 把触发条件从“分发”扩展到“提供网络服务”（C 对）。D 恰恰相反——GPL 的义务是“使用即受约束”。老王的 GPL 菜谱可以卖钱，但改良菜谱必须共享。

Q9. 某 AI 产品以 MIT 协议发布，其中某个功能库是 GPL 且无替代品，团队仍想对外分发，以下做法最合规的是？

单选题 · hard

  • A.产品整体改用 GPL 后分发← 正确答案
  • B.保留 MIT 声明照常分发
  • C.只分发二进制不附源码
  • D.把 GPL 库改为私有模块

答案：A。合并 GPL 组件并再分发，合并作品整体必须可依 GPL 再分发，因此 A 正确。B 无视 GPL 义务构成违约；C 违反“提供源码”要求；D 试图规避传染性，法律风险极高。这正是老王“主菜谱 MIT、酱料 GPL”决策背后的合规逻辑。

Q10. 团队仅将 GPL 代码修改后部署为内部服务，不对外分发，正确的是？

单选题 · extreme

  • A.必须开源全部修改
  • B.可以不公开源码← 正确答案
  • C.必须购买商业授权
  • D.必须改用 AGPL 协议

答案：B。GPL 的触发条件包含“分发”，纯内部运行不触发开源义务，因此 B 正确。AGPL 才把网络服务纳入触发范围，但前提是原项目采用 AGPL 而非 GPL。这个边界最常见的考题就是“服务端用 GPL 到底开不开源”——答案是：不开源，只要你没分发。