开源权重的许可证与商用边界：「开源」到底开放了什么

很多团队选模型时看到「开源」两个字就默认能商用，等到准备上线、要过法务或要报备时才卡住：权重是放出来了，但附加条款一堆。这篇不讨论哪个模型更强，只讲许可证怎么读、哪些条款会真正影响你的产品，以及上线前你必须自己确认清楚的三件事。

选模型时看到「开源」两个字，很多团队的默认反应就是「能商用、能改、随便用」。真到准备上线、要过法务、要跟客户签交付合同时才发现，权重确实放出来了，但附加条款写了一堆，能不能用、用到什么程度，全得逐条抠。这篇不聊哪个模型强，只讲许可证怎么读、哪些条款会真正卡住你的产品，以及上线前你至少得自己确认清楚的三件事。

先把预期放低一点：许可证这件事没有一劳永逸的答案，同一家发布方不同时间放出的权重，条款可能完全不同；同一个模型的不同版本，也可能一个能商用一个只能研究。你要练的不是背结论，而是一套遇到新模型能自己跑一遍的核查动作。

权重开放 ≠ 代码开源：两件事别混

代码开源通常给你的是训练或推理代码的使用权，权重开放给你的是模型参数的下载与运行权。这是两份可以拆开发的授权：可以只放代码不放权重，也可以只放权重不放代码，甚至可以放权重但训练代码和数据集一个字都不给。所以看到仓库挂着开源协议，先确认它开的是哪一部分。

权重开放

能下载参数文件并在自己的机器上跑推理，但不代表你能改写、能对外再分发、能商用

代码开源

训练脚本、推理框架、配置文件的授权，跟权重本身是不是能商用是两套判断

可商用

许可证正文里对 commercial / commercial use 的表述说了算，简介页写的「开放」不算数

可修改

对应 derivative / modify 这类词，能不能微调、能不能蒸馏出小模型，看这一条

可再分发

对应 redistribute / distribute 这类词，决定你能不能把权重打包进自己的产品交付给客户

判断顺序建议固定下来：先翻许可证正文里 use、commercial、redistribute、derivative 这几个词出现的每一句，再把它们翻成大白话；然后看仓库根目录有没有单独的附加条款文件，比如使用政策、可接受使用清单、申请表单。正文加附件一起读完，才算读完了这份许可证。只读 README 的一句「开源免费」是最容易踩坑的做法。

常见附加条款：用户量阈值、署名、禁商用

附加条款不会写在标题上，通常混在正文中后段或者单独的附件里。下面这几类是实际交付中最常卡人的，读的时候逐类对照。

这里最容易低估的是再分发限制。很多团队自己跑没问题，一旦客户说「部署到我们内网」，你把权重文件一起给出去，动作性质就从自用变成了分发，适用条款完全变了。用户在采购阶段问的其实是同一件事，早点确认比事后解释便宜得多。

• 用户量阈值类：先记下触发条件的表述方式，是月活、还是调用次数、还是收入规模
• 署名类：先确认你的产品形态是直接调用还是二次封装，两种情况口径往往不同
• 禁商用类：只要出现禁止商用的字样，无论权重多好，直接排除出付费链路
• 再分发类：凡是涉及把文件交给第三方的场景，一律先假设不行，再去找例外
• 版本差异类：同一系列每个版本单独建一条记录，别用记忆代替查证

条款会怎么落到你的产品上

同样是「不能商用」，落在不同类型的产品上，杀伤力完全不一样。做内部工具，最多是不能拿来对外承诺效果；做面向消费者的付费产品，就是直接判死刑；做 To B 交付，则可能卡在交付那一刻而不是开发那一刻。所以判断前先把自己的产品形态定清楚，再去看条款。

还有个常被忽略的点：条款约束的是使用方式，不是使用量级本身。同一条款下，你改一次产品定位，可能就把自己从合规挪到了不合规。所以每次产品形态有大变动，许可证都应该重新过一遍，而不是项目启动时查过就算完。

上线前必须确认的三件事

