用了开源代码被要求开源 企业开源许可合规自查要点

先搞清楚你用的到底是哪种许可证

常见场景：技术团队从代码托管平台拉了一个组件，看能跑通就合进产品，仓库里既没有 LICENSE 文件备份，也没人记录版本号。等到客户做尽调、或者被权利人发函，才发现这个组件是带传染性条款的许可证。

实操上，第一步是做组件清单：名称、版本、来源地址、许可证名称、引入时间、使用方式（直接调用、修改后嵌入、仅内部工具）。许可证要以组件仓库中的 LICENSE 原文为准，不能只看项目首页的简介，同一项目不同版本可能换过许可证。遇到双许可（如社区版与商业版并存）要单独标注，因为它往往决定你能否闭源分发。

常见退回原因：清单只写组件名不写版本，导致无法回溯；把 LGPL 与 GPL 混为一谈；把“开源”当成“免费可随意用”。这几类问题在尽调或客户合规问询中通常会被直接打回。

传染性判断：分发方式决定义务边界

多数 copyleft 许可证的义务触发点是“分发”，而不是“使用”。仅在公司内部部署、不向外部提供软件副本的场景，与把软件交给客户安装、通过镜像交付、随硬件出货，义务差别很大。SaaS 模式是否构成分发，实践中存在不同理解，涉及 AGPL 等许可证时风险更高，需要按具体许可证文本逐条比对。

判断动作可以分三步：先确认产品交付形态（本地安装、容器镜像、云服务、SDK 嵌入）；再确认该组件与自有代码的结合方式（独立进程调用、动态链接、静态链接、源码级修改合并）；最后对照许可证条款看是否要求披露对应源码。静态链接和源码修改通常是最容易触发义务的两种方式，建议在架构评审阶段就标记出来。

许可证兼容性与替换动作

不同许可证之间存在兼容性问题：把 Apache-2.0 组件并入 GPL 项目一般可行，反向操作则可能产生冲突。企业自研产品若同时引入多个许可证，需要做一次兼容性矩阵核对，重点看专利授权条款、附加限制条款与免责条款是否互相打架。

发现不兼容或许可证过严时，可执行的替换动作包括：寻找功能相近、许可证更宽松的替代组件；改为独立进程调用以降低结合程度；向权利人购买商业许可；将该组件从交付物中剥离，仅保留在内部工具链。替换后要同步更新组件清单与版本锁定文件。

审计留痕与对外答复口径

建议把开源合规嵌入现有研发流程：代码合并前做许可证扫描，发布前做一次全量清单复核，采购或引入第三方代码时要求供方提供组件清单。扫描工具的误报率不低，人工复核环节不能省，尤其是被扫描标记为“未知许可证”的组件，要回到原文确认。

收到权利人问询或客户尽调问卷时，答复口径应基于清单事实：用了什么、什么版本、什么许可证、如何结合、是否分发、采取了哪些义务履行措施。不要在没有核对的情况下口头承诺“我们没用开源”或“全部合规”，这类表述后续很难收回。涉及是否公开源码、是否支付商业许可费用的决策，建议由法务与技术负责人共同确认后再对外回复。官方收费与登记要求以官方最新公告为准。

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