标签 专利 下的文章

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 倍。

引子:开源软件作者发出求救

约一个月前,笔者撰写了“开源情怀遭遇专利咸猪手”。现在我们回一下锅:看看事情的进展,分析可能的结果,以期开源人再碰到类似状况时,对可能的发展能多一点预期和准备,少一点盲目性和不确定性。

事情是这样开始的:按照开源中国博客文章,一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利。

XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。

依照开源中国的另一篇博客文章,XXL-JOB 作者委托开源中国与专利申请人进行交涉,作者的基本诉求包括:申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望,如,申请人从事实和技术角度加以澄清,并提出如果专利授权,应声明其与有关开源项目的关系,并“无偿开源”等。

如笔者在前文中指出的,此事件很典型,无论在国内还是国外都不是孤立性事件。事情的根本在于:开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留,将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利:包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

从此事开始以及开源中国与专利申请人进行交涉的进展报告发出到现在,3 个多月过去了,没有进一步的实质性进展。笔者并不认为奇怪。为什么呢?

如何发展?我们来抽丝剥茧……

没有进展,就是双方谈不拢。开源作者及开源中国一方的要求总结如下:

作者的诉求包括:

  • 专利申请人向专利局申请撤销专利。
  • 以公司名义发布正面声明,客观的描述此事。

开源中国与作者对声明内容的要求是:

  1. 详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。
  2. 在声明中表明将公开宣布主动申请撤销专利。
  3. 如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

从法律角度讲,双方对话行为属于民事行为,是基于双方自愿而进行的,任何一方都没有义务必须要进行对话协商。而如果对话不能进行,且当任何一方认为自己的正当权益受到对方损害时,可以向法院针对对方提起民事诉讼,也就是让法院做主。

专利申请人那头先按下不表,让我们看看作者一方的正当权益是否受到了损害。很遗憾,看来现在的主动权在专利申请人一边。

开源作者的要求:专利申请人向专利局申请撤销专利。

解读:如果专利申请是不正当的,上述要求是合理的。反之,则不合理。所以问题的关键是专利申请人所提出的专利申请是否正当。该问题随后再进行分析。

开源作者的要求:(专利申请人)以公司名义发布正面声明,客观的描述此事。

解读:公司就这个问题做出声明和澄清,从法律角度讲,公司可以自主做出决定,通常出于礼貌和善意的沟通,尤其不会产生负面影响时,公司会比较愿意进行。但法律方面没有强制要求,也就是说,专利申请人没有沟通或发出声明的义务,即使公司方面存在问题。而实际上,公司方面是否存在问题,即专利申请人所提出的专利申请是否正当,尚没有确定。

开源中国与作者对声明内容的要求 1:详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。

解读:“管理不善”应当是指专利申请人如果进行了不正当的专利申请,则是一个管理不善的问题。这就又转回到了那个关键问题:专利申请是否正当。

这句话是比较有意思的:“如果是在开源软件上做改进,那么应该详细描述改进的内容”。这句话字面之下似乎淡淡的有一层意思:如果专利申请针对的是在开源软件基础上做出的改进,那么专利申请可以是正当的。是否如此呢?答案基本上是肯定的。

如笔者前文中提到过的,按照专利制度的本意,任何人可以在现有的公知技术的基础上做出创新性的改进,然后就改进的内容去申请专利。这是正当的,也是受到鼓励和法律保护的。

关键问题的答案

所以,“专利申请是否正当”这个关键问题的答案就依赖于专利申请人是否做出了创新性的改进并就该改进来申请的专利,如果是,则专利申请是正当的;如果不是,就不正当。

接下来,就更加微妙了。开源方要求“细描述改进的内容”,仅就此要求而言,站在专利申请人立场上,是绝对不可以加以说明的。原因是:专利申请人就此内容的任何技术性说明都可能对申请人的专利构成不良影响。专利正在经受国家知识产权局的审查,审查的重点内容就是专利的新创性,也就是其对现有技术到底做出了什么样的改进,改进是否有新创性。专利申请人就此内容发表的任何意见,专利审查员都可以从中摘出对专利申请的新创性不利的内容,利用其来缩小专利的保护范围甚至驳回专利申请。

这种情形之下,申请人不针对“改进的内容”发表任何意见是明智、正当的。而开源方如果坚持要求申请人“细描述改进的内容”就显得强人所难,就不那么正当了。这时,开源方正确的做法是自己来完成开源软件作品与专利申请的比对,如果认为专利申请并未做出实质性的创新,可以将技术分析意见及相关支持性的技术文件按照第三方意见的形式通过正当程序提交给专利审查员。如果审查员认为开源方提出的意见是正确的,当然会加以采纳,相应会对专利申请加以合理限制或予以驳回。如果开源方对审查员的认定结果并不满意,后续还有行政和司法救济程序可以利用。

