开源许可证风险地图：从 MIT 到 AGPL，企业该怕什么、不该怕什么

开源许可证有两千多种，但企业法务和工程团队真正需要建立直觉的，只有一张按“传染性”分层的地图。怕错了对象，要么错杀效率（禁用一切 GPL），要么放过风险（把 AGPL 组件塞进 SaaS）。

第一层：宽松型——放心用，但别忘了署名

MIT、BSD、Apache-2.0 属于宽松型（Permissive）许可证，允许商用、修改、闭源分发，义务基本只有保留版权声明与许可证文本。Apache-2.0 额外带专利授权条款，对企业反而是保护。这一层的真实风险不是许可证本身，而是执行细节：产品里连一份 NOTICE 文件都没有的“零署名”交付，在客户尽调时同样会被记为合规缺陷。我们在审计中最常见的问题，恰恰是有团队把宽松型代码的版权头也剥掉当自研——这在片段级检测面前无所遁形，详见我们的 SCA 选型指南。

第二层：弱传染——动了它才传染你

LGPL、MPL-2.0、EPL 属于弱 Copyleft：以“文件”或“库”为边界，你修改了它的文件必须开源该部分，但你自己的代码只要保持边界清晰就不受影响。工程上的关键是链接与隔离方式——LGPL 组件用动态链接通常安全，静态链接则可能把整个产品拖入开源义务。嵌入式与 C/C++ 项目是重灾区，因为静态链接是常态。

第三层：强传染——分发即触发

GPL-2.0/3.0 的规则简单而严厉：只要你分发了包含 GPL 代码的软件，整个衍生作品必须以 GPL 开源。对外交付的商业软件、预装设备固件、客户端程序都构成分发。但注意两个常被误解的边界：一是纯内部使用不构成分发，服务器上自用 GPL 软件没有开源义务；二是 GPL 的“衍生作品”边界在法律上仍有灰区，独立进程通信通常不传染，深度链接则风险高。

第四层：网络传染与商业限制——SaaS 时代的新雷区

AGPL-3.0 把触发条件从“分发”扩展到“网络提供服务”——用户通过网络使用你的 SaaS，你就要开源。这正是各大云厂商把 AGPL 列入禁用清单的原因。更新的一批“源可用”（source-available）许可证走得更远：SSPL（MongoDB）、BSL（HashiCorp 曾用）、Elastic License 直接限制“提供竞争性托管服务”，它们已不是 OSI 认证的开源许可证，但大量团队仍把这些组件当普通开源引入。近年多个明星项目的许可证切换证明：许可证不是静态属性，版本升级可能改变一切，锁定版本时必须同时锁定许可证版本。

三步落地的治理方法

第一步：摸清家底。用 CleanSource SCA 对代码库做全量扫描，重点不是依赖清单里声明的，而是复制粘贴与改名引用进来的——许可证风险最高的代码，往往正是清单上看不到的那部分。轻量起步可以用免费的 社区版。

第二步：按分发模式定策略。同一个组件，在内部工具、对外交付、SaaS 三种形态下的风险完全不同。策略应写成矩阵（许可证类型 × 分发模式 × 允许/评审/禁止），并配置进扫描工具作为准入门禁，而不是留在法务的 Word 文档里。

第三步：把义务履行工程化。自动生成随版本更新的开源声明文件（NOTICE/attribution），把许可证信息写进 SBOM 一并交付。客户验收和出海认证时，这份文件的存在与否，直接决定合规检查是十分钟还是十天。

许可证合规的目标从来不是“消灭 GPL”，而是让每一次引入都是知情决策。地图画清楚了，路怎么走是业务的自由。