小面馆老板小明花了三年研发出独门“云吞秘方”，最近他犯愁：想把手艺分享给街坊，又怕别人照搬开连锁店抢自己生意。银行工作的老朋友老王是个兼职法律顾问，他说：“分享没问题，但怎么'打开门'送出去，才是门学问。” 这就好比今天的 AI 开发者发布模型：权重像“菜谱成品”，代码像“做法步骤”，训练数据像“食材进货单”。你愿意让别人拿来开店吗？要不要允许他们改良配方？如果人家改出了新秘方，要不要回传给整条街？这些问题，都由“开源协议”来回答。本文带你像挑菜谱授权方式一样，看懂 MIT、Apache、GPL、AGPL 的区别，搞清楚 AI 模型协议与传统软件的差异，学会判断商用边界、保护自己的模型、规避协议冲突，让你分享得安心、用得放心。

岗位关联

对 AI 从业者而言，协议选择直接决定模型能否商用、产品能否上线、融资尽调是否安全。掌握这份知识，等于给你的技术生涯上了法律保险栓。

目录
  1. 可视化演示
  2. 协议基础认知：先看清“菜谱”的玩法
  3. 宽松系协议：随手分享的 MIT 与 Apache
  4. 强左系协议：用了就传染的 GPL / AGPL
  5. 模型许可特性：菜谱成品与做法步骤
  6. 商用合规评估：开餐厅前的三项检查
  7. 发布保护协调：菜谱合并与冲突规避
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示AI模型开源协议怎么选的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

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

AI模型开源协议怎么选：AI模型 AI模型协议与传统软件协议的本 主流AI模型协议的条款对比 核心机制可视化 AI模型开源协议怎么选整体架构与关键组件

协议基础认知：先看清“菜谱”的玩法

小明家的云吞秘方广受好评，他决定把秘方放进街口的共享信箱，任人取阅。可老王提醒他：“光把纸放进去没用，你必须在纸上写清楚：别人拿到菜谱后能干什么、不能干什么、必须干什么。” 这个“使用说明书”，就是软件世界的许可证；在 AI 世界里，就是模型开源协议。每个协议都可以理解成一个“权利包”，权利包的尺寸决定了别人对你的模型有多大的行动自由。

从技术上看，几乎所有开源协议都能拆解成三个集合：允许做的事、要求做的事、禁止做的事。比如 MIT 允许商用、修改、再分发，要求保留版权声明，禁止将作者名字用于推广。Apache 2.0 在这基础上，还给了使用者一份“专利授权”。GPL 则要求任何衍生作品必须继续使用 GPL 发布。AI 开发者拿到一个模型时，首先要做的不是看模型卡上的夸赞指标，而是翻到 License 字段，确认这份“菜谱”随附的玩法说明是哪一种。

老王把那本“授权印章盒”摆在桌上，告诉小明：印章的组合方式，决定了你的秘方是被街坊拿去开面馆，还是被大厂收进中央厨房。搞懂协议基础，是选型前的第一步。

L=(A允许,R要求,P禁止)L = (A_{\text{允许}}, R_{\text{要求}}, P_{\text{禁止}})
一个开源协议，可以看成由“允许、要求、禁止”三类规则组成的三元组。读懂协议，就是看这个三元组里装了什么。
  1. 协议定义为三元组一个许可证 L 由三个集合共同刻画。
    L=(A允许,R要求,P禁止)L = (A_{\text{允许}}, R_{\text{要求}}, P_{\text{禁止}})
  2. 允许集合列出使用者可以做的事，如商用、修改、再分发。
    A允许={商用,修改,再分发}A_{\text{允许}} = \{\text{商用}, \text{修改}, \text{再分发}\}
  3. 要求集合列出使用者必须履行的义务，如保留版权声明、公开源码。
    R要求={署名,开放源码,⋯ }R_{\text{要求}} = \{\text{署名}, \text{开放源码}, \cdots\}
  4. 禁止集合列出明确不允许的事，如使用原作者名义背书。
    P禁止={商标使用,责任担保,⋯ }P_{\text{禁止}} = \{\text{商标使用}, \text{责任担保}, \cdots\}

宽松系协议：随手分享的 MIT 与 Apache

