Twitter CEO：自动化会甚至会对编程工作构成威胁

Twitter CEO Jack Dorsey 表示，“机器学习和深度学习的许多目标是随着时间的发展编写软件本身，因此许多初级级编程工作将不再那么重要了，”

来源：新浪科技

硬核老王点评：毕竟“初级”编程工作也是要被取代的初级工种之一。

多个 DNS 解析程序漏洞允许攻击者发动拒绝服务攻击

该漏洞被称为 NXNSAttack。DNS 解析程序不能向“名字”发送域名查询，因此解析器首先需要获得权威 DNS 服务器的 IPv4 或 IPv6 地址，之后才能继续查询域名。NXNSAttack 就是基于这一原理，攻击者发送的委托包含了假的权威服务器名字，指向受害者的 DNS 服务器，迫使解析程序对受害者的 DNS 服务器生成查询。一次查询会被放大数十次乃至数百次，对受害者服务器发动了拒绝服务攻击。众多 DNS 软件都受到影响，其中包括 BIND、 Unbound、PowerDNS、Cloudflare、Google、Amazon、Microsoft、Oracle（DYN）、Verisign、IBM Quad9 和 ICANN。

来源：solidot

硬核老王点评：互联网建设和设计之初，并没有考虑到这么复杂的安全隐患，或者说考虑到了在当时也只能暂时忽视。随着互联网的发展，这种早期的协议上的漏洞会逐一被发现、修补和迭代。

GNOME 基金会和 RPI 的专利诉讼案达成和解

去年 9 月，Rothschild Patent Imaging LLC（RPI）的公司对 GNOME 基金会提起了专利侵权诉讼，指控 GNOME 桌面环境项目中的一个组件 Shotwell 照片管理器侵犯了它于 2008 年申请的专利，该专利描述了无线连接图像捕捉设备和接收设备的系统和方法。现在，GNOME 与 RPI 达成和解，RPI 并承诺不再对 GNOME 提起任何专利诉讼。此外，RPI 和 Leigh Rothschild 的专利免除和承诺覆盖了在 OSI 批准的所有开源许可证下发布的软件。

来源：solidot

硬核老王点评：妄想从开源社区/开源组织身上咬下一块肉，先要看看是否能承受社会压力。

安全研究人员分析过去几年发生的开源软件供应链攻击

软件供应链攻击有两类：其一是在软件产品中植入恶意代码去感染终端用户，此类攻击的一个例子是 CCleaner 的恶意版本通过官网传播给终端用户，它在长达一个多月时间里被下载了 230 万次。另一类软件供应链攻击是向软件产品的依赖包植入恶意代码。随着开源软件开发模式的流行，此类的攻击日益常见。研究人员分析了 npm、PyPI 和 RubyGems 软件包管理系统发现的 174 个恶意依赖包，他们发现 56% 的软件包在安装时触发恶意行为，41% 使用额外的条件去判断是否运行。61% 的恶意软件包利用了名字相似性向开源生态系统植入恶意包。攻击者的主要目的是析取数据。

来源：solidot

硬核老王点评：开源软件本身这个模式并不能决定是否安全，只是给用户一个安全的可能性。所以，在享受开源软件的福利时，其带来的可能的隐患也需要重视，并可能付出不菲的成本和代价。

微软开源 1983 年的 GW-BASIC

微软在历史参考和教育目的的名义下开源了 1983 年的 GW-BASIC，源代码托管在 GitHub 上，采用 MIT 许可证。微软表示他们不接受修改任何代码的 PR 请求。GW-BASIC 是源自 IBM Advanced BASIC/BASICA 的 BASIC 解释器。微软不同的 BASIC 实现都可以上溯到比尔盖茨和保罗艾伦完成的微软首个产品：Altair 8800 BASIC 解释器。和 70/80 年代的众多软件一样，GW-BASIC 的源代码是百分之百的汇编语言。

来源：solidot

硬核老王点评：反正放家里也是烂着，就当成古董给大家把玩吧。

两者之间的差异对我们如何构建软件开发过程产生了影响。

制定标准规范和开源软件的开发有许多共同之处：两者都是竞争者可以合作的机制；两者都可以促进互操作性；两者都可用于促进新技术的采用；两者都可用于聚合或协调成熟技术。

一项技术可以同时使用标准和开源：有时一个先于另一个；在其他情况下，它们可以并行进行。它们越来越多地使用类似的工具和流程实践（例如，细粒度版本控制；利用问题跟踪器一起推动某些开发讨论）。

