分类 开源智慧 下的文章

关于 React.js 的开源许可证从去年 7 月份争议到现在,Apache 基金会终于确认了立场,反对使用 React.js 和 Facebook 其他使用此许可证(BSD+Patents licensed)的流行软件。

最近,随着开源运动不断壮大,这边 LC3 大会刚过去不久,人们的热情还是未曾消去,那边 Apache 和 Facebook 又搅动着整个社区。

作为本次事件焦点的 Facebook Patents license 已经不是第一次出风头了,时不时成为人们讨论的主题。

上一次挑动大众神经是在 2016 年 7 月,Facebook 给 React 应用的开源许可协议是,在 BSD3-clause 协议基础上加上旨在保护 Facebook 自身的扩展协议。而这一次依然是围绕 Facebook Patents license 展开,简单梳理此次事件:

  • 2017 年 4 月,Apache Cassandra 项目正考虑增加 RocksDB 作为存储引擎,但考虑到专利授权的问题,Jeff Jirsa 向 Apache 法律社区寻求意见。
  • 2017 年 6 月,Apache 法律社区开始讨论 Facebook Patents license 协议专利授权的不对称性问题,且该协议与Apache Software License(即 Apache 2.0 等)不兼容。
  • 2017 年 7 月 15 日,Apache Software Foundation(以下简称 ASF)主管兼法律事务副主席 Chris Mattmann 正式发表声明称:Facebook BSD+Patents license(以下简称 FB+PL)已经正式被列入 “CategoryX” 列表,因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码;而已经发布的代码,涉及 FB+PL 许可证的,需要在 8 月 31 号前完成替换。

这一结论一出场便自带光环,引起了整个社区的关注,包括国内著名社交论坛知乎。当然,其对 Apache 项目自身的影响不比外界的关注度低。

如,虽然 Facebook 已于本月 17 号将 RocksDB 许可证更新为 Apache 2.0 和 GPLv2 双许可,但更大的问题是 React 也是基于 FB+PL 开源,Apache 的 CouchDB 项目、Apache Superset 项目等都依赖于 React,但是要让其开发人员在一个月内摆脱对 React 的依赖似乎也不是一件简单的事情。

到底是什么原因让 ASF 对 Facebook 的 FB+PL 许可协议下禁止令?要回答这个问题,需要先分析一下 FB+PL 许可协议。

众所周知,Facebook 也算是开源社区的中坚力量,截至目前已经发布了很多开源软件技术,包括使用广泛的 React.JS 框架和键值数据库 RocksDB。

不过,Facebook 没有像其他社区一样,自定义自己的开源许可证,也没有仅采用现存的开源许可证,而是采用 “BSD+Patents license” 许可证组合授权其大部分项目,该协议组合也被称为 FB+PL 组合。

其中,BSD 是指 BSD3-clause license,是被 OSI 和 FSF 都认可的开源软件许可证,也是被业界称为“宽松型”的开源许可证。

正是这个“宽松型”的 BSD 许可证附加了专利条款的开源许可协议,已经被 ASF 列为 “Category X”,杜绝了任何以 FB+PL 授权的软件进入 Apache 项目中的可能性,等于 FB+PL 已被 Apache 明确打入冷宫。

FB+PL 协议中,BSD3-clause license 本身没有问题,问题自然就出在 Facebook Patents license,即 Facebook 开源软件组合协议 FB+PL 中的附加专利许可条款。

以下是 Facebook Patents license 条款内容

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software. Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent
infringement against you in the first instance, and you respond by filing a
patent infringement counterclaim in that lawsuit against that party that is
unrelated to the Software, the license granted hereunder will not terminate
under section (i) of this paragraph due to such counterclaim.

A "Necessary Claim" is a claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone.

A "Patent Assertion" is any lawsuit or other action alleging direct, indirect,
or contributory infringement or inducement to infringe any patent, including a
cross-claim or counterclaim.

就是以上这段不算长的附加专利授权条款,让不少开发者甚至开源社区组织顾虑重重。

对开源运动有了解的人可能都知道,开源社区对专利非常敏感,甚至有开源大佬和前辈毫不掩饰对软件专利的厌恶和痛恨。更甚者,国外有专门的反软件专利组织,但毕竟专利制度是很多国家的法律制度,不可能受某个人或某一个群体的人的意见而转移。

因此,开源社区能做的就是改变自己以及影响自己可以影响的人,所以不少开源软件许可证都有针对专利的规范条款。

