如何应对开源软件的版权牟利者？ 开源律师说这样做！
Linux 社区的许多开发人员对 GPL 许可证牟利者 Patrick McHardy 的行为表示担忧，美国资深开源律师对一些常见问题进行解答，并对如何应对版权牟利行为提出了建议。
GPL 专利
Linux 社区的许多开发人员对 GPL 许可证牟利者 Patrick McHardy 的行为表示担忧，美国资深开源律师对一些常见问题进行解答，并对如何应对版权牟利行为提出了建议。

> 
> 提要：Linux 社区的许多开发人员对 GPL 许可证牟利者 Patrick McHardy 的行为表示担忧，美国资深开源律师对一些常见问题进行解答，并对如何应对版权牟利行为提出了建议。
> 
> 
> 


![](/data/attachment/album/201710/27/225931pu50abnqariq00g5.png)


针对 Patrick McHardy 强制要求 Linux 分发者遵循 GPL 许可证的举动，开源社区许多人士表示了担忧。基于与 McHardy 行动相关的公开信息，以及开源合规维权的一些法律原则，美国资深开源律师对一些常见问题进行了解答。


Patrick Mchardy 是谁？ McHardy 是 Netfilter 核心开发团队的前任负责人。 Netfilter 是 Linux 内核中的一个实用程序，可以执行各种网络功能，例如改善网络地址转换（NAT），NAT 是将 Internet 协议地址转换为另一个 IP 地址的过程。对于维护 Linux 系统的安全性来说，控制网络流量至关重要。


### McHardy 对 Linux 有多少贡献？


