踢掉 FB+PL：Apache 的开源激进宣言？

哪里有压迫，哪里就有反抗

身为知识产权圈里的专利人，笔者钦佩开源情怀，并曾写道：即使专利人也有专利情怀，现实世界中开源与专利的碰撞依然难免丑陋。现在看来，这话有点轻描淡写了。

笔者未能认真发掘开源运动史，只好拍拍脑袋认定：开源软件运动是针对知识产权制度，尤其是专利制度，对软件产业之压迫的暴动。

“哪里有压迫，哪里就有反抗。”

这场轰轰烈烈的暴动在发展过程中，于 2017 年 7 月，“Apache Software Foundation 主管兼法律事务副主席 Chris Mattmann 正式发表声明称：Facebook BSD+Patents license（以下简称 FB+PL）已经正式被列入 “CategoryX” 列表，因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉及 FB+PL 许可证的，需要在 8 月 31 号前完成替换。”

简而言之，Apache 一脚将 FB+PL 踢出了。这是不是 Apache 在开源暴动中的激进声明？为什么这么说？

专利情怀

故事要从头讲起：

专利制度产生了，那时候大家并不认为这是一个万恶的吃人的制度。专利制度的根本目的还是促进技术进步，从而推动产业和经济发展。为了达成此目的，则需要合理保护发明人的积极性，具体而言，就是给予他们一定时期的专有保护为回报，在这种利益驱动下，他们会积极的做出发明，并通过申请专利，在向社会公布技术促进技术进步的同时，兑现专有保护。

"Before then [the adoption of the United States Constitution], any man might instantly use what another had invented; so that the inventor had no special advantage from his own invention. The patent system changed this; secured to the inventor, for a limited time, the exclusive use of his invention; and thereby added the fuel of interest to the fire of genius, in the discovery and production of new and useful things. "

-- Abraham Lincoln, Second lecture on discoveries and inventions, February 11, 1859

以上这段诠释了专利情怀的话出自美国总统林肯的演讲。只需要读懂这个短句就好了：专利制度为天才之火添上利益之油。

开源与专利的碰撞

到上世纪 90 年代，专利海盗开始大行其道，软件产业受害最深。在软件行业里，程序员和开发者需要开放、自由地交流和利用彼此的成果才利于行业发展。这一特性先天与专利制度八字不合。这个死结是一百多年的林肯总统绝对意料不到的。

从根本上，开源情怀在于：对于自己的智力劳动成果，放弃可取得收益的专有权利，给软件松绑，从而利于成果的流通、利用，以及行业发展。

绑在软件身上的主要知识产权绳索有两条：版权，专利。商标不起核心作用。解开版权这条绳索的方式比较成熟：版权开源许可证。而专利很微妙，最主要的原因是它的无形，主动权常常不在开源作者自己手里。版权是属于作者的，所以作者有主动权；而专利属于申请人，申请人有主动权，申请人可以是任何第三方。这是开源与专利之矛盾的根源。

对开源情怀的最大伤害在于：不知道是谁用专利这根无形绳索悄悄捆绑了自己的作品。这是开源人对专利的敏感和敌视的由来。开源人常常感到愤怒和难以理解的是：为什么自己的智力成果，别人可以用专利来捆上？

对不起，这一个很让人遗憾的回答：任何人都可以对包括已公开的开源技术在内的任何现有技术做出改进，并就改进获得专利权。而当有别人在某项开源技术比较可行的主要改进方向上都申请了专利，就相当于把主要出路都卡上了，那么这项开源技术也就被别人的专利绑上了。这种专利申请技术，在圈内有一个好听的名字：专利布局。防御性的专利布局可以用来对自己的技术成果形成严密保护。进攻性的专利布局可以用来摘别人的桃子的，包括摘开源的桃子。专利海盗就属于充分、高超地利用专利手段和法律程序，激进地玩进攻性专利布局来摘别人桃子的。有时，手法可以高超到骗过专利审查员的法眼，将与现有技术很接近的内容纳入自己的保护范围。软件行业是重灾区。

应当说，在专利方面，对开源最大的威胁来自第三方，而不是开源的作者、后续开发者、用户。在社区内，大家尝试在版权开源许可之外附加专利开源许可，但是因为这种附加许可的效力仅能延伸到后续开发者、用户，不能规制第三方或专利海盗，实质能达到的效果较为有限。

Facebook 被踢的委屈

现在，我们重新梳理一下 Apache 踢 FB+PL 这件事。Apache 主要是对 Facebook Patents license，即对专利许可的条件不满意才开踢的。

Apache 的表态很干脆地捍卫了开源情怀，但是不是有些偏强硬激进了呢？

