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