计算机软件著作权侵权案件中的常见开源抗辩（一） ——“项目管理者”与“贡献者”的原告主体资格与权利范围-立方律师事务所

作者：张斌、李纯、张畅然、付瑾瑜

近年来，随着开源软件在商业软件开发中的广泛应用，以原告主体资格和权利范围为中心的开源抗辩逐渐出现在计算机软件著作权侵权案件中。与传统软件主要由单一主体独立开发的情形不同，开源项目通常由项目发起人发布初始版本，并由其他开发者通过提交代码、修复漏洞、增加功能模块等方式持续参与迭代。项目发起人、项目管理者、代码贡献者与软件著作权人可能相互重合，也可能分别由不同主体担任，由此增加了权利归属及诉讼主体认定的复杂性。

基于此，本文将以GitHub为例说明开源项目的协作流程以及CLA、CAA、DCO等贡献权利确认机制，分析项目管理者的初步权属证明及多贡献者参与对其权利范围的影响，以期为计算机软件著作权侵权案件中相关开源抗辩的提出及应对提供较为清晰的分析路径。

一、GitHub协作流程与“贡献者”

在讨论开源软件的权利归属及诉讼主体资格之前，有必要先理解开源项目的基本协作机制。GitHub是目前开源项目最常用的托管与协作平台之一，本文拟以GitHub为例，梳理开源项目的典型协作流程，并以此作为后续分析权利归属等法律问题的基础。

（一）GitHub协作流程

开源项目在GitHub上通常以“仓库”（repository）的形式由项目发起人（一般后续会转化为项目管理者）[1]公开发布，仓库中显示项目源代码、说明文档、许可证文件、围绕该项目产生的讨论、问题反馈等文件及记录[2]。

图1 以DeepSeek为例的GitHub仓库示例图

GitHub上其他开发者如果希望对某个开源项目作出修改，最常见的开源协作方式是先fork，再通过pull request请求合并。

所谓fork，可以理解为“复制一份项目副本”，假设某开发者发现一个开源项目中存在bug，或者希望为该项目增加一个新功能，其可以使用“fork”功能，将原项目复制到自己的GitHub账户下。此时，原项目通常被称为“上游仓库”（upstream repository），开发者自己账户下的副本则是其fork出来的仓库。开发者可以在自己的fork中自由修改代码，而不会影响原项目的稳定性。[3]

图2 Fork仓库示例图

当开发者在自己的fork中完成修改后，形成修改commit[4]。如果希望上游仓库采纳这些修改，需要创建pull request。GitHub官方将pull request定义为将代码变更合并到项目中的提议，通俗的理解即为贡献者向项目维护者提出请求，希望维护者将其修改内容合并进原项目。项目维护者可以查看修改内容，也可以要求贡献者进一步修改，最终决定是否接受该pull request。[5]pull request被合并后，贡献者的修改才成为主分支的一部分。

图3 DeepSeek-V3开源项目项下的pull request列表

（二）开源项目中的“贡献者”

在GitHub上，“贡献者”通常是指以某种方式参与项目建设并留下可追踪记录的人。狭义上，最典型的贡献者是向仓库提交过代码、且相关commit被合并进项目仓库的人，这类人员通常会体现在项目的提交历史或“贡献者”列表中。广义上，提交pull request、参与讨论、进行代码复核、更新文档、提出bug修复或功能建议的人，也可能被GitHub在个人贡献记录或项目协作记录中视为“贡献者”。但需要注意，GitHub平台意义上的“贡献者”并不当然等同于著作权法上的作者或权利人，是否构成法律意义上的贡献，还需要结合其提交内容是否具有独创性、是否受项目许可证或贡献协议约束等因素进一步判断。本文中所讨论的主要是狭义的贡献者。

图4 GitHub平台贡献者列表示例

（三）贡献代码的权利确认机制：CLA、CAA与DCO

在GitHub等平台上，外部开发者向开源项目提交贡献后，项目维护者通常需要确认一个问题，贡献者是否有权提交该代码，以及项目是否有权按照既定开源许可证使用、分发并继续维护该贡献内容。为了解决这一问题，开源项目实践中形成了两类常见机制：一类是贡献者许可协议（Contributor License Agreement，简称CLA），部分包含知识产权转让的协议也被称为CAA（Contributor Assignment Agreement，简称CAA）；另一类是开发者原创声明或开发者来源证明（Developer Certificate of Origin，简称DCO）。