三点提示

这里提示的第一点是:不能简单因为专利申请当中涉及到的开源软件中采用的技术就直接认为专利申请中不存在新创性的技术改进。对新创性改进而得来的技术方案,在加以描述时要涉及到现有技术,这是正常的,不可避免的。

第二点:真正完成专利申请是否有实质性创新,专业性很强,成本很高;走行政和司法救济程序,成本就更高了。

第三点暂且不表。为什么事情还没有进展其实已经清楚了:专利申请人方面不表态是正当和必然的。至少要等到专利审查员做出授权或驳回的决定才有初步分晓。

开源中国与作者对声明内容的要求:

2、在声明中表明将公开宣布主动申请撤销专利。

3、如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

解读:如果专利审查员做出授权决定,表明专利针对开源软件在内的现有技术做出了新创性改进,相应专利申请也就是正当的。既然是正当的,专利申请人想来不会撤销或放弃专利申请,也不会将辛苦得来的专利“开源”或开放给公众。如果专利审查员做出驳回决定,也就不存在专利申请人撤销或放弃专利申请的问题了。当然,如果有人发起后续行政、司法救济程序,则可能带来变数。

完整地讨论好问题,就要说到第三点:如果专利最终被行政或司法认定成没有新创性从而被驳回,是否就足以证明专利申请人恶意窃取开源软件的技术成果呢?如果没有充分的相关理由和证据,还真不好这么下结论。因为很可能专利申请人出于善意想做出发明,并认为自己已经做出了具有新创性的改进,而最终做出认定的国家知识产权局或法院对新创性的理解和要求与专利申请人不同,才得出了不具有新创性的结论。如果是这种情况,专利申请人只是犯了一个诚实的错误而并不具有恶意。

收尾,旧话重提

我看到,投身开源软件的有情怀的理想主义者,有一些在黑暗和不公的打击之下,愤而退出了开源事业。笔者非常理解他们。我还看到,更多的人无视这些打击,以不变的情怀和理想,在这条道路上继续栉风沐雨,砥砺前行。笔者非常敬佩他们。人间正道是沧桑。


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

本文撰写参考了以下文章,并引用了该文章部分内容:专利告诉你,为何 Apache 禁用 FB + PL 代码,作者:付钦伟。

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

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

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

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

这场轰轰烈烈的暴动在发展过程中,于 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 后文艺理工男,属牛,性子慢但踏实稳妥。

投身开源软件的人,多是有情怀的理想主义者,期望通过无私的努力,让世界更美好。这是原本专注于专利问题的笔者,偶然被牵入到开源研究项目后,对他们所产生的第一印像。

然而,即使专利人也有专利情怀,现实世界中开源与专利的碰撞依然难免丑陋。这要求投身开源的理想主义者必须比一般人更加坚强和执着,才可能推进他们的美好理想。以下,笔者从伸向开源情怀的专利咸猪手这一角度,来提示一下开源人所要面对的现实、承受的考验。

引子

相信社区里的人对此事并不陌生:一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利

按照开源中国博客文章XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。依照开源中国的另一篇博客文章,XXL-JOB 作者委托开源中国与专利申请人进行交涉,作者的基本诉求包括:申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望,如,申请人从事实和技术角度加以澄清,并提出如果专利授权,应声明其与有关开源项目的关系,并“无偿开源”等。

开源软件遭遇专利咸猪手

我们暂且将之称为开源软件遭遇专利咸猪手吧!应当说,此事件很典型,无论在国内还是国外都不是孤立性事件。事情的根本在于:开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留,将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利:包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

开源软件开发者的情怀在于:多少相信,免费获取和利用知识是人的权利。投身开源的人,对售卖知识的知识产权制度多少有些敌意。不得不承认,我们当今的知识产权制度并不完美,最典型的就是专利海盗现象,它给技术进步和产业发展,尤其是软件产业发展带来了巨大的负面冲击。从某种意义上讲,开源软件的产生,就是一种打破目前知识产权制度对软件行业过度禁锢的积极尝试,而且发展势头良好。

而现实世界比较复杂。从开放的眼光看,存在即为合理,开源软件所遭遇的海盗式专利咸猪手,并非一无是处。因为目前不完美的知识产权制度仍是当下最为现实的解决方案。对于智力成果给予专有保护的必要性和积极意义是毋庸质疑的。知识产权专有保护的着力点主要在限制商业应用;而对于利用知识、技术进行学习和研发,则采取支持、鼓励的态度。

