Lush 说这是可能的。

在不到一个月内将你的核心业务从一个公共云迁移到另一个公共云看起来像是一个遥不可及的目标，但是英国化妆品巨头 Lush 认为可以做到这一点。

去年九月 Lush —— 你也许知道它是那些糖果色的、好闻的沐浴和护肤产品背后的公司 —— 与已有的基础设施供应商 Acquia 的合同快要到期了。

Acquia 已经在 AWS 中托管了 Lush 的基于 Drupal 的电子商务环境好几年了，但该零售商想要退出合作。

根据 Lush 的首席数字官及公司的继承人 Jack Constantine（他的父母在 1995 年成立该公司）的说法，该安排是“尴尬”和僵硬的。

他今天在旧金山举行的 Google Cloud Next 会议上说：“我们不太满意那份合同，我们想看看我们还能做些什么。”

“那是一个非常封闭的环境，这使我们难于看清下一步做什么。”

“(我们) 可以再签署一年，在此期间想出一个有更多的控制权的长期计划，但是（我们）最终结束了这种挣扎。”

在淘遍市场后，Lush 目标放在 Google 的云平台上。该公司已经很熟悉 Google 了，已于 2013 年底从 Scalix 迁移到 Google Apps（现称为 G Suite）上。

然而，只有几个月不到的时间进行迁移，要赶在 12 月 22 日现有合同截止前和圣诞节购物的关键时期前。

Constantine 说：“所以这不仅仅是有点关键的业务，我们要考虑高峰交易期，那时会有巨大的交易。”

Lush 摆脱了官僚主义意味着 Constantine 能够在选择供应商上快速决定。他说：“接着团队只要全力进行就行。”

他们还为这次迁移专门优先优化了用于迁移的 “一体化” Drupal 程序，而把 bug 修复推到以后。

Lush 12 月 1 日开始物理迁移，12 月 22 日完成。

团队“像其他迁移一样”遇到了挑战，Constantine 说：“你肯定会担心将数据从一个地方传输到另一个地方，你必须确保一致性，客户、产品数据等需要稳定。”

但是，这位 CDO 表示，让公司采用这个难以置信的紧张时间表是因为团队缺乏备选方案: 没有后备计划。

Constantine 说：“在截止日期前的一个星期，我的同事和我们的 Google 合作伙伴打了电话，他们对这是否会发生有点紧张，他们问我们 Plan B 是什么，我的同事说：Plan B 就是让 Plan A，就是这样”。

“当你抛出这样一个听起来有点难以置信的艰难的截止日期时，而（你需要保持）关注那些认为这是我们可在这个时间范围内可以实现的目标的人，而不是那些放置阻碍说‘我们必须要延期’的人。”

“是的，每个人都很紧张，但你实现了很多。你实际上完成并盯牢了它。你所要做的就是完成、完成。”

现在的重点是将该电子商务应用转移到微服务架构，同时研究各种 Google 工具，如 Kubernetes 容器管理系统和 Spanner 关系数据库。

Constantine 说，该零售商最近也建立了使用 GCP 和 Android 的原型 POS 系统。

（题图：Lush's Oxford St, UK store. Credit: Lush）

via: https://www.itnews.com.au/news/a-public-cloud-migration-in-22-days-454186

作者：Allie Coyne 译者：geekpi 校对：wxy

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

不断变化的社会和文化条件正促使着开放的领导。

领导力就是力量。更具体地说，领导力是影响他人行动的力量。 关于领导力的神话不仅可以让人联想到人类浪漫的一面而且还有人类境况险恶的一面。 我们最终决定如何领导才能决定其真正的本质。

现代许多对领导力的理解都是在战争中诞生的，在那里，领导力意味着熟练地执行命令和控制思想。 在现代商业的大部分时间里，我们都是以一个到达权力顶峰的伟大的男人或女人作为领导，并通过地位来发挥力量的。 这种传统的通过等级和报告关系的领导方式严重依赖于正式的权威。 这些结构中的权威通过垂直层次结构向下流动，并沿命令链的形式存在。