不过,对于 Facebook 附加专利许可协议,开源圈内人士从一开始都不是特别待见。甚至一些反对软件专利的人认为 FB+PL 协议关于专利的授权,拥有这样的专利授权比没有这样的授权更糟糕。

究其原因,从以上 Facebook Additional Grant of Patent Rights(附加专利授权条款)可以看出,该协议是一个单边优惠协议,授予人和被授予人的权利不平衡。

简单说就是基于 FB+PL 授权的软件使用者以及基于 FB+PL 开发衍生代码的开发者,与 Facebook 的权利不平衡。一旦被许可人对 Facebook 及其子公司甚至关联公司提出直接的或间接专利诉讼,无论该诉讼是与所涉及项目有关还是无关,亦或是硬件专利诉讼,甚至是 Facebook 主动提出的专利诉讼而被告者进行的专利反诉,该协议授予用户的专利权利即刻自动终止。

另外,2015 年 4 月 10 以前,Facebook Additional Grant of Patent Rights 第一版中,针对 Facebook 任何形式的诉讼,包括反诉、以及与专利无关的诉讼,都会导致基于该协议的专利授权自动终止。后来由于社区人员对该条款争议较大, Facebook 进行了修改,也即是目前的第二版

值得一提的是,在众多的开源许可证中,有专利权利终止以及许可证权利终止条款的许可证并不少见,例如,Apache2.0 以及GPLv2/v3 都有关于权利终止的条款约束。之所以 FB+PL 会有如此强烈的反应关键有两点:

  1. FB+PL 专利终止条款过于宽泛;
  2. FB+PL 专利条款使得被授予者与 Facebook 之间的权利不平衡。

从另一个层面上讲,Facebook 附加专利授权条款的存在也不是全无道理,毕竟开源软件无时无刻不在承受着来自软件专利的威胁。尽管这些年软件专利没有成功将开源运动送入坟墓,反而使其不断壮大,而开源社区对专利的排斥和恐惧却已深入骨髓。

Facebook 作为开源领域一员猛将,并且已经开源了大量的代码和技术,将所有可能导致侵权的专利技术授权给用户。另一方面,为了自身防护的原因,想办法建立一种自保的机制也在情理之中,毕竟谁都不想成为被鱼肉被屠宰的一方。

整体来讲,Facebook 附加专利授权条款是一个带有严格的惩罚性措施的协议,其严厉性特别表现在其第一版,虽然在第二版中,将诉讼范围限定于专利诉讼,但在许多人看来其范围依然是过大。

Facebook 附加专利授权条款有一种过激的表现,但是如果你能想象一个刚刚崭露头角的少年,还未有可观的积蓄(专利),在群狼环嗣,个个武装到牙齿的对手面前,那种本能的警惕,也许会对 Facebook 多少有点理解。

毕竟,即便 Facebook 附加专利授权条款在严格,对于个人开发者,以及不喜欢搞专利诉讼的组织来说,大家彼此相安无事,也不失为一件好事。

就我个人来讲,我对 Facebook 之于开源的真诚性是认可的。

目前,虽然“ 开源软件 Open Source Software ”和“ 自由软件 Free Software ”两种哲学理念还存在分歧,但很多社区以及组织包括像 Facebook 这样自我保护略显偏激的组织,都是开源/自由软件理念真诚的践行者。还有一部分像微软一样“从良”的,也为开源做了不少贡献,像这种老牌的商业公司背负了太多的包袱,一下子转身可能性不大。

当然,浑水摸鱼以及投机的分子也肯定不少。不过,开源是软件开发的未来趋势和必然走向,开源理念不仅避免了重复开发中时间、人力和资金了浪费,更是智力共享、集体智慧的完美实践。

因此,虽然目前开源运动还存在着种种的冲突和矛盾,但就像所有的新生事物一样,从萌芽到成长再到成熟都会有一个过程,而在这个过程中磕磕绊绊在所难免。

整体上说,这次 Apache 对 Facebook 附加专利授权条款下禁止令,只是开源运动在一件小事,而开源的生命力正是在这种碰撞、冲突和磨合中逐渐显现,慢慢成熟。

(题图:react-etc.net)


作者简介:付钦伟,专利代理人、专利咨询师,任职于集慧智佳知识产权咨询公司。研究生选专业“误入歧途”,进入高大上的知识产权领域,目前从事专利咨询分析工作,励志为中国知识产权事业抛头颅、洒热血。

