用了开源代码做产品，为什么被要求开源整个系统？许可证类型、传染性边界与三条自保线

开发团队图省事，从网上找了一段开源代码放进产品里，上线大半年都相安无事。直到某天收到一封律师函，或者被客户安全尽调问到"你们的软件用了哪些开源组件"，才发现麻烦来了：人家要求你把整个产品的源代码公开。老板一脸问号——我用的只是免费代码，凭什么要我开源全部？

一、先看懂：开源 ≠ 免费随便用

关键概念是"传染性"：某些许可证规定，你的代码只要与它"结合"成衍生作品，整个结合体都必须按同一许可证开源。这就是"用了一段代码、赔上整个系统"的法律机制。

二、"传染"什么时候真的触发，三个边界要分清

·分发边界：传统 GPL 的开源义务在"分发"时触发。SaaS 在线服务不分发副本，严格说可能不触发 GPL——但 AGPL 就是为堵这个口子而生的，网络服务也算触发。你的产品是卖安装包还是只提供在线服务，决定了完全不同的风险敞口。

·结合方式边界：静态链接、动态链接、进程间通信、独立程序通过管道交互——法律上是否构成"衍生作品"，各许可证与各国判例口径不同。静态链接风险最高，独立进程 + 标准接口风险最低。

·修改边界：原样使用、小修小补、深度改造，义务强度递增。LGPL/MPL 通常只要求把对该组件本身的修改开源，你的业务代码不必然被牵连。

要特别注意：嵌入式与硬件场景最容易出事。路由器、智能设备、车载系统固件里塞了 GPL 组件，整机分发就是分发衍生作品，近年来多起公开维权案例都发生在这个领域。

三、三条自保线，从今天开始布

·第一条：先做软件物料清单（SBOM）。把产品里所有第三方与开源组件列成清单：组件名、版本、许可证、引入方式、在哪个模块用。没有这份清单，后面一切无从谈起——你连自己用了什么都不知道，谈何合规。

·第二条：高传染组件隔离评估。对 GPL/AGPL 组件逐个决策：替换掉、隔离用（独立进程 + 接口交互，不链接）、还是接受开源义务。唯一不能选的是"先用了再说"。AGPL 组件在闭源 SaaS 里基本等于定时炸弹。

·第三条：把规则写进研发流程。引入新组件必须登记许可证；构建流水线加开源扫描工具自动出报告；每次发版前过一遍合规门禁。合规不是一次审计，而是一条持续的生产线。

四、被找上门了，处理顺序是这样

·第一步：核实指控与义务范围。对方主张的组件、版本、许可证是否属实，你方是分发还是仅服务，先定事实再谈方案。

·第二步：评估合规成本两条路：补齐义务（开源相应代码、补版权声明）或替换组件。多数权利方第一步要的是合规而不是赔偿，拖延和装死才会升级成诉讼。

·第三步：客户尽调场景主动披露。安全问卷里如实列明开源组件与许可证，附上 SBOM——主动透明的供应商，反而比藏着掖着的更容易过大客户审核。

五、选型时的三个习惯

·先看许可证再下载：组件好用不好用其次，许可证对不对路是第一问。

·区分"自用"与"随产品分发"：内部工具用强传染组件风险可控，进产品分发就是另一回事，两套标准分开管。

·警惕"复制粘贴"来的代码：Stack Overflow、博客片段、AI 生成的代码同样可能有来源问题，大段引入前要溯源。

写在最后

开源的世界里，免费的是代码，不免费的是义务。许可证就是作者开出的使用条款，GPL 的"传染"不是恶意，而是一种明确写进协议的对价。用之前读懂它、用的时候记录它、发版之前检查它——三步做完，开源是加速器；跳过任何一步，它都可能变成把整个系统掀开给人看的扳机。

👉 在公众号后台回复「开源合规」，获取开源许可证识别与软件物料清单建立指引。

CHENXING GLOBAL

全球设立，合规经营｜Build Globally. Operate Compliantly.

免责声明：本文为一般性信息分享，不构成针对任何具体情形的税务、法律或审计意见。各国及地区的政策、申报要求、费用标准与办理时效可能发生调整，实际操作应以当地现行法规、主管部门要求及专业机构核实结果为准。