相似程度可能导致过度概括，错误地暗示一切都是可互换的（混合与搭配），在这儿选择一种做法；在那儿将它与一个过程相结合。实际上，获取在一个领域中获得的经验并查看它提供的好处是否可以在其他环境中获得，可能是有价值的。但是，对于某些实践而言，背景更为重要。

虽然有相似之处，但也存在显著差异。在前面的文章《没有规则的治理：复刻潜力如何帮助项目》中，我讨论了在利用 复刻 （ forking ） 潜力作为一种可以促进轻量级治理的力量方面，开源软件开发和标准开发治理能力的不同。另一个不同之处在于专利规则的选择。

如何对待专利

参与者专利权的处理通常在开源软件开发和标准开发中以不同方式排列。这种差异有一个理由。而且，这种差异会对构建开发过程产生影响。

• 开源：在为开源项目做出贡献时授予的专利许可通常由每个贡献者的贡献确定。
• 标准：参与者在标准制定方面做出的专利承诺通常由整个最终规范确定。

开源项目：基于贡献的专利规则

基于贡献的专利规则是什么意思？如果专利所有者提供软件，由于软件添加到项目中，项目软件侵犯了该贡献者拥有的专利，那么贡献者不应该返回来期望获得使用它所贡献的软件的专利许可费。当然，有许多不同的许可文本可以让我们忙于分析每个许可的解释，并讨论情况中的不确定性和细微差别。在另一篇文章中，我在 MIT 许可协议的背景下谈到了这个问题（《为什么 MIT 的专利许可不讨人喜欢？》）。我认为，基本上来说，开源开发中的共同期望就像我上面所描述的那样：当你为开源做出贡献时，你将为你提供的软件提供所有必需的权限，之后你将无法返回来再要求获得使用你所贡献软件的许可费。

标准制定：基于标准规范的专利规则

相比之下，在制定标准时，通常会有更高的期望：参与者应对专利做出承诺，这些专利对整个最终规范至关重要，而不仅仅是对其贡献。这些专利承诺并不取决于确定谁对规范提出了什么想法；对于那些参与开发规范的人来说，他们的承诺是整个标准规范。

包括在其中的专利

确定相关专利的分析在软件和规范之间也有所不同。软件通常包括与相应的标准规范相比不需要的实现细节；在提供软件时，将包括对这些细节使用任何专利的许可。相反，规范开发的专利承诺仅限于对规范“必要”或“必需”的专利。当然，这取决于规范的内容。对于互操作性标准，规范应仅包括实现互操作性所需的详细级别，从而允许实现细节在标准的竞争性实现之间有所不同。对必要专利的承诺不包括实施细节方面的专利，这些专利可用作竞争优势。

专利规则差异的基础

为什么在专利处理方面存在这种差异？鉴于标准和开源软件的开发方式存在差异，这种不同的处理方式很有意义。

更有限的与贡献范围相关的专利符合大多数协作软件开发的渐进式、开放式特性。开源项目经常持续发展，其方向可能会随着时间的推移而演化。虽然可以设置路线图和里程碑并发布快照版本，但这些不太常见，并且比标准项目中常见的范围限制和版本目标具有更少的限制性影响。

可以看出，考虑到标准规范开发结构的差异，标准开发的更高期望值（整个最终规范，不仅仅是贡献）是有意义的。标准规范通常采用具有明确范围的强版本导向演进。规范开发通常适用于特定的快照版本。标准开发活动通常具有一组目标功能（通常在诸如章程之类的文档中表示）。与许多软件开发活动的情况相比，这为可能应用到标准开发活动的技术范围提供了更清晰的公共的进展预期。这种范围的明确性有助于潜在参与者在开始参与时评估参与标准制定项目的专利影响。相比之下，开源软件开发项目更为开放，通常不会排除采用任何特定技术的可能性。

对开源项目和标准管理的影响

这些对待专利的不同措施需要不同的项目管理方法。

开源项目通常准备接受来自新贡献者的补丁。贡献者可能会随着时间的推移而来去。一些贡献者留下来。其他人可能会为该项目来解决一个有限的问题。通过软件贡献，可以更容易地了解谁贡献了什么软件，而不是准确理解谁以一种更抽象的方式“参与”。

另一方面，参与标准制定活动通常具有大量的正式手续。而且，在涉及专利承诺时，这种参与的正式性非常重要。当一个人参与该规范的大部分开发时，对最终规范的专利承诺是有意义的。标准制定过程是否可以从提供单一、有限贡献的人那里获得完整的最终规范承诺？重要的是要有一个过程，以便清楚地了解谁参与谁，谁不参与。需要明确参与者以支持来自实际专利所有者的专利承诺，实际专利所有者通常是由坐在桌旁（比喻，尽管这可能涉及实际的谈判桌）的个人所代表的公司。