本文由高级咨询师薛亮据自由软件基金会(FSF)的英文原文翻译而成,这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题,对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据 GNU 许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

1、关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题

1.1 “GPL” 代表什么意思?

“GPL” 代表“ 通用公共许可证 General Public License ”。 最常见的此类许可证是 GNU 通用公共许可证,简称 GNU GPL。 如果人们能够自然而然地将其理解为 GNU GPL,可以进一步缩短为“GPL”。

1.2 自由软件是否意味着必须使用 GPL?

根本不是的,还有许多其他自由软件许可证。我们有一个不完整的列表。任何为用户提供特定自由的许可证都是自由软件许可证。

1.3 为什么我要使用 GNU GPL,而不是其他自由软件许可证?

使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过,在某些特殊情况下,最好使用一个更宽松的许可证。

1.4 所有 GNU 软件都使用 GNU GPL 作为其许可证吗?

大多数 GNU 软件包都使用 GNU GPL,但是有一些 GNU 程序(以及程序的一部分)使用更宽松的许可证,例如 LGPL( 较宽松公共许可证 Lesser GPL )。我们这样做是基于战略考虑。

1.5 如果一个程序使用 GPL 许可证,是否会使其成为 GNU 软件?

任何人都可以依据 GNU GPL 发布一个程序,但并不能使其成为 GNU 软件包。

让程序成为 GNU 软件包意味着将其明确地贡献给 GNU 项目。当程序的开发人员和 GNU 项目都同意这样做时,才会发生这种情况。如果您有兴趣向 GNU 项目贡献程序,请写信至 mailto:[email protected]

1.6 我可以将 GPL 应用于软件以外的其他作品吗?

您可以将 GPL 应用于任何类型的作品,只需明确该作品的“源代码”构成即可。 GPL 将“源代码”定义为作品的首选形式,以便在其中进行修改。

不过,对于手册和教科书,或更一般地,任何旨在教授某个主题的作品,我们建议使用 GFDL,而非 GPL。

1.7 手册为什么不使用 GPL 许可证?

手册也可以使用 GPL 许可证,但对于手册来说,最好使用 GFDL( 自由文本授权 GNU Free Documentation License )许可证。

GPL 是为软件程序设计的,它包含许多复杂的条款,对于程序来说至关重要;但对于图书或手册来说,这将是麻烦和不必要的。例如,任何人如果(以 GPL )出版纸质图书,就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”,或提供书面文件,表明将稍后发送“源代码”。

同时,GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款,例如,出售封面文字。 背书 Endorsements 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的,但该修改版本不能被标记为“该标准”。

使用 GFDL,我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要,因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由,它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” invariant ,使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。

1.8 GPL 被翻译成其他语言了吗?

将 GPL 翻译成英文以外的语言将是有用的。人们甚至进行了翻译,并将文本发送给我们。但我们不敢将翻译文本批准为正式有效。其中的风险如此之大,以至于我们不敢接受。

法律文件在某种程度上就像一个程序。翻译它就像将程序从一种语言和操作系统转换到另一种语言。只有同时熟练使用这两种语言的律师才能做到这一点——即便如此,也有引入错误的风险。

如果我们正式批准 GPL 的翻译文本,我们将不得不给予所有人许可,让他们可以去做翻译文本规定可以做的任何事情。如果这是一个完全准确的翻译,那没关系。但如果翻译错误,后果可能是我们无法解决的灾难。

如果一个程序有 bug,我们可以发布一个新的版本,最终旧版本将会逐渐消失。但是,一旦我们给予每个人去根据特定翻译文本行事的许可,如果我们稍后发现它有一个错误,我们无法收回该权限。

乐意提供帮助的人有时会为我们做翻译工作。如果问题是要找人做这个工作的话,那问题就解决了。但实际的问题是错误的风险,做翻译工作不能避免风险。我们无法授权非律师撰写的翻译文本。

因此,目前我们并不认可GPL的翻译文本是全球有效和具有约束力的。相反,我们正在做两件事情:

  • 将非正式的翻译指引给人们。这意味着我们允许人们进行GPL的翻译,但是我们不认可翻译文本具有法律效力和约束力。
    未经批准的翻译文本没有法律效力,应该如此明确地表述。翻译文本应标明如下:
