标签 Facebook 下的文章

26 日,Facebook 发布React 16,并如之前承诺的,将 React 16 JavaScript 库以及 GraphQL 查询语言的许可证从原来的 BSD + 专利条款改为更受欢迎的 MIT 许可证

正如 Facebook 工程总监 Adam Wolff 上周说的,“Facebook 未能说服开发者社区其 BSD + 专利条款的许可证是与开源需求所兼容的”,因此,在招致社区的抗议和抛弃,尤其是在发生了 Apache 基金会将 React 的许可证列入“X 类别”WordPress 弃用 React 事件之后,Facebook 表示愿意将这个重要的 JavaScript 基础框架更换成大家更欢迎的 MIT 许可证。

作为最广泛使用的用于构建 Web 用户界面的基础框架,React 的这一许可证的修改得到了社区的强烈反响,虽然有些不同意见,但是大部分人还是表示喜闻乐见——一方面代表了社区的胜利,另外一方面也可以避免大量的采用 React 的项目重写。

不过,也有一些人对 Facebook 采用 MIT 许可证表达了不同的看法。RedMonk 的创始人 Stephen O'Grady 表示,Facebook 采用不包括专利条款的 MIT 许可证,而没有采用包含了更弱的专利条款的 Apache 许可证,相比于原来的 BSD + 专利条款,按倒了葫芦起了瓢。“问题是,通过选择这种方式,Facebook 并没有像在 Apache 许可证下一样在 MIT 许可证中传达任何专利授权……如果 Facebook 在 React 申请了专利,换句话说,该软件的用户并没有被 MIT 许可证授予明确的许可,只有一个未经测试的隐含许可”。

此外,除了 React 16 换用了新的 MIT 之外, Facebook 也将前一天发布的 React 15.6.2 换用了 MIT 许可证,以便那些不方便升级 React 16 的用户使用。

而曾经被 Gitlab 由于该许可证条款而放弃的 GraphQL 也被修改了许可证。作为一个用于规定实现标准的规范,其现在被放在 开放式网络基金会协议 Open Web Foundation Agreement (OWFa) v1.0 之下,并且现在 Facebook 的 GraphQL 实现也采用了 MIT 许可证发布。

作为一个广泛使用 JavaScript 框架,这次 React 16 的升级只有很少的破坏性改变,虽然其中大部分库都经过了重写。而新的 React 16 支持异步渲染,允许处理大型组件树而不会阻塞主执行线程。此外,还增加了一些屡屡被要求而难以添加的功能,比如使用错误边界进行异常捕获,和从渲染器返回多个组件。

而 React 16 中的服务器端渲染也要比之前的版本快得多,测试表明,其比 Node 4 快 2.4 倍,比 Node 6 快 3 倍,比 Node 8.4 快 3.8 倍。

就在几个小时前,Facebook 宣布,将在下周发布的 React 16 会以 MIT 许可证重新授权,以应对社区对之前的 BSD + 专利许可模式的不安。

Facebook 负责 React 和 GraphQL 等产品的产品架构组工程总监 Adam Wolff 写道:

“下周,我们将以 MIT 许可证对我们的开源项目 React、Jest、Flow 和 Immutable.js 重新进行许可。我们重新许可这些项目是因为 React 是广泛的互联网开源软件生态的基石,我们并不想因非技术原因而阻碍其前行的道路。”

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

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

在 Apache 基金会将 React 这样的采用 BSD 许可证 + 专利条款的软件列入“X 类别”之后,社区再次引发了对此问题强烈关注,并导致很多大型的互联网公司开始绸缪放弃和替换 React——尤其是在 WordPress 宣布将重写其软件,剥离对 React 的依赖之后达到了顶峰。而国内的互联网公司,如百度、阿里,也纷纷有传言将追随这一动作,弃用 React。

迫于这种压力,Facebook 决定对 React 等开源项目放弃其原有的 BSD 许可证 + 专利条款的许可模式,虽然他们认为“BSD 许可证 + 专利条款为项目的用户提供了一些好处”,但是他们也“承认没能说服社区接受这一许可模式”。

在感受到这一许可证的不确定性风险之后,许多团队开始选择替代性的产品。Facebook 对此感到抱歉,对 React 重新许可虽然不一定能赢得这些团队回心转意,但是还是“希望将这扇门继续打开”。

这一转变自然也会引起人们对 Facebook 其它的开源项目的质疑,因为目前 Facebook 许多流行的开源项目都采用的是 BSD 许可 + 专利条款方式。但是他们会“重新评估这些项目的许可证,而每个项目的情况有所不同,替换许可证取决于各种因素”。下周,除了 React 之外,Facebook 也将对 Jest、Flow 和 Immutable.js 等开源项目进行重新许可。

这一许可证的变化将随着下周即将发布的 React 16 一起更新。React 16 已经开发了一年,内部进行完全重写,解锁了强大的功能,让每个人都可以用它来构建大规模的用户界面。

Adam Wolff 表示,将许可证的讨论放到后面,无论大家用不用 React ,希望它都可以给开发者以灵感,毕竟,我们最关心的是:交付伟大的产品。

对 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分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