然而，在 20 世纪后期，一些东西开始改变。 新技术打开了全球化的大门，从而使团队更加分散。 我们投入人力资本的方式开始转变，永远地改变了人们之间的沟通方式。组织内部的人开始感觉得到了责任感，他们要求对自己的成功(和失败)拥有归属感。 领导者不再是权力的唯一拥有者。 21世纪的领导者带领 21 世纪的组织开始了解授权、协作、责任和清晰的沟通是一种新型权力的本质。 这些新领导人开始分享权力——他们无保留地信任他们的追随者。

随着组织继续变得更加开放，即使是没有“领导力”头衔的人也会感到有责任推动变革。 这些组织消除了等级制度的枷锁，让工人们以他们认为合适的方式去工作。 历史暴露了 20 世纪领导人倾向通过单边决策和单向信息流来扼杀敏捷性。 但是，新世纪的领导者却是确定一个组织，让由它授权的若干个体来完成一些事情。 重点是权力赋予若干个体——坦率地说，一个领导者不能在任何时候出现在所有的地方，做出所有的决定。

因此，领导人也开始变得开放。

控制

当旧式领导人专注于指挥和控制的地位权力时，一个开放的领导者通过新形式的组织管理方式、新技术和其他减少摩擦的方式，将组织控制权放在了其它人身上，这样可以更有效的方式实现集体行动的方式。 这些领导者了解信任的力量，相信追随者总是会表现出主动性、参与性和独立性。 而这种新的领导方式需要在战术上有所转变——从告诉人们如何去做，到向他们展示如何去做，并在路上指导他们。开放的领导人很快就发现，领导力不是影响我们发挥进步的力量，而是我们在组织成员中分配的力量和信心。 21 世纪的领导者专注于社区和对他人的教化。最后，开放的领导者并不是专注于自我，而是无私的。

交流

20 世纪的领导者人组织并控制整个组织的信息的流动。 然而，开放的领导者试图通过与团队成员共享信息和背景（以及权力）来组织一个组织。 这些领导人摧毁了领地，谦逊前行，分享着前所未有的力量。 集体赋权和参与的协作创造了灵活性，分担责任，所有权，尤其是幸福。 当一个组织的成员被授权做他们的工作时，他们比等级层次的同事更快乐（因而更有生产力）。

信任

开放的领导者接受不确定性，相信他们的追随者在正确的时间做正确的事情。 他们拥有比传统对手，有更高的吸引人力资本效率的能力。 再说一次：他们不会像命令和控制的微观管理者那样运作。 提高透明度，而不是暗箱操作，他们尽可能的把决策和行动放在公开场合，解释决策的基础，并假设员工对组织内的情况有高度的把握。开放领导者的操作的前提是，如果没有他们的持续干预，该组织的人力资本就更有能力取得成功。

自治权

在 20 世纪具有强大指挥和控制力的领导者专注于某些权力的时候，一个开放的领导者更多地关注组织内个人的实际活动。 当领导者专注于个人时，他们就能够更好地训练和指导团队成员。 从这个角度来看，一个开放的领导者关注的是与组织的愿景和使命一致的行为和行动。最后，一个开放的领导者被看作是团队中的一员，而不是团队的领导者。 这并不意味着领导人放弃了权力的地位，而是低估了这一点，以分享权力，并通过自主创造成果赋予个人权力。

赋权

开放的领导人把重点放在授予组织成员的权力上。 在这个过程中承认领导者在组织人力资本中的技能、能力和信任，从而为整个团队带来了积极的动力和意愿。 最终，赋权就是帮助追随者相信他们自己的能力。 那些相信自己拥有个人权力的追随者更有可能采取主动行动、制定和实现更高的目标，并在困难的环境下坚持下去。 最终，开放组织的概念是关于包容性，每个人都是属于自己的，个性和不同的观点对于成功是至关重要的。 一个开放的组织及其开放的领导者提供了一种社区的感觉，而成员则受到组织的使命或目的的驱动。 这会产生一种比个人更大的归属感。 个性创造了成员之间的幸福和工作满意度。 反过来，又实现了更高的效率和成功。