This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English).
本 GPL 翻译文本是非正式的,没有被自由软件基金会(FSF)正式批准为有效。若要完全确定何种行为被允许,请参阅原始 GPL(英文)。

但未经批准的翻译文本可以作为如何理解英文 GPL 的参考。对于许多用户来说,这就足够了。不过,在商业活动中使用 GNU 软件的企业,以及进行公共 ftp 发行的人员,需要去核查实际的英文 GPL,以明确其允许的行为。

  • 发布仅在单个国家/地区有效的翻译文本。
    我们正在考虑发布仅在单个国家正式生效的翻译文本。这样一来,如果发现有错误,那么错误将局限于这个国家,破坏力不会太大。
    即便是一个富有同情心和能力的律师来做翻译,仍然需要相当多的专门知识和努力,所以我们不能很快答应任何这样的翻译。

1.9 为什么有一些 GNU 库依据普通 GPL 而不是 LGPL 来发布?

对于任何特定库使用 LGPL 构成了自由软件的倒退。这意味着我们部分放弃了捍卫用户自由权利的努力,对基于 GPL 软件所构建产品的分享要求也降低了。在它们自身而言,这是更糟糕的变化。

有时一个小范围的倒退是很好的策略。某种情况下,使用 LGPL 的库可能会带来该库的广泛使用,从而进一步改善该库,为自由软件带来更广泛的支持,诸如此类。如果在相当大的程度上出现这种情况,这可能对自由软件很有好处。但它发生的几率有多少呢?我们只能推测。

在每个库上用一段时间的 LGPL,看看它是否有帮助,如果 LGPL 没有帮助,再将其更改为 GPL。这种做法听起来很好,但却是不可行的。一旦我们对特定库使用了 LGPL,那就很难进行改变。因此,我们根据具体情况决定每个库使用哪个许可证。对于我们如何判断该问题,有一段很长的解释

1.10 谁有权力执行 GPL 许可证?

由于 GPL 是版权许可,软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为,您应该向遵循GPL的该软件的开发人员通报。他们是版权所有者,或与版权所有者有关。若要详细了解如何报告 GPL 违规,请参阅“如果发现了可能违反 GPL 许可证的行为,我该怎么办?

1.11 为什么 FSF 要求为 FSF 拥有版权的程序做出贡献的贡献者将版权 分配 assign 给 FSF?如果我持有 GPL 程序的版权,我也应该这样做吗?如果是,怎么做?

我们的律师告诉我们,为了最大限度地向法院要求违规者强制执行 GPL,我们应该让程序的版权状况尽可能简单。为了做到这一点,我们要求每个贡献者将贡献部分的版权分配给 FSF,或者放弃对贡献部分的版权要求。

我们也要求个人贡献者从雇主那里获得版权放弃声明(如果有的话),以确保雇主不会声称拥有这部分贡献的版权。

当然,如果所有的贡献者把他们的代码放在公共领域,也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权,只把小规模的修改放在公共领域。

如果您想要在您的程序中执行 GPL,遵循类似的策略可能是一个好主意。如果您需要更多信息,请联系 mailto:[email protected]

1.12 我可以修改 GPL 并创建一个修改后的许可证吗?

您可以制作GPL的修改版本,但这往往会产生实践上的后果。

您可以在其他许可证中合法使用GPL条款(可能是修改过的),只要您以其他名称来称呼您的许可证,并且不包括 GPL 的 引言 preamble ,只要您对最后的使用说明进行了足够多的修改,使其措辞明显不同,没有提到 GNU(尽管您描述的实际过程可能与其类似)。

如果您想在修改后的许可证中使用我们的引言,请写信至 mailto:[email protected],以获得许可。我们需要查看实际的许可证要求,才能决定我们是否能够批准它们。

虽然我们不会以这种方式对您修改许可证提出法律上的反对意见,但我们希望您三思而行,别去修改许可证。类似这些修改后的许可证几乎肯定与 GNU GPL 不兼容,并且这种不兼容性阻碍了模块之间的有用组合。

不同自由软件许可证的扩散本身就是一个负担。请使用 GPL v3 提供的 例外 exception 机制,而不是去修改 GPL。

1.13 为什么你们决定将 GNU Affero GPL v3 作为一个单独的许可证?