对于发展开源事业，首要的问题是什么呢？当然应当是分清谁是朋友，谁是敌人。然后，团结一切可以团结的进步力量，形成对敌统一战线。

笔者猜想，开源的敌人是第三方专利海盗，以及供专利海盗滋生的土壤。Facebook 看起来更像可以团结的朋友：Facebook 对开源有很积极的贡献和推动，其在专利许可方面的动作应当也没有越线。Facebook 如果真想以专利捆绑开源，另安排一个白手套作为第三方来布局专利，岂不干脆彻底？哪里还需要如此费事的搞 Facebook Patents license？至少应当说，Facebook 还是出于基本善意的立场提出的专利许可。

扒扒 Facebook 专利许可

再深入剖析这个问题，就要梳理 Facebook Patents license 的主要条款对开源的影响了。

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 对免费专利许可设了限制条件：你不可以诉我知识产权侵权；
• 专利许可所涉及的专利，仅限于所涉及的开源软件本身，对于软件修改后或与其他技术共同使用而可能侵犯的专利，不在许可之列。

法律背景扑朔迷离

即使分析以上两个要点，也要仔细衡量，须考虑现实背景中的重要因素：

• 如果无专利许可，会如何？
• 许可不涉及实质性的对价。
• 许可涉及复杂的国际司法环境。

笔者认为，许可条款之外的上述背景中的三条因素才真正使许可的效力变得扑朔迷离。

就背景因素 1 而言，现实情况中，普遍存在开源许可证仅涉及版权而回避了专利的情况。这是社区当中大家普遍可以接受的条件。未提及专利，并不等于没有给予专利许可，尤其在许可证中没有明示“专利要另收钱”的情况下。有一个奇妙的东西，可以叫作基于诚实信用或善意公平原则的“默认许可”。

何为“默认许可”？简单讲，当你给人家什么东西去用，没有明示这个东西要收钱，人家用了之后，你向人家去收钱，这么做不太厚道吧？基于诚实信用或善意公平原则，通常法院不会支持这种像是给人下了套，然后去收钱的行为的，而会认为当你给人家东西去用，没有明示这个东西要收钱时，已经“默认许可”人家免费用了。

开源软件的作者或提供者，同时又作为相关专利的专利权人时，在提供了明确免除版权费用的许可证的情况下，如果在向用户交付产品的同时，没有明示要收取专利费，“默认许可”应当成立。从学术讨论的角度，也有将之称为“专利权权利用尽”的。但是由于未收钱，“专利权权利用尽”的成立更有困难些。笔者还是坚持“默认许可”路线。

但还是很遗憾，法律世界不同于软件世界。在软件世界里，每一段算法程序，在给定条件后，都会给你执行出一个清楚的结果。法律世界里很难如此。“默认许可”是否会得到司法完全支持？真的很难讲，各个国家，甚至一个国家在不同时期，都可能对相似的情况采取不同的思路并给出不同的分寸和方向的判决。在美国、英国、澳大利亚等海洋法系的国家，前后判例的一致性会比较高。而中国、德国等大陆法系国家，变化可能较大。以下将要讨论的诸多问题均受各国司法差异因素影响，以下不再赘述。

总之，不确定性较大。尽管笔者对各国实际判例缺少一手研究，但从法理和情理上倾向于在专利“默认许可”成立，即利于开源免费。

就背景因素 2 而言，许可是否涉及实质性的对价是很重要的因素。实际上，我们现在讨论的是许可证，性质又不同于协议，但一些相关因素可以类比来考虑。没有实质性对价，指没有因交易性的收获进行实质支付，比如，支付价款。在这种情形下，许可证或协议在性质上更类似于赠与，对有关方的权利义务要求未必牢固。比如，Facebook 将自己开发的软件拿出来开源，自己付出了开发成本，却没有向使用者收取费用；使用者可以较随意地拿 Facebook 的开源软件免费使用。如果由于这种免费的行为中暗藏玄机，而导致 Facebook 或使用者要承受重大的义务、付出重大代价，则是有失基本公平的，除非有特别原因。所以，各国从司法的角度，会考虑“是否涉及实质性的对价”这一因素，但仍然是会采取不同的思路并给出不同的分寸和方向的判决。简而言之，Facebook Patents license 并不涉及实质性的对价，所以司法层面不会随便基于这种许可而使有关方承担与对价不相匹配的重大义务。

总之，还是不确定性较大，尽管笔者还是对各国实际判例缺少一手研究，但从法理和情理上仍倾向于 Facebook Patents license 因不存在实质性对价，相关方带来重大义务或损失的可能性较低，即利于开源免费。

背景因素 3 已经融合在以上讨论之中了。

综合以上背景因素的讨论，可知 Facebook Patents license 对开源还是比较友好的，至少不会造成重大损害。