我们都应该为 21 世纪领导人所要求的开放性而努力。 这需要自我反省，好奇心，尤其是它正在进行的改变。 通过新的态度和习惯，我们逐渐发现了一个真正的开放领导者，并且希望我们在适应 21 世纪的领导风格的同时，也开始采纳这些理念。

是的，领导力就是力量。我们如何利用这种权力决定了我们组织的成败。 那些滥用权力的人不会持久，但那些分享权力和庆祝他人的人会更持久。 通过阅读 这本书，你可以在开放组织及其领导的持续对话中开始发挥重要作用。 在本卷的结论中，您将找到与开放组织社区联系的额外资源和机会，以便您也可以与我们聊天、思考和成长。 欢迎来到谈话——欢光临！

这篇文章最初是作为《开放组织领导手册》的引言出现的，它现在可以从 Opensource.com　中可获得。

（ 题图：opensource.com）

作者简介：

Philip A Foster - Dr. Philip A. Foster 是一名领导/商业教练兼顾问兼兼职教授。 他是企业运营、组织发展、展望和战略领导层的著名思想领袖。 Dr. Foster 通过设计和实施战略、战略预见和规划来促进变革。

via: https://opensource.com/open-organization/17/2/need-open-leaders-more-ever

作者：Philip A Foster 译者：TimeBear 校对：wxy

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

在上个月旧金山 Twitter 总部举办的 WomenWhoCode Connect 活动中参会者了解到，就像组织会形成技术债务一样，如果他们不相应地计划，也会形成一个名为“安全债务”的东西。

甲骨文首席安全官 Mary Ann Davidson 与 WomenWhoCode 的 Zassmin Montes de Oca 在一个面对开发人员的安全性的主题谈话中强调，安全性已经成为软件开发过程中每步的重要组成部分，

在过去，除银行外，安全性几乎被所有人忽视。但安全性比以往任何时候都更重要，因为现在有这么多接入点。我们已经进入物联网的时代，窃贼可以通过劫持你的冰箱而了解到你不在家的情况。

Davidson 负责 Oracle 的保障，“我们确保为建立的一切构建安全性，无论是内部部署产品、云服务，甚至是设备，我们在客户的网站建立有支持小组并报告数据给我们，帮助我们做诊断 - 每件事情都必须对其进行安全保护。”

AirBnB 的 Keziah Plattner 在分组会议中回应了这个看法。她说：“大多数开发者并不认为安全是他们的工作，但这必须改变。”

她分享了工程师的四项基本安全原则。首先，安全债务是昂贵的。现在有很多人在谈论技术债务，她认为这些谈话应该也包括安全债务。

Plattner 说：“历史上这个看法是‘我们会稍后考虑安全’”。当公司抓住软件效率和增长的唾手可得的成果时，他们忽视了安全性，但最初的不安全设计可能在未来几年会引发问题。

她说，很难为现有的脆弱系统增加安全性。即使你知道安全漏洞在哪里，并且有进行更改的时间和资源的预算，重新设计一个安全系统也是耗时和困难的。

她说，所以这就是关键，从一开始就建立安全性。将安全性视为技术债务的一部分以避免这个问题，并涵盖所有可能性。

根据 Plattner 说的，最重要的是难以让人们改变行为。没有人会自愿改变，她说，即使你指出新的行为更安全。他们也只不过是点点头而已。

Davidson 说，工程师们需要开始考虑他们的代码如何被攻击，并从这个角度进行设计。她说她只有两个规则。第一个从不信任任何未验证的数据；规则二参见规则一。

她笑着说：“人们一直这样做。他们说：‘我的客户端给我发送数据，所以没有问题’。千万不要……”。

Plattner说，安全的第二个关键是“永远不信任用户”。

Davidson 以另外一种说法表示：“我的工作是做专业的偏执狂。”她一直担心有人或许无意中会破坏她的系统。这不是学术性的考虑，最近已经有通过 IoT 设备的拒绝服务攻击。

Little Bobby Tables

Plattner 说：“如果你安全计划的一部分是信任用户做正确的事情，那么无论你有什么其他安全措施，你系统本质上是不安全的。”

