开源许可证冲突检测实操：五种典型冲突与工程化处置

读懂单个许可证不难，难的是组合：一个现代应用动辄数千个组件、几十种许可证，两两之间的兼容关系构成一张复杂的矩阵，任何一处冲突都可能让整个产品的分发合法性出问题。这篇讲工程团队实际会遇到的五种冲突形态，以及怎么用工具把检测和处置流程化——这是律所研究文章不会写、但交付验收时真正被检查的部分。

五种典型冲突形态

一：强传染许可证混入专有产品。最经典也最严重：GPL 代码进入闭源交付物。入口往往不是显式依赖，而是复制的工具函数、fork 后改名的模块、外包团队"借用"的实现——依赖清单干干净净，冲突藏在文件级。我们的许可证风险地图详细讲过各层级的传染逻辑。

二：开源许可证之间互不兼容。最著名的组合是 Apache-2.0 与 GPLv2：Apache-2.0 的专利条款与 GPLv2 的要求冲突，两者的代码不能合并进同一个衍生作品（GPLv3 解决了这个问题）。同理还有 CDDL 与 GPL（当年 ZFS 不能进 Linux 内核主线的原因）。单看每个许可证都"没问题"，合在一起就是问题。

三：声明与实际不符。组件包管理器元数据声明 MIT，包体内却混着 GPL 文件——上游作者自己拷了别人的代码。清单级工具信任声明，这类冲突只有对文件与片段实际比对才能发现。这不是罕见情形：多语言大型项目里，声明与实际的偏差率足以让纯清单审计的结论失去意义。

四：双许可证组件未做选择记录。MySQL 客户端库、Qt 这类双许可证（GPL/商业）组件，用了哪个许可证分发需要明确的决策与记录。没有记录，审计时默认按最严格的那个算——而那往往是 GPL。

五：弱传染许可证的边界破坏。LGPL 组件本可安全使用，但静态链接、直接修改源码后未开源、或者把它的代码抽出来内联进自己的模块，都会击穿"库边界"，让弱传染升级为实际义务。

工程化检测：三层递进

第一层，清单解析：读依赖声明，快速建立组件与声明许可证的基线——免费的 CleanSource SCA 社区版即可完成。第二层，文件与片段级验证：对源码做许可证文本识别、版权头解析与代码指纹比对，发现"声明之外"的真实成分，核对声明与实际是否一致——这需要片段级检测能力。第三层，冲突判定：基于许可证兼容矩阵与你的分发模式（对外交付/SaaS/内部使用）自动计算冲突项，按严重度分级输出。

关键配置是把分发模式作为判定输入。同一个 AGPL 组件，内部工具里是低风险，SaaS 里是高危——脱离分发模式谈冲突都是误报或漏报。

四级处置动作

检出冲突后按成本从低到高走：替换（同功能的宽松许可证替代品，工具通常能直接推荐候选）；隔离（进程级分离、动态链接、网络接口调用，把传染边界挡在产品之外——需要架构评审确认隔离有效）；履约（按许可证要求开源相应部分、附带声明文件——有时开源一个非核心模块的成本远低于替换）；商业授权（双许可证组件购买商业许可，或与版权方协商）。

每个处置决策都应记录进台账：哪个组件、什么冲突、选了哪种处置、谁批准的——这份记录在客户尽调和出海认证时就是你的证据链。

最后一条经验

许可证冲突治理最贵的时点是交付前两周才开始。把三层检测配置进 CI，让冲突在引入当天就被拦截，处置成本是交付前突击的十分之一。合规不是一场审计,而是一道常开的门禁。