CLA是项目方与贡献者之间单独签署或确认的协议。核心作用是要求贡献者明确声明其有权向项目提交相关代码、文档或其他内容，并且同意将该等贡献按照约定条件许可给项目方使用。部分CLA还会进一步约定项目方是否有权复制、修改、分发、再许可贡献内容，是否可以将贡献内容纳入商业产品，是否可以在未来更换开源许可证，或者是否取得专利许可等。从法律效果看，CLA通常并不当然意味着著作权的转让，多数CLA的核心仅是使项目方取得一项使用许可，也有少数项目可能要求贡献者进行版权转让或更强程度的权利安排，但这需要看具体CLA文本，不能一概而论。典型包含诉权安排的CLA如Porsche CLA，其在“Right to Enforce Infringement Claims”条款中明确约定：若第三方违反许可条款使用贡献代码，项目方有权以自身名义，就贡献者对贡献代码享有的版权，向第三方主张停止侵害、信息披露、销毁侵权产品等救济权利。[6]

CAA是一类要求贡献者将其贡献的版权转让（Assign）给项目实体或组织的法律协议，这与仅授予使用许可的CLA有本质区别。较为典型的示例包括自由软件基金会（FSF）为其GNU项目（例如GCC）要求贡献者签署CAA。具体而言，贡献者需将其贡献内容的版权转让给FSF，FSF则承诺将这些作品以自由软件许可证（如GPL）分发，同时，FSF会回授给贡献者一个非独占、免版税的许可，允许其自由使用自己的贡献。[7]

DCO主要用于确认贡献者有权提交贡献内容。相较于CLA与CAA，DCO是一种更为轻量化的贡献确认机制，其最为常见的文本为Developer Certificate of Origin 1.1，由Linux Foundation发起[8]。其要求贡献者在每次提交commit时通过Signed-off-by语句确认其有权提交该贡献，DCO通常体现为commit中的一行声明信息，例如“Signed-off-by: Zhang San <zhangsan@example.com>”。GitHub上提供专门的DCO App，用于在Pull Request中强制检查所有commit是否包含Signed-off-by信息。[9]

因此，在开源项目中，贡献者并不会因将代码提交给项目而当然丧失其权利。在计算机软件著作权侵权案件中，若被告抗辩称涉案项目存在大量外部贡献者，且贡献者未签署版权转让协议情况下，原告并非全部代码的权利人，未经全体贡献者同意不得单独提起诉讼，理论上，则应进一步审查项目中的权利安排，CLA、CAA与DCO等贡献机制或协议应当成为判断原告权利基础及其诉讼主体资格的重要依据。

二、项目管理者起诉时的权利基础与请求范围

本文所称“项目发起人”，是指创建开源项目、发布初始版本或者组织初始开发工作的自然人、法人或者非法人组织；“项目管理者”，是指持续参与项目维护，并对仓库主分支、代码审查及贡献合并等事项具有实际管理权限的主体。二者可能重合，也可能分离。为便于讨论，本文所称“项目管理者”限于不仅承担项目治理职责，而且对涉案软件的初始版本、核心功能或者主要代码作出实质性创作贡献的主体。

在开源项目管理者提起侵权诉讼的案件中，被告通常会从是否有权利和权利范围两个层面，对原告的诉讼主体资格提出抗辩：其一，被告可能抗辩称涉案开源软件的知识产权并不归属于原告，原告不具备提起诉讼的权利基础；其二，被告可能抗辩称涉案开源软件系由众多社区开发者共同参与、持续迭代形成，其中包含大量外部贡献代码，原告并非全部代码的唯一著作权人，在未取得其他贡献者授权或者同意的情况下，无权就涉案软件整体主张权利。

（一）认定开源软件权属的初步证明

根据《中华人民共和国著作权法》第十二条的相关规定，在作品上署名的自然人、法人或者非法人组织为作者，且该作品上存在相应权利，但有相反证明的除外。在开源软件权属认定中，法院可能会依据计算机软件著作权登记证书、开源平台中的项目发起、发布及维护信息，软件开发、运营和商业化资料，以及相关账号、联系方式与原告之间的关联关系，对权利归属进行综合认定。