这不是一个容易回答的问题。首先，评估贡献的重要性并不容易；我们能做的就是查看<ruby> 提交 <rp>  （ </rp> <rt>  commit </rt> <rp>  ） </rp></ruby>的数量和大小。其次，即使去跟踪提交，跟踪机制也不完美。 Git 有一个 blame 功能，跟踪谁在名义上向 Git 数据库提交了哪些代码行。Git 的 blame 功能可以使用诸如 [cregit](https://cregit.linuxsources.org/) 这样的工具，以更具细粒度的水平来报告提交，从而在文件级别上对贡献度有一个更准确的认知。Git 的 blame 机制和 cregit 是非常实用的，因为它们都使用公开易得的信息，而信息只需要被正确解释。


结合 cregit 和 blame 进行分析可以帮助评估 McHardy 的潜在贡献。例如：


* 他的大部分贡献似乎是在 2006 年到 2008 年和 2012 年期间。
* 在 McHardy 包含其版权声明的大约 135 个文件中，只有 1/3 的文件是 McHardy 贡献了该文件代码的 50％ 或以上。
* 他的贡献看起来不到内核代码的 0.25％。


McHardy 的大部分贡献似乎都给了 Netfilter；然而，blame 机制可能并不总能还原全貌。例如，提交者可以<ruby> 签入 <rp>  （ </rp> <rt>  check in </rt> <rp>  ） </rp></ruby>许多行代码，但只进行细微修改，也可以签入其他人编写或拥有的代码。由于这些原因，提交者的作者身份可能被过低或过多报告。


在 2002 年之前对内核贡献的记录对于识别贡献者来说不是特别有用，因为在当时，Linus Torvalds 签入了所有代码。 McHardy 的贡献直到 2004 年才开始。 


[Hellwig 诉 VMware 一案](https://www.theregister.co.uk/2016/08/15/vmware_survives_gpl_breach_case_but_plaintiff_promises_appeal/)中出现了使用开发存储库的元数据确认版权所有权的困难。法院可能不愿意接受这样的信息来作为证明作者身份的证据。


### McHardy 在 Linux 内核中拥有哪些版权？


大型项目（如 Linux 内核）的版权归属复杂。这就像一个拼凑的被子。当开发者对内核做出贡献时，他们不签署任何贡献协议或版权转让协议。GPL 涵盖了他们的贡献，软件副本的接收人根据 GPL 直接从所有作者获得许可。内核项目使用一个名为<ruby> “原始开发者证书” <rp>  （ </rp> <rt>  Developer Certificate of Origin </rt> <rp>  ） </rp></ruby>的文件，该文件不授予任何版权许可。贡献者的个人权利与在项目中的权利作为整体并存。 所以，像 McHardy 这样的作者一般都会拥有他所创作的作品的版权，但并不享有整个内核的版权。


### 什么是<ruby> “社区维权” <rp>  （ </rp> <rt>  community enforcement </rt> <rp>  ） </rp></ruby>？


由于大型项目（如 Linux 内核）的所有权常常分散在许多作者手中，所以个体所有者可以采取不符合社区目标的维权行动。虽然社区可能会对如何以最好的方式来鼓励遵守 GPL 条款有很多看法，但大多数人认为维权应该是非正式的（不是通过诉讼），而且主要目标应该是合规（而不是惩罚）。例如，<ruby> <a href="https://sfconservancy.org/">  软件自由保护组织 </a> <rp>  （ </rp> <rt>  Software Freedom Conservancy </rt> <rp>  ） </rp></ruby>（SFC）已经颁布了一些[社区维权原则](https://sfconservancy.org/copyleft-compliance/principles.html)，其中优选合规，而不是寻求诉讼或赔偿金。对于非正式行为何时应该成为诉讼，或维权者应该要求赔偿多少钱，没有明确的规定。然而，Linux 社区的大多数开发人员将诉讼视为最后的手段，并不愿意采取法律行动，而与真正希望合规的用户进行合作。


### 为什么这么多的开源诉讼在德国提交？


一些寻求进行开源许可证维权的原告已经向德国法院提交权利主张。在德国有一些在美国或其他<ruby> 普通法 <rp>  （ </rp> <rt>  common law </rt> <rp>  ） </rp></ruby>国家没有能够确切与之类比的寻求法律诉讼的手段。


* [**Abmahnung**](https://en.wikipedia.org/wiki/Abmahnung)**（<ruby> “警告” <rp>  （ </rp> <rt>  warning </rt> <rp>  ） </rp></ruby>****）**：“警告”是索赔人要求被告停止做某事的要求。在版权语境下，这是版权所有者发出的一封信函，要求所述侵权人停止侵权。这些信件是由律师而不是法庭签发的，通常是德国版权维权行动的第一步。在美国，最接近的方式应该是<ruby> 警告信 <rt>  cease and desist letter </rt></ruby>。
* [**Unterlassungserklaerung**](https://de.wikipedia.org/wiki/Unterlassungserkl%C3%A4rung)**（<ruby> “停止声明” <rt>  cease and desist declaration </rt></ruby>****或<ruby> “禁止声明” <rt>  declaration of injunction </rt></ruby>****）**：“警告”通常会附有“停止声明”。这种“声明”就像合同一样，签署的话会要求被告人承担其它并不存在的法律义务。特别是，该声明可能包含 GPL 本身并不要求的义务。在德国，这样一份文件通常包含针对不合规进行惩罚的内容。在美国，类似的做法是和解协议，但和解协议很少规定违约的处罚方式，事实上在美国，合同中的“处罚”可能无法强制执行。“声明”不是法院命令，但如果被告签字，可以获得法院命令的法定效力。**所以，在征求律师法律意见之前签字往往不是一个好主意。**在考虑如何应对寄出停止声明的原告时，还有其他方法，包括提出修改后的处罚或义务较少的声明。此外，由于停止声明可能包含不公开的要求，签署这些文件也可能产生额外的困难，例如限制原告寻求其他被告支持或向社区公开索赔人的权利主张。  
更多详情参见：[abmahnung.org/unterlassungserklaerung/](http://www.abmahnung.org/unterlassungserklaerung/) 。
* [**Einstweilige Verf****ü****gung**](https://de.wikipedia.org/wiki/Vorl%C3%A4ufiger_Rechtsschutz#Einstweilige_Verf.C3.BCgung)**（“<ruby> 临时禁令 <rt>  interim injunction </rt></ruby>****”或“<ruby> 初步禁令 <rt>  preliminary injunction </rt></ruby>****”）**：“临时禁令”是一项类似美国临时禁令的法院命令。虽然没有要求原告在向法院提出“临时禁令”之前发出“警告”，但在被告对“警告”或“声明”不作出回应时，鼓励原告寻求“临时禁令”。侵犯版权的临时禁令可以处以 25 万欧元罚款或 6 个月的监禁。相比之下，在美国，侵犯版权的刑事处罚极为罕见，必须由政府而不是私人机构追究。此外，在美国，法院也没有为未来的侵权行为提供补救措施，它们只是要求被告停止现行的侵权行为或者支付损害赔偿金。在德国，<ruby> 单方 <rt>  ex parte </rt></ruby>也可以提出临时禁令，这意味着原告可以在没有被告听证的情况下向法院提出申请，而且可以在没有被告参与的情况下发出临时禁令。如果您收到“警告”，并怀疑原告可能会随之提出 “临时禁令”，可以向法院抢先提出<ruby> “异议” <rt>  opposition </rt></ruby>。  
更多详情参见：[Abmahnung.org](http://www.abmahnung.org/einstweilige-verfuegung/) 。
* [**Widerspruch**](https://de.wikipedia.org/wiki/Widerspruch_%28Recht%29#Zivilprozessrecht)**（<ruby> “异议” <rt>  opposition </rt></ruby>****或<ruby> “反驳” <rt>  contradiction </rt></ruby>****）**：“异议”是被告向法院提出否决“临时禁令”的机会。  
更多详情参见：[这篇德国法院命令的英文翻译](http://www.jbb.de/Docs/LG_Halle_GPL3.pdf) 。


### McHardy 发起了多少权利主张？


由于许多德国法庭案件缺乏公开记录，因此很难确定 McHardy 的确切行动数量。据说 McHardy 已经接触了超过 50 个维权目标。有关详细信息，请参阅<ruby> <a href="https://sourcecodecontrol.co/gpl/">  “源码控制” </a> <rp>  （ </rp> <rt>  Source Code Control </rt> <rp>  ） </rp></ruby>和<ruby> <a href="https://opensource.com/article/17/1/yearbook-7-notable-legal-developments-2016">  《2016 年开源社区 7 个显著的法律进展》 </a> <rp>  （ </rp> <rt>  7 Notable Legal Developments in Open Source in 2016 </rt> <rp>  ） </rp></ruby>。这并不一定意味着有 50 起诉讼，而是可能意味着 50 起威胁要提起诉讼的要求。但是，很难用公开信息来核实这个说法。有关详细信息，请参阅<ruby> <a href="https://www.slideshare.net/blackducksoftware/litigation-and-compliance-in-the-open-source-ecosystem">  《开源生态系统的诉讼和合规》 </a> <rp>  （ </rp> <rt>  Litigation and Compliance in the Open Source Ecosystem </rt> <rp>  ） </rp></ruby>。


### 为什么社区没有去阻止 McHardy？


包括软件自由保护组织在内的各种社区成员已经开始试图说服 McHardy 改变策略，但到目前为止还没有成功。 Netfilter 项目最近发布了一个[许可问答](http://www.netfilter.org/licensing.html)，解决大家对 McHardy 行为担忧的问题。


### 我们可以做些什么来阻止 McHardy 和其他版权牟利者？


这个问题没有确定的答案，也许没有办法能完全阻止他们。但是，这些建议可能会减少版权牟利者的数量。


* **尽可能遵守开源许可证。**目前有足够的资源来学习如何遵守许可证，以及如何在贵公司设立开源合规计划。例如：
	+ Linux基金会发布了<ruby> <a href="https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance">  《实用 GPL 合规手册》 </a> <rp>  （ </rp> <rt>  Practical GPL Compliance </rt> <rp>  ） </rp></ruby>。
	+ 软件自由法律中心发布了<ruby> <a href="https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html">  《GPL 合规实用指南” （第二版） 》 </a> <rp>  （ </rp> <rt>  A Practical Guide to GPL Compliance </rt> <rp>  ） </rp></ruby>。
	+ [OpenChain 项目](https://www.openchainproject.org/)发布了开源管理内部流程规范。
* **在寻求法律意见之前不要签署<ruby> “停止声明” <rp>  （ </rp> <rt>  Unterlassungserklärung </rt> <rp>  ） </rp></ruby>****。**如上所述，停止声明可能让您承担 GPL 身没有的义务和处罚。不要与版权牟利者合作。你可以使自己成为一个更难攻克的目标，并争取社区其他目标的帮助。
* **支持开源开发。**作者不应该诉诸投机来谋生。使用开源软件的公司不应该期望开源开发人员免费开发软件，他们应该筹集资金支持重要项目。
* **学会识别版权牟利者。**了解社区导向的 GPL 维权与版权勒索之间的一般差异。面向社区的维权一般旨在通过教育和帮助实现 GPL 合规，同时尊重用户的自由。相比之下，牟利行为可能侧重以不加考究和漫无目的的权力主张和威胁要提起法律诉讼来获得经济利益。注意确认优先考虑经济利益的权利主张，警惕不合理的损害赔偿金。
* **公开权利主张。**如果你是一个牟利者的目标，并且可以选择公开其权利主张，那就公开它，通过阻碍对方的行动来帮助你和其他人。作为开源社区的成员，我们都有义务向那些企图以诉讼拖垮社区的牟利者们提出反对，因为问题能够以更恰当和更少争议的方式解决。




---


作者简介：Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人，为客户提供技术交易和知识产权方面的建议，是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。<ruby> 《最佳律师》 <rp>  （ </rp> <rt>  Best Lawyers </rt> <rp>  ） </rp></ruby>将她提名为 2018 年年度 IT 律师。


译者简介：张琳，集慧智佳知识产权咨询公司分析师，专业德语，辅修法律。

