学以致用 | 谁是开源软件侵权案件的适格原告

一、案例编号

（2021）最高法知民终2063号

标准条款

《企业知识产权管理规范（GB/T 29490—2013）》

7.5　合同管理

a) 应对合同中有关知识产权条款进行审查，并形成记录。

8.1　立项

c) 进行知识产权风险评估，并将评估结果、防范预案作为项目立项与整体预算的依据。

本期导读

开源软件对促进软件产业快速发展与创新发挥着重要作用。开源软件的授权人通常需要遵循某种开源许可证协议，将其源代码向公众公开，并允许用户在许可证约定的条件下自由使用、修改和分发。也即开源软件的授权人将其享有的著作财产权和部分人格权授予用户。那么，如果具有多名贡献者的开源软件遇到了侵权，谁，以及在什么条件下才能成为适格的维权人呢？今天的案例或许能带给您有益的启发。（本案件是基于GPL3.0协议的判决，其他案件是否适用仍需研究具体的协议内容）

二、判决书原文要点

背景信息

甲公司开发了涉案软件，并在软件托管平台GitHub上公开了涉案软件的源代码（甲公司成为涉案软件项目管理者），同时在该平台上申明，任何人如需将涉案软件用于商业用途，需向甲公司购买商业授权。之后，又有34名贡献者在GitHub上对涉案软件源代码进行了修改。

GitHub网站约定，项目管理者可以在该网站上传其独立编写的软件项目初始源代码，并创建主分支master，其他用户可以基于主分支创建其自己的分支并自行修改维护。其他用户可以基于其创建的分支提起“创建拉取请求”，即申请将其分支中的修改合并入主分支中，项目管理者决定是否同意其他用户的“创建拉取请求”，若同意则将该分支合并入主分支中，该用户成为主分支的贡献者。

乙公司系被诉侵权软件的著作权人。被诉侵权软件的源代码与涉案软件源代码的421个可比代码文件中有308个代码文件具有实质相似性，有27个代码文件具有高度相似性，有78个代码文件具有一般相似性。

二审中，乙公司认为甲公司没有提供任何证据证明这34个贡献者都将著作权转让给其行使，也没有提供任何证据证明其他开源代码的作者将著作权转让给其行使。因此，原审判决认为甲公司是涉案软件的著作权人，且无需其他贡献者同意或授权，属于法律适用错误。

三、判决书（节选）要点：

本案中，共计34名贡献者对涉案源代码作出了修改，对于这部分贡献者的行为是否可以认定成为与项目管理者的合作创作行为，需从以下几个角度分析：第一，项目管理者是否与贡献者存在创作的合意；第二，项目管理者与贡献者是否存在共同创作的行为；第三，贡献者对软件作品本身起的作用是否具有实质性，换言之，贡献者的创作部分是否具有独创性；第四，将软件认定为合作作品是否具有法律和经济效率上的合理性。

计算机软件在发布与开源之时已体现出创作者完整的创作意图，贡献者针对开源软件提交代码的流程是：由贡献者发起拉取申请，经项目管理者同意后并入主分支中。这一过程反映了软件源代码开源的本意，即通过互联网媒介，集合全球开发者的智慧，尽可能使软件最优化，从而促进知识的传播。这一目的是开源软件作者、贡献者与使用者的前提共识，贡献者对开源软件的修改只是为了这一目的更好地实现，并不能就此认为开源软件的贡献者与作者具有创作的合意，亦不能认为贡献者针对开源软件提出修改意见的行为是共同创作行为。本案中项目管理者甲公司对“主分支”中涉案软件源代码的形成起到了决定性作用，贡献者提交的内容是否对涉案软件产生实质性影响尚不明确，根据在案证据难以得出贡献者系涉案软件合作作者的结论。

退一步而言，即便贡献者对作品的创作产生实质影响，即贡献者创作的代码具备独创性、可以单独使用、享有独立的软件著作权，基于GPL3.0协议，项目管理人与贡献者之间也可以存在相互许可的关系，项目管理人也可以成为被许可人，据此项目管理人对此类代码享有普通许可使用权。同时，对于开源软件而言，往往难以界定全部著作权人，只要该项目保持开源，则贡献者数量会持续动态增加，这意味着开源程序始终处于动态的未完成状态，而这将对权利人范围的确定造成极大的阻碍，若要求必须经过所有贡献者的授权才能提起诉讼，将导致开源软件维权无从谈起。基于GPL3.0协议，根据开源软件项目管理人的上传开源代码并创建主分支，贡献者针对开源软件提交代码的发起拉取申请并经项目管理者同意后并入主分支等一系列约定内容及行为表现来看，贡献者针对开源软件提交代码并发起拉取申请应视为其默示同意作为普通被许可人的项目管理人提起侵权之诉，针对有关的被诉侵权行为可以一并认定并判赔。贡献者乃至在先代码著作权人若对涉案软件的著作权归属或权益分配存在争议，可另行向项目管理人主张。综上，本院认为甲公司作为提交了涉案软件绝大部分源代码的项目管理人，其提起本案诉讼无需经过其他贡献者的授权。

关于本案权利人在起诉前是否存在必须履行的前置程序。根据GPL3.0协议第8条（此处省略协议内容，感兴趣的读者朋友可自行查看）但是，就此认为权利人行使诉权之前必须履行“前置程序”是一种误读。权利人有自由选择争议解决方式的权利，协议第8条仅明确了权利人选择发出通知这一方式会导致授权效力的何种变化，但其中涉及的“通知-改正”程序并不构成解决争议的必要条件。因此，本案权利人在起诉前并不存在必须履行的前置程序。

另外，乙公司认为根据GPL3.0协议第10条“你也不可以发起诉讼”的约定，甲公司不享有诉讼的权利，对此本院认为，GPL3.0协议第10条“你也不可以发起诉讼”的表述所针对的是专利权，而本案系计算机软件著作权纠纷，乙公司引用此条款认为甲公司不享有起诉的权利，系对GPL3.0协议的误读。

综上所述，基于GPL3.0协议的约定，软件开源并不会当然产生项目管理人与贡献者推定为合作作者的效力。本案中甲公司作为涉案软件著作权人，有权提起本案诉讼，无需贡献者的同意或授权。