小明决定先试试最简单的方式：在菜谱上印一行字“本秘方来自小明云吞铺，欢迎自由使用，只要保留这句话”。这种“贴标签即可随便用”的授权思路，就是宽松系许可。它就像你借给朋友一本书，只要求人家还书时别把扉页撕掉。MIT、BSD 和 Apache 2.0 都属于这个家族，也是目前开源模型领域最友好、最常见的选择。

宽松系的核心特征是“无传染性”：别人拿走你的权重、代码改得面目全非，闭源商用，你都没有意见，只要保留版权声明。Apache 2.0 比 MIT 更进一步，它附带了明确的专利授权条款——如果模型内包含专利技术，使用者在 Apache 2.0 下获得一份自动的专利许可；同时它还限制了商标使用，防止别人用"Apache"旗号招摇撞骗。对于 AI 创业公司，Apache 2.0 通常是比 MIT 更稳妥的选择，因为它把专利风险写明了。

小明松了口气：“这么说，宽松系就像把菜谱贴满全城，谁爱学谁学？” 老王点头：“对，但别忘了，贴出去的每一份菜谱上都留着你的名字。这就是宽松系的'署名'底线。”

RApache=RMIT∪{专利授权}R_{\text{Apache}} = R_{\text{MIT}} \cup \{\text{专利授权}\}
Apache 2.0 的权利集合，等于 MIT 的权利集合，再并上一个“专利授权”元素。这个额外元素，恰好补上了 AI 技术商业化时最怕的专利地雷。
  1. 列出 MIT 权利集合MIT 允许商用、修改、再分发，并要求署名。
    RMIT={商用,修改,再分发,署名}R_{\text{MIT}} = \{\text{商用}, \text{修改}, \text{再分发}, \text{署名}\}
  2. 追加专利授权Apache 2.0 在 MIT 基础上增加一条专利许可。
    RApache=RMIT∪{专利授权}R_{\text{Apache}} = R_{\text{MIT}} \cup \{\text{专利授权}\}
  3. 集合取并的意义任何 MIT 下的合法使用方式，在 Apache 2.0 下依然合法，且多一重保障。
    ∀x∈RMIT:x∈RApache\forall x \in R_{\text{MIT}} : x \in R_{\text{Apache}}

强左系协议：用了就传染的 GPL / AGPL

又过了几天，小明有些心疼：隔壁老赵用他的秘方开了一家“网红云吞店”，生意比他还火。老王笑着说：“你要是想让'改良后的秘方也惠及全街坊'，那就得上强左系协议，也就是 copyleft。” 这就像你送出一本菜谱的同时，在扉页写明：“任何人用这本菜谱做出新菜谱，必须同样免费公开给所有人。”

GPL 的“传染性”指：如果你把 GPL 代码或模型融入自己的作品并对外发布，整个衍生作品必须采用 GPL 或兼容许可发布。你不能把 GPL 组件“打包进”一个 MIT 项目而让整体变成 MIT。AGPL 则更狠：即使你不发布软件，只把它作为网络服务（SaaS）跑在服务器上，用户通过网络使用它，你也必须提供对应源码。这直接击中了 AI 时代最常见的商业模式——把模型封装成 API 出售。用 AGPL 的组件撑起 API 服务而不开源，是典型的合规雷区。

小明听得直冒汗：“照这么说，如果我请老赵帮忙改良秘方，他改完的新秘方也得贴回共享信箱？” 老王点头：“没错，这就是强左系的交换条件：你拿了大家的，也得给大家一个公平的回馈。”

Deriv(D,G)⇒D∈GPL\text{Deriv}(D, G) \Rightarrow D \in \text{GPL}
若 D 是 GPL 作品 G 的衍生作品，则 D 必须同样以 GPL 发布。这就是“传染”的数学表达：开源的义务顺着衍生关系一路传导。
  1. 定义衍生关系假设 D 是由 GPL 作品 G 派生出来的作品。
    Deriv(D,G)\text{Deriv}(D, G)
  2. 触发传染义务只要 D 满足衍生关系并对外分发，D 就必须采用 GPL。
    Deriv(D,G)⇒D∈GPL\text{Deriv}(D, G) \Rightarrow D \in \text{GPL}
  3. 约束的分发条件若 D 只在内部使用而不对外分发，则不触发该义务。
    ¬Distribute(D)⇒¬Require(D∈GPL)\neg \text{Distribute}(D) \Rightarrow \neg \text{Require}(D \in \text{GPL})

