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

开源网络出版软件 WordPress 的联合创始人 Matt Mullenweg 日前表示，出于对 Facebook 开源许可证中专利条款的担忧，WordPress 社区将不再使用 Facebook 的 React JavaScript 库。

Mullenweg 在一篇博客文章中对其决定做出了解释。几个星期之前，即便是在 Apache 基金会表示了不再允许其项目使用 Facebook 许可证后，Facebook 还是决定保留其在 React 许可证中附加的专利条款。Mullenweg 认为，试图去删除该专利条款将“增加他们在对抗无事实根据的诉讼方面所花费的时间和费用”。

Mullenweg 表示，他不是在评论 Facebook 或者认为 Facebook 错了。Facebook 的决定对于 Facebook 来说是正确的，这是他们的工作，Facebook 可以决定以任何他们想要的方式来授权其软件。但对于 Mullenweg 来说，Facebook 的意图已经非常明确了。

几年之前，Automattic 将 React 作为基础来重写 WordPress.com 的前端 Calypso，这应该是基于 React 的最大的开源项目之一。正如 Automattic 的法律顾问所写，Automattic 做出了最好不要牵涉到专利问题的决定，在今天仍是如此。

总体来说，Mullenweg 过去一直对 React 很满意。最近，WordPress 社区开始将 React 用于 Gutenberg 项目，这是该社区多年以来最大的核心项目。人们在 React 方面的经验以及 React 社区（包括 Calypso）的规模，是 WordPress 将 React 用于 Gutenberg 项目的考虑因素之一。这使得 React 成为 WordPress 以及为 WordPress 编写的数以万计插件的事实上的标准。

Mullenweg 在博客里表示，WordPress 曾准备了一份几千字的公告，阐述了 React 是多么伟大，WordPress 如何正式采用了 React，以及鼓励插件同样采用 React。在该公告中，Mullenweg 一直希望专利问题能够以一种让用户放心使用的方式解决。

但这份公告现在不会被公布了。Mullenweg 表示，Gutenberg 项目将会退而采用另外的库来进行重写。这使得 Gutenberg 项目至少要延迟几个星期，其发布日期可能要推到明年。

Automattic 还将采用另外的同样的库来重写 Calypso，这将需要更长的时间。Automattic 目前还未牵涉到专利条款的问题当中。虽然会对业务造成短期影响，但是从内核的长期一致性来考虑，重写是值得的。WordPress 的内核升级涉及到全部网页的四分之一以上，让它们全部继承专利条款问题令人担忧。

Mullenweg 认为，Facebook 的专利条款实际上比许多公司可以采取的其他方法更清晰，Facebook 已经成为不错的开源贡献者之一。让全世界夸赞 Facebook 专利条款不是 Automattic 的工作，而是 Facebook 自己的战斗。

Mullenweg 在博客中表示，采用哪个库来重写将会在另外的帖子中公布，这主要是技术性的决定。Automattic 将会寻求具备 React 的大部分优势，同时又没有给许多人造成混淆和威胁的专利条款包袱的替代选择，并请大家就这些问题提供反馈。目前针对替换的库已经有了几个建议，包括 VueJS 、Preact 等。

另据 TechCrunch 报道，针对 Facebook 公司的专利条款，一些最激烈的批评家认为其将“特洛伊木马”引入了开源社区。对于 Mullenweg 在博客中发布的决定，一位评论家称之为“艰难但重要的决定”，其他评论家则将其称为“明智”和“有益”的决定。

而另外一些评论则发出了警告：“不要过度反应。过去五六年来，WordPress 生态系统的动荡和流失已经足够多了。Facebook 的业务规模和范围使得该条款变得非常可怕。它们最终必须放弃。”

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

WordPress 和 ReactJS 分道扬镳了，WordPress 的共同创始人 Matt Mullenweg 在其博客中宣布了这一消息。

关于 WordPress 之后将采用何种 JavaScript 框架，Matt 并未宣布，目前几个选择：

  1. VueJS
  2. Preact
  3. 其它框架（Angular、 Ember、 Polymer、 Aurelia 等等）

其中， VueJS 和 Preact 的呼声最高。关于它们的优劣势分析如下：

