【引言】开源是一种分布式协作模式，通过对软件源代码的开放，参与者可以使用、修改、再发布，进而共享创新成果。如今，利用开源代码编写软件已成为软件研发的主流模式，然而“天下没有免费的午餐”，这种便利同样也受到开源软件所采用的开源规则的限制，譬如商业使用限制、署名要求、专利保留要求、新增代码开源要求等等。作为开发者，如果你打算开源自己的代码，务必要选择一种开源许可证；作为使用者，也应当了解相应许可证的权利与义务要求，合规创新以避免侵犯他人权利被诉诸赔偿。

GPL V2规定了关于作品聚合（aggregation）不受传染的例外——仅仅将另一个不是基于本开源程序的作品，与本开源软件（包括派生作品）聚合在一起，并不会导致其他作品受到GPL V2的约束。

GPL V3延续了这一例外规定。并进一步明确了聚合的概念，它是指开源程序和其他独立程序的特殊组合，这一组合仅仅是为生成更大的程序，而非该开源程序的扩展，也非为在某个媒介上与开源程序结合（compilation），并且这一组合对使用者的访问限制不超过独立作品对使用者进行访问等合法权利的限制。

根据GNU发布的FAQ，“聚合”包含有多个独立的程序，并在同一个CD-ROM或其他媒介上发行。区分的合理标准既依赖于通信的机制（，pipes，rpc，共享地址空间的函数调用等），也依赖于通信的语义（交换了什么样的信息）。GPL V3允许开发者制作并发布一个聚合体，即使其中其他软件的许可证不是开源许可或与GPL不兼容亦可，除非聚合体的许可证禁止用户行使每个独立程序的许可证允许的权利。

不过，到底如何在复杂的现实情况下，界定“聚合”和“衍生”，GNU也指出“具体判断的工作则应交由法官决定”。

在我国的司法实践中，已出现了一起有关“聚合软件”认定的案例——柚子（北京）移动技术有限公司等与数字天堂（北京）网络技术有限公司侵害计算机软件著作权纠纷上诉案。该案中，涉案HBuilder软件有边改边看等三个插件，均处于独立的文件夹中且文件夹中并无GPL开源协议文件，权利人针对三个插件分别进行了著作权登记。

一审北京知识产权法院认为：涉案三个插件并不属于GPL协议所指应被开源的衍生产品或修订版本，该协议对涉案三个插件无拘束力。二审北京高院虽未直接认定HBuilder软件属于“聚合体软件”，但认可了数字天堂公司关于“HBuilder软件系包含Eclipse平台框架、Aptana插件、数字天堂公司为Eclipse开发的插件以及其他第三方公司为Eclipse开发的插件为一体的聚合体软件包”的诉讼意见。根据本案判决，笔者试归纳如下司法裁判观点：

第一，功能插件以独立文件夹形式存在于软件压缩包内，根目录及功能插件文件夹内均不存在GPL许可证的，GPL协议对插件无拘束力；

第二，插件是否能够独立运行，不影响“聚合体软件”的认定；

第三，插件是否单独进行了软件著作权登记，可以在“聚合体软件”认定中综合考虑。