结合罗盒公司诉风灵公司案[10]进行说明，该案件中原告罗盒公司主张权利的开源项目VirtualApp在GitHub平台的发起人显示为Lody。法院结合国家版权局颁发的计算机软件著作权登记证书、罗盒（VirtualApp）引擎系统报价单、GitHub网站上显示VirtualApp由罗盒科技开发运营，项目联系方式的使用者与项目发起人Lody亦指向罗盒公司的法定代表人及股东等证据，认定罗盒公司系“罗盒（VirtualApp）V1.0”软件的著作权人。

图5 罗盒案所涉开源项目发起人

图6 罗盒案所涉开源项目“授权说明”

（二）开源项目中涉及贡献者时的诉权基础与权利边界

通常情况下，如果开源项目中只有项目管理者，开源软件权属及诉讼主体的认定比较简单。但是大多数情况下，项目管理者发布初始版本后，其他开发者可能通过提交代码、修复漏洞、增加功能模块等方式参与项目。因此，在涉及开源软件的著作权纠纷中，需要解决的问题不仅是项目管理者能否单独提起诉讼，还包括其对哪些代码享有权利、可以主张何种范围的救济，以及项目管理者与贡献者之间如何分配维权所得。

就项目管理者的诉讼资格而言，我国司法实践已经形成了具有开源治理特点的处理思路：开源项目中存在其他贡献者，并不当然意味着项目管理者必须取得全体贡献者的同意或者授权后才能提起诉讼。在项目管理者能够对涉案软件提供初步权属证明，而被告不能证明其他贡献者的加入足以否定该权利基础的情况下，法院可以认可项目管理者以自己的名义实施维权。

这一裁判思路回应了开源项目贡献者人数众多、身份分散且持续变动的现实困难，避免权利人因无法逐一联系贡献者而失去司法救济的可能。不过，“有权起诉”与“对全部代码享有著作权”并非同一问题。认可项目管理者的诉讼资格，并不意味着其他贡献者的著作权因此被否定，也不意味着项目管理者当然可以按照整个项目的价值获得全部赔偿。

因此，在承认项目管理者原则上可以单独维权的基础上，仍有必要进一步考虑项目文件对权属和诉权的安排、贡献内容是否具有独创性、项目是否构成合作作品、相关代码能否分割使用，以及被诉行为所使用的代码与原告实际享有权利的代码之间是否具有对应关系。在我国目前的司法实践下，上述因素通常不会被用于当然否定项目管理者的起诉资格，而可能会主要被用于确定其实体权利范围及停止侵害、损害赔偿等救济的具体尺度。

1. 项目管理者原则上可以单独提起诉讼

目前我国就项目管理者是否可以单独提起诉讼有两个较为典型的案例，分别为罗盒公司诉风灵公司案及罗盒公司诉玩友公司案。

在罗盒公司诉风灵公司案[11]中，该案中被告风灵公司认为VirtualApp系GitHub开源项目，存在多名贡献者，“作者”Lody仅仅为开发工作的召集者和开发者之一，有多少代码来自贡献者不得而知，罗盒公司没有提供任何证据证明贡献者都将著作权转让给其行使。法院最终未采纳该抗辩。法院结合GitHub协作规则认为，罗盒公司对主分支中涉案软件源代码的形成起到了决定性作用。虽然涉案项目有多名贡献者对源代码作出修改，但贡献者提交的内容是否对涉案软件产生实质性影响尚不明确，根据在案证据难以认定贡献者系涉案软件的合作作者。即便个别贡献者对作品创作产生实质影响，贡献者针对开源软件提交代码并发起pull request应视为其默示同意作为普通被许可人的项目管理者提起侵权之诉，针对有关的被诉侵权行为可以一并认定并判赔。法院特别强调，开源项目的贡献者处于持续变动之中，如果要求项目管理者必须取得全体贡献者授权才能起诉，将导致开源软件维权无从谈起。贡献者或在先代码权利人若对著作权归属或权益分配存在争议，可以另行向项目管理者主张。

图7 罗盒案所涉开源项目贡献者列表（本文撰写时的截图）[12]