如何获得基于规范的承诺？软件标准中典型的免许可费专利承诺最常被作为获得标准组织成员资格或负责规范开发的特定委员会成员资格的条件。为了使这一机制发挥作用，成员资格必须是一个定义明确的概念，以便有一个明确的成员资格决策点（即，用于触发专利承诺的明确行动）和承诺的受益人可以依赖的明确的记录文件。除了参与清晰度之外，为了促进持怀疑态度的专利参与者的参与，项目需要具有明确的范围和明确的开始和结束（明确指出专利承诺将适用的“最终规范”）。这种参与模式与典型的开源项目有很大不同，典型的开源项目可能有一个连续的参与，其范围包括维护几个主要的驱动程序到只提交一个补丁。

专利政策

虽然我所描述的差异通常是这种情况，但某些特定活动遵循不同模式可能有一些原因。例如，考虑作为标准开发活动附带的参考实现的软件。可能有一个强有力的理由期望参与者对完整的最终参考实施提供承诺，而不仅仅是限定于他们对它的贡献。当然，可能存在其他边缘情况；可能存在严格安排的开源开发；可能会有连续的、随心所欲的规范开发。

标准制定的专利政策可分为合理和非歧视（RAND）或免许可费（RF）：基本上来说，实施标准的专利许可费包括需要交（RAND）或不需要交（RF）。制定与软件相关的标准（本文的重点）更多地使用免许可费政策。关于专利许可费预期问题是许可或承诺范围政策之外的另一个维度。

结论

标准的制定和开源软件的开发通常具有不同的参与者专利期望范围（仅限于贡献或整个最终可交付成果）。这些不同的选择基于通常如何进行开发的显著差异，而不是任意差异。

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

提要：对于面临滥用专利制度的实体发起诉讼威胁的技术公司和创新者来说，此案是一个重大胜利。

对于面临滥用专利制度的实体发起诉讼威胁的技术公司和创新者来说，日前美国最高法院对 Oil States 诉 Greene’s Energy 案做出的裁决是一个重大胜利。此类滥用专利制度的实体试图从创新者和创造就业机会的企业身上攫取价值。

在 Oil States 案中，美国最高法院对美国专利商标局（USPTO）一项旨在质疑此前授权但存在问题的专利是否有效的行政程序是否违宪做出了裁决。 专利流氓 （ patent trolls ） 最喜欢利用此类专利发起诉讼。这一称为 “双方复审” （ inter partes review ） 的程序已经成为一种应对基于可能无效专利而轻率发起的侵权主张的重要工具，其成本远低于在联邦法院检验此类专利有效性的成本。

美国国会根据 《2011年美国发明法案》 （ America Invents Act of 2011 ） 创建了这种双方复审程序，以清理美国国会所认为的大量被不当授权的专利。此类专利被专利流氓用于向创新者谋取费用。自 2012 年实施该程序以来，已经有 7000 多份申请被提交，主要是为了审查计算机和高科技领域的可疑专利，并且有超过 1300 项权利主张被裁定无效。

在 7 比 2 的多数意见中，托马斯法官表示：“授予专利的决定是涉及公共权利的事项。双方复审只是对该授权过程的再审，美国国会已经授权美国专利商标局实施此种再审。”法官认为双方复审程序并没有侵犯专利权人所拥有的案件需由联邦法院裁决（在联邦法院无效专利的成本更高，诉讼费用明显更为昂贵）的宪法权利。

与开发、销售或实施复杂技术的任何实体一样，开发或实施开源软件的成功企业是专利流氓诉讼威胁的颇有吸引力的目标。因此，确认双方复审程序的合宪性不仅提高了专利系统的质量，而且也保留了一种工具来保护开源技术免受那些滥用专利系统的实体的攻击。

美国专利商标局打算评估双方复审程序的实施情况，这可能会影响其作为防御工具的有效性。但科技行业人士应继续让政策制定者保留《2011 年美国发明法案》所带来的有益变革，以保护创新并阻止滥用专利的行为。

作者简介：Matt Krupnick 是 红帽公司 （ Red Hat ） 公共政策总监，于 2017 年加入红帽公司，负责政策制定以及为一系列对红帽公司及开源技术有潜在影响的各种政策问题提供建议。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

提要：传统观点认为，Apache 许可证拥有“真正”的专利许可，那 MIT 许可证呢？

