开源权重许可证的变化

“模型可以下载”曾经被很多团队直接理解为“开源、免费、可商用”。随着模型发布方式变多，这个判断越来越危险。同一个仓库里，推理代码可能采用 Apache-2.0，权重采用单独的社区许可，数据集又有自己的使用条款；可以本地运行，也不代表可以任意再分发或训练竞争模型。

近年的核心变化不是许可证统一了，而是分层更细：开源软件许可证、开放权重、研究许可、社区许可和带用途限制的模型条款并存。本文基于公开许可文本整理判断方法，不构成法律意见；具体项目必须核对你下载版本所附的原始 LICENSE、NOTICE 与可接受使用政策。

一、先把“开源”与“开放权重”分开

传统开源软件强调使用、研究、修改和再分发的自由。AI 模型除了代码，还包含架构、权重、训练数据与训练流程。只放出权重，开发者能推理和微调，却未必能重现训练过程或自由使用全部组件。

Open Source Initiative 的 Open Source AI Definition 1.0 把自由使用、研究、修改和分享作为核心，并提出“preferred form for modification”需要相应的数据说明与代码。这个定义提供了讨论基准，但市场宣传中的“open”并不会自动等于满足该定义。

因此技术文档最好使用准确词汇：如果只有参数可下载，写“开放权重”；如果代码是 OSI 批准许可证，写“推理代码开源”；只有完整系统满足所采用的开源定义时，再称“开源 AI”。术语准确能避免采购、法务和工程团队讨论的其实不是同一件事。

二、许可证从单文件变成多层协议栈

一个模型包常见至少五层条款：仓库代码许可证、模型权重许可证、训练或微调数据许可证、可接受使用政策、第三方依赖与 tokenizer 许可。模型卡是说明材料，不一定等同于授权文件。

组件	常见授权方式	工程上要确认的问题
推理代码	Apache-2.0、MIT 等	能否修改、分发，是否保留 NOTICE
模型权重	社区许可或模型专用许可	商用、托管、再分发是否允许
数据与样例	数据集单独条款	是否允许训练、输出再利用
使用政策	禁止用途清单	产品场景与用户行为是否覆盖
衍生模型	原许可延伸条款	微调后命名、归属、分发义务

只做软件成分分析通常只能识别第一层。企业模型登记表需要把权重哈希与其许可证版本绑定，否则仓库更新后，团队无法证明生产中运行的究竟受哪一份条款约束。

三、社区许可带来了“可用但有条件”的中间地带

以 Meta Llama 3 的公开社区许可为例，文本授予使用、复制、修改与创建衍生作品等权利，同时对再分发、品牌展示、衍生模型命名和特定规模用户另有条件，并附带可接受使用政策。它提供了广泛使用空间，但结构不同于无用途限制的传统宽松开源许可证。

这类许可的价值是模型发布方可以保留品牌、安全与商业边界；代价是使用者不能仅凭“免费可下载”判断合规。尤其是 SaaS、模型托管、白标产品和二次分发，需要逐条确认自己是“使用模型提供服务”，还是“分发模型材料或衍生模型”。

不同代际模型的条款也可能改变。不能因为上一代允许某种用途，就默认新版权重相同；也不能用仓库根目录的代码 LICENSE 覆盖子目录中的模型许可证。

四、商用许可不是一个简单的是非题

“允许商用”至少包含四种不同动作：公司内部使用；把模型嵌入面向客户的功能；提供模型 API 或托管服务；把原始或修改后的权重再分发。许可证可能允许前两项，却对后两项设置额外条件。

还要检查规模门槛、地域、行业或用途限制，以及条款是否要求展示归属、传递许可证、说明修改、使用特定名称。对输出的权利也应单独查看：权重许可不一定解决训练数据版权、用户输入权利和生成内容责任。

采购表中不要只保留 commercial_use: true。更实用的字段是：内部推理、客户功能、托管 API、权重分发、微调分发是否允许；需要哪些 notice；有哪些规模触发条件；谁完成了审查。

五、衍生模型与合并模型最容易产生误判

LoRA、全量微调、蒸馏、量化、模型合并是否构成衍生材料，要按具体许可定义判断。技术上只发布 adapter，不意味着法律上一定脱离基础模型条款。模型命名和 README 也可能有强制要求。

合并多个权重时，最宽松的许可证不能覆盖更严格的一方。团队需要为每个输入模型建立来源清单，并检查条款是否兼容。若一个模型禁止某种用途，合并后不能靠另一个 Apache-2.0 模型把限制“冲掉”。

发布量化版本同样属于高风险节点。量化通常保留了基础权重的大量表达，发布者应保存原始来源、转换脚本、哈希、许可证与 attribution，并在自动发布流水线中加入许可门禁。

六、许可证变化会进入供应链风险

模型发布方可能为新版本采用不同条款，旧版本也可能伴随可接受使用政策的更新。生产系统如果一直跟随 latest 或仓库主分支，就会把法律与运营变化混进普通升级。

建议像管理依赖一样管理模型：固定模型制品哈希；保存获取日期和许可文本副本；记录来源 URL 与版本；新版本进入隔离评测；许可差异由负责人确认后再升级。历史条款是否可被单方改变属于具体法律问题，应交由专业人员判断，工程系统至少要保存证据。

模型文件还要做完整性校验，避免镜像站替换权重或遗漏 LICENSE。模型供应链的更广泛风险可参考 AI 生成代码的来源与追溯，其中的版本、来源和审计思路同样适用。

七、企业可以建立一张许可决策表

每次引入模型时，由工程填写事实、法务解释条款、产品确认用途。下面是一份最小结构：

model_artifact: vendor/model@sha256:...
license_file: licenses/model-license-2026-09.txt
source_url: https://example.com/vendor/model
use_case:
  internal_inference: true
  customer_facing_feature: true
  hosted_api: false
  redistribute_weights: false
derivatives:
  fine_tune: true
  publish_adapter: false
obligations:
  attribution: pending_review
  naming: pending_review
review_owner: legal-ai
reviewed_at: 2026-09-15

“pending_review” 必须阻止发布，不能被当作默认允许。用途改变时重新审查，例如内部检索模型后来被包装成公共 API，原批准结论不应自动沿用。

八、自动化扫描能做什么，不能做什么

流水线可以检查模型制品是否带许可证、哈希是否登记、NOTICE 是否进入分发包、禁止清单是否命中已知场景。它也可以阻止未知模型直接进入生产，并在许可证文本变化时生成差异。

自动化不能可靠解释所有法律概念，也不能仅凭 SPDX 标识判断模型专用条款。最佳边界是机器负责发现、固定证据和执行已批准策略，人负责解释模糊条款与业务事实。

对于只调用第三方 API 的团队，仍要审查服务条款与数据政策，但无需承担权重再分发义务。自托管带来数据控制和可定制性，也把模型供应链、基础设施与许可管理交给了自己。相关取舍见开源模型 vs 闭源模型：企业选型框架。

九、行业变化的实际结论

开放模型生态正在从“有没有权重”走向“开放到哪一层、允许什么行为、承担什么义务”的精细比较。OSI 的定义推动行业区分完整开源系统与仅开放权重，模型厂商的社区许可则形成了广泛可用但附带条件的另一条路线。

开发者不需要先解决术语争论，才能安全选型。只要坚持按制品版本阅读原始条款、按真实使用动作做矩阵、把审查结果固化进发布门禁，就能显著减少“下载时以为免费，上线后才发现限制”的返工。