罗盒公司诉玩友公司案[13]中，被告玩友公司认为原告主张权利的是开源项目VirtualApp的VirtualApp-master版本源代码，该开源项目参与编写源代码程序的人数多，项目人aslody仅为著作权人之一。该开源程序项目为不可分割使用的合作作品，根据著作权法相关规定，合作作品著作权的转让应当取得全部权利人的协商一致，同时应当提供书面的转让协议。法院认为，首先原告股东作为项目管理者将VirtualApp初始版本源代码上传至开源网站。贡献者是在此基础上不断升级优化，贡献者提交的代码能否并入涉案软件主分支由项目管理者决定，项目管理者提交的代码量占整个涉案软件代码量的绝大部分，因此其他贡献者提交的代码并未对涉案软件著作权产生实质影响。其次，项目管理者和贡献者存在共同创作的合意，但是，玩友公司并未举证证明贡献者提交的代码是否属于有独创性表达的创作，在案证据无法认定涉案软件属合作作品。再次，涉案VirtualApp适用了LGPLV3协议或GPLV3协议，贡献者在申请将其代码合并入主分支时默认同意将其代码开源贡献给项目管理者和其他用户在授权许可协议范围内自由使用。最后，即使涉案软件属合作作品，就在案证据难以查清所有权利人的基本情况下，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那么将导致开源软件维权无从提起。综上认定，罗盒公司作为提交了绝大部分代码量的项目管理者提起本案诉讼亦无需经过其他贡献者的授权，有权单独提起本案诉讼。

上述两案确立的并不是“项目管理者当然享有项目全部著作权”，而是一项面向开源协作特点的诉权认定原则。在项目管理者已经完成初始版本或者绝大部分代码、实际控制主分支，并能提供软件登记、署名、版本记录等初步权属证据的情况下，仅以项目中存在其他贡献者为由，通常不足以否定其诉讼资格。对于贡献代码是否具有独创性、是否构成合作作品等问题，则应由提出异议的一方提供相应证据。

由此，项目管理者的诉权问题可以分为两个层次。第一个层次是其能否启动司法救济，不宜因贡献者的存在设置过高的程序门槛。第二个层次是其能够就哪些代码获得救济。仍应根据权利来源、代码贡献和被诉使用行为进行具体判断。

2. 项目文件对权属及权利行使的安排

项目管理者能否提供明确的合同或者项目文件，是确定其权利范围的重要因素。实践中，应审查开源项目参与方是否通过CLA、CAA对著作权归属、权利许可及诉权行使作出事先安排。如果CLA、CAA明确约定贡献者将相关著作财产权转让给项目管理者，或者明确授权项目管理者以自己的名义就贡献代码实施维权，原则上应当尊重当事人的意思自治。在此情形下，项目管理者的权利基础相对明确，贡献者是否属于合作作者、相关代码能否分割使用等问题，对于诉讼资格的影响也会明显降低。鉴于CLA、CAA并无统一、固定的文本格式，项目管理者是否取得相关著作权，或是否有权以自己的名义单独提起诉讼，仍须结合具体条款逐项判断。

部分项目采用开发者原创声明，即DCO。与CLA、CAA相比，DCO通常侧重于确认贡献者有权提交相关代码，并同意按照项目适用的开源许可条款提供该项贡献。DCO可以作为判断代码来源的证据，但其一般不当然发生著作权转让或者独立诉讼授权的效果。是否可以依据DCO认定项目管理者取得相关权利，仍取决于具体文本及贡献者提交代码时的声明内容。

因此，CLA、CAA与DCO及其他项目文件的意义，主要在于明确项目内部的权属和行使权利的安排、降低项目管理者的举证成本，在我国的司法实践下，暂不能被当然解释为项目管理者取得诉权的必要条件。即使项目没有采用CLA、CAA或DCO，只要项目管理者能够通过署名、软件登记、代码提交历史、主分支管理记录等证据证明其权利基础，仍可能依法提起诉讼。

3. 贡献代码的属性及其对权利范围的影响

项目中出现贡献者，并不意味着每一名贡献者都当然成为涉案软件的著作权人。贡献者提交的代码、补丁或者修改内容是否构成著作权法意义上的作品，应当结合具体内容进行判断。

对于仅涉及简单错误修复、拼写调整、参数替换、机械性格式修改，或者受技术功能唯一限定的代码表达，通常较难认定其具有独创性。贡献者如果只是提出功能需求、设计思路、算法原理或者测试意见，而未形成具体表达，也不能仅凭上述行为取得软件著作权。审阅、测试或者决定是否合并他人提交的代码，原则上同样不等于直接参与代码创作。