前面讲的都是读法，这一节讲动作。上线前下面三件事如果你没做完，就不算确认过。这三件事看起来简单，但实际项目里经常是「以为查过了」，一追问发现查的是介绍页不是许可证。

1. 确认授权主体弄清楚许可证是哪个实体发布的，有没有它要求的申请、登记或勾选同意流程。有些授权不是默认生效，而是要走一遍表单或邮件确认，这一步没做，后面所有判断都不成立。
2. 确认你的使用方式落在哪一条把自用、对外提供服务、打包再分发三种方式分清楚，然后去许可证里找对应的表述。同一份许可证对这三种方式的限制经常完全不同，用自用的结论去套再分发是最常见的错误。
3. 确认留痕把许可证原文、版本信息、获取时间、你判断适用的条款和理由，一起存进项目文档。将来遇到审计、客户尽调或者团队换人，这是唯一能自证的东西，口头结论不算。

这三件事做完，你手上应该有一份不超过一页的说明：这个模型能不能商用、有没有量级上限、能不能交给客户、要不要署名。写不出来，说明还没查清楚。

一份可照做的核查清单

把上面的判断做成固定动作，每次引入新模型都跑一遍，比临时翻文档快得多。顺序不要跳，第一步和第二步最容易偷懒，也最容易在交付前暴露问题。

1. 找许可证字段与版本记录到模型资料库核对这个模型的许可证字段和版本记录，别只看下载页的简介。站内路径见 /models，里面有按模型整理的许可证信息。
2. 把关键句抄出来把许可证里带 use / commercial / redistribute / derivative 的句子逐条抄出，翻译成大白话，逐条判断是否适用于你的场景。
3. 书面问发布方把几个问题发邮件给发布方或社区渠道并保留答复：能否商用、有没有量级上限、能否再分发、要不要署名。书面答复比社区帖子可靠。
4. 不确定就按不能商用处理有疑问的条款先按最保守解释执行，换模型或先走授权流程，不要赌解释空间。
5. 写进内部说明并归档上线前把结论写成一页说明，产品、法务、工程各留一份，和许可证原文放在一起。

如果想让这套流程更省事，可以顺手把候选模型的部署要求也一起看了，避免选完发现资源扛不住还要回头重选。站内 /models/deploy 有按模型整理的部署测算参考，当时的具体数字在那里核对。

什么情况下这套判断不适用

上面讲的是一般情况，有几类场景可以少走几步，但前提是你真的确认过，而不是凭印象跳过。跳过之前先问自己一句：我是查过了，还是懒得查。

• 许可证正文明确写着无限制可商用、且你确认没有单独附加条款时，阈值与署名部分可以跳过
• 纯 API 调用、从不下载权重的团队，多数权重条款不直接约束你，但仍要读官方 API 的使用政策
• 只在本地做技术验证、不对外提供任何服务时风险最低，但也别把验证环境的输出直接拿去商用
• 已经拿到发布方书面授权答复的，按答复执行，同时把答复原文一并归档

还有一类情况需要额外小心：你判断「不适用」的依据来自二手转述，比如同事说的、群里传的、某篇博客写的。二手信息可以用来缩小排查范围，但不能作为最终依据，最终还是要落到许可证原文或发布方书面答复上。

真要换模型，怎么迁移不返工

核查完发现当前模型不能用，或者阈值条款限制了增长空间，换模型就是必然动作。这时候返工成本主要来自两件事：业务代码里写死了模型相关逻辑，以及迁移前没确认新模型的资源要求。

• 把调用层和模型层解耦，换模型时只改配置，不动业务代码
• 迁移前先到 /models/deploy 过一遍目标模型的显存与并发要求，确认扛得住现在的量
• 迁移顺序按离线评测、小流量、全量切三段走，每段都留回滚口子
• 切换前把旧模型的许可证记录和用量记录一起归档，后面复盘或审计用得上
• 如果旧模型是因为条款问题下线的，新模型的许可证核查流程要走完再动手

换模型的成本往往不在推理本身，而在合规判断和资源确认这两块。把这两件事前置到选型阶段做，迁移就只剩技术动作。