Heather Meeker 发布的文章

提要: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 和其他版权牟利者?

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

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

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

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

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

开源软件虽然可以免费使用,但就如同饲养一条幼犬一样(开始虽然花钱不多,后边越养越费钱)。在采用开源之前,确保能够了解其隐藏的成本和陷阱。

对于初创公司来说,开源软件是一把双刃剑。它可以成为一家创业公司的生命线,因为开源软件可以帮助初创企业快速创新,而不必从头开始。不过,正如有些人所说的,开源软件虽然可以免费使用,但就如同饲养一条幼犬一样,开始虽然花钱不多,后边越养越费钱。开源软件的真正代价是开源许可证合规成本。

滥用开源软件可能会造成获得投资的机遇被延迟或破坏。但是,如果遵守这些简单的法则,初创企业可以轻松地实现开源许可证合规。

法则一:不使用没有许可条款的软件

互联网上的一些软件不包含许可证通知,但这不意味它们可以自由使用。发布软件的人可能没有遵守上游许可条款。或者软件的作者可能尚未为其软件指定许可协议——无论是以开源方式亦或是其他方式。“没有许可条款”是指没有许可证:您应该避免使用该软件或要求作者为其该软件指定许可证。

法则二:不要违反开源许可证

开源软件的使用可能难以让其作者进行追踪,但并不意味着该软件的使用和不合规行为会被忽视。违反开源许可证可能会使初创公司面临法律责任和公众谴责,甚至可能会影响其被投资或收购。也可能导致潜在客户由于担心下游责任而拒绝购买您的产品。软件开发人员为实现其软件开源付出了巨大的努力,其中也包括上述的许可费用。滥用开源软件对这些开发人员是不公平的,并且损害了他们希望促成的创新。

法则三:跟踪您正在使用的软件

将来有一天您将必须提供您正在使用的开源软件的列表。及时维护该列表将会为您节约大量的时间和精力,因为潜在的投资者和收购方将会要求您提供该列表。大多数开源软件下载包中都包括一个 “license.txt” 或 “copy.txt” 文件。保留该许可证的副本,并记录其涵盖的软件。大多数创业公司都使用简单的电子表格跟踪软件许可情况。

法则四:了解 宽松 ( permissive ) 许可证和 左版 ( copyleft ) 许可证

开源许可证大致分为两种类型:宽松许可证(BSD、MIT 和 Apache)和左版许可证(GPL、LGPL、Eclipse 公共许可证、Mozilla 公共许可证以及 通用开发和分发许可证 ( Common Development and Distribution License ) )。大多数公司及其客户对于使用遵循宽松许可证的软件没有什么法律上的担心。不过,遵循左版许可证需要更加谨慎,将软件保留为专有可能会与某些特定计划不一致。

法则五:遵守许可证 通知 ( notice ) 要求

无论是宽松许可证还是左版许可证,所有开源许可都有通知要求。通常,这意味着在分发开源软件时,您需要包含其所适用的许可证的副本,仅仅包括许可证的链接或缩略形式通常是不完备的。为了避免混淆或疏离您的客户,开发一个符合大多数开源许可证的通知传送策略非常重要。

法则六:了解哪些开源许可证与分布式软件兼容

除了 Affero GPL 之外,大多数开源许可证都没有涉及软件即服务(SaaS)的情境。对于 SaaS 和云系统的分布式组件(如 JavaScript)或分布式软件(包括移动 APP 和测试版),您可以使用遵循宽松许可证的软件,但在使用遵循左版许可证的软件之前,您需要特别小心。仅在其完全在自己的进程中执行并且没有链接的代码时才去使用遵循 GPL 的软件,而不要相信以下如何让 GPL 合规的谣传:动态链接至 GPL 代码或让客户下载 GPL 软件。仅将 LGPL 软件作为动态链接库进行使用。在不修改 API 的前提下使用遵循其它左版许可证的软件。遵循移动 APP 市场的分发规定也许与遵循某些特定的左版许可证有冲突(例如 GPL 或者 LGPL)。

法则七:在咨询律师之前不要贡献或发布开源软件