我经常听到说，MIT 许可证中没有专利许可，或者它只有一些“默示”专利许可的可能性。如果 MIT 许可证很敏感的话，那么它可能会因为大家对其较为年轻的同伴 Apache 许可证的不断称赞而产生自卑感，传统观点认为，Apache 许可证拥有“真正”的专利许可。

这种区分经常重复出现，以至于人们认为，在许可证文本中是否出现“专利”一词具有很大的法律意义。不过，对“专利”一词的强调是错误的。1927 年，美国最高法院表示：

“专利所有人使用的任何语言，或者专利所有人向其他人展示的任何行为，使得其他人可以从中合理地推断出专利所有人同意他依据专利来制造、使用或销售，便构成了许可行为，并可以作为侵权行为的辩护理由。”

MIT 许可证无疑拥有明示许可。该许可证不限于授予任何特定类型的知识产权。但其许可证声明里不使用“专利”或“版权”一词。您上次听到有人表示担心 MIT 许可证仅包含默示版权许可是什么时候了？

既然授予权利的文本中没有“版权”和“专利”，让我们来研究一下 MIT 许可证中的字眼，看看我们能否了解到哪些权利被授予。

没有任何信息会导致人们认为，许可人会保留对使用专利所有人创造的软件的行为起诉专利侵权的权利，并允许其他人“无限制地处理本软件”。

为什么说这是默示专利许可呢？没有充足的理由这么做。我们来看一个默示专利许可的案例。Met-Coil Systems Corp. 诉Korners Unlimited 的专利纠纷涉及专利的默示许可（美国专利 4,466,641，很久以前已过期），该专利涉及用于连接供暖和空调系统中使用的金属管道段。处理该专利纠纷上诉的美国法院认定，专利权人（Met-Coil）出售其成型机（一种不属于专利保护主体的机器，但用于弯曲金属管道端部的法兰，使其作为以专利方式连接管道的一部分）授予其客户默示专利许可；因此，所谓的专利侵权者（Korners Unlimited）向这些客户出售某些与专利有关的部件（与 Met-Coil 机器弯曲产生的法兰一起使用的特殊角件）并不促成专利的侵权，因为客户被授予了许可（默示许可）。

通过销售其目的是在使用受专利保护的发明中发挥作用的金属弯曲机，专利权人向机器的购买者授予了专利许可。在 Met-Coil 案例中，可以看到需要谈论“默示”许可，因为根本不存在书面许可；法院也试图寻找由行为默示的许可。

现在，让我们回到 MIT 许可证。这是一个明示许可证。这个明示许可证授予了专利许可吗？事实上，在授予“无限制地处理软件”权限的情况下，MIT 许可证的确如此。没有比通过直接阅读授予许可的文字来得出结论更有效的办法了。

“明示专利许可”一词可以用于两种含义之一：

• 包括授予专利权利的明示许可证，或
• 明确提及专利权利的许可证。

其中第一项是与默示专利许可的对比。如果没有授予专利权利的明示许可，人们可以在分析中继续查看是否默示了专利许可。

人们经常使用第二个含义“明示专利许可”。不幸的是，这导致一些人错误地认为缺乏这样的“明示专利许可”会让人寻找默示许可。但是，第二种含义没有特别的法律意义。没有明确提及专利权利并不意味着没有授予专利权利的明示许可。因此，没有明确提及专利权利并不意味着仅受限于专利权利的默示许可。

说完这一切之后，那它究竟有多重要呢？

并没有多重要。当个人和企业根据 MIT 协议贡献软件时，他们并不希望稍后对那些使用专利所有人为之做出贡献的软件的人们主张专利权利。这是一个强有力的声明，当然，我没有直接看到贡献者的期望。但是根据 20 多年来我对依据 MIT 许可证贡献代码的观察，我没有看到任何迹象表明贡献者认为他们应该保留后续对使用其贡献的代码的行为征收专利许可费用的权利。恰恰相反，我观察到了与许可证中“无限制”这个短语一致的行为。

本讨论基于美国法律。其他司法管辖区的法律专家可以针对在其他国家的结果是否有所不同提出意见。

作者简介：Scott Peterson 是红帽公司（Red Hat）法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个决定性的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

提要：Apache 2.0许可证中的专利许可条款使得开源代码可以安全使用，但它经常被误解。

Apache 2.0 许可证包含许多关键条款，其中也包括根据我的经验经常被误解的 专利许可 （ patent grant ） 条款。专利许可对于开源代码的安全使用具有重大影响。我通过分析 Apache 2.0 许可证第 3 部分的其中一段来具体解释：