Facebook 公司的 BSD+专利许可证失败的原因不是因为许可证本身,而是因为它忽略了开源软件更深层次的本质。

2017 年 7 月,Facebook 公司应用于 react 等项目的许可证组合被 Apache 软件基金会禁止使用。该许可证组合曾被 Facebook 应用于其所有作为开源软件发布的项目,它使用了被 OSI 批准的广泛使用的非互惠许可证 BSD 3-Clause,并且加入了宽泛的、非互惠的专利授权条款,但为了应对挑衅者,该许可证组合的终止规则同样宽泛。这种组合代表了一种新的开源许可证,我称之为“Facebook BSD+专利许可证”(FB + PL),在我看来,该许可证试图与 GPL v2 和 Apache v2 许可证保持兼容,以规避这些许可证所指称的不兼容性。

使用 FB + PL 许可证的 Apache 项目仍在发挥作用,但是我认为 Facebook 所犯错误的原因可能不会立即被一贯秉持实用主义态度的软件开发人员们所注意到。例如,由律师转行做程序员的 Dennis Walsh 针对这个问题表示:“它没有什么实质意义”。他的观点是,FB + PL 许可证仅对你所使用的适用该许可证的特定软件项目产生影响,专利授权撤回的后果对另一个专利持有者来说并不严重。他得出结论说:

“Facebook 想要推广开源软件同时不被起诉——这是一个崇高的目标。为此,它可以使用一些苛刻的条款。但在这种情况下,由于上述实践和法律方面的原因,很难在被攻击之后发现是谁干的。”

Dennis 也许是对的,但这并不重要。Facebook 自出机杼地发明自己的开源许可证是一个坏主意。有一系列非直接风险或具体情境的重要因素需要考虑,Facebook 的许可证几乎将它们完全忽略了。

  1. 许可证审批很重要
    使用非 OSI 批准的许可证意味着,就像任何专有许可证一样,将其应用于企业用途时总是需要法律审查。OSI 许可证审批之所以重要,是因为它为开发人员提供了一种指示,即社区评估已经认可了该许可证,并认为它以不会产生不可接受风险的方式提供了软件自由。如果 Facebook 采取了寻求 OSI 批准的路线,那么很有可能一开始就会发现并且回避了他造成的问题。实际上有一种 OSI 批准的许可证能够实现 Facebook 的明确目标(BSD + 专利许可证)。该许可证最近刚被提交和批准,这看起来是 Facebook 可以考虑采用的合理替代方案。
  2. 较少的提前许可
    不仅仅是许可证批准很重要。任何有关创新自由的不确定性都会阻碍开发人员使用代码。与使用相关的含糊条款在使用前需要消除歧义——该步骤相当于为了继续推进而寻求许可。出于同样的原因,公共领域对于软件开发者来说是不利的,因为使用条款规定了在采用之前需要寻求许可。由于需要向项目添加一个与 Facebook 相关的法律文件,每个企业开发人员现在都需要与法律顾问联系,才能继续推进。即使答案是“是的,可以”,他们仍然不得不停下来寻求许可。正如 Aaron Williamson 指出的那样,这可能不是他们的反应。
  3. 不公平的比赛场
    Facebook 使用的专利授权条款为其提供了特殊权利和保护,而项目中的其他人并不享有。这使得开源开发人员感到紧张,原因与 贡献者协议 contributor agreements 一样。开源项目的软件自由的全部价值在于它创造了一个安全的空间,在其中每个人都是平等的,它保护每个人免受他人动机的影响。刻意为自己设置额外权利是反社会的行为,可悲的是,开源社区有很多不平等权利最终被滥用的例子。
  4. 隐含的授权无效
    许多开源法律机构认为,通过对用于任何目的的软件使用授予许可,即使没有提及专利的许可证也隐含授予专利许可。通过添加任意形式的外部专利授权,Facebook 表示它不认为隐含授权足够(最好的情形)或存在(最差的情形)。专注于开源软件的律师们认为,这是 Facebook 毫无根据的扩大化解释。这也是为什么 OSI 放弃了对 CC0 许可协议批准的原因
  5. Apache 基金会的规则
    虽然我没有找到清晰和完整的理由,但 Apache 基金会似乎已经对 Facebook 的许可证组合做出了裁定,因为 Apache 基金会认为,Facebook 的专利授权比 Apache v2 许可证中的专利条款限制性更强。Apache 基金会希望自身是一个中立的软件来源——一个“万能供血者”,而对此产生妨害的条款很有可能违背其规则。对于旨在成为 Apache 生态系统一部分的组件,与 Apache 的许可证产生混乱的做法看起来不太明智。

所以争论这个问题没有什么意义,因为风险很小,问题微不足道。以一种忽视我上面列出的五个社区规范的方式行动无益于任何人,甚至也帮不了 Facebook。虽然 Facebook 目前正在坚持己见,但我希望它能够改正,我愿意提供帮助。


作者简介:Simon Phipps 是 “公开软件” Public Software 开源项目的发起人,以志愿者身份担任 OSI 和 文档基金会 The Document Foundation 的理事。

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

关于 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)


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

在 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分析,开源软件知识产权风险分析,致力于为互联网企业,高科技公司提供知识产权咨询服务。