VueJS：

  • 优势：易于学习
  • 优势：与 Laravel 一贯协作良好
  • 优势：比 Preact 更流行，支持的社区更多
  • 优势：贡献者比 Preact 更多
  • 劣势：依赖于关键人物
  • 状态：Github 上有 133 个核心贡献者，67152 个星标，做了 209 次发布
  • 资金支持：截止至本文写作， 在社区的支持下，VueJS 在 OpenCollective 得到了每年 $9,895 的捐助，作者尤雨溪在 [Patreon](https://www.patreon.com/evanyou) 得到了每月 $8,815 的捐助。

我确信 WordPress 使用 VueJS 能够更好。VueJS 有大量的拥护者，而且初学者易于上手。如果采用 VueJS，这对于 WordPress 是极好的。我自己也在几个项目中使用 VueJS，我喜欢它。

此外，这个框架也可以用在 WordPress 之外的项目（比如 Vue 与 Laravel 的集成），这可以让开发者在 WordPress 项目和非 WordPress 项目中发挥其经验。 有很多开发者都同时参与 Laravel 和 WordPress 项目，所以如果使用同一个框架，有助于同时推动 Laravel、 VueJS 和 WordPress 的发展。

PreactJS：

  • 优势：易于过渡
  • 优势：与 VueJS 大致相同的资金支持，不断推进的社区
  • 优势：基于 React 的子集库仍然被 Preact 和 compat 支持
  • 劣势：过渡也许导致代码混乱和困扰（针对初学者）
  • 劣势：依赖于关键人物
  • 状态：在 GitHub 上有 100 个核心贡献者， 14319 个星标，做了 114 次发布
  • 资金支持：截止至本文写作，在社区的支持下， Preact 在 OpenCollective 得到了 $16,087 的捐助

PreactJS 有其优势，但我找不到合适的人咨询（我仅在两个项目中稍微使用过它）。不过看起来从 React 过渡到 Preact 非常容易。这也许会促使开发者选择 Preact，但是我认为这不是选择它的理由。这只会让开发者在采用这个新的 JavaScript 框架生态、node 模块、Webpack 时发生混淆，Preact 又不是 React 的别名！这会让代码味道难闻。

本文作者在几个平台上做了投票，欢迎参与你的意见：

那么你的意见呢？

（题图：maxprog.net.pl）

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 来构建应用吗？“入门”是很容易的，可是接下来呢？

React 是一个构建用户界面的库，而它只是组成一个应用的一部分。应用还有其他的部分——风格、路由器、npm 模块、ES6 代码、捆绑和更多——这就是为什么使用它们的开发者不断流失的原因。这被称为 JavaScript 疲劳。尽管存在这种复杂性，但是使用 React 的用户依旧继续增长。

社区应对这一挑战的方法是共享模版文件。这些模版文件展示出开发者们架构选择的多样性。官方的“开始入门”似乎离一个实际可用的应用程序相去甚远。

新的，零配置体验

受开发者来自 Ember.js 和 Elm 的经验启发，Facebook 的人们想要提供一个简单、直接的方式。他们发明了一个新的开发 React 应用的方法 ：create-react-app。在初始的公开版发布的三个星期以来，它已经受到了极大的社区关注（超过 8000 个 GitHub 粉丝）和支持（许多的拉取请求）。

create-react-app 是不同于许多过去使用模板和开发启动工具包的尝试。它的目标是零配置的惯例-优于-配置，使开发者关注于他们的应用的不同之处。

零配置一个强大的附带影响是这个工具可以在后台逐步成型。零配置奠定了工具生态系统的基础，创造的自动化和喜悦的开发远远超越 React 本身。

将零配置部署到 Heroku 上

多亏了 create-react-app 中打下的零配置基础，零配置的目标看起来快要达到了。因为这些新的应用都使用一个公共的、默认的架构，构建的过程可以被自动化，同时可以使用智能的默认项来配置。因此，我们创造这个社区构建包来体验在 Heroku 零配置的过程。

在两分钟内创造和发布 React 应用

你可以免费在 Heroku 上开始构建 React 应用。

npm install -g create-react-app
create-react-app my-app
cd my-app
git init
heroku create -b https://github.com/mars/create-react-app-buildpack.git
git add .
git commit -m "react-create-app on Heroku"
git push heroku master
heroku open

使用构建包文档亲自试试吧。

从零配置出发

create-react-app 非常的新（目前版本是 0.2），同时因为它的目标是简洁的开发者体验，更多高级的使用情景并不支持（或者肯定不会支持）。例如，它不支持服务端渲染或者自定义捆绑。

为了支持更好的控制，create-react-app 包括了 npm run eject 命令。Eject 将所有的工具（配置文件和 package.json 依赖库）解压到应用所在的路径，因此你可以按照你心中的想法定做。一旦被弹出，你做的改变或许有必要选择一个特定的用 Node.js 或静态的构建包来布署。总是通过一个分支/拉取请求来使类似的工程改变生效，因此这些改变可以轻易撤销。Heroku 的预览应用对测试发布的改变是完美的。

我们将会追踪 create-react-app 的进度，当它们可用时，同时适配构建包来支持更多的高级使用情况。发布万岁！

via: https://blog.heroku.com/deploying-react-with-zero-configuration

作者：Mars Hall 译者：zky001 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

  1. 1
  2. 2