但是，如果贡献者提交的内容达到一定代码规模，在功能实现、程序结构、模块设计或者表达方式上体现了个性化选择和安排，则不排除构成受著作权法保护的计算机软件作品或者作品组成部分。在此情况下，贡献者可能对其创作的代码享有独立的著作权。

贡献代码是否构成作品，会影响项目管理者是否能对相关代码主张权利。如果被告能够明确指出涉案代码由其他贡献者创作，在项目管理者不能进一步证明取得相关著作权或获得足以支持诉讼的许可或者授权的情况下，法院可能会据此限定原告可以主张的权利范围。但是，被告仅以GitHub页面显示存在多名贡献者，或者笼统主张软件使用了大量第三方代码，通常不足以推翻项目管理者依据署名、登记和提交记录形成的初步权属证明。

这一举证责任安排具有实务合理性。项目管理者应当首先证明其与涉案软件之间的权利联系。被告如果主张特定代码属于其他贡献者，则应当指明相关贡献者、代码范围及提交记录。在被告提出具体反证后，项目管理者再就相关代码的创作、受让、许可或者诉讼授权作进一步说明。如此既不会因贡献者众多而使项目管理者无法维权，也能避免项目管理者将他人的独创性贡献当然纳入自己的权利范围。

4. 合作作品认定对权利范围的影响

如果贡献者提交的内容构成作品，是否构成合作作品、合作作品是否可以分割等问题则会进一步影响项目管理者的权利范围。

判断是否构成合作作品，需要考虑项目管理者与贡献者之间是否形成合作创作关系。合作作品的成立不仅要求各参与者分别作出具有独创性的贡献，还要求其具有共同创作作品的合意。

有观点认为，在贡献者提交的内容构成著作权法意义上的作品时，项目管理者与贡献者通过pull request等机制共同完成软件主分支的开发，可以据此认定双方具有共同创作合意。在罗盒公司诉玩友公司案[14]中，法院认为，涉案软件源代码的提交者包括项目管理者和贡献者，而贡献者提交代码的流程是先由贡献者发起拉取申请（pull request），经项目管理者同意后才会并入主分支中，双方存在共同创作的合意。部分学者亦持相近观点，若贡献者主动申请将其代码并入主分支，且相关代码经评审后实际被项目管理者合并，可以据此认为贡献者与项目管理者、核心开发团队之间具有共同开发、完善项目版本的合作意愿。[15]

但也有观点认为，pull request及代码合并机制本身不足以证明项目管理者与贡献者之间存在共同创作合意，因而不能仅据此认定涉案软件构成合作作品。在罗盒公司诉风灵公司案中，法院认为，由贡献者发起拉取申请，经项目管理者同意后并入主分支中。这一过程反映了软件源代码开源的本意，即通过互联网媒介，集合全球开发者的智慧，尽可能使软件最优化，从而促进知识的传播。这一目的是开源软件作者、贡献者与使用者的前提共识，贡献者对开源软件的修改只是为了这一目的更好地实现，并不能就此认为开源软件的贡献者与作者具有创作的合意，亦不能认为贡献者针对开源软件提出修改意见的行为是共同创作行为。部分学者进一步指出，从软件开发者的角度来说，他们可能基于储存代码、开源许可协议的强制性要求等多样化动机在开源平台上公开源代码，他们并不存在与贡献者共同创作的意图。贡献者的意图是将其贡献融入作品，而将自己的贡献融入作品不能使贡献者成为合作作者。[16]

因此，开源项目是否构成合作作品，尚存在一定争议，仍应结合项目规则、版本形成过程、贡献内容、参与者意思表示以及代码之间的关系综合判断。当然，即使涉案软件构成合作作品，也不意味着项目管理者当然不能单独起诉，还需结合涉案软件是否为可以分割进一步判断。

5. 涉案软件是否可以分割对权利范围的影响

（1）涉案软件为分割使用的合作作品

根据《著作权法》第十四条第三款，合作作品可以分割使用的，作者对各自创作的部分可以单独享有著作权，但行使著作权时不得侵犯合作作品整体的著作权。因此，对于可分割使用的开源项目，项目管理者原则上只能就自己创作或者依法取得权利的部分单独起诉。

判断相关代码是否可以分割使用，不宜仅以其能否脱离整个项目独立运行作为标准，还应综合考察相关代码能否从整体作品中明确识别，能否被单独复制、修改、调用或者许可，是否具有相对独立的功能，以及其与其他代码之间是否存在难以分离的功能耦合或者数据依赖。