模型许可特性：菜谱成品与做法步骤

小明又遇到新问题：他想把“云吞秘方”和“拌面酱秘方”一起打包，做成一套“套餐秘方”。可两份秘方的“成分结构”完全不同——一份是腌制好的成品酱料（权重），一份是详细做法步骤（代码）。老王说，这正是 AI 模型协议和传统软件协议最大的不同：传统开源协议管的是“做法步骤”（源代码），而 AI 模型的核心资产是“菜谱成品”（训练好的权重参数）。

很多模型厂商打出“开放权重”（Open Weights）的口号，但开放权重不等于开源。Llama 系列模型对权重开放下载，但许可条款限制月活用户规模、不允许用模型输出训练竞品；这更像“开放品尝，但禁止复制配方开店”。真正的“开源模型”应当代码、权重、数据三方面都有开放许可，而目前绝大多数模型只开放权重和推理代码，训练数据仍是不公开的“秘制食材”。此外，训练数据集常用 Creative Commons（CC）或 Open Data Commons（ODC）协议，这些协议与模型权重的许可证互相独立，使用时必须单独核查。

小明恍然：“原来'共享信箱里有我的成品酱料'不等于'他们把腌制过程也教给全街坊'。” 老王赞许道：“正是这个道理。看清三层结构，才不会把'开放权重'误当成'开源模型'。”

Omodel≠Ocode∩Oweight∩OdataO_{\text{model}} \neq O_{\text{code}} \cap O_{\text{weight}} \cap O_{\text{data}}
一个模型真正意义上的“开放”，不等于代码、权重、数据三者同时开放。开放权重只是其中一个子集，别把“能下载”当成“全开放”。
  1. 定义全集模型开放完整开源模型要求代码、权重、数据三要素全部开放。
    Omodel=Ocode∩Oweight∩OdataO_{\text{model}} = O_{\text{code}} \cap O_{\text{weight}} \cap O_{\text{data}}
  2. 开放权重是必要非充分条件仅开放权重时，等式左侧的模型开放不成立。
    Oweight⇏OmodelO_{\text{weight}} \not\Rightarrow O_{\text{model}}
  3. 不等号的含义开放权重与完整开放之间存在巨大差距，商用前要逐一确认。
    Omodel≠OweightO_{\text{model}} \neq O_{\text{weight}}

商用合规评估：开餐厅前的三项检查

小明的好友小美看中他的秘方，计划开一家连锁云吞店。她拿着菜谱复印件来问老王：“这菜谱我到底能不能用？” 老王让她做三项检查：第一，菜谱上写没写“禁止商用”；第二，她改良后的菜谱算谁的；第三，她开业后要不要在门口挂“源自小明秘方”的牌子。把这三点搞清楚，商用合规问题就解决了一大半。

落到 AI 领域，商用合规评估同样分三步。第一步，商用许可判定：查看许可是“仅研究”（research-only）还是允许商业用途，例如许多模型许可明确写“Non-commercial use only“。第二步，衍生品界定：对模型进行微调（fine-tune）后，权重衍生自原模型，通常视为衍生作品，需遵循原协议；某些许可证还要求把微调后的权重以同等条款开源。第三步，义务履行：保留版权声明、放置许可证副本、在分发时附上源码获取方式或”修改说明”。三步全绿，商用才落地。

小美做完三项检查，在合同上签了字。老王把检查单钉在墙上：“任何 AI 产品要商业化，这套检查单都要走一遍。别等产品上线收到律师函才后悔。”

Com(M)=Acom∧Dok∧Ook\text{Com}(M) = A_{\text{com}} \land D_{\text{ok}} \land O_{\text{ok}}
模型的商用可行性是三件事的逻辑与：商用条款允许、衍生品定位清晰、必须履行的义务都能做到。任何一项为假，整体即为假。
  1. 商用条款允许判断许可证的“允许集合”里是否包含商用。
    Acom=(商用∈A允许)A_{\text{com}} = (\text{商用} \in A_{\text{允许}})
  2. 衍生品归属明确评估微调、合并等操作后作品是否仍受原协议约束。
    Dok=(衍生义务可确定)D_{\text{ok}} = (\text{衍生义务可确定})
  3. 义务可以履行确认署名、开源、保留通知等义务在商业场景中可落地。
    Ook=(义务可执行)O_{\text{ok}} = (\text{义务可执行})
  4. 三项做逻辑与任意一项不满足，整个商用决策都需暂停。
    Com(M)=Acom∧Dok∧Ook\text{Com}(M) = A_{\text{com}} \land D_{\text{ok}} \land O_{\text{ok}}