Facebook，面子大于里子

再审视 Facebook Patents license 的两个关键点，其对“默认许可”是否仍能成立各有微妙影响。笔者的观点是，很可能使情形确实反而不如没有这个 Facebook Patents license，不过负面影响有限。

就关键点 1，Facebook 对免费专利许可设了限制条件：你不可以诉我知识产权侵权。

明示的效力当然优于默认的效力，所以笔者倾向认为默认许可的效力被破坏了。但以下三个因素将对开源有利：

• 用户对 Facebook 发起诉讼时，许可终止，但用户此前的使用仍享受免费许可。所以，主动权还是在用户手里，可以选择有利形势。当用户认为自己更多的知识产权为 Facebook 所使用，份量重于自己所使用的 Facebook 开源软件的知识产权时，才发起诉讼，并在诉讼前做好调整和准备；如果自己用的 Facebook 的知识产权比较多，而被 Facebook 使用的知识产权少，自己还是在赚便宜，何必去找 Facebook 麻烦呢？更应当指出，Facebook 所设的这个条件较容易做被规避：可以将专利转移给第三人，也就是白手套，由白手套去诉 Facebook。这样，即可以继续享受免费许可，又可以搞 Facebook。这在法理上是成立的。
• 对单一用户来讲，出现要诉 Facebook 而会破坏免费许可这一情况的现实可能性较低。
• Facebook 此条件有构成滥用知识产权的风险。

以上第 1 条实际上已经能够让 Facebook 的关键点 1 形同虚设，达不成实际意义了。以上第 3 条，不确定性很大。

就关键点 2，专利许可所涉及的专利，仅限于所涉及的软件本身，对于软件修改后或与其他技术共同使用而可能侵犯的专利，不在许可之列。

关键点 2 实际上暗藏杀机，比形同虚设的关键点 1 凶险些，但实际威力也还有限。重点在于：

• Facebook 明示不予许可的专利：软件修改后或与其他技术共同使用而可能侵犯的专利，实际上照样可能将开源软件捆死。这是其心机最凶险之处。
• 尽管 Facebook 明示排除了软件修改后或与其他技术共同使用而可能侵犯的专利，但只是泛泛而论。实际上，用户修改软件或将之与其他技术共同使用是必然普遍发生的情况，如果 Facebook 没有及时向用户提示这些具体专利的存在，并对收费有明确具体要求，笔者倾向于默认许可的效力仍应成立。当然，不确定性仍然较大。“及时向用户提示”指对于软件交付之前已经持有的专利，应在软件交付前明确提示；对于软件交付之后获得的专利，应在专利获得后马上提示。

综上，尽管复杂的不确定性仍较多，笔者倾向于认为 Facebook Patents license 总体上对开源较为友善，与不涉及专利的许可证相比较，没有带来实质性变劣。对 Facebook 而言，可能象征意义更大于实质意义，即面子大于里子。

Apache 潜在风险

另外，还有一个潜在风险因素，使 Apache 踢掉 FB+PL 之后使自己处在更为不利的境地。

Apache的风险控制措施是：“Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉 及FB+PL 许可证的，需要在 8 月 31 号前完成替换。”这一措施理论上说说还好，但在可操作性上问题很多。笔者认为，剔除 FB+PL 版权许可证所涉及的内容比较好操作：只要剔除相关的代码，替之以其他来源或自编的代码就好了。因为其他来源或自编的代码，基本就能确保在表达方式上的不同，从而规避版权侵权。这是现实的操作方式。

而规避侵犯 Facebook 专利权，上述方式很可能并不奏效。简单而言，版权保护表达形式，专利保护构想。规避表达形式，也就是从表述方式上加以实质调整就可以做到了。而规避构想，确实很难。实际上，Facebook 到底有哪些专利与之相关恐怕也很不清晰，还要加以规避，就更是难上加难了。分析工作和代码的重新设计对专利的专业性要求非常高，工作很复杂，工作量也很大。

这种情况下，Apache 可能面对的最坏情况是：放弃了 FB+PL 的开源代码，仍存在侵犯 Facebook 专利的高风险，又不会得到 Facebook 明示、默认许可。

Apache 的激进开源

所以，笔者认为，Apache 的表态很干脆地捍卫了开源情怀，踢掉 FB+PL 的行事方式有可能略偏强硬激进，尽管从规避不确定的风险而言，也不是完全没有道理。

（题图：HuffPost）

作者简介：

李可

集慧智佳知识产权咨询公司，李可。江湖人称“可哥”，老牌专利代理人，知识产权高级咨询师。70 后文艺理工男，属牛，性子慢但踏实稳妥。

本文转载来自 Linux 中国: https://github.com/Linux-CN/archive