开源软件社区贡献者维权的法律问题——以德国,“McHardy,v.Geniatech”,案为视角
刘海虹
（上海外国语大学法学院，上海 200083）
自1998 年开源组织OSI 正式提出 “开源” 理念以来，通过海量用户和开发者汇聚创意、检查漏洞的 “集市” 开发模式①Eric S.Raymond 在其著作《大教堂与集市》中将开源软件的开发模式描述为 “集市” 模式。RAYMOND E，The Cathedral&the Bazaar:Musings on Linux and Open Source by an Accidental Revolutionary.O’Reilly&Associates,Inc.,2001.极大推动了软件产业的发展。在数字网络技术持续发展的背景下，全球对开源的热情不减，开源项目数量持续攀升。2021年3月， “支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务” 首次被明确写入国家 “十四五” 规划②《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》。，2021年10月 “完善开源知识产权和法律体系” 又被列为 “十四五” 国家知识产权保护工作重点③《 “十四五” 国家知识产权保护和运用规划》。。
我国司法实践中涉及开源软件的早期纠纷主要表现为利用开源软件的二次开发者被诉侵犯原告软件著作权时以 “涉案软件使用了开源代码” 作为抗辩。在这些案件④主要案件如：天津市网城天创科技有限责任公司等诉温岭市达克罗涂复工业有限公司等侵害计算机软件著作权纠纷案，一审案号：（2016）浙1081民初3924号，二审案号：（2017）浙10民终1825号；
柚子（北京）科技有限公司等与数字天堂（北京）网络技术有限公司侵犯计算机软件著作权纠纷案，案号：(2018)京民终471号；
“京闪亮时尚信息技术有限公司诉不乱买电子商务（北京）有限公司侵害计算机软件著作权纠纷案，案号：（2019）最高法知民终663号。中，法院均以证据不足不予支持，但均认可了GPL 开源协议的效力。2019 年，济宁罗盒网络科技有限公司分别在广州、深圳向两家使用其开源软件的公司发起了侵权之诉⑤济宁市罗盒网络科技有限公司诉福建风灵创景科技有限公司等侵害计算机软件著作权纠纷案，案号：(2019)粤03 民初3928 号；
济宁市罗盒网络科技有限公司诉广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案，案号：（2019）粤73知民初207号。，开启了我国开源软件著作权人维权的司法实践。
开源软件的维权案中原告是否有起诉资格取决于开源软件的著作权归属，开源软件的开发是一种开放协作，大型开源项目的开发一般都涉及众多社区贡献者，其著作权权属的认定更为复杂。除了开源项目的发起人之外，作为开源软件开发的重要参与者，开源社区贡献者是否也有权就开源软件单独维权？开源软件社区贡献者的维权还会涉及哪些法律问题？
在过去几年，一名Linux 内核Netfilter 的代码贡献者Patrick McHardy，在德国频频向涉嫌违规使用者发出警告函，提出他们分发含有Netfilter 软件的行为没有提供源代码，违反了GPLv2 许可协议[1]。
收到警告函的不少企业选择支付一定金额的费用达成和解，有报道称，他在18 个月内利用这样的维权从多家企业获得超过200 万欧元的 “赔偿”[2]。
Patrick McHardy 的维权引发了广泛争议，也招致Netfilter 项目的公开反对[3]，被不少开源精神的捍卫者称为 “版权流氓” （copyright troll）。2017年7月，Patrick购买了中国深圳Geniatech 公司的欧洲代理商Geniatech Europe GmbH 销售的包含Linux Netfilter 软件的卫星电视接收器，以该公司未按照GPLv2的规定开放源代码侵犯其著作权为由向科隆地区法院申请对Geniatech Europe GmbH 签发临时禁令。针对法院做出临时禁令的裁决⑥Landgericht köln：14 O 188/17.，被申请人提起上诉。2018 年3 月7 日，Patrick 在德国科隆高等地区法院举行的口头听证会上撤诉，听证中的争议焦点集中在开源软件社区贡献者的诉讼资格及发送警告函维权的正当性问题⑦临时禁令申请上诉口头听证会内容及相关专家证据等由于原告撤诉均未公开发布，参见德国知名的开源软件专家Herald Welte 撰写的听证会综述：WELTE H. Report from the Geniatech vs. McHardy GPL violation court hearing.http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/.最后访问时间：2022年9月12日。。
我国目前尚无开源软件社区贡献者的维权实践，以下以 “McHardy v. Geniatech” 案为切入点，从开源软件开发的特点与开源软件 “开发者” 的推定，开源软件的著作权归属与社区贡献者的维权资格，以及开源软件社区贡献者维权的正当性边界等几方面结合我国相关法律对开源软件社区贡献者维权的法律问题予以论述。
根据《中华人民共和国著作权法》（以下简称《著作权法》）的规定，著作权属于作者，软件著作权属于软件开发者⑧《中华人民共和国著作权法》（2020）第11条，《计算机软件保护条例》（2013）第9条。。
因此，认定计算机软件著作权归属的根本在于 “计算机软件的开发” 。从法律上讲受著作权法保护的计算机软件是以指令、文字、符号等表达的计算机程序及其有关文档；
而从技术上讲，计算机软件的本质是 “以计算为工具实现应用目标的解决方案”[4]，它是对人脑思维形成的问题解决方案的计算机语言表达。实践中，软件开发（software development）是一个体系化的创作过程，其核心是涵盖软件生命周期过程模型以及软件开发中采用的方法[5], 随着开发技术的发展，完成这个方案的过程模型也在不断发展，但一般均包括问题定义、需求分析、设计、编码、测试、维护等一系列的创作过程[6]。
（一）开源软件开发的特点
开源软件的开发与传统软件开发最大的区别在于源代码开放，众多软件用户都可以直接参与软件的测试、维护和改进。开源软件的协作开发是一个复杂的动态创作过程，开发人员的组成、分工、能力等会发生经常性的改变，在技术上利用 “标签” 、代码管理系统等工具高效分类、索引、整合众多参与者的代码创作活动，在人员管理上通过组织架构促进参与者有效分工和提高协作效率。
1.开源软件开发的动态技术过程及其法律意义
首先，开源项目发起人会选择一个开源社区平台发起开源项目，将项目原型程序（Origin）的初始源代码在开源社区发布。这是开源软件开发的启动阶段，目的是吸引用户使用项目原型程序。与普通软件开发不同的是，开源软件的开发不是由用户提出需求的按需开发，而是将可以满足用户某些需求的原型程序直接提供给用户使用。为了吸引用户的使用和引导用户结合自己的使用场景积极参与项目反馈，开源项目发起人一般都会在发起项目时就向社区用户明确项目的意图、预期的目标、要解决的关键问题等。
其次，开源软件在社区开源发布之后，社区用户通过使用对项目原型程序的初始源代码进行测试，对缺陷予以修改，或者根据特定场景的需求编写实现新功能的代码等，即社区协作开发。为了防止互相干扰，提高协作同开发效率，大部分开源项目都是采取分支管理代码的方式开展协作开发。分支管理开发有不同的模式，常见的有主干开发模式（Trunk Based Development）和特性分支开发模式（Feature Branch Development）。主干开发模式是指所有的开发人员仅在一个主线（master）上进行协作开发，一般不允许新建其他长期存在的开发分支，所有的代码提交均需要在主线上完成。特性分支开发模式是指为一个或多个特定的需求/缺陷/任务创建代码分支（branch），在其上完成相应的开发后，把它合并（merge）到主线的开发模式⑨https://cn.trunkbaseddevelopment.com/.。
开源软件社区用户的代码贡献既涉及开源项目原型程序的测试和修改，也有新特性的开发。一些复杂的开源软件项目采取的是多分支并行开发模式，即同时存在一个主线和多个分支，不同的分支各自独立，具有不同的开发目的。社区用户在相关分支上提交代码，可以请求将其贡献的代码合并到主线（pull request），提交的补丁程序或实现新特性的代码是否符合项目的预期目需要同行评审。如果通过审核并最终被合并到主线上，就会形成开源软件的 “主线版本” ；
未被纳入主线的 “分支版本” 如果未被删除则可以独立存在。
最后，开源软件的社区协作开发是 “连续、循环进行的迭代” 。社区用户的修改早期是通过错误报告邮件列表（bug report mailing list）提交，随着技术的发展，修订控制系统（Revision Control System，RCS）、版本控制系统（Version Control System，VCS）和代码管理系统等开发支持工具不断迭代更新，社区用户工作的完整历史记录得以便捷地存档，提高了开源社区用户共同参与协同开发的效率。主线版本和分支版本各自会不断优化迭代升级，每一个软件版本可能包含对上一个版本所含bug( 软件缺陷) 的修复，也可能包含新添加的功能。在每次发布新的软件版本时，软件项目的管理团队需要在综合考虑软件的稳定性以及任务紧迫性的前提下，决定是否需要把某些特定改动加入到本次发布计划中[7]。
以 “McHardy v. Geniatech” 案争议的开源项目Linux 内核的开发为例，它是由Linus Torvalds 开发的Linux开源项目原型程序，虽然仅是完整Linux系统中较小的一部分软件，但它是确定该系统运行不可或缺的核心，于1991 年10 月5 日正式发布v.0.0.2 版本。最初社区用户提交的代码是通过邮件列表等提交审核，由Linus Torvalds 决定是否纳入源代码库，后来，该项目采用了更先进的Git分布式版本控制系统实现多分支的平行开发。Linux 内核共有五个分支：mainline 分支、mm 分支、next 分支、stable 分支和staging 分支⑩mainline分支是主线，记录了进入主线的所有代码修改、提交记录，Linux内核的每个发布版本都是以主线为基础的；
mm分支是对所有提交到mainline 分支的子系统代码进行整合测试的；
next 分支是一个自动化整合测试分支，每天自动拉取两百多个子系统分支代码；
stable 分支的目的则是对已经发布的正式版本进行后续维护；
而staging 分支则用来存放那些不足以进入mainline分支的独立的文件系统或驱动代码。。社区用户首先通过邮件列表讨论分支中正在测试的代码，发现代码问题之后，用户将其编写的新代码或代码修改提交到相应的分支，由分支的维护人员进行单独测试，然后再确定是否进一步集成到mm分支或next 分支中进行整合测试；
接着由Linus Torvalds 决定从几个主要测试分支上拉取没有问题的代码到主线；
最后Linus Torvalds 基于主线上集成的代码发布新的Linux内核版本。
频繁地发布、修改、提交，迭代是开源软件开发过程的最大特点，在这个动态过程中社区贡献者也是流动的，开发者流失与对应程序包丢弃、被接管等也普遍存在[8]。在开源软件社区贡献者维权时，首先需要在事实上界定开源软件的二次使用人使用的是哪个版本的程序，在法律上需要认定维权者的贡献是否构成著作权法意义上的 “开发” 。
2.开源软件开发的组织架构与参与者署名问题
从技术上讲，开源项目的社区协作开发活动的核心是代码编写、提交、审核及合并，在利用分支管理模式的软件开发核心活动中，通常包括以下角色：项目维护者、分支/模块维护者、普通开发者。项目维护者的主要工作内容是合并分支、发布版本；
模块维护者的主要工作内容是审核代码、合入代码；
开发者的主要工作内容是编写代码、提交代码[9]。当然，这些角色并非一成不变，如果项目小，可能并不区分模块，就不需要模块维护者。但是，广义上讲，开源社区用户的 “贡献” 除了代码之外，还包括各种其他活动。比如回答新手的问题，对发布的新版本进行测试并反馈问题，对开源源代码进行复核并发表意见，以及与代码完全无关的外围支持，如操作界面的外语翻译，数据类型错误或者数据丢失的缺陷报告等。
为了确保上述参与者的协作开发高效运行，实践中较为复杂的开源项目会形成包括项目发起人、核心开发者团队和社区贡献者的梯层组织结构对应承担上述角色。在开源项目的社区协作开发中通常项目维护者的角色由项目发起人承担，分支/模块维护者一般都是核心开发者，众多社区用户作为普通开发者以贡献代码的方式参与开发。开源软件社区还会确立各种人员管理机制，比如，社区成员成为贡献者的机制（如基于贡献度PR数，或基于开发者投票等），核心团队的产生机制，开发过程中的沟通机制（如通过邮件列表沟通）及参与开发者在管理开发过程的分工机制等。
以Linux 开源项目为例，由于其内核最初是由Linus Torvalds 发起并全权负责的，随着项目的发展逐渐确立了社区贡献者、核心开发团队和发起人的协作开发组织架构。社区用户提交的补丁程序需要首先在邮件列表中通过同行评审和更广泛的测试，分支的核心开发者1Greg Koroah Hartman,Andrew Morton,Stephen Rothwell,David S.Miller 等都是Linux 内核发布后5 年内加入的核心开发人员，分别负责领导上述Linux内核分支的维护。负责决定是否将补丁纳入分支版本。但是，所有的代码最终都要通Linus Torvalds的审查，他对进入内核的代码拥有最终决定权[10]。Git 数据包记录着Linux 内核开发过程中社区每次代码修改、审核提交和版本发布的信息；
此外，Linux 内核发布版本的C 文件的注释里标有该版本文件的作者和重要修改者信息（姓名、邮箱等）；
在Linux 内核发布版本中有一个文件名为Maintainer 的文件，维护者的信息均记录在这个文件里。版本控制系统记录中的署名或作为核心开发者的署名在法律上有什么意义呢？
（二）开源软件开发者的推定
从法律上而言，为开源项目开发做出贡献的社区用户是否能构成开源软件开发者应依据著作权法的相关规定来认定。我国《计算机软件保护条例》第九条规定：软件著作权属于软件开发者，本条例另有规定的除外。如无相反证明，在软件上署名的自然人、法人或者其他组织为开发者。德国著作权法也有相同的规定2《德国著作权法》第十条。。
在 “McHardy v. Geniatech” 案中，争议的开源软件Netfilter 是Linux 内核中的一个可以执行各种网络功能的实用程序，Patrick 自2013 年担任Netfilter 核心开发团队的负责人，直到2016 年都是Netfilter 核心开发团队的成员。McHardy 向科隆地区法院请求临时禁令（einstweilige Verfuegung），禁止的内容是很宽泛的，包括禁止被告向公众提供Linux 内核软件，销售含有Linux 内核软件的产品及在其网站上提供Linux 内核软件的下载链接、程序文档的下载等。科隆地区法院在初审裁决中基于Patrick 已经证明其作为Netfilter 核心开发团队的负责人（head of the netfilter core team）身份及Linux 内核网络堆栈维护者（subsystem maintainer）身份，认定其长期参与Linux内核的开发，因此他具有申请临时禁令的资格。但是，科隆高等地区法院在上诉口头听证会认为不能依据 “核心开发团队的负责人” 以及分支版本维护者的署名直接推定其为 “开发者” ；
审核过大量的 “补丁” 以及决定是否将补丁并入也不意味着其对这些补丁享有著作权，必须根据该程序的开发方式和过程明确其贡献的法律性质。
开源软件版本控制系统的记录是通过技术管理开发过程和版本发布，项目开发的组织架构则侧重高效组织协作开发中参与者的活动。比如，核心开发团队的成员可能并未实际参与核心的代码提交和审核活动。因此，这些署名不能与软件著作权登记中的开发者署名等同，在法律上并不能根据这样的 “署名” 推定被署名者为软件开发者。
由于开源项目软件的版本是不断迭代的，在认定社区用户贡献的法律性质时，必须首先明确其主张的版本。在典型的开源软件 “集市开发” 模式下，发起人发布的项目初始原型是由其单独开发完成的初始版本，发起人对其单独享有著作权，社区用户对初始版本没有任何贡献，不能对初始版本主张权利。社区用户的参与主要涉及对初始版本的不断改进，对于其参与改进的版本，其贡献可能涉及著作权法上的合作开发和改编。
（一）合作开发者的认定
在 “McHardy v. Geniatech” 案中，证据显示Linux内核是由Linus Torvalds 独立开发完成之后再向社区发布的，虽然后续有超过15 000 的社区开发者参与改进，仅就Linux 内核初始版本的开发而言，Linus Torvalds对其单独享有著作权。临时禁令的被申请人否认Patrick 提起临时禁令申请的资格，请求法院驳回禁令申请，因为他既不是Linux 内核的合作作者（Miturheber），也不是Linux 内核网络堆栈或组件Netfilter的合作作者。
主审法官认为并不是所有对Linux内核做出贡献的人都可以主张自己是整个程序的合作作者，应根据德国著作权法的相关规定结合Patrick 的具体贡献，认定其是否为Linux 内核的合作作者。根据《德国著作权法》第八条的规定，如果多人共同创作了一部作品，并且各自创作的部分不能被分开使用，他们就是该作品的合作作者。社区贡献者能否被认定为德国著作权法规定的合作作者取决于其与其他开发者是否有共同创作的合意，其贡献是否满足作品独创性的要求，以及其创作的部分与其他合作者创作的部分是否具有不可分割性。
首先，需要认定社区贡献者与发起人和核心开发团队是否存在改进版本的共同创作合意。根据分支管理代码的方式，由项目发起人或核心开发团队创建主线，社区用户可以基于主线创建其自己的分支并自行修改维护。社区用户申请 “同行评审” 由项目管理者（发起人或核心团队相关人员）根据项目发起人的开发意图做出取舍决定是否将其分支中的修改合并入主线。这个过程表明项目发起人、核心团队和贡献代码的用户之间是存在合作开发改进版本的合意。如果社区用户并不申请将其创作的代码并入主线，或者并未通过同行评审及项目管理者的最终决定被并入主线，就不应该认定其存在合作开发的合意。
其次，还需要认定社区用户的贡献是否具有独创性。回答新手的问题，对发布的新版本进行测试并反馈问题，对开源源代码进行复核并发表意见等社区用户的贡献均难以被认定具有 “独创性” ；
而提交代码的补丁一般可以认定为具有独创性。根据德国著作权法的规定，这些代码需具有独创性，还需要被合并到主线成为开源软件不可分割的部分，才能认定该社区贡献者具有合作作者的法律地位。
德国法关于合作开发软件的规定与我国的相关规定相似，不同的是我国《计算机软件保护条例》规定合作开发的软件著作权可以由合作开发者书面约定，若无约定的，须区分可分割使用的软件和不可分割使用的软件，确定著作权行使规则3《计算机软件保护条例》第十条。。
但是对于如何认定合作开发者，计算机软件保护条例并没有明确规定，应依据著作权法关于合作作者的规定来认定，即合作作者之间要有共同创作的合意，合作作者的贡献应为著作权法规定的创作，即有独创性。无论不同合作作者创作完成的部分之间是否可以分割使用，均可以构成合作作品。
（二）改编者的认定
对于未被纳入主线的 “分支版本” 如果未被删除则可以独立存在，分支版本是基于开源软件源代码的初始版本所做的修改，该修改依据开源协议是经过授权的4Section 2 of GPL V.2 provides:You may modify your copy or copies of the Program or any portion of it,thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions.。
根据《德国著作权法》第三条的规定属于对既有作品的改编（Bearbeitung），如果改编具有独创性，改编者对分支版本享有独立的著作权，但同时应遵守开源协议的相关条款规定。当然，开源软件社区开发的实践中，分支版本的开发者常常很多，分支版本也可能被认定为合作开发的软件。还要进一步分析主张著作权的社区贡献者贡献的代码是否具有独创性，以确定其是否为分支版本改编作品的共同开发者。
在 “McHardy v. Geniatech” 案中，Patrick主张他在参与Linux 社区开发的多年间，一共编写了约50 000行代码，并提交了一张带有修改日志的CD 作为证据。但是，科隆高等地区法院认为这并不足以证明这些代码均受著作权法保护。根据口头听证会上专家证人Greg Kroah Hartman 提交的宣誓证据[11]，Linux内核2.5.12 版由Linus Torvolds 于2002 年4 月30 日发布,在贡献者记录中没有证据5Patrick对Linux内核所做明确贡献的首个记录是在2002年4月23日,最后访问时间：2015年11月24日。表明Patrick 对内核2.4.18 和2.5.12 版之前的版本做出过任何代码贡献。因此，科隆高等地区法院裁定，Linux 内核开发模式不支持Patrick作为Linux 内核合作作者的主张，他充其量仅是改编者。
（三）社区贡献者的维权资格
如果社区贡献者被认定为共同开发者或改编作品的共同开发者，他是否可以对他人违规使用合作开发版本和改编版本的行为以自己的名义来提起侵权之诉呢？ “McHardy v. Geniatech” 案中，二审法院认为Patrick 作为改编者仅拥有其自己贡献的代码的著作权，但不拥有整个Linux 内核的著作权。他有权向法院申请临时禁令，但是范围仅限于其享有著作权的部分，他没有资格就整个Linux 内核的著作权申请临时禁令。在上诉法院的口头听证会后，Patrick撤回了禁令申请。
开源软件的社区贡献者在我国维权的话，根据我国《计算机软件保护条例》的规定6第十条...合作开发者对其共同开发的软件著作权归属没有约定或约定不明的，合作开发的软件可以分割使用的，开发者对各自开发的部分可以单独享有著作权；
但是，行使著作权时，不得扩展到合作开发的软件整体的著作权。合作开发的软件不能分割使用的，其著作权由各合作开发者共同享有，通过协商一致行使；
不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让权以外的其他权利，但是所得收益应当合理分配给所有合作开发者。，如果他是分支版本的唯一作者，就可以单独就分支版本提起诉讼；
如果他仅为分支版本的合作作者，或是主线版本的合作作者，我国现行《著作权法》对合作作者诉权行使未作规定。司法实践中，合作作品侵权之诉的被告常以单独起诉的合作作者未经其他合作作者授权为由，提出其没有起诉资格的抗辩。对此，有的法院认为合作作者不可以单独起诉，必须取得其他合作作者授权才享有起诉的资格7浙江省杭州市中级人民法院民事裁定书(2009)浙杭知初字第365号。；
有的法院认为可以依据《著作权法实施条例》第九条（现著作权法第十四条第二款）有关合作作品著作权行使的规定，合作作者之间就起诉应协商一致，如果未能达成一致起诉的决定，没有正当理由，其他合作作者不得阻止主张起诉的作者单独起诉8(2015)浦民三(知)初字第60号。；
还有的法院认为合作作者可以单独起诉9(2011)豫法民三终字第19号。。
针对这一实践中的问题，2014 年公布的《著作权法（修订草案送审稿）》第十七条第四款0《著作权法（修订草案送审稿）》（2014）第十七条第四款 “他人侵犯合作作品著作权的，任何合作作者可以以自己的名义提起诉讼，但其所获得的赔偿应当合理分配给所有合作作者” 。规定合作作者可单独行使其诉权，但这一规定并未被2020 年著作权法第三次修正案采纳。
在济宁罗盒网络科技有限公司提起的两起侵权诉讼案中，对于作为共同著作权人的发起人的维权资格，法院考虑开源软件社区开发中发起人与社区贡献者的角色不同，认为发起人因公开开源项目的初始版源代码具备主张著作权的基础，同时又在软件研发过程中的创造性劳动最多，此外还考虑维权若要分散各地的社区贡献者一致同意是不现实的，最终认定发起人具有起诉资格。但按照这个裁判思路，社区贡献者在软件开发过程中并非都是贡献创造性劳动较多，可能很难具有单独起诉的资格。
即使社区贡献者没有单独起诉的资格，如果以向违规使用者发送侵权警告函的形式维权又有什么问题呢？
如上所述，开源软件的开发虽然具有与非开源软件不同的特点，但同样受著作权保护，只是著作权人通过开源许可协议保障了所有用户自由使用软件的权利1一般开源许可协议均授予所有用户自由地复制、修改和分发开源软件程序的权利。；
但是开源许可协议通常也规定了用户使用软件的义务。开源软件许可协议大致可以分为 “copyleft” ， “宽松” 或 “弱copyleft” 两类。
“McHardy v.Geniatech” 案所涉开源许可协议为GPLv2 属于copyleft 类型。GPLv2 下开源软件使用者的核心义务是承诺继续开源，即任何基于copyleft 程序衍生开发的作品必须以与原程序相同的copyleft许可协议授予许可，这就是所谓的copyleft 的 “遗传效应” 或 “传染性”2为使用户能够自由地学习、修改和共享，所有的GPL 程序用户在获得二进制或可执行代码后，都有权要求分发人提供完整对应源码(Complete and corresponding source code,简称C&CS)。如果完整对应源码未与二进制代码一起分发，则需要附随一份书面要约（即表示愿意提供完整对应源码的书面声明），无论使用何种介质分发软件均是如此。要求分发者提供或表示愿意提供C&CS 是保护用户权利的基本要求。参见Eben Moglen,Mishi Choudhary,Software Freedom Law Center Guide to GPL Compliance, 2nd Edition (2014), https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.pdf,最后访问时间：2022年7月8日。。
copyleft 开源软件项目的目标在于确保每个用户都有权自由地修复bugs、提升性能和二次使用代码，保障实现开源软件开发者开发软件的意图。开源软件的使用者不遵守上述开源许可协议的行为都意味着用户权利的损失。比如，如果使用开源软件的二次开发者未向其用户提供其产品中所含copyleft 软件及适用许可条款等必要信息，该二次开发产品的用户就无法通过可靠方式获取copyleft 软件的源代码。因此，开源社区鼓励以非诉的方式督促使用者遵守开源许可协议的规定，而不是寻求诉讼或赔偿。
但是，Patrick McHardy 的维权之所以备受争议不仅在于其维权资格存在瑕疵，还在于他向80多家3由于不少公司做出的停止侵害声明都规定了保密条款，Patrick具体向多少家公司发送过警告函并没有准确的数字，也有报道称50多家。公司发了警告函，利用维权获得大量赔偿金。Patrick利用警告函获得赔偿金的维权固然与德国法下警告函的性质有关，但也暴露出开源软件社区贡献者维权的正当性边界问题。
（一）知识产权侵权警告的法律性质与侵权警告的正当性
我国相关法律法规中没有明确规定 “知识产权侵权警告” 的概念，对于知识产权侵权警告的法律性质存在不同的观点。
“权利行使论” 认为发送侵权警告函是知识产权人行使其权利的行为，否定警告者的责任[12]；
但是，我国司法实践中有法院认定发送警告函是一种维护自身权益的行为4在理邦案的二审中，法院认为 “迈瑞公司作为相关专利产品的专利权人，针对涉嫌侵权产品的销售者发出要求停止侵权的警告，是采取合法手段维护自身权益的正当行为” 。该案案号为最高人民法院(2015)民申字第191号。。对于 “维护自身权益的行为” 是不是构成自力救济，学者们均认同其具有自力救济的色彩，但并非民法典明确规定的自力救济行为[13]。
因此，发送知识产权警告函不应像自力救济那样以存在危害请求权的实现且依靠公力救济仍无法避免为前提，其正当性的空间应该更大一些。也有学者认为， “警告函在性质上应被视为签订服从合同而发出的要约。在警告函中，警告人要求被警告人作出以违约金作担保的停止侵权的承诺，但不能要求赔偿损失。”[14]但是，《德国著作权法》第97a条规定著作权人可以通过警告函（Abmahnung）和自愿接受惩罚（Unterwerfungerklaerung）的非诉方式行使请求权。警告函一般都会要求违规使用者将来不再从事侵权行为，并允许被警告者做出 “停止侵害声明” 终结双方纠纷，即声明如果再次侵权便自愿支付适当金额的惩罚金。这也带来了滥用警告函进行营利性维权的风险。
根据德国法规定，这种警告函构成 “以缔结自愿接受惩罚合同为目的而做出的《德国民法典》第145条意义上的要约（Antrag）”[15]。
如果被警告的违规使用者作出了自愿接受惩罚的声明，著作权人就对其将来的侵权行为获得了一种以合同罚金作为担保的合同请求权保护。由于停止侵害声明可能还会包含保密的要求，例如：限制权利人寻求其他侵权人的支持或向社区公开权利人的权利主张，接收到Patrick 警告函的大多数公司为了避免可能被诉和侵权行为在社区被公开都会对警告函作出回应，并作出自愿接受惩罚的 “停止侵害声明” 。被警告的违规使用者如果不履行合规义务，存在继续或重复侵权行为，就对发出警告函的权利人负有支付惩罚金的合同义务。发出警告函的权利人可以直接向法院请求被警告的违规使用者履行该合同义务。
根据德国法的相关规定，警告函的目的在于消除侵权人重复侵权的危险，使著作权人能够在不借助法院的帮助下对侵权行为进行迅速而有效的防御。但是，由于停止侵害声明具有合同性质，警告函也存在被滥用的可能。比如，警告者并非被侵权内容的著作权人，或者尽管警告者对被侵权内容享有著作权，但是首个警告函并不详细列出所有已知的侵权行为；
此外，还有要求众多被警告者签署宽泛的停止侵权声明，超出警告者著作权保护的范围等。Patrick向众多公司发出警告函要求他们停止分发含有Linux内核产品的维权就存在上述问题。由于许多公司作出的停止侵害声明中均有保密的要求，Patrick的集中维权并没有及时引起关注，因而，他通过发送警告函的方式获得了大量的损害赔偿金，直到被警告的Geniatech Europe GmbH 拒绝作出自愿接受惩罚停止侵害的声明。
对于知识产权人发送侵权警告函的正当性，我国最高法院在 “理邦” 案的再审判决中指出：通常要根据权利人的权利状况、警告内容及发送的意图、对象、方式、范围等多种因素进行综合判断5最高人民法院(2015)民申字第191号。。
如上所述开源软件的开发涉及众多社区贡献者，其贡献可能被认定为共同开发或改编，且所涉开源软件的版本也需要根据具体情况来确定，社区贡献者发送警告函的行为在权利状况、警告内容、警告范围等方面均可能存在瑕疵，超出正常范围。被警告者在回应警告函时应及时寻求专业法律意见，谨慎作出停止侵害的承诺。
（二）GPLv2 开源协议自动终止条款的滥用风险与侵权警告的正当性
侵权警告的目的是认定警告正当性的重要考量因素，开源软件社区贡献者发送警告函的目的是维护自身权益，还是 “勒索” 赔偿金并不容易认定。根据开源许可协议，使用开源软件的二次开发者对软件源代码的获取和使用本来就是自由的，大部分开源软件著作权人的维权是为了督促使用者履行开源软件许可协议中开放衍生作品源代码的义务。为了约束使用人，GPLv2 第4 节规定了自动终止条款，即使用者如果违背开源协议条款，则自动终止许可。这样，使用者如果想重新获得分发的权利，必须获得著作权人的重新授权。
尽管开源社区的著作权人对于依据侵权人的请求恢复分发权一直持合作态度，但这也给像Patrick这样以维权营利的人提供了索要巨额费用才同意恢复权利的机会。Patrick 在向科隆地区法院申请禁令之前，就通过Email 直接终止了Geniatech Europe GmbH 在GPLv2 下的权利。但是，德国相关判例6Landgericht Muechen:21 O 6123/04,Welte/Sitecom Deutschland GmbH.对GPLv2 第4 节的解释是：GPLv2 下的许可并不因使用者的侵权而自动终止，侵权人可以通过接受和遵守许可协议规定的合规行为随时获得权利。
这一做法本身进一步证明Patrick 维权的目的不是督促违规使用者合规，而是索要赔偿金。
对于这一存在潜在滥用风险的条款，GPLv3 协议进行修改，将GPLv2 中的 “如果违反条款将自动终止许可” 规定改为 “如果是首次违反条款，则可在一定时期内自我修正，并自动恢复许可证所授予的权利” 这一修改与之前德国法院判例中的解释是一致的，根据该修改，违规使用者在首次收到警告函之后只要及时纠正违规使用行为就不必担心被维权营利者终止权利了。
对于Patrick 版权流氓式的维权，包括软件自由保护组织在内的各种社区成员一直努力试图说服其改变策略，经过漫长的交涉，Linux内核的核心团队终于在2021 年12 月27 日就Linux 内核的维权问题在德国曼海姆地区法院与Patrick 达成和解。双方共同承诺未经Linux 内核Netfilter 核心团队的大多数活跃成员事先同意不得自行通过发送警告函等方式就适用GNU 开源许可协议的软件著作权（包括共同著作权或改编著作权）侵权维权或强制违规使用者合规。
“McHardy v. Geniatech” 案具有其特殊性，但是该案也暴露出开源软件社区贡献者维权中的问题。德国法院对开源软件社区贡献者申请禁令的资格及发送警告函维权的正当边界的意见对于开源软件在我国的司法保护仍具有重要的参考意义。
2021 年，GitHub 上的中国用户数达到755 万人，实际参与到开源项目中的开发者仅占32%[16]，开源软件开发者维权的案件刚刚出现。在济宁罗盒网络科技有限公司提起的两起侵权诉讼案中，被告均对原告的起诉资格提出挑战，认为原告主张被侵权的软件源代码是开源代码，而参与编写该开源代码的有32 人，作为原告股东的项目发起人仅为合作开发软件的共同著作权人。该案的判决中法官最终认可发起人的起诉资格，理由是发起人在开源平台公开初始版源代码具备主张著作权的基础，且在软件研发过程中的创造性劳动最多；
此外，开源项目的贡献者人数众多、互不相识又身居世界各地，且随着项目修改处于持续增加、变动之中，若要全体一致同意，实则导致维权无从提起。
可见，我国目前涉及开源软件的司法实践中保护软件研发的创造性劳动是基本核心，无论是开源项目的发起人还是社区贡献者，判断其是否具有维权资格，均应依据《著作权法》和《软件著作权保护条例》的规定，结合其在开发中的具体贡献来认定。根据开源软件分支管理代码的开发方式，主线版本与分支版本的著作权归属应区别对待。社区用户编写的代码具有独创性并提交审核被纳入主线版本的，该社区贡献者可以认定为主线版本的共同著作权人；
未经过审核被纳入主线版本的分支版本是基于开源软件初始版本的改编作品，如果社区贡献者是分支版本的唯一开发者，就可以单独就分支版本维权。作为主线版本及分支版本共同开发者的社区贡献者，应根据共同著作权人行使著作权的规定维权。
但是，侵权诉讼一向是开源软件权利人维权的最终法律解决机制，督促开源软件使用人合规才是其根本目标。为了解放开源软件开发者所面临的维权负担，捍卫 “自由、协作、共享” 的开源精神，提高开源软件使用人的合规意识，自由软件基金会(FSF)这类托管机构开始设立，还有软件自由法律中心(SFLC) 、软件自由保护组织(SFC）和GPL-violations.org 这些专门为开源社区提供法律服务的机构。他们经开源软件著作权人授权，代理其维权。一般情况下他们先对投诉情况进行全面调查并核实，然后再与明显违规的当事人联系，通过协商或发送警告函的方式要求违规者纠正违规行为；
对于没有纠正的违规者，上述机构也曾代理权利人提起侵权诉讼。
目前，我国的开源基金会仅有2020 年成立的开放原子开源基金会，通过接受捐赠和获得授权管理开源项目。为避免社区贡献者自行营利性维权，应借鉴国外著名的开源社区的经验，鼓励开源软件社区管理组织确立以公开为原则、激励合规为导向的社区投诉和维权规则。同时，应加强开源软件社区管理组织或开源软件基金会在法律救济中的地位，明确他们的法律地位，便于他们更有效参与开源软件著作权的维权。
猜你喜欢贡献者开发者开源从“学习者”到“贡献者”：中国管理学发展的路径现代商贸工业(2020年1期)2020-02-06“‘一国两制’杰出贡献者”国家荣誉称号宁夏画报(2019年8期)2019-09-10五毛钱能买多少头牛创新作文(1-2年级)(2019年3期)2019-09-03现当代文化贡献者——布赫贺希格西部蒙古论坛(2018年3期)2018-12-13“85后”高学历男性成为APP开发新生主力军经济(2016年29期)2016-12-27大家说：开源、人工智能及创新办公自动化(2016年18期)2016-08-20开源中国开源世界高峰论坛圆桌会议纵论开源与互联网+创新2.0办公自动化(2016年18期)2016-08-20一种交互式事件常识知识的获取方法中文信息学报(2016年3期)2016-05-0416%游戏开发者看好VRCHIP新电脑(2016年3期)2016-03-10开源计算机辅助翻译工具研究上海理工大学学报（社会科学版）(2015年3期)2015-11-30