React 的許可協議到底發生了什麼問題?

暫時性的結果

先說截止目前的結論: Explaining React's license

換言之,不會對 React 的許可協議做任何修改。

那這意味著 Apache 基金會下的開源項目都需要在 8 月 31 號前移除 React 相關代碼。

不清楚事件來龍去脈的同學可能問心生疑問了,

這意味著React 的許可協議有問題咯?會不會影響我繼續使用 React 呢?

那 React 的許可協議到底發生了什麼問題呢?我希望能通過回溯下事件經過,來幫助大家理清下整件事件的脈絡。

起因

Apache 基金會在 7 月 16 日把 Facebook BSD+Patents 加入了禁止名單中。

那這個 Facebook BSD+Patents 是什麼呢?這個又要從許可協議講起。

許可協議

或者叫軟體許可證, 英文 Software License, 根據維基百科的解釋如下:

軟體許可證是一種具有法律性質的合同或指導,目的在規範受著作權保護的軟體的使用或散布行為。通常的授權方式會允許用戶來使用單一或多份該軟體的複製,因為若無授權而徑予使用該軟體,將違反著作權法給予該軟體開發者的專屬保護。效用上來說,軟體授權是軟體開發者與其用戶之間的一份合約,用來保證在匹配授權範圍的情況下,用戶將不會受到控告。

轉自 軟體許可證。

通常,我們在項目中引入的開源框架和開源庫也是有一個許可協議的,統稱為開源代碼許可協議,Open-source License。

開源代碼許可協議有很多,他們對源碼的使用,發布規定不盡相同。

比如 Linux 使用的 GPL,就規定了使用 GPL 源碼的人必須也得開源。

各大開源代碼許可協議的差異可查閱 Comparison of free and open-source software licenses。

了解了這些基本常識後,我們就可以來看看 Facebook BSD+Patents 了

Facebook BSD+Patents

Facebook BSD+Patents 則是 The 3-Clause BSD License 協議的一個變種。

BSD 的授權本身是簡單,開放,沒有限制的,但 Facebook 在此基礎增加了一個 專利協議。

簡單來說就是基於 Facebook BSD+Patents 授權的軟體使用者,以及基於該許可協議開發衍生代碼的開發者,一旦被許可人對 Facebook 及其子公司甚至關聯公司提出直接的或間接專利訴訟,無論該訴訟是與所涉及項目有關還是無關,亦或是硬體專利訴訟,甚至是 Facebook 主動提出的專利訴訟而被告者進行的專利反訴,該協議授予用戶的專利權利即刻自動終止。

之後 Facebook 也有針對普通開發人員的一個人話版 FAQ 說明。

We use a standard BSD license paired with an additional patent grant for most of our open source projects. For brevity, we call this combination the Facebook BSD+Patents license. Weve compiled some answers to common questions about the additional patent grant:

Does the additional patent grant in the Facebook BSD+Patents license terminate if I create a competing product?

No.

Does the additional patent grant in the Facebook BSD+Patents license terminate if I sue Facebook for something other than patent infringement?

No.

Does the additional patent grant in the Facebook BSD+Patents license terminate if Facebook sues me for patent infringement first, and then I respond with a patent counterclaim against Facebook?

No, unless your patent counterclaim is related to Facebooks software licensed under the Facebook BSD+Patents license.

Does termination of the additional patent grant in the Facebook BSD+Patents license cause the copyright license to also terminate?

No.

可以看出,開發競爭產品是沒有問題的,這個附加的專利協議可以說是一個防禦型協議,這裡算一個伏筆,後面會提。

但這樣的協議依然是一個單邊優惠協議,授予人和被授予人的權利不平衡,Apache 基金會認為該許可協議與 Apache Software License 是不相容的。

RocksDB

很湊巧的是,Facebook 旗下的另外一款開源產品 RocksDB,在 7 月 16 號從 Facebook BSD+Patents 更換為了 Apache 2.0 和 GPLv2 雙許可。

這就讓 React 社區彷彿看到了希望的曙光,徹底沸騰了。

沸騰

於是 React 社區就開始冒出各種請願貼,場面一度很混亂,還有各種觀光旅遊團在下面留言。

然後 FB 的人開始刪帖引流,把人都集中到了這個 issue, Consider re-licensing to AL v2.0, as RocksDB has just done。

由於事件一開始我就 watch 了 這個 issue,回復的內容差不多都看過。

這個場景就像是一群程序員故意穿得破破爛爛去攔 Facebook 官老爺的轎子,撲通一下往地上一跪,「大人,小民有天大的冤情啊」。然後一部分人歡呼 FB 有新動態了,一部分人開始咒罵萬惡的開源流氓,一部分人開始威脅說我們不用了,我們用 Vue 和 Angular 去了,一部分人呼籲保持冷靜,靜觀其變,我們要相信組織。

場面是相當的不堪,相當的有辱斯文啊。

由於情緒化的內容過多,所以每隔一段時間 FB 的人就會上刪一些沒啥用的回復,然後呼籲大家保持冷靜,FB 自己也在討論。

於是熱度又慢慢冷了下去

再沸騰

在大家逐步保持冷靜的過程中,大家突然發現,

「咦!Jest 也有這個 Patents!」