专利咸猪手的法理依据是这样的:

  • 在前人智力成果的基础上再进行创造性改进是每个人的权利,是利于社会进步的,即使前人智力成果也受知识产权保护。
  • 创造性改进的成果也是智慧成果,可以申请成专利,它的知识产权属于做出创造性改进的人,也就是专利发明人。

应再强调,这里的发明人不应将前人的成果纳入自己的权利保护范围,仅可以就自己做出的改进部分主张权利。相信有情怀的开源人和专利人都不会反对以上两条。

而以下这两个问题,大家可以充分探讨和质疑:仅就 XXL-JOB 专利事件,专利是将 XXL-JOB 的已有技术也纳入了保护范围?还是仅对 XXL-JOB 的改进部分要求进行保护?

如果情况属于前者,该专利将不符合法定授权条件,不应获得授权。如果情况属于后者,第三方发明人获得专利保护则是完全正当的。

现实的狗血在于,想回答清楚这个问题:专利是否将 XXL-JOB 的已有技术纳入了保护范围,是技术上很复杂,成本非常高的问题。负责任地回答这个问题,需要进行非常专业的技术和法律分析,而得出的结论还不能是定论。没错,这个专业分析的成本几千元起,花几万元可能也不奇怪,即专业性强,还成本高,而且没有定论,这一点是肯定的。

为什么没有定论?简单讲,经过司法程序认定,例如,在产生了生效判决的情况下,才有司法定论。请注意,是生效判决,指不被后续司法救济程序推翻的判决。通常,有了司法定论可能还平息不了学术争议,但司法定论是现实中管事的。而要得到司法定论,成本就更高了。

这是开源作者必然会面对的局面,并且常常让人感觉悲哀无助,因为专业性问题可以先放其次,高成本是谁都难以轻易承担的。

还就 XXL-JOB 专利事件而言,即使专利说明书中包括了 XXL-JOB 的技术内容,也不能简单得出专利要求将 XXL-JOB 的已有技术内容纳入了保护范围的结论。技术改进中涉及原有技术的内容是正当的、不可避免的。专利申请人是否不恰当地将 XXL-JOB 的已有技术内容纳入了保护范围,各方各有观点,但尚无定论,第一个要正式面对和回答这一问题的就是专利局的专利审查员。

专利审查员的工作受技术条件、现实条件的制约,也并不能解决全部问题。很多问题只能留待以后产生争议时,由后续准司法和司法程序解决。这又回到了前面所提及的:问题分析专业性强,成本高。

开源作者未完结的悲哀无助

开源作者所受的悲哀无助还没有完。使问题更为加剧的是恶意利用制度和程序而产生的问题。简单而言,就是专利海盗式的操作。既然问题难有定论,就拦不住有人在商业利益的驱动之下,百折不挠地努力尝试打各种擦边球,而且总会有所收获。他们中的急先锋便是各类专利海盗。专利海盗充分利用了复杂的程序、高专业性、高成本形成的高门槛。专利,经过专业性的包装等手法,会给专利审查增加很高的技术难度,有可能将开源软件中的已有技术改头换面包装成改进过的新技术,变相纳入私有保护范围,从而混水摸鱼得偿所愿:例如通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

实际上,以这种方式做事的,不仅止是专利海盗,背后和之后还有大批正当公司,因为有商业利益驱动。有可能有些激进,但这属于合理利用法律制度和程序。这个问题,至少目前还看不到根本性的解决办法。

开源软件遭遇专利咸猪手,说开了,就是被摘了桃子。实际上,专利高手,充分利用制度和程序,合理合法地何止是摘开源软件的桃子,谁的桃子都摘。这已经属于商业经营活动中的正常专利风险,任谁都避不干净。

白话总结

如果以简单直白的方式总结一下的话:任何人都有权利对开源软件中的技术方案加以改进然后去申请专利,如果做得专业老道,有可能用这些专利卡住开源软件的脖子。这种做法合理合法,其中手段高超的,还会被圈里人称赞为:专利布局水平很高!

笔者忍不住要插一句:当年我们都不懂知识产权时,外国人没少这么搞我们。现在,我们也已经有一些高手可以这么去搞外国人了。这是有钱才玩得起的昂贵的游戏。一旦搞起来,谈不上对内对外,外国人和我们对内自然也免不了一样搞法。没办法,这就是西方人设计的知识产权制度骨子里的东西。

这是开源作者必然面对的局面,很多时候除了想开些,除了以很高的成本对簿公堂,没有现实的解决办法。笔者有把世界描写得太过黑暗吗?

我看到,投身开源软件的有情怀的理想主义者,有一些在这些黑暗和不公的打击之下,愤而退出了开源事业。笔者非常理解他们。我还看到,更多的人无视这些打击,以不变的情怀和理想,在这条道路上继续栉风沐雨,砥砺前行。笔者非常敬佩他们。人间正道是沧桑。

