本文目录导读：
这是一个非常经典且常被误解的问题,GPL（GNU通用公共许可证）的“传染性”是指其 Copyleft（版权左派） 特性：如果你使用了GPL许可的代码，你的衍生作品也必须采用GPL许可。
下面是关于GPL传染性的详细、分层解释，帮助你理解其边界和具体规则。
核心原则：什么是“传染”？
GPL的传染性并非法律术语,而是一个形象的比喻，它指的是GPL许可条款会强制“向下游传播”。
- 触发条件： 你的程序包含了GPL代码（无论是全部复制、修改还是静态链接）。
- 传染后果： 你的整个程序必须作为一个整体，以GPL许可发布，这意味着你必须：
- 公开你修改后的全部源代码。
- 允许任何用户以GPL许可条款再分发你的程序。
- 你不能再附加任何限制（例如增加专利条款或额外收费要求）。
“传染”的边界：关键区分点
GPL的传染性并非无限,主要取决于你的代码与GPL代码的交互方式，这里有三个关键区分：
链接方式（Linkage）：这是最关键的区别
-
静态链接 (Static Linking)：
- 传染：是。 你的代码和GPL代码在编译时合并成一个独立的二进制文件，两者密不可分，这个整体必须全部使用GPL许可。
- 例子： 你写了一个工具
myapp，它静态链接了GPL的数学库libmath-gpl.a。myapp必须开源并采用GPL。
-
动态链接 (Dynamic Linking)：
- 传染：争议核心，通常认为“是”。
- GPL官方（FSF，自由软件基金会）立场：动态链接创建的衍生作品，同样受传染，因为程序运行时依赖GPL库，因此整体也是衍生作品。
- 现实情况（尤其在企业界）： 许多商业公司认为，如果只是通过标准系统接口动态调用GPL库，且你的程序本身独立，可能构成“聚合体”（Aggregate）而非衍生作品，但这种做法存在法律风险，大多数公司会避免。
- 例外： LGPL（GNU宽通用公共许可证） 就是为了解决这个问题而设计的。LGPL明确允许动态链接而不传染，你可以用LGPL库，你的主程序可以闭源。
-
通过网络通信（如API调用、SOAP/REST）：
- 传染：否。 程序A通过网络（例如HTTP请求）调用程序B的API，它们运行在独立的进程中，只是交换数据，不构成“单行作品”，你的A程序无需开源，B程序依然是GPL。
- 这是AGPL设计的初衷： 为了防止云服务商利用这个“漏洞”修改代码但不公开（即“云服务黑洞”），AGPL（Affero GPL）规定：即使用户只是通过网络使用修改后的AGPL软件，你也必须提供完整的源代码，这是“传染性”的升级版。
是否为“聚合体”（Aggregate）
GPL允许你将一个GPL作品和一个独立作品“单纯地聚集”在一起，
- 在同一个发行版CD/DVD中，既有你的GPL程序，也有你的商业软件。
- 在同一个系统镜像中,GPL的Linux内核与你的闭源驱动程序共存。
关键： 这两个作品之间没有“紧密集成”，它们只是被放在了一起，但没有在函数/库层面链接或调用，你的闭源软件可以独立运行，无需GPL代码。
非衍生使用（Mere Aggregation）
- 如果你是最终用户，只是在自己的计算机上运行一个GPL软件，这没有任何问题。
- 如果你整体使用一个GPL软件（不修改、不链接、不嵌入），例如使用GPL的MySQL数据库，你的应用程序通过SQL查询数据库，这通常被视为正常使用，你的应用程序不一定是衍生作品，但细节需谨慎，尤其是驱动和插件。
一个重要的例外：GPL的三种常见版本
| 特性 | GPLv2 | GPLv3 | LGPL |
|---|---|---|---|
| 传染性强度 | 强，但有“聚合”例外 | 更强，增加了专利授权条款 | 弱，专为库设计 |
| 允许闭源链接 | 否（除非获得例外） | 否（除非获得例外） | 是（动态链接） |
| 主要用途 | Linux内核、Git | 大多数新的GPL项目 | Qt框架、glibc、许多通用库 |
如果你的目标是： 使用第三方库但保持自己代码闭源，请优先选择LGPL、MIT、Apache 2.0、BSD等宽松许可证的库，GPL库是你的最后选择。
如何避免“被传染”
| 你的情况 | 建议 | |
|---|---|---|
| 你只是使用了GPL的“思想”（没有复制代码） | 安全 | 可以自由使用，无需开源 |
| 你复制了少量GPL代码（例如一个函数） | 传染 | 你的整个项目必须开源 |
| 你修改了GPL代码 | 传染 | 你必须开源修改后的版本 |
| 你的代码静态链接了GPL库 | 传染 | 不可能闭源 |
| 你的代码动态链接了GPL库 | 非常大风险 | 严格遵循FSF立场：传染，实践中很多官司因此产生。 |
| 你的代码动态链接了LGPL库 | 安全 | 可以闭源，但需要满足LGPL的特定要求（如提供库的源代码、允许反向工程） |
| 你的程序通过网络API调用GPL程序 | 通常安全 | 但AGPL会覆盖这种情况 |
| 你使用了GPL的作品，但没有修改或分发 | 安全 | 自由使用 |
最实用的建议
- 如果你不想开源： 永远不要直接使用GPL或AGPL代码，也不要链接它们，选择MIT、Apache 2.0、BSD、LGPL等许可证。
- 如果你愿意开源： 使用GPL是优秀的选择，可以确保你的修改回馈社区。
- 多库项目： 如果你的软件链接了多个开源库，务必检查每个库的许可证，你不能将一个GPL库和一个闭源库静态链接在一起。
- 法律咨询： 以上为通用解释，不构成法律意见，在企业项目中，涉及GPL的使用，务必咨询专业的知识产权律师。
一句话总结：GPL的传染性旨在保护自由，要求你的衍生作品也必须开放，如果你不想开放，就别碰它。