她解释说，重要的是要净化所有的用户输入，如 XKCD 漫画中的那样，一位妈妈干掉整个学校的数据库——因为她的儿子的中间名是 “DropTable Students”（LCTT 译注：看不懂的点这里）。

所以净化所有的用户输入。你一定检查一下。

她展示了一个 JavaScript 开发者在开源软件中使用 eval 的例子。她警告说：“一个好的基本规则是‘从不使用 eval()’”。 eval() 函数会执行 JavaScript 代码。“如果你这样做，你正在向任意用户开放你的系统。”

Davidson 警告说，她甚至偏执到将文档中的示例代码的安全测试也包括在内。她笑着说：“我们都知道没有人会去复制示例代码”。她强调指出，任何代码都应进行安全检查。

Plattner 的第三个建议：要使安全容易实施。她建议采取阻力最小的道路。

对外，使用户 默认采用 option out 安全措施而不是 可选采用 option in ，或者更好使其成为强制性的措施。她说，改变人们的行为是科技中最难的问题。一旦用户习惯以非安全的方式使用你的产品，让他们改进会变得非常困难。

在公司内部，她建议制定安全标准，因此这不是个别开发人员需要考虑的内容。例如，将数据加密作为服务，这样工程师可以只需要调用服务就可以加密或解密数据。

她说，确保公司注重安全环境。在让整个公司切换到好的安全习惯。

你的安全短板决定了你的安全水准，所以重要的是每个人都有良好的个人安全习惯，并具有良好的企业安全环境。

在 Oracle，他们已经全面覆盖安全的各个环节。Davidson 表示，她厌倦了向没有安全培训的大学毕业的工程师解释安全性，所以她写了 Oracle 的第一个编码标准，现在已经有数百个页面之多以及很多贡献者，还有一些课程是强制性的。它们具有符合安全要求的度量标准。这些课程不仅适用于工程师，也适用于文档作者。她说：“这是一种文化。”

没有提及密码的关于安全性的讨论怎么能是安全的？Plattner 说：“每个人都应该使用一个好的密码管理器，在工作中应该是强制性的，还有双重身份验证。”

她说，基本的密码原则应该是每个工程师日常生活的一部分。密码中最重要的是它们的长度和熵（使按键的集合尽可能地随机）。强健的密码熵检查器对此非常有用。她建议使用 Dropbox 开源的熵检查器 zxcvbn。

Plattner 说，另一个诀窍是在验证用户输入时使用一些故意减慢速度的算法，如 bcrypt。慢速并不困扰大多数合法用户，但会让那些试图强行进行密码尝试的黑客难受。

Davidson 说：“所有这些都为那些想要进入技术安全领域的人提供了工作安全保障，我们在各种地方放了各种代码，这就产生了系统性风险。只要我们继续在技术领域做有趣的事情，我不认为任何人不想要在安全中工作。”

via: https://thenewstack.io/security-engineers-problem/

作者：TC Currie 译者：geekpi 校对：wxy

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

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

国外有一位 Linux 粉丝做了一张壁纸，其中对“我们为什么爱用 Linux”说了大实话：

我们告诉人们用 Linux 是因为它很安全，或者因为它是免费的、因为它是可以定制的、因为它是自由的、因为它有一个强大的社区支持着……

但是上面的所有原因都是在扯淡。我们这么跟非 Linux 用户讲是因为他们没法了解真正的原因。而且我们说多了这些借口，我们自己也开始就这么相信了。

但是在我们内心深处，还保留着真正的原因没说。

我们用 Linux 是因为它很有趣。

折腾你的系统很有趣；修改所有的设置，把系统搞挂，然后进入回复模式去修复它很有趣；有上百个发行版供你选择很有趣；用命令行很有趣。

让我再重申一遍，用命令行很有趣。

难怪非 Linux 用户无法理解。

我是在说 Linux 的爱好者们用 Linux 是因为自己的缘故。当然，我们喜欢做好自己的工作；当然，我们喜欢避免染上病毒；当然，我们喜欢省钱。但是这些仅仅是副产品。我们真正喜欢的是把玩这个系统，瞎胡折腾，并且发现些隐藏在软件深处迷人的真相。

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