开源软件开发者这边的故事讲完了,而开源用户应当如何面对这些问题呢?希望以后有机会与大家讨论。

(题图:legalraasta.com)


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

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

观点:停止向企业收取虚假的 Android 专利。是的,没错,现在还在收着!

我是一个 Linux 和开源软件的老用户了,我是在 Linux Mint 17.3 桌面上使用 LibreOffice 5.1 写的这篇文章。虽然我知道微软做了一些改变,但是我并不真的相信微软改变了它的反开源路线。

让我们来看看微软都做了些什么。2014年,微软 CEO 萨提亚·纳德拉 Satya Nadella 公开宣称说微软爱 Linux。甚至连曾经说过“Linux 是癌症”的前微软 CEO 史蒂夫·鲍尔默 Steve Ballmer ,现在也认为微软走向开源软件是一个好的方向

这并不是微软的最新举措。早在 2008 年,时任微软平台技术战略总监的 Sam Ramji 就说过,“微软的开源战略关注于帮助客户和合作伙伴们在现今琳琅满目的技术世界取得成功。”

空谈容易,代码才是干货,微软确实也做到了这一点。

2016 年伊始,微软宣布开发 Linux 上的 SQL Server将 Eclipse 和 Visual Studio 集成到一起、发布了基于 Debian Linux 的开源网络交换机,已经将 RedHat RHEL 添加到它的 Azure 混合云里面。

这仅仅是一部分。去年,微软努力将 .NET Core 带到了 Linux 上在 Azure 云上支持 Debian GNU/Linux,甚至还有它自己的 Linux 认证。在此基础上,它在 Ubuntu 上提供了开源的 Hadoop 大数据软件。微软甚至还有它自己的 Linux 发行版——Azure Cloud Switch

但是,为什么微软做了这么多开源举措,仍然有很多开源爱好者和开发者认为微软不值得信任?

一些人讨厌微软是因为他们认为微软又在玩老一套的“ 拥抱、扩展、摧毁 Embrace, extend, and extinguish ”的把戏。但是我不这样认为,微软确实在开源许可证下释放了很多代码,这里并没有隐藏的陷阱。

另外一些人讨厌微软纯粹是因为他们一直讨厌而已。对于他们而言,今天的微软同上世纪90年代到本世纪初那个资助 SCO 攻击 Linux 的微软并没什么不同。其实这也是不对的。

开源社区的越来越多的人们认识到 2016 年的微软不再贪婪,不再是 比尔·盖茨 Bill Gates 史蒂夫·鲍尔默 Steve Ballmer 时代的那个微软了。

然而,还有一件事不能让开源人士们真正相信微软:微软还在继续要求 Android 厂商支付 Android 专利费用。在最近的三月初,微软又签下了两份的 Android 专利许可

每次我写了微软开源方面的进展的文章,读者们就会告诉我,如果微软真的成了一个开源拥护者,那它就应该停止强迫其它公司们为它的虚假 Android 专利付费

虚假?是的,虚假!

根据中国商务部公布的信息,我们知道微软在 Android 方面有 310 项专利。据关注于知识产权和无形资产的全球性金融机构 M-Cam 的报告,微软所拥有的 Android 专利中涉及的专利内容已经是“公开领域的一部分”了

这也是为什么2015年9月微软和 Google/摩托罗拉达成了专利和解的一个原因。微软并没有放弃它的专利,但是不再就这些专利向 Google 收费。

那么,为什么人们宁愿付费而不是打专利官司呢?因为专利诉讼非常非常的昂贵。相比去法院碰碰运气,人们宁愿为每台设备花费 $5 到 $15 的小钱。

而微软呢?在 2014 年,微软就从它的 Android 专利上收入了 34 亿美元。仅仅三星就向微软单独支付了 10 亿美金的 Android 专利费用。这甚至对于世界五百强公司来说也是一笔很大的钱了。

在最近的一个财季,批量许可和专利就占到了微软全部收入的大约 9%

这就是为什么微软绝不会停止 Android 专利收费的原因,这个雷蒙德的家伙可以每年从这些专利中源源不断得到数十亿美元,它才不会放弃呢。

为什么呢?虽然一些开源程序员不喜欢微软的专利流氓做法,但是一些诸如 Canonical 和 RedHat 这样的主要的开源企业仍然在同微软合作。

底线是底线。反正那些骨灰级的自由软件开发者绝不会信任微软,可那又如何?只要微软能在同开源企业合作的同时依旧收取 Android 专利费用,它就没有理由停下来不收。