贡献和发布开源软件可能是公众的福音,但它可能不是您业务上的正确选择。一旦作出贡献或发布,您在软件中拥有的任何知识产权将不大可能构成您公司估值的依据。您的律师可以帮助您更好地理解在专有和开源软件之间如何选择,并对这一重要业务决策提供指导。

法则八:确保您的员工和第三方开发人员遵守这些规则

不管是由于您的员工或第三方承包商造成的开源违规行为,所引起的法律和宣传问题都将砸在您的头上。您可以通过适当的培训和跟踪开源软件来避免这些问题。

法则九:规划未来

初创公司业务模式可以快速变化。SaaS 模式可以快速转变为分布式软件模式。无论您当前的模式是什么,遵守分布式软件的规则将为您转变为分布式软件模式提供更大的灵活性,而无需删除某些开源软件并更改相关功能。

采用这些法则将有助于初创企业利用开源软件的优势,降低您在获取投资或收购时遇到的风险。对您的初创企业感兴趣的第三方想知道您如何应对开源软件问题,确保您做好准备,并能够为他们提供积极和专业的答案。

(题图:Beth Cortez-Neavel on Flickr. Public Domain. Modified by Opensource.com)


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

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

对 Apache 基金会禁止将 BSD+专利许可证(FB + PL)用于其项目的批评,在理性的审视之下是无法成立的。

最近,Apache 基金会将 Facebook 公司 BSD + 专利许可证下的代码重新分类为 “X 类”,从而有效地阻止了其未来对 Apache 基金会项目的贡献。这一举动再度引发了对专利授权的争议,但是像开源社区的许多事件一样,与实际情况相比,这个争议更具倾向性。事实上,这样做不太可能影响 React.js 的采用,对 BSD +专利许可证(FB + PL)的批评大多数不能在理性的审视下成立。

官方名称为“专利权的补充授权第二版”的 Facebook 专利授权条款已经生效多年。它用于非常受欢迎的 React.js 代码,该代码是一种用于呈现用户界面的 JavaScript 库。使用该代码的主要技术公司的名单令人印象深刻,其中包括像 Netflix 这样面向消费者的巨头公司,当然还有 Facebook 自身。(LCTT 译注:国内包括百度、阿里云等顶级互联网公司也在使用它,但是据闻这些公司在纷纷考虑更换对该库的依赖。)

对旧授权的新反应

对这个消息的反应是令人惊讶的,因为并行专利许可模式并不是什么新鲜事。 Facebook 在 2013 年发布了 BSD + 专利授权许可证(2015 年进行了修订)。而 Google 2010 年也在 WebM 编解码器上有些高调地使用了类似的模型。该许可模式涉及两个并列和同时授权的权利:软件版权的 BSD 许可,以及单独授予的执行该软件的专利授权。将两者合在一起意味着有两个独立和平行的授权权利。在这方面,它与 Apache 2.0 许可证非常相似,与 BSD 一样,Apache 2.0 是一个许可证,并且还包含与版权许可授权一起存在的防御性终止条款。

对 Apache 基金会通告的大部分反应造成了混乱,例如有篇文章误导性地称之为“陷阱”。事实上,许多开源许可证都有防御性的终止条款,这些规定大多被认为是阻止专利诉讼的合理机制,而不是陷阱。它们是规则而不是例外;所有具有专利授权的主要开源许可证也具有防御性的终止条款——虽然每个条款略有不同。在 Apache 所拒绝的 Facebook 专利授权与 Apache 对其项目所采取的 Apache 2.0 许可证之间,其中的区别比争议提出的更为微妙。

防御性终止条款有多种风格

防御性终止条款在两个主要方面有所不同:终止条款的触发和权利终止的范围。

关于权利终止的范围,有两个阵营:仅终止专利授权(包括 Apache 2.0、Eclipse 公共许可证和 Facebook 专利授权)以及也同时终止版权许可(Mozilla 公共许可证和 GPL v3)。换句话说,对于大多数的许可证,提起专利侵权诉讼只能导致专利权的终止;对于其他许可证来说,提起专利诉讼能够同时导致版权许可的终止,即让某人停止使用该代码。版权许可终止是一个更强大的反专利机制,对于私营企业来说风险更大,因此导致一些私营公司拒绝使用 GPL v3 或 MPL 代码。