「咦!Relay 也有這個 Patents!」

「咦!React Native 也有這個 Patents!」

「咦!Yoga 也有這個 Patents!」

「咦!AsyncDisplayKit 也有這個 Patents!」

大家到從這個事件開始,才第一次認真的看項目裡面每一個文件的意義,而不只是使用。

在意識到被 FB 農村包圍城市以後,於是第二波高潮又來了,大家又開始在各大 FB 子項目裡面請願了。

這些請願又被全部轉向了 Consider re-licensing to AL v2.0, as RocksDB has just done。

於是又一輪水帖刪帖開始了,慢慢又回歸了沉寂。

結論

還沒到網友們劃定的截止日期 8 月 31 號,FB 就給出了自己的結論 Explaining React's license。

FB 聲明自己這樣做的原因,這是一種自我保護,不想在專利訴訟方面浪費寶貴的資源和精力,希望能將精力更多的放在開源事業本身上,同事聲明 Facebook BSD+Patents 與其他開源協議是相容的,並尊重 Apache 基金會的決定和 React 社區中不同的聲音。

一些個人思考(私貨)

協議你看了嗎?

從本次事件來看,其實 Facebook BSD+Patents 的許可協議長期以來都是存在於 FB 各大開源項目之中的,但大家習慣於作伸手黨,也習慣於去忽略許可協議了。

如果你只是作個人項目,純玩的性質,那麼確實你無需在意太多,而如果你是商業性質項目,或是公司自營產品,或是服務於乙方,那麼你需要明確以下幾點:

1. 你對開源代碼的使用是否符合該開源代碼的許可協議?

2. 你對開源代碼的使用是否符合該開源代碼所依賴的第三方庫的許可協議?

那有同學可能要說了,Airbnb,微軟 Skype 團隊用 React、React Native 不是用的好好的嗎,也沒見有什麼問題呢?

是的,這個問題取決於你司的法務敏感程度。

從 FB 的聲明來看,確實它的初衷是一個防禦性質的,但從法務來講,情況可能就複雜一些了。

我們可以來看一個案例。

Preact 是 React 的另外一種開源實現。從 Preact 的 Companies using Preact 「請切換語言到英文」,我們可以看到一些熟悉的身影。

所以用,還是不用這個可能需要更高層的決定了,而作為程序員有在技術選型時做告知的必要。

替代品

社區中湧現了不少替代品,如上文所說的 Preact ,基本能保證你從 React的無痛遷移。

但有些東西你是無法找到替代品的。

比如 React Native,即便你用 Preact 實現替換了,像內部的 Native Render,你是無法替換的,而 React Native 的樣式布局解析是用的 Yoga 。

Yoga 本身也是使用的 Facebook BSD+Patents,連 Weex 的樣式布局解析在當前版本也是使用的 Yoga。

這些第三方庫在做技術選型時也是需要做調查的。

擔憂

什麼樣的開源是可持續的?

最早的開源很像技術世界的共產主義,大家一起維持著世界大同的夢想,但事實證明這樣的思想在商業世界下變得那麼的不堪一擊。

只有付出的慈善是難以為繼的。

FB 選擇添加了附屬專利協議,無論是出於什麼樣的目的,實際上都是在鞏固擴大自己的基本盤和話語權。

而這樣的開源被 FB 實踐證明是可行的。

未來,可能更多的大公司會加入類似這樣的附屬專利協議。

所以在社區中也有人指責 FB 在開一個壞頭,一個讓開源變得不純粹的壞頭。

他們擔心在未來,這樣的壞例子會讓大公司們加入 FB 的行列,使大家的項目中慢慢的充斥中各種限制協議。

該怎麼辦

如果公司許可,能用那就用,不能就不用。

但好的東西其實我們還是可以研究,吸取的。

JDK 不也有 OpenJDK 和 OracleJDK 嗎?

所以其實這樣的事情一直都有,也一直都存在。

而 FB 敢不敢使用這個潛在武器主動進行專利訴訟攻擊呢?

我的看法是不敢的。

FB 的基本盤開起來擴大了,一旦進行專利訴訟攻擊,社區瞬間就會散光。

社區成員現在留下的,更多的是基於對 FB 價值觀的信任,而開源,說白了,需要的還是無私奉獻,堅守在一起的人。

所以社區中也有人認為,這個跟猶太人已經統治世界的陰謀論一樣可笑。

影響

但無論如何,從 8 月 31 號開始,Apache 基金會下的項目凡是含有 Facebook BSD+Patents 的源碼,都必須移除,包括 React。

除非 Apache 基金會轉變看法。

前方高能,離題的私貨

知乎專欄 React && TypeScript 700 粉了,也增加了一位編輯。

希望大家能夠繼續關注專欄,因為接下來將會推出

React 源碼解析React Native 性能優化React 在 TypeScript 中實踐 等三個系列。

而且,沒錯,而且專欄將會保證每周至少兩更。


推薦閱讀:

移動應用開發入門,是否可以考慮先學習 React Native?
react native 真機調試apk無法安裝到設備?
碼農如何從零開始做出有設計感的app?
ReactJs控制項庫哪個比較好?
React Native 為何要新設計一個 ListView (FlatList )?

TAG:React | ReactNative | Facebook |