Apache 2.0 项目发现 GPLv2 组件：先确认版本，再判断组合与分发

计划采用Apache 2.0发布项目，却发现其中存在GPLv2代码，第一步应当还原具体许可和工程关系。把仓库顶层LICENSE改成Apache 2.0，并不能改变第三方代码已有的授权条件。

先区分 GPLv2 的两种授权表述

应查看实际文件和发行包中的声明，确认是仅限GPLv2，还是允许采用该版本或后续版本。Apache官方说明：Apache 2.0与GPLv2不兼容，但Apache代码可以进入按GPLv3分发的组合作品。若相关代码确实允许选择后续版本，可进一步评估GPLv3路径；这不意味着能够将GPL代码重新标成Apache 2.0。Apache兼容说明

再判断代码如何进入产品

GPLv2区分基于程序的作品与独立作品的简单聚合。因此，“同一个代码仓库”或“同一份安装包”本身都不足以决定整个项目的许可。要结合代码复制、修改、链接、运行依赖和分发方式分析。GPLv2第2节

仅作为独立构建工具使用，与把其实现代码编入最终程序，是不同的事实。即使属于独立聚合，被分发的GPL组件本身仍要履行相应义务。工具生成物是否包含受许可代码，也需单独检查。

IPC 不是自动豁免开关

拆成两个进程有助于描述边界，但法律判断还会涉及通信内容和模块之间的关系。不能把socket、RPC或容器视为无条件隔离方案。GNU官方FAQ同样强调，机制与通信语义都影响分析。GNU GPLv2 FAQ

发布前可以怎样处理

团队可建立一张清单，记录每个相关组件的版本、许可、修改内容、链接方式和最终交付位置，再根据审查结果选择路径：

• 保留真正独立的组件，并分别提供许可、版权和所需源码材料。
• 在相关权利确实允许时，调整组合作品的发布许可。
• 获得权利方提供的额外授权，确认其范围覆盖实际用途。
• 替换组件或重写相关功能，并验证新实现及其依赖。

选择方案后，还要更新文件声明、NOTICE、源码提供方式和构建材料；不能把“替换完成”当作全部审查结束。兼容性检查工具可以筛出冲突线索，组合关系和授权范围仍需要研发与法务共同确认。