GPLv3 的早期草案在第 7 节中允许许可人在发布源代码时添加一个类似 Affero 的要求。但是,一些开发和依赖自由软件的公司认为这个要求太过繁重。他们希望避免使用遵循这个要求的代码,并且对检查代码是否符合这个附加要求所带来的管理成本表示担忧。通过将 GNU Affero GPL v3 作为单独的许可证发布,在该许可证以及 GPL v3 中允许遵循该许可证的代码链接到彼此,我们完成了所有最初的目标,同时更容易确定哪些源代码需要遵循发布要求。

(题图:pycom.io)


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

在 2016 年 7 月,Facebook 公司的 React.js 开源许可协议曾引起激烈争论。一年过后,该协议再次成为开源社区的头条新闻。

背景介绍

React.js 是 Facebook 推出的一个用来构建用户界面的 JavaScript 库,起源于 Facebook 的内部项目,用来架设 Instagram 的网站。

  • 2013 年 5 月,Facebook 将 React.js 开源
  • 2016 年 7月,React.js 开源许可协议中的附加专利条款引发争议。
  • 2016 年 11 月,Facebook 发布官方问答,对附加专利条款进行澄清。
  • 2017 年 7 月,Apache 基金会禁止使用遵循 BSD 许可证 + 专利开源协议的 JAR 包。

Apache 基金会的立场

2017 年 7 月,针对 Facebook 公司的 BSD 许可证 + 专利开源协议,Apache 基金会提出了如下建议:

  1. 任何新项目、子项目或代码库都不允许使用遵循 Facebook 公司 “BSD 许可证 + 专利开源协议”的 jar 包。换句话说,如果你之前没有使用过,之后也不允许去使用。这种许可协议被 Apache 基金会列为 X 类别(Cat-X)。
  2. 如果你一直在使用,并且在 release 中已经这么做了,那么在 2017 年 8 月 31 日之前,你将暂时从 X 类别中被排除。在此之后,任何和所有使用 Facebook 公司 “BSD 许可证+专利开源协议”的产品都将被 Apache 基金会禁止使用,你必须找到采用了合适许可证的替代品,或者放弃使用。这种情况没有例外。
  3. 上述条款没有涵盖的任何其他情形也禁止使用。

X 类别被定义为“Apache 产品中可能不允许的许可证”,目前包括 GNU GPL、GNU LGPL、BCL、BSD-4-Clause 等许可证。有关禁用许可证列表可以在 Apache 基金会网站上查询

Facebook 的 “BSD 许可证 + 专利开源协议”

React 是一种流行的用于创建丰富用户界面的 JavaScript 技术,最初来源于 Facebook,并被广泛使用。该技术依据 BSD 许可证进行开源,但是,它的附加专利条款需要特别注意(以下为节选)。

Facebook, Inc.(Facebook)特此授予软件的每个接收人(“你”)基于任何 “必要权利要求” Necessary Claims 的永久的、全球范围的、免版税的、非排他的、不可撤销的许可(遵守以下终止条款),可以制造、曾经制造、使用、销售、许诺销售、进口以及转移软件。

如果您(或任何您的子公司、关联方或代理商)直接或间接地启动了专利主张,或从专利主张中直接获取经济利益,本协议授予的许可将自动终止,恕不另行通知:(i)针对 Facebook 或其任何子公司或关联方;(ii)全部或部分来自于 Facebook 或其任何子公司或关联方的任何软件、技术、产品或服务的专利主张针对任何一方;或(iii)与软件相关的任何一方。尽管如此,如果 Facebook 或其任何子公司或关联方首先对你提起专利侵权诉讼指控,你在该诉讼中针对与软件无关的一方提起专利侵权反诉,你所被授予的许可不会因反诉而在本段第(i)款的规定下终止。

如果你的项目中正在使用或打算使用 React,你可能需要去咨询律师了。由于专利条款的限制,你不能做任何构成与 Facebook 竞争的事情。如果你采取法律行动或者以其他方式挑战 Facebook,那么你使用 React 的许可会被立即撤销。

如果你与其他使用 React 的公司发生法律纠纷,那你使用 React 的许可也会被撤销。Aurelia 框架创建者、Angular 2 开发团队前成员 Rob Eisenberg 表示,这就是 Google 公司和 Microsoft 公司的员工在工作中不允许使用 React.js 的原因。

虽然这只是在理论上对大多数采用 React 的项目可能产生的影响,但仍然值得特别注意,并且,类似 WordPress Calypso 这种已经与 React.js 建立了深刻联系的项目,可能会受到限制。运营 WordPress 的 Automattic 公司对一些小官司并不陌生,但这次很可能成为 Facebook 这个大公司的诉讼对象。