发布保护协调：菜谱合并与冲突规避

小明的生意越做越好，他想把自己的云吞秘方和一条街外的川味面馆的麻辣酱秘方合并，研发一款“麻辣云吞”。可问题来了：自家秘方用的是 MIT 授权（谁都可以用），对方秘方却写着“使用后衍生品必须同样开放”（GPL）。两套规则一碰，就像一碗面里同时加糖和加盐，味道全乱了。老王说，这就是协议兼容性冲突。

协议兼容的底层逻辑是：宽松协议可以被吸收进强左协议项目，但强左协议无法被“降级”进宽松项目。MIT 代码可以并入 GPL 项目，因为 GPL 的规则比 MIT 更严格，整体仍以 GPL 发布；Apache 2.0 可以并入 GPL 3.0，但 Apache 与 GPL 2.0 存在争议；AGPL 几乎只能与少数强左协议共存。应对冲突有三招：隔离（把不同协议组件放到独立进程/独立仓库）、双许可（同一模型提供“开源版”和“商用版”两条授权路径）、升级与替换（把冲突组件换成兼容版本）。AI 模型领域常见的 OpenRAIL 协议还会附加“禁止用于军事、违法用途”等负责任 AI 条款，这些附加条款同样可能与其他许可证冲突，需要逐一比对。

最终，小明请老王为自己那本“终极秘方”选了双许可策略：社区用 Apache 2.0，商用另谈。他把这句口诀贴在厨房门口：“合并之前查矩阵，附加条款单独核；隔离双许来解围，合规安心把店开。”

C(A,B)  ⟺  permit(A)⊇require(B)C(A, B) \iff \text{permit}(A) \supseteq \text{require}(B)
协议 A 能与协议 B 兼容，当且仅当 A 的允许范围能覆盖 B 的强制义务。换句话说，你选择的许可证，必须“扛得住”对方协议里最严格的那条要求。
  1. 列出 A 的允许范围协议 A 假设允许使用者做更多事，例如 MIT 允许闭源再分发。
    permit(MIT)={商用,闭源,再分发}\text{permit}(\text{MIT}) = \{\text{商用}, \text{闭源}, \text{再分发}\}
  2. 列出 B 的强制义务协议 B 假设要求衍生品继续开放源码。
    require(GPL)={开源,署名}\text{require}(\text{GPL}) = \{\text{开源}, \text{署名}\}
  3. 判断包含关系若 A 的允许范围完全覆盖 B 的义务集合，则 A 可以并入 B 项目。
    permit(MIT)⊇require(GPL)⇒C(MIT,GPL)=True\text{permit}(\text{MIT}) \supseteq \text{require}(\text{GPL}) \Rightarrow C(\text{MIT}, \text{GPL}) = \text{True}

AI 应用场景

开源模型商用选型

阶段：模型选型与采购

解决的问题：过去团队挑模型只看榜单精度，无视许可证限制，结果把“仅研究”模型直接集成进商业产品，上线前法务才发现要全部返工。现在用协议知识先做合规筛查，把 MIT/Apache 模型纳入白名单，对有商用限制的模型自动标红，避免返工和赔偿风险。

具体案例：某 AI 客服创业公司要选择一个对话模型底座，候选包括 Llama 3.1、Mistral 和 Qwen。法务与技术联合开会，对比 License 字段：Mistral 采用 Apache 2.0 可放心商用，Llama 有月活门槛附加条款需控制规模，Qwen 需看具体版本条款。最终选定 Apache 2.0 模型做底座，产品顺利过审上线。

发布自有微调模型的许可选择

阶段：模型发布与开源策略

