开源大模型许可争议：中小企业风险排查清单

一、传染性许可波及自有代码（概率高、后果重）

部分开源大模型采用带传染性的许可条款，若将其代码或衍生模型与自有系统深度耦合，可能被要求整体开源。识别信号：许可证名称含GPL、AGPL类字样，或条款中出现“衍生作品”“同一许可分发”表述；团队把模型权重、推理代码直接并入核心产品仓库。应对动作：法务或外部顾问逐条比对许可证原文，区分“调用服务”与“分发代码”；将模型部署在独立进程或独立仓库，通过API调用隔离；建立第三方组件清单，记录每个模型的许可证名称与版本号。

二、商用范围与用户量门槛误判（概率中高、后果重）

不少模型许可附带商用限制，例如按日活用户数或营收规模分层，超过阈值需另行申请授权。识别信号：许可文件中出现“商业使用”“月度活跃用户”“需获得书面许可”等措辞；产品上线后用户增长但无人复核许可条件。应对动作：在产品立项表增加“许可商用条款”一栏，写明允许的商用场景与门槛数值；运营侧按月统计相关指标，接近门槛前启动授权沟通；保留许可方公开的授权申请渠道与回复记录。

三、署名与传播义务遗漏（概率高、后果中）

多数宽松型许可仍要求保留版权声明、许可文本，并在再分发时附带说明。识别信号：产品关于页面、模型卡、安装包内未见原始版权声明；对外交付的镜像或SDK中删除了LICENSE文件。应对动作：在关于页面与文档中固定展示模型名称、版权方与许可名称；打包流程加入LICENSE文件检查项；对二次分发的模型副本附上修改说明。

四、版本升级导致许可变更（概率中、后果中）

同一模型的不同版本可能切换许可，旧版本宽松、新版本收紧的情况并不少见。识别信号：团队直接拉取“最新版”而未锁定版本号；许可文件更新后无人比对差异。应对动作：在依赖清单中锁定具体版本与提交哈希；升级前比对前后两版许可文本，重点看商用条款与传染性范围；对关键版本留存许可原文快照，便于回溯。

把许可审查放进采购与上线流程，比事后补救成本低得多。

本文由钻瓜网整理发布，内容仅供参考，具体政策、流程与费用请以国家知识产权局及各地官方机构最新公告为准。