3. 专利许可的授予 （ Grant of Patent License ） 。根据本许可证的条款和条件，每个 贡献者 （ Contributor ） 特此授予您永久的、全球性的、非独占的、免费的、免版税的、不可撤销的（本节所述除外）专利许可，从而制作、委托制作、使用、许诺销售、销售、进口和以其他方式转移 作品 （ the Work ） ，该专利许可仅适用于贡献者提供的满足以下条件的专利权利要求：贡献者的 贡献 （ Contribution ） 单独对该权利要求必然构成侵权，或贡献者的贡献与贡献者提交此类贡献的作品之间的结合对该权利要求必然构成侵权。

实质上，当软件开发人员为项目（即 Apache 2.0 许可证中的“作品”）贡献代码，他/她就成为贡献者。在上述条款中，贡献者授予了使用任何可能与其贡献相关的专利的许可。这让用户感到安心，因为贡献者可能会被禁止向任何使用包含该贡献的软件的用户收取专利许可费。

但当软件开发人员贡献的代码仅其自身来说没有被贡献者的任何专利所覆盖，而只有与贡献者提交此类贡献的遵循 Apache 2.0 许可证的开源项目相结合才能被相关专利覆盖时，问题就变得复杂了。因此，拥有相关专利的贡献者可以向使用修订版作品的用户收取专利许可费。Apache 2.0 许可证的作者进行了前瞻性思考，对这种情况也进行了说明。第 3 条规定，该许可证适用于“贡献者提供的满足以下条件的专利权利要求：……贡献者的贡献与贡献者提交此类贡献的作品之间的结合对该权利要求必然构成侵权。”

一些贡献者可能担心他们的贡献会导致广泛的专利许可。例如，您向遵循 Apache 2.0 许可证的开源项目贡献代码，在您提交贡献的时候，无论是您的贡献自身还是其与开源项目的结合都没有对您的专利构成侵权，但后续该作品通过其他人而非您的贡献在功能上进行了扩展，从而被您的专利所覆盖，这种情况该怎么办呢？您的专利会被自动许可吗？按照 Apache 软件基金会的常见问题解答，情况并非如此。

这个结果似乎以一种开放/合作的方式，在向 Apache 2.0 开源项目贡献代码的专利所有者与保证相关专利不会针对依据 Apache 2.0 许可证享有权益的作品用户主张专利权的必要性之间，达成了一种明智的平衡。

关于依据 Apache 2.0 许可证向 Apache 软件基金会提交贡献的专利许可范围的相关问题和答案，可以在 Apache 软件基金会有关许可的常见问题解答里找到。

请记住，这是 Apache 软件基金会对 Apache 2.0 许可证的解释。使用 Apache 2.0 许可证的其他许可人可能会以不同的方式解释该许可证中专利许可条款的范围，但我认为那似乎不太可能会成功，Apache 软件基金会的常见问题解答对专利许可条款的解释看起来合情合理。

作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 Red Hat 公司的开源知识产权律师，还担任 托马斯杰斐逊法学院 （ Thomas Jefferson School of Law ） 的兼职教授。在任职 Red Hat 之前，Jeffrey曾担任 高通公司 （ Qualcomm Incorporated ） 的专利顾问，为 首席科学家办公室 （ Office of the Chief Scientist ） 提供开源事务咨询。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

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

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

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

McHardy 对 Linux 有多少贡献？

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

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

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

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

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

Hellwig 诉 VMware 一案中出现了使用开发存储库的元数据确认版权所有权的困难。法院可能不愿意接受这样的信息来作为证明作者身份的证据。

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

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

什么是 “社区维权” （ community enforcement ） ？

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

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

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

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

McHardy 发起了多少权利主张？

由于许多德国法庭案件缺乏公开记录，因此很难确定 McHardy 的确切行动数量。据说 McHardy 已经接触了超过 50 个维权目标。有关详细信息，请参阅 “源码控制” （ Source Code Control ） 和 《2016 年开源社区 7 个显著的法律进展》 （ 7 Notable Legal Developments in Open Source in 2016 ） 。这并不一定意味着有 50 起诉讼，而是可能意味着 50 起威胁要提起诉讼的要求。但是，很难用公开信息来核实这个说法。有关详细信息，请参阅 《开源生态系统的诉讼和合规》 （ Litigation and Compliance in the Open Source Ecosystem ） 。

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

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

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

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

• 尽可能遵守开源许可证。目前有足够的资源来学习如何遵守许可证，以及如何在贵公司设立开源合规计划。例如：

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

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

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