踢掉 FB+PL:Apache 的開源激進宣言?
本文撰寫參考了以下文章,並引用了該文章部分內容:專利告訴你,為何 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 後文藝理工男,屬牛,性子慢但踏實穩妥。
相關文章
- 開源Apache KafkaApacheKafka
- Apache RocketMQ 的 Service Mesh 開源之旅ApacheMQ
- Apache開源相關元件Apache元件
- 開源引路人:我的Apache Mentor之路Apache
- 10個強大的Apache開源模組Apache
- 一腳踢掉NEW (轉)
- Apache畢業賀禮—Apache ShardingSphere跌宕起伏的開源之路Apache
- 國產開源API閘道器專案進入Apache孵化器:APISIXAPIApache
- Reactive宣言的思考React
- 如何在開發專案裡進行自我激勵!
- 12V-5A反激式開關電源例項
- 全票通過!百度開源專案ECharts首進Apache孵化器EchartsApache
- 開篇宣言---深入學好用好JavaScriptJavaScript
- 相信開源的力量:Nebula Graph 採用 Apache 2.0 作為其開源協議Apache協議
- 新的《敏捷宣言》 - Magno敏捷
- Yahoo開源的Apache Kafka管理工具:Kafka ManagerApacheKafka
- go reactive宣言GoReact
- 微軟在 Apache 下開源 ASP.NET MVC微軟ApacheASP.NETMVC
- 基於 Traefik 的激進 TLS 安全配置實踐TLS
- Polkadot激進的區塊鏈治理計劃區塊鏈
- 參與 Apache 頂級開源專案的 N 種方式,Apache Dubbo Samples SIG 成立!Apache
- 我的web寫作宣言Web
- Apache Hadoop 3.0的特性和開發進展的更新 [session]ApacheHadoopSession
- 終端登入被互相踢掉,思路分析
- 激發創新,助力研究:CogVLM,強大且開源的視覺語言模型亮相視覺模型
- 開源專案剖析之apache-common-poolApache
- 姜寧 ASF 2023 董事競選宣言:成為開源世界的催化劑和變革者
- Apache Camel與Spring-boot和Kafka的整合開源案例ApacheSpringbootKafka
- 五種開源協議的比較(BSD,Apache,GPL,LGPL,MIT)協議ApacheMIT
- 程式設計師老爸的宣言程式設計師
- 將開源進行到底:Facebook引爆下輪開源浪潮
- Apache Pulsar 榮獲中國開源雲聯盟「2021 優秀開源專案」Apache
- Apache RocketMQ 榮獲 2021 中國開源雲聯盟優秀開源專案ApacheMQ
- 走進開源專案 - urlcat
- 共探開源生態|Apache Pulsar 社群助力 Apache APISIX Summit Asia 2022ApacheAPIMIT
- 如何向開源專案(Apache-InLong)提交程式碼Apache
- Apache基金會接受阿里開源JStorm捐贈Apache阿里JSORM
- Kafdrop是Apache Kafka的開源Web UI視覺化介面 - Emil KoutanovApacheKafkaWebUI視覺化