与大多数其他开源许可证相比,Facebook 专利授权触发终止的阈值不同。例如,在 Apache 2.0 中,专利授权的终止是由对该许可证下的软件提出指控的专利权利主张引发的。这个想法是为软件创建一个 “专利共同体” ( patent commons ) 。大多数其他开源许可证大致遵循这个推演。(但在 Facebook 许可证中,)如果被许可人向 Facebook 或任何对 Facebook 产品提出指控的第三方提出权利主张,Facebook 专利许可也将终止。在这方面,终止触发机制类似于 IBM 多年前撰写的 Common Public License 1.0 (CPL)中的终止触发机制。(“如果接收者利用适用于本软件的专利对贡献者提出专利诉讼,则该贡献者根据本协议授予该接收者的任何专利许可,将在提起诉讼之日终止。”)

天下无新事

Facebook 授权范围的防御性终止条款在开源场景之外的专利许可中很常见。如果被许可人向许可人提出专利权利主张,大多数专利许可将被终止。原因是许可人不想在专利战争中被单方面“解除武装”。大多数专利只有在竞争对手起诉专利所有人时才被防御性使用。A 起诉 B,然后 B 起诉 A,导致互相伤害。如果 B 在没有广泛的防御性终止条款的情况下以开源许可证发布其软件,则 B 可能没有追索权,并且为其开源代码的发布付出高昂的代价。A 在免费利用 B 的软件进行开发的同时,还起诉 B 专利侵权。

最后,Facebook 专利授权本身并不新鲜。该授权于 2013 年发布,自那时起,React.js 的受欢迎程度一直在增长。与许多开源许可证一样,行业忍受新许可证的意愿取决于其下发布的代码的质量。在 React.js 代码质量非常好的情况下,这个专利许可条款虽然是新的,但合理。

还是开源吗?

有些人认为 BSD + 专利条款违反 “开源定义” ( Open Source Definition ) 。OSD 不接受歧视个人、团体或领域的许可证。但专利授权没有许可范围限制;如果被许可人有不当行为,许可就会终止,并且与其他人相比,针对代码作者的不当行为的触发门槛更低。因此,BSD + 专利许可似乎并不违反 OSD,而且 CPL 已经被 OSI 认可为合规的。如同 BSD + 专利许可一样,CPL 根据针对代码作者的专利诉讼,设定了一个较低的终止门槛。

结果是什么?

Apache 基金会决定的实际结果尚不清楚。 遵循 X 类许可的代码不能包含在 Apache 基金会的存储库中(该类别还包括 GPL 等许可证)。Apache 的重新分类并不意味着任何人都不能使用 React.js——它只是不能在 Apache 项目中被提交。目前甚至不清楚 Apache 项目是否包含对 BSD + 专利许可代码的依赖。

同时,在私营企业中,根据 BSD + 专利条款使用代码几乎没有争议。大多数公司已经检查了该许可证与其他许可证(如 Apache 2.0)相比的边际法律风险,并认为没有需要特别注意的地方。除非公司决定起诉 Facebook(或指控其产品侵权),否则终止触发机制没有实际效果。如果您想要在开发和发布一大堆代码的公司中发起专利权利主张,将该代码从您的业务中删除似乎是一种合理的代价。

有些争议似乎起因于担心 Facebook 在许可条款中比其他人占优。但是,这与伤害开源社区是不一样的。与 Apache 2.0 一样,BSD + 专利授权以“专利共同体”为基准建立,但是为贡献者(Facebook)针对被许可人的软件专利权利主张提供了更多的保护。很奇怪的是,一个如此反对软件专利的社区会发现这是令人反感的,特别是考虑到过去使用的一系列防御性终止规定。

请注意:此文章是关于 BSD + 专利许可,而不是关于 Facebook 公司。这篇文章仅代表作者的个人观点,而不是 Facebook 的观点。作者在开源事务上代表 Facebook,但作者没有起草 BSD + 专利许可证。

(题图:techtimes.com)


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

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