Drupal 和 WordPress 等许多开源产品都在采用 Facebook 公司的 React.js 技术。对于 Automattic 公司这种拥有开源产品的公司来说,未来如果被 Facebook 认定与 Facebook 构成竞争,将会是一个棘手的问题。

目前 Facebook 正如日中天,以上可能性发生的几率比较小,但如同 Yahoo 公司一样,Facebook 总有一天会从神坛跌落。到那时,Facebook 公司很有可能会从竞争角度充分利用许可协议所赋予的权利。所以,如果你打算利用 React.js 创建一个有可能终结 Facebook 神话的产品,最好先咨询你的律师。

但是,美国专利法非常复杂,尤其是在知识产权相关问题上,往往难以解释。从 Google 和 Oracle 公司有关安卓使用 Java 的争议可以看出,解决此类问题往往需要好几年时间。这意味着你必须要财大气粗,即使是你最后赢了官司。

Facebook 公司的官方问答

React 的技术优势难以挑战。从开发者构建 web 用户界面方面来说,React 引发了一场变革。Facebook 在某些方面不太清楚的许可协议(BSD 许可证+专利)在开源开发者中间引发了激烈争论。开源社区继续坚持对“邪恶公司”的抵制,而 Facebook 很容易被归为此类公司。

2016 年 11 月,Facebook 澄清了其在 React、React Native 和其他许多项目中广泛采用的开源许可协议方面的立场。与任何法律文本一样,软件许可协议非常难以解释。Facebook 提供了一个 FAQ 来回应经常被问到的问题。其中包括:

  1. 如果我创建了一个竞争性产品,那么 Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权是否会被终止?
  2. 如果我用专利侵权以外的理由起诉 Facebook,那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止?
  3. 如果 Facebook 公司首先起诉我专利侵权,而我反诉 Facebook 公司专利侵权,那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止?
  4. Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权的终止是否也会导致版权许可的终止?

对 1、2、4 的回答是明确的“”,而对于第 3 个问题,FAQ 中规定,反诉主张不得与 Facebook 任何专利相关。上述官方说法比较可靠,在这个 Facebook 即便成为专利流氓也所获甚微的时刻,Facebook 仍然坚持其对 React 许可协议的看法。

使用 React.js 的开发者怎么办?

Apple 和 Microsoft 等行业巨头对于采用 React 的态度令人关注。有报道称,由于担心法律纠纷,这些巨头们已经禁止在项目中使用 React UI 库。但显然这是一个引发争议的问题,因为两家巨头都发布了使用 React 的网络资源或库。

Microsoft 提供了一个用于扩展 PowerPoint 和其他 Office365 产品的 React UI 组件库。Apple 开发者网站上的 API 文档采用 React.js 构建。

以上两款产品都不是两家公司的核心产品,Apple 也不太可能发布一款利用 React Native 编写的 iOS 邮件客户端。值得注意的是,虽然两家公司都看到了利用 React 创建 web 用户界面的价值,但它们的法律部门也没有因此遇到麻烦。

所以对大多数应用案例来说,似乎专利诉讼被严格限制在使用中的具体工具上,在这种情况下无需过分担心。由于使用了宽松的 BSD 许可证,对于开发者来说,React 实际上比使用传染性的 GPL 许可证的库更为安全。

Facebook 公司的数据库引擎 RocksDB 正准备将许可证更改为 Apache 2.0。但 React.js 是一个特殊的项目,Facebook 公司似乎有意继续保留专利条款。

虽然商业实体很乐意在产品中使用 React 授权代码,尽管 WordPress 等许多受欢迎的开源项目仍将继续采用 React,但开源社区对 Facebook 不断捍卫和澄清这种特殊授权感到了厌倦。

因此,如果你想找到类似 Solr 这种采用 React UI 的 Apache 项目,可能还需要很长时间。幸运的是,React 本身并非独一无二,你的项目可以采用与 React 类似的替代品,例如 PreactInferno,而不用担心遇到 React 的专利授权问题。

参考来源

(题图:facebook.github.io)


编译:

薛亮,北京集慧智佳知识产权管理咨询股份有限公司互联网事业部 高级咨询师,擅长专利检索,专利分析,竞争对手跟踪,FTO分析,开源软件知识产权风险分析,致力于为互联网企业,高科技公司提供知识产权咨询服务。