解决的问题：创业团队微调出垂直领域模型，既想扩大社区影响力，又怕大厂拿走模型做成竞品。通过学习协议知识，团队在发布时主动选择 Apache 2.0 并附加商标保护条款，既保持宽松友好，又锁定署名权与免责边界。

具体案例：一家医疗影像团队基于开放权重模型微调出肺结节检测模型，发布时参考 OpenRAIL 思路，在 Apache 2.0 基础上附加“禁止用于临床决策”的用途限制条款，既传播了模型价值，又规避了医疗责任风险。

SaaS 平台中的 AGPL 风险排查

阶段：合规审计与发布

解决的问题：许多 AI 平台的推理服务使用了开源组件，却不知道 AGPL 的“网络条款”会穿透服务器边界，导致整个 API 服务被迫开源。通过协议矩阵核查，可提前识别强左依赖并替换或隔离。

具体案例：某 NLP API 平台在依赖清单中发现一个 AGPL 协议的前处理库，若直接使用，用户通过网络调用 API 将触发源码公开义务。团队将该库替换为 MIT 等价实现，并将无法替换的组件隔离到独立微服务中，成功保住核心代码封闭性。

Python 演示

python52 行
# -*- coding: utf-8 -*-"""AI模型协议合规检查器：模拟多组件组合时的商用与开源风险判断""" class LicenseRule:    def __init__(self, name, commercial, copyleft, network, attribution):        self.name = name        self.commercial = commercial        self.copyleft = copyleft        self.network = network        self.attribution = attribution  RULES = {    "MIT": LicenseRule("MIT", True, False, False, True),    "Apache-2.0": LicenseRule("Apache-2.0", True, False, False, True),    "BSD-3-Clause": LicenseRule("BSD-3-Clause", True, False, False, True),    "GPL-3.0": LicenseRule("GPL-3.0", True, True, False, True),    "AGPL-3.0": LicenseRule("AGPL-3.0", True, True, True, True),    "CC-BY-NC-4.0": LicenseRule("CC-BY-NC-4.0", False, False, False, True),}  def check_commercial(base_license, dep_licenses, usage):    """检查主协议与依赖协议组合后的商用可行性"""    reports = []    main_rule = RULES[base_license]    if not main_rule.commercial:        reports.append(("主模型许可", base_license, "禁止商用"))    else:        reports.append(("主模型许可", base_license, "允许商用"))    copyleft_deps = [d for d in dep_licenses if RULES[d].copyleft]    network_deps = [d for d in dep_licenses if RULES[d].network]    if copyleft_deps:        reports.append(("强左依赖", "+".join(copyleft_deps), "衍生品需以相同许可开源"))    if usage == "saas" and network_deps:        reports.append(("网络条款", "+".join(network_deps), "SaaS场景触发源码公开义务"))    if not copyleft_deps:        reports.append(("传染性检查", "全部宽松", "无传染风险"))    return reports  def main():    base = "MIT"    deps = ["Apache-2.0", "AGPL-3.0"]    usage = "saas"    reports = check_commercial(base, deps, usage)    for section, lic, note in reports:        print("{} | {} | {}".format(section, lic, note))  if __name__ == "__main__":    main()
目的：模拟一个“法务+技术”双视角的协议审计工具，输入主模型许可、依赖组件许可和使用方式，输出商用可行性与传染风险提示。
  1. RULES = {...}用字典把每种协议的商用、传染、网络三属性建表，相当于“许可证体检档案”。
  2. if not main_rule.commercial:第一关：商用条款一键核查，非商用许可直接亮红牌。
  3. copyleft_deps = [d for d in dep_licenses if RULES[d].copyleft]扫出所有带传染性的强左依赖，找到潜在的“回传”风险源。
  4. if usage == "saas" and network_deps:针对性检查 AGPL 网络条款：SaaS 场景下，网络使用也会触发开源义务。
  5. print("{} | {} | {}".format(...))输出结构化的审计报告，让技术和法务都能迅速定位问题。

常见误区

误区我总以为模型仓库里写着"Open Source"，就意味着我可以把模型拿去接外包、做 API 卖钱，反正不用付一分钱。

正解开源协议管的是“使用规则”而非“价格”。“免费使用”和“允许商用”是两个维度。CC-BY-NC 这类协议明确禁止商业用途，很多模型许可也写明“仅研究”。这就像朋友请你免费品尝他的秘制酱料，不代表你就能把酱料装瓶出售。任何商用动作前，都必须先查协议里“商用”这一项。