《五环之歌》案[17]可以说明可分割合作作品中的诉权边界。《牡丹之歌》的歌词与曲分别由不同作者创作，二者在表现形式上可以明确区分，也可以分别使用，因而被认定为可分割使用的合作作品。原告仅取得词作者的授权，起诉称《五环之歌》构成侵权。法院认为，原告可以就歌词部分享有的权利提起诉讼，但无权就其未取得权利的曲部分主张侵权。换言之，对于可分割使用的合作作品，未经许可使用的是哪一位作者的创作成果，应当由对该部分依法享有权利的主体追究侵权责任。单个合作作者一般不能仅凭其合作作者身份，代替其他作者就后者创作的部分主张权利。

BusyBox系列诉讼[18]也体现了类似思路。相关诉讼主要由软件自由法律中心（Software Freedom Law Center，SFLC）或者软件自由保护组织（Software Freedom Conservancy，SFC）代表Erik Andersen、Rob Landley等开发者提起。对此，BusyBox作者之一Bruce Perens曾公开表示不满，公开发表《Statement on BusyBox Lawsuits》[19]称其并未被通知参加诉讼，也未参与和解，并主张自己仍对BusyBox享有著作权，其还指称现任开发者似乎删除了其他开发者的版权声明、修改了许可声明，从而质疑Andersen等人是否足以代表整个BusyBox项目维权。就法院态度而言，BusyBox相关案件并未正面回应“开源项目是否必须由全体贡献者共同起诉”等问题。法院仅认可了原告对其贡献的部分代码享有版权的事实，并据此支持其诉讼请求。[20]

综上，如果涉案软件构成可分割的合作作品，项目管理者原则上应当说明其对主张权利的具体部分享有何种权利，而不能仅凭项目管理身份代替其他作者主张权利。

（2）涉案软件为不可分割使用的合作作品

如果各贡献者的独创性代码在结构、功能或者数据处理上相互嵌合，难以从整体软件中分离使用，则项目可能构成不可分割使用的合作作品。但应当注意，技术上的代码交叉或者功能依赖并不当然等同于著作权法上的不可分割。法院仍可能会结合共同创作合意、贡献内容的独创性、代码在整体中的作用以及被诉侵权行为所涉及的具体表达进行判断。

对于不可分割使用的合作作品，《著作权法》第十四条第二款规定，其著作权原则上由合作作者协商一致行使；不能协商一致且无正当理由的，任何一方不得阻止其他合作作者行使转让、许可他人专有使用、出质以外的其他权利，但所得收益应当合理分配给全体合作作者。有观点认为，著作权侵权诉讼通常属于维护合作作品权利的行为，并不属于上述受到限制的处分行为。因此，在没有相反约定的情况下，合作作者中的一方原则上可以为了制止侵权而以自己的名义提起诉讼，但其不能据此独占合作作品的全部利益，所得收益仍应在合作作者之间合理分配。

此外，2026年公布的《著作权法实施条例（修订草案征求意见稿）》第十一条对此予以进一步明确：“合作作品不可以分割使用的，各合作作者均有权为维护作品著作权以自己的名义提起诉讼”。该规定尚未正式生效，不能直接作为裁判依据，但其较为清晰地体现了我国对于合作作品诉权的解释方向。

综上，如果涉案软件构成不可分割的合作作品，项目管理者原则上可以对整个涉案软件主张权利，但所得收益仍应在合作作者之间合理分配。

三、项目贡献者起诉时的权利基础与请求范围

与项目管理者的诉权相比，项目贡献者的权利基础相对明确，贡献者对其独立创作并具有独创性的代码享有著作权，并可以就该部分代码遭受的侵害提起诉讼。但是，“项目贡献者”只是一种协作开发或者社区治理意义上的身份，并不当然意味着其对整个开源项目享有著作权，更不当然赋予其代表项目整体提起诉讼的资格。

