适用场景
所有在软件开发、产品研发或技术服务中使用了开源软件（尤其是GPL、LGPL、AGPL许可证软件）的中国出海企业，特别是在产品分发或商业化部署阶段。
核心要点
1. GPL许可证的“传染性”是核心风险
GPL类许可证具有“强传染性”，如果你的软件作品衍生自或包含了GPL开源代码，在分发时整个作品都可能被要求采用相同的GPL许可证开源。这包括GPL的纵向传染（对修改版本）和横向传染（对包含其代码的作品）。
2. 违反许可证将导致授权终止并构成侵权
GPL许可证被视为具有法律约束力的著作权许可合同。一旦违反其使用条件（如未开源），授权自动终止，后续的复制、修改、分发行为即构成著作权侵权，面临诉讼、高额赔偿及产品下架风险。
3. “分发”行为是触发开源义务的关键
GPL/LGPL的传染性通常在“分发”时触发。将软件提供给外部用户下载、安装或私有化部署都构成分发。而内部自用、SaaS服务（对GPL/LGPL而言）通常不触发。但需注意AGPL对SaaS服务的特殊开源要求。
4. 可通过技术手段隔离风险
企业可以通过技术架构设计来规避传染。对于GPL软件，可采用进程隔离、通过管道/套接字通信等方式确保独立。对于LGPL库，优先采用动态链接而非静态链接，并确保接口兼容，以满足其宽松条件。
5. 开源合规需法律与技术协同
有效管理开源风险需要建立跨部门协作机制。技术团队需明确所用组件的许可证版本及关系，法务团队需评估法律风险，共同制定合规使用策略和代码审查流程。
实务建议
- 建立开源软件使用清单：对所有项目中使用的开源组件进行登记，明确其名称、版本、许可证类型及版本号。
- 进行“分发”场景评估：在计划对外发布软件产品、提供下载或进行私有化部署前，必须评估是否触发了GPL类许可证的开源义务。
- 优先采用动态链接使用LGPL库：如果必须使用LGPL许可证的库，应通过动态链接方式调用，并确保你的程序与库的接口兼容，以便用户替换修改后的库。
- 对GPL代码进行进程级隔离：若需集成GPL功能模块，应将其设计为独立的进程，通过管道、套接字或命令行参数进行通信，避免代码编译链接到同一可执行文件中。
- 履行全部许可证义务：如果确定需要开源，必须严格按照许可证要求提供完整、对应的源代码，并保留原始著作权声明、修改说明及许可证文本。
- 在采购或并购中开展开源尽职调查：评估第三方软件或收购标的中的开源代码使用情况，识别潜在的“传染”风险与合规负债。
风险提示
- 误区：认为内部使用或SaaS服务绝对安全。警告：AGPL许可证明确要求即便通过SaaS提供服务，若修改了代码也必须开源。
- 误区：混淆不同版本的GPL许可证。警告：GPL v2、v3、LGPL等版本独立共存，权利义务不同，必须确认具体使用的版本。
- 误区：认为少量使用或修改就不受约束。警告：只要你的作品“衍生自”或“包含”GPL代码，无论比例大小，都可能被整体传染。
- 注意事项：开源组件可能嵌套依赖其他许可证。需追溯整个依赖链的许可证，检查是否存在不兼容的许可证组合。
- 注意事项：新《著作权法》大幅提高了侵权赔偿上限并引入惩罚性赔偿，故意侵权成本极高，不可抱有侥幸心理。