案例研究｜案例库：开源项目管理者是否需要全部贡献者同意才能起诉

快速结论

项目管理者的诉权应结合对代码形成的作用与贡献许可关系判断，不宜机械要求取得动态增加的全部贡献者逐一授权。

案件事实与法院理由

涉案权利软件为使用GPL3.0协议的开源软件。某网络公司是该软件登记的著作权人，在GitHub上公开源代码，并声明任何人将软件用于商业用途需向其购买商业授权；该项目的项目管理人负责主分支的形成，显名贡献者有34人。GitHub用户对源代码作出修改、补充后，若要将相关内容并入项目管理人的主分支，需符合其开发意图并由其作出取舍，成功并入的用户成为该项目的贡献者。某网络公司主张两科技公司在被诉侵权软件中大量使用与其权利软件相同或者实质相似的源代码，且未履行开源义务，请求判令停止侵害并赔偿经济损失2000万元及维权合理开支50万元。一审法院判令两科技公司停止侵权并赔偿共计50万元；最高人民法院二审认可某网络公司的原告资格，判决驳回上诉，维持原判。

审判规则总结（本站归纳）

项目管理者的诉权应结合对代码形成的作用与贡献许可关系判断，不宜机械要求取得动态增加的全部贡献者逐一授权。开源软件的项目管理者对软件源代码的形成一般具有决定性作用，贡献者主动参与该开源项目应视为其默示同意项目管理者提起侵权之诉，项目管理者一般无需经过其他贡献者授权，即可以自身名义起诉维权。即便贡献者对软件产生实质性影响、对其修改补充的代码享有著作权，基于GPL3.0协议，项目管理人与贡献者之间也存在相互许可关系，项目管理者对此类代码至少享有普通许可使用权。此类案件依据在案证据往往难以界定全部著作权人，开源程序持续处于动态变化之中，若要求必须经过所有贡献者授权才能起诉，可能导致开源软件维权无从谈起；贡献者乃至在先代码著作权人对权属或权益分配有争议的，可另行向项目管理者主张。

笔者分析与办理要点

开源项目管理与版权归属不能只按仓库管理员权限判断。管理者需要说明自己贡献了什么、怎样控制主分支形成、贡献者如何提交以及适用何种许可。仓库名称、提交记录、审核讨论和项目规则，可以共同帮助还原真实关系。只有一个管理员账号，不自动说明其拥有所有代码的版权。

准备起诉时，宜确定被复制版本及其中的来源结构。项目持续变化，最新版可能与侵权发生时版本不同，应保留对应标签、提交历史和许可证。若主张第三方贡献也包含在受保护范围内，应解释许可关系及项目规则，不能把可公开下载与可无条件侵权复制混为一谈。

贡献者的参与方式也应规范。项目可以提前说明贡献许可、版权声明、审核合并和权益争议处理，减少后来无法识别授权范围的情况。这样的规则不仅利于维权，也有助于接受企业用户尽调。要求贡献者确认有权提交代码，不能替代管理者对明显第三方素材的合理审查。

被诉方质疑原告资格，应指出具体代码及权属问题，而不是只说开源作者人数多。即使部分贡献存在争议，也需分析对当前侵权请求的影响。使用者还应核查自己是否履行了许可条件，不能一边依赖开源授权，一边否定所有提供和管理该授权的主体。

本案对开源生态的意义，是在真实项目结构中找到能够行使权利的主体，同时保留贡献者另行主张内部权益的空间。软件企业采用双重许可、商业授权或社区开发模式时，都应将代码来源、管理关系和授权方式写得清楚，以减少诉权、合规和收入分配三类问题相互混杂。

适用要点

案中“商业用途需购买授权”是特定项目的声明，不能据此概括GPL本身禁止商业使用。GPLv3允许按其条件运行、传播和修改，商业分发仍须履行相应义务；双重许可的选择、额外限制的效力以及其他贡献者代码能否另行商业授权，要分别核实。本案支持侵权请求的重要前提还包括：被诉软件复制了实质相似代码且未履行本应履行的开源义务，而不是仅因营利即侵权。许可证原文、FSF关于商业使用限制的说明。

本案并非宣布所有项目管理者当然拥有全体贡献者版权。具体项目的贡献程度、许可约定和合作关系不同，需个案核对。

公开来源

来源为最高人民法院知识产权法庭 2026-01-02 发布的入库案例（人民法院案例库入库编号2024-13-2-158-002）。法院或主管机关公开材料。检索核对日期：2026-10-11。事实依据取自该来源公开内容，实务建议为本站分析。