为何常见：大家习惯了“开源软件=免费”的互联网直觉，忽略了许可证文本里对场景的细分限制，尤其 AI 模型许可中研究许可极为常见。

误区我觉得 MIT 和 Apache 差不多，都是宽松许可，用哪个都行，反正就是标注一下出处罢了。

正解两者最大差别是专利授权。Apache 2.0 明确规定：如果项目中有专利，使用者在遵循许可的前提下自动获得专利授权，这为商用扫清了专利诉讼地雷；同时 Apache 还限制你用原作者商标做背书。MIT 简洁但有专利漏洞。这就像两份都允许“随便用”的菜谱，一份额外写清了“调料包专利你也可以用，但别打我家招牌”——差别在细节里。

为何常见：MIT 和 Apache 在大多数操作上表现一致，人们不读专利条款，自然以为只是“多写一行”。

误区我认为 GPL 针对的是 C++/Java 源码，模型权重就是一堆浮点数，不算源代码，所以 GPL 管不到我头上。

正解模型权重确实是“制品”而非源代码，但 AI 模型的训练代码、推理代码、以及经过微调的权重，都可能被法务认定为“衍生作品”。用 GPL 代码训练模型、或将 GPL 组件嵌入推理管线，都面临传染风险。这就像菜谱里混入了“共享俱乐部”的秘制调料——即使你主要用自家的面粉，那一勺调料也能让整锅汤背上公开义务。

为何常见：AI 是新事物，大家默认“旧协议管不到新技术”，却忽略了法院和许可方会用“衍生作品”的弹性概念来扩展解释。

误区我看到模型页面上写着“Open Weights，可下载”就欢呼“这模型开源了”，然后放心地集成进自己的商业产品。

正解开放权重只是开放了“菜谱成品”，训练数据、完整训练代码往往并不开放，且许可条款常附带“月活用户上限”“禁止用输出训练竞品”等限制。一个模型要称得上“开源”，需要代码、权重、数据三方面都符合开源定义。开放权重更像“公开试吃”，不等于“公开配方”。

为何常见：厂商营销故意把“Open Weights“包装成”Open Source”，媒体也习惯混用，导致开发者只看下载按钮，不看协议正文。

误区我基于 Llama 微调了一个行业模型，觉得改得够多已经算“新作品”，可以直接申请自己的版权、闭源销售。

正解微调是在原权重基础上继续训练产生的衍生权重，除非许可协议明确豁免，否则通常被视为衍生作品，原许可证的条款继续约束你。这就像你买了老王的预制菜，回家加了葱花和辣椒，再拿出去卖，仍然得遵守老王在包装上写的“禁止转售”条款。想摆脱约束，只能找明确允许自由改动的宽松协议，或与权利人另签商用合同。

为何常见：人的直觉是“我加了新东西就是我的”，但著作权法对衍生作品的界定更看重“是否基于原作品创作”，而不是改动量。

面试题

Q1. MIT 协议要求使用者履行的最小义务是什么？

单选题 · easy

  • A.保留版权声明← 正确答案
  • B.公开全部源码
  • C.禁止任何商用
  • D.支付授权费用

答案：A。MIT 是最宽松的协议之一，唯一核心义务是保留原版权声明和许可文本。它不像 GPL 那样要求公开源码，也不禁止商用、修改和再分发。相当于菜谱上只要求“保留我的署名”，其余自由。

Q2. Apache 2.0 相比 MIT 多出的关键条款是什么？

单选题 · easy

  • A.专利授权条款← 正确答案
  • B.强制开源源码
  • C.禁止商业使用
  • D.要求付费使用

答案：A。Apache 2.0 在 MIT 的基础上增加了明确的专利授权，使用者在遵守许可时自动获得项目中相关专利的使用权，且它限制商标使用。这一条对 AI 商用至关重要，相当于菜谱附带“调料包专利你也能用”的保证。

Q3. GPL 协议的“传染性”指什么？

单选题 · mid

  • A.衍生作品必须同样以 GPL 发布← 正确答案
  • B.使用后必须向作者付费
  • C.禁止对代码做任何修改
  • D.只能在个人项目中内部使用

