本文目录导读：
开源项目的聚合作品（Aggregate）与衍生作品（Derivative Work）的核心区别在于是否包含对原开源代码的修改或与之形成逻辑上的统一整体，以及各部分之间的耦合程度。
聚合作品是“捆绑在一起”，而衍生作品是“改写或融入”。
以下是详细的区分,主要依据GPL等强Copyleft许可证的法律精神（这也是实践中争议最多的地方）：
核心定义
-
聚合作品（Aggregate）：
- 指将多个独立的、本已存在的程序（或作品）通过物理或媒介方式（如CD-ROM、安装包、一个磁盘镜像）打包在一起。
- 每个组成部分都是独立且完整的程序,它们没有相互修改，也没有在逻辑上形成一个更大的单一程序。
- 关键： 各部分之间的通信是松耦合的（例如通过命令行参数、网络协议、数据库、管道等标准接口）。
-
衍生作品（Derivative Work）：
- 指基于原开源作品进行修改、改编、翻译、扩展或将其作为新作品的核心库。
- 衍生作品在逻辑上依赖于原作品才能运行，或者原代码被直接复制、修改后嵌入到新作品中。
- 关键： 各部分之间存在紧耦合（例如函数调用、共享内存空间、链接为同一可执行文件）。
详细对比与判断标准
| 对比维度 | 聚合作品 | 衍生作品 |
|---|---|---|
| 代码修改 | 不修改原开源代码的内部逻辑和结构。 | 直接修改原代码，或将其作为库调用、继承其类、链接其对象文件。 |
| 通信方式 | 通过进程间通信（IPC）、管道、SOCKET、命令行参数、配置文件等非内部方式交互。 | 通过函数调用、类继承、链接（静态/动态）、头文件引用、全局变量共享等内部机制交互。 |
| 作品形态 | 两个独立的程序（如：WordPress网站 + 一个独立的GPL图片处理命令行工具）。 | 一个统一的程序（如：一个使用了GPL库代码的App）。 |
| 许可证传染性 | 通常不传染，各部分可以保持各自的许可证（一个MIT项目和一个GPL项目打包在一起，GPL不会感染MIT部分）。 | 会传染，如果原作品是GPL，衍生作品通常必须整体采用GPL许可证（或兼容许可证）公开源码。 |
| 典型例子 | 一个Linux发行版（内核是GPL，但里面的浏览器、游戏、办公软件可以是MIT、Apache、闭源）——只要它们是通过文件系统、网络调用交互。 | 一个使用了GPL的解析库（如readline）的软件，通过静态或动态链接调用了它；或者一个修改了原有GPL代码的项目。 |
容易混淆的“边界情况”
实际判断中,最常引起法律争议的是动态链接（Dynamic Linking）和插件/模块架构：
-
动态链接（有争议）：
- 主流观点（尤其针对GPL v2）： 如果你的程序动态链接到了一个GPL的库（如
libreadline），并且在运行时调用其函数，这通常被视为衍生作品，因为你的程序在逻辑上依赖GPL库才能完成功能，FSF（自由软件基金会）认为这要求你的程序也要开源。 - 例外（LGPL库）： LGPL许可证明确允许商业程序通过动态链接使用它，而无需开源主程序（但修改LGPL库本身需要开源）。
- 反例（系统调用）： 如果你用
fork()调用了一个GPL程序（比如gzip），那是聚合作品，不传染。
- 主流观点（尤其针对GPL v2）： 如果你的程序动态链接到了一个GPL的库（如
-
插件/模块：
- 如果主程序通过标准接口（如
dlopen加载，通过纯C结构体交互）加载一个独立编译的插件，且插件没有修改主程序核心，可能被视为聚合作品。 - 关键判断点： 插件是否调用了主程序内部的核心数据结构或私有函数？如果插件完全独立，只是通过API/ABI通信，更像聚合；如果插件深度依赖主程序内部实现，则更像衍生。
- 如果主程序通过标准接口（如
为什么要区分？
这直接决定了许可证义务：
- 如果是聚合作品： 你可以在不违反许可证的前提下，将GPL软件与闭源/其他许可证软件打包分发。
- 如果是衍生作品： 如果原项目是GPL，你的新项目必须也作为GPL发布（即“Copyleft”），且必须提供完整源代码，这是企业最担心的“传染性”来源。
一个简单的自测问题
“把项目A和项目B分开后，他们还能独立完成各自的核心功能吗？”
- 如果可以（比如去掉A，B还能当独立软件用），且他们的交互方式简单（命令行/网络），极端偏向聚合作品。
- 如果不行（比如去掉A，B就崩溃或无法实现核心功能），并且B是直接调用了A的内部逻辑（函数/类/链接），那就是衍生作品。
最稳妥的做法： 如果你的项目引入了一个GPL/AGPL的依赖，并且不是通过“纯粹的”进程间通信，它大概率会被法院或社区视为衍生作品，建议咨询法律专业人士，或选择许可证更宽松的替代库（MIT、Apache、BSD）。