Hellwig诉VMware案与McHardy诉Geniatech案反映了司法实践对项目贡献者起诉的态度。Hellwig v. VMware案[21]中，原告Christoph Hellwig是Linux内核的贡献者之一，其在德国汉堡地区法院起诉VMware，主张VMware的ESXi/vSphere产品中包含或利用了Linux内核相关GPLv2代码，形成了应受GPLv2约束的衍生作品，但VMware未按GPLv2要求开放相应完整源代码，因此构成GPL违约或著作权侵权。2016年，汉堡地区法院驳回Hellwig的起诉。公开报道和SFC后续说明均指出，法院并未处理GPLv2相关实体问题，而是认为Hellwig未能按照德国证据规则充分识别VMware产品中具体使用了哪些由其享有著作权的代码。[22]Hellwig对该结果提起上诉。2019年，SFC公告称，汉堡高等地区法院维持了一审裁定，该案最终结束。SFC特别强调，二审同样是基于程序性理由驳回，并未处理案件的实体问题。

McHardy v. Geniatech案[23]中，Linux内核项目最初由林纳斯·托瓦兹（Linus Torvalds）于1991年发起，其后大量开发者是在开放协作模式下，基于不同时间、不同模块和不同功能需求，逐步、独立地提交代码贡献，McHardy为该项目的贡献者之一。在该案中，有法官观点认为，即便McHardy曾对Linux内核中的部分代码进行修改或贡献，其权利范围也应限于其实际享有著作权的具体代码部分，而不能据此对整个Linux内核主张权利。其“netfilter核心团队负责人”或“子系统维护者”等身份，至多说明其在项目治理、代码维护中承担一定责任，并不能自动证明其对全部相关代码享有著作权。审阅、测试或决定是否合并补丁，并不等同于对补丁代码本身享有著作权。如禁止被告使用和分发Linux内核，覆盖范围显然超出了McHardy可能实际享有权利的代码部分，与其权利基础并不匹配。基于此，该法官倾向于认为，此前法院发布的禁止被告使用和分发Linux内核的禁令应被撤销，或至少应大幅限缩至McHardy能够证明其享有著作权的具体代码范围内。

综上，Hellwig案与McHardy案并未否定开源项目贡献者单独维权的资格。相反，两案所否定的是贡献者仅凭其社区身份或者概括性的贡献事实，对整个开源项目提出范围过宽的权利主张。对于项目贡献者的主体资格，应当区分“有权起诉”与“有权就何种范围起诉”两个问题。贡献者能够证明自己创作了具有独创性的代码，并且仍然享有该部分代码的著作权，即原则上具备提起侵权诉讼的权利基础。但是，其诉权范围通常不得超过自己享有著作权的代码部分。贡献者只有进一步证明涉案项目构成不可分割使用的合作作品，并且自己属于该合作作品的合作作者，才有可能就作品整体受到的侵害主张权利。

开源项目具有参与主体众多、权利关系复杂等特点，开源并不意味着著作权的放弃，判断相关主体能否主张权利及在何种范围内主张权利，仍应回到著作权法的基本规则，具体审查其创作了哪些代码，其诉讼请求也应与实际享有的权利范围相匹配。

注释：

[1] 本文所称“项目发起人”，是指创建并发布开源项目初始版本的主体；“项目管理者”，是指实际控制仓库主分支、审核并合并代码贡献的主体。二者可能重合，也可能分离。项目发起或者管理身份本身并不当然产生著作权，仍需结合创作事实、职务关系、权利转让及许可安排确定其法律身份。本文中所指代的“项目管理者”指的是对开源代码有较大贡献的主体。

[2] 参见https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories

[3] 参见https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks

[4] 在GitHub语境下，commit可以理解为一次“代码修改记录”或“版本快照”，记录谁在什么时候改了什么、为什么改、具体增删了哪些代码。

[5] 参见https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests?

[6] 参见https://opensource.porsche.com/docs/cla

[7] 参见https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf； https://gcc.sourceware.org/contribute.html

[8] 参见https://developercertificate.org/及https://baike.baidu.com/item/%E5%BC%80%E5%8F%91%E8%80%85%E5%8E%9F%E5%88%9B%E8%AF%81%E4%B9%A6/67730343

[9] 参见https://github.com/apps/dco?utm

[10] 广东省深圳市中级人民法院（2019）粤03民初3928号、最高人民法院(2021)最高法知民终2063号

[11] 广东省深圳市中级人民法院（2019）粤03民初3928号、最高人民法院(2021)最高法知民终2063号

[12] 参见https://github.com/asLody/VirtualApp

[13] 广州知识产权法院(2019)粤73知民初207号