答案：A。GPL 传染性指：若你将 GPL 组件融入作品并对外分发，整个衍生作品必须采用 GPL 或兼容许可发布。它并不禁止商用或修改，而是要求修改后的源码继续开放，如同“用了共享菜谱，新菜谱也得共享”。

Q4. AGPL 与 GPL 最大的区别是什么？

单选题 · mid

  • A.网络服务场景也触发开源义务← 正确答案
  • B.完全禁止商业用途
  • C.不再要求保留署名
  • D.与所有宽松协议兼容

答案：A。AGPL 在 GPL 基础上增加了“网络条款”：即使你不分发软件，只以 SaaS 形式通过网络提供服务，用户也能要求获取源码。这击中了 AI API 服务的商业命门，相当于“不卖菜谱，只开餐厅，也要求你把菜谱公开”。

Q5. 把模型权重比作“菜谱成品”，传统开源协议主要针对的对象是什么？

单选题 · mid

  • A.代码做法步骤← 正确答案
  • B.权重菜谱成品
  • C.数据集原材料
  • D.部署环境配置

答案：A。传统开源协议（如 GPL、MIT）诞生于软件世界，核心对象是源代码，即“做法步骤”。而模型权重是被训练出的参数制品，更像“做好的菜谱成品”，两者法律性质不同，这也是 AI 模型许可需要专门定制条款的原因。

Q6. 以下哪些属于宽松系开源协议？

多选题 · mid

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

答案：ABD。MIT、Apache-2.0、BSD-3-Clause 都属于宽松系，特点是允许闭源商用、无传染性。GPL 属于强左系，要求衍生作品继续开源。宽松系如同“随便用只要署名”的菜谱，GPL 则是“用了就必须回传”的共享俱乐部。

Q7. 在商用合规评估中，对模型进行微调后发布，通常被视为什么？

单选题 · hard

  • A.原模型的衍生作品← 正确答案
  • B.全新的独立作品
  • C.不适用任何协议
  • D.自动进入公有领域

答案：A。微调基于原模型权重继续训练，在著作权法框架下通常被视为衍生作品，除非协议明确豁免，否则原许可证继续约束微调产物。就像用老王的预制菜加料再卖，仍需遵守包装上的“禁止转售”条款，而非自动变成你的新菜。

Q8. 使用 AGPL 组件搭建 SaaS 服务，下列说法正确的是？

多选题 · hard

  • A.需向网络用户提供对应源码← 正确答案
  • B.网络使用触发源码公开义务← 正确答案
  • C.与 MIT 组件组合则无冲突
  • D.无论如何都禁止商用

答案：AB。AGPL 允许商用（D 错），但网络用户使用服务即触发公开源码义务（B 对、A 对）。若 AGPL 组件与 MIT 组件组合成衍生作品，整体需以 AGPL 发布，并非无冲突（C 错）。这是 AI 平台把 AGPL 库请进服务前必须想清楚的账。

Q9. OpenRAIL 系列许可强调的 "RAIL" 核心价值是什么？

单选题 · easy

  • A.负责任 AI 用途限制← 正确答案
  • B.全部权利免费赠送
  • C.强制专利授权
  • D.禁止任何修改

答案：A。RAIL 即 Responsible AI Licenses（负责任 AI 许可），核心是在传统开源条款之外附加“禁止用于军事、违法、伤害性场景”等用途限制。它像在菜谱角落加一行“禁止用来做危害邻居的黑暗料理”，体现 AI 时代的伦理考量。

Q10. 关于开源协议兼容性，下列说法正确的是？

多选题 · extreme

  • A.MIT 代码可并入 GPL 项目← 正确答案
  • B.Apache-2.0 可并入 GPLv3← 正确答案
  • C.AGPL 可并入 MIT 项目
  • D.GPL 代码可并入 MIT 项目

答案：AB。宽松协议可被吸收进强左协议：MIT 允许其代码在 GPL 项目中以 GPL 再发布（A 对），Apache-2.0 与 GPLv3 兼容（B 对）。反向则不成立：AGPL 传染性会让整个 MIT 项目被迫 AGPL（C 错），GPL 同理也不能降级并入 MIT（D 错）。兼容方向如同“糖可以进辣椒酱，但辣椒酱不会变甜”。