开源大模型绕不开的许可协议问题正好一次性说清楚。选择模型许可证本质上是在选商用边界和技术自由度MIT/Apache 2.0 几乎不设限MPL 允许闭源分发但源码修改必须公开GPL/AGPL 则要求衍生作品整体开源。更麻烦的是很多模型权重和代码走的是两套许可证混用的时候容易踩坑。1. 先从一张表看懂主流许可证差异在选型之前先把最常见的几类开源许可证摆在一起对比。不用记法律条文主要看四个维度能否闭源商用、修改后是否强制开源、对 SaaS 服务有没有额外约束、专利授权是否包含在内。许可证闭源商用修改后必须开源对 SaaS 的约束专利授权典型模型MIT允许否无额外约束无明确条款早期小型模型Apache 2.0允许否无额外约束有明确授权Llama 3、Qwen 系列MPL 2.0允许仅修改文件需开源无额外约束无明确条款部分组件级模型GPL 3.0允许整个衍生作品需开源无额外约束除非分发有明确授权部分专用模型AGPL 3.0允许整个衍生作品需开源网络服务视为分发有明确授权极少见个别专用模型2. 三档许可证的边界感完全不同2.1 MIT 与 Apache 2.0商用最友好的第一档MIT 只有一个要求保留版权声明。你用 MIT 协议的模型做任何事都行改成闭源产品卖出去也没人管你连修改说明都不用给。Apache 2.0 比 MIT 多两个东西明确的专利授权条款以及“如果你对别人发起专利诉讼那你的 Apache 授权自动终止”的限制。对大公司来说Apache 2.0 反而比 MIT 更让人放心因为专利条款写清楚了不担心模型贡献者突然翻脸告你侵权。实际操作中Llama 3、Qwen 这些主流开源模型走的是 Apache 2.0 或类似宽松协议。它们的共同点是可以闭源商用可以改可以集成进自己的产品里唯一要做的是在分发时附上许可证文本和版权声明。2.2 MPL 2.0文件级开源的折中路线MPL 2.0 经常被误以为是“传染性开源”实际没那么多限制。它只要求你修改过的那一个文件源码必须公开。其它文件、整体项目打包方式、商业闭源统统不管。举例说明你下载一个 MPL 协议的推理框架改动了inference_engine.py这个文件那只要把这个文件的修改版开源就行其余部分可以闭源甚至可以卖钱。对模型生态来说MPL 多用在工具链、推理引擎、训练框架这些组件上很少直接用在模型权重上。因为权重文件的“修改”边界很难界定MPL 的文件级逻辑更适合代码项目。2.3 GPL 3.0 与 AGPL 3.0最强传染性慎用GPL 3.0 的核心规则是只要你的项目用到了 GPL 代码通过链接或静态集成整个项目都必须以 GPL 协议开源。这等于把闭源商用这条路彻底堵死了。AGPL 3.0 更是把“使用”的边界扩展到网络服务只要用户通过网络访问你的服务就算“分发”同样触发开源义务。如果公司内部用了 AGPL 组件只要不对外提供服务、不对外分发问题还不大。但只要是对外提供给用户使用的产品用了 AGPL 组件就基本等于把自己整个产品开源。很多做 to B 业务的团队在选型时直接排除 AGPL原因就在这。3. 模型权重和源码经常不是同一套许可证最容易踩坑的地方不在模型本身的协议而在权重的许可证和配套代码的许可证不一致。很多开源模型发布了两个东西模型权重文件和推理/训练代码它们可能分别遵循不同的许可证。一个典型场景模型权重声明是 Apache 2.0可以直接商用但配套的微调工具是 GPL 协议。这时候你用 Apache 2.0 的权重微调没问题但如果你把 GPL 的微调工具源码改完集成进自己的服务里就得考虑整个服务是否会被要求开源。处理方法也很简单在项目里单独列出两份依赖清单一份管权重许可证一份管代码许可证。集成前先判断是否涉及“修改”行为和“分发”行为再决定要不要动代码。4. 模型权重到底受什么约束模型权重能否单独作为“作品”受许可证约束不同法域解释还不完全一致但商业实践已经有共识模型权重文件通常被视为受许可证约束的“作品”。一些模型在发布时直接明确要求“不得使用本模型权重进行商用”。即便如此只要权重文件附带开源许可证就按照许可证条款执行。对商用场景影响最大的是“参数访问”和“修改后的权重再分发”两个动作。如果许可证允许商用但禁止重新分发修改后的权重那你的做法只能是内部用或者作为服务对外提供但不能把改过的权重文件直接传到网上。5. 选许可证时的4个现实判断标准5.1 看商业模式而非技术栈你要是做 API 服务优先级最高的是许可证是否允许“网络服务商用”。Apache 2.0 没问题MPL 也基本没问题GPL 就得特别小心AGPL 基本不可用。你要是做交付型项目源码要交给客户那更要严格审查所有依赖项的许可证。5.2 看修改边界能否清晰界定模型微调算不算“修改”推理引擎的改动算不算“修改”这些在技术层面和法律层面都没有统一答案。选择 MPL 或 GPL 的项目时尽量搞清楚项目维护者的解释口径或者咨询法务团队。Apache 2.0 的容错空间最大争议最少。5.3 看模型发布方的额外条款有些模型虽然标着 Apache 2.0但单独附加了“月活用户量超过1亿需申请额外授权”这类限制。这类条款是独立于开源许可证存在的合规审查时必须把两者放在一起看。5.4 看是否有专利授权保障商用模型最怕专利纠纷。Apache 2.0 和 GPL 3.0 都包含明确的专利授权条款MIT 没有。对有大公司背景的团队来说专利授权条款比版权条款更重要。6. 实操中最容易忽略的三个坑第一个坑是只看主许可证文件忽略模型卡Model Card里单独写的使用限制。模型卡里的语言往往比许可证本身更严格而且很多模型卡直接引用额外条款结合起来看才完整。第二个坑是把训练数据的许可证和模型权重的许可证混为一谈。训练数据可能是 CC BY 或其它协议看似开放但你要分发数据本身就不被允许。模型权重虽然开源但你不能从权重里反推数据再分发。第三个坑是对“商用”的定义理解过窄。开源许可证里的“商用”不仅指卖软件还包括公司内部业务使用、对外提供付费或免费服务、在商业广告中使用模型能力。只要没有内部使用的豁免条款内部业务场景也受约束。7. 常见问题的快速排查思路遇到许可证问题建议按固定顺序排查第一步确认组件的准确许可证不能只看官网描述要看仓库里的 LICENSE 文件。第二步确认模型权重和配套代码是否各自使用不同许可证。第三步根据分发方式和修改行为判断触发条件。第四步确认有没有模型卡或附加条款里的额外限制。第五步最终让法务团队做正式审查。8. 几个应用场景的许可证选择建议内部技术验证、原型开发MIT 或 Apache 2.0 随便挑怎么快怎么来。对外提供 SaaS 服务首选 Apache 2.0尽可能避开 AGPLMPL 需要额外评估代码集成方式。交付给客户的私有化部署Apache 2.0 最稳妥MPL 可以用但客户可能要求你确认是否修改过特定文件。对模型做深度二次开发再分发Apache 2.0 和 MPL 都可行MPL 要求修改过的文件开源Apache 2.0 什么都不要求。需要模型本身也作为产品出售只选 Apache 2.0 或 MIT其它都有不同程度的传染风险。选择开源模型许可证从来不是单纯的法律问题它和产品形态、技术架构、商业模式绑定在一起。建议在上手任何一个模型之前先做一次简单的许可证清单整理把权重、代码、附加条款各列一栏再对着自己的分发方式做判断能避开绝大多数隐性风险。