從谷歌華爲暫停合做提及——聊聊主流開源協議

時間 2019-12-05

標籤谷歌華爲暫停提及聊聊主流開源協議欄目 Chrome 简体版

原文原文鏈接

引子

2019年5月20日，科技界最火爆的消息莫過於谷歌暫停支持華爲部分業務。關於這個事件將產生的影響，你們能夠從相關的科技媒體上找到詳細的分析。比較一致的見解是：谷歌的這個作法，對於國內的華爲用戶，影響不大；對於海外的華爲用戶，尤爲是在上游應用生態環境上，會有必定的影響。css

這是因爲，谷歌暫停合做的服務，都是在用戶層面的服務GMS。用戶層與安卓底層內核聽從不一樣的協議，所以沒必要開源，進而致使替換成本高企。基於現有生態，在海外市場構建應用生態環境難度很是大。html

這篇文章將嘗試從這則新聞涉及的開源協議來分析一下，這個作法背後相關的邏輯，並籍此，跟各位讀者聊一聊主流的開源協議。linux

安卓與開源協議

開源軟件或稱自由軟件是自由獲取，源代碼開放的，人們能夠自由地獲取和使用這些軟件。同時，爲了維護開發者和貢獻者的合法權利，使得軟件可以更好的被使用並不影響軟件的正常發展，開源社區開發出了各類開源協議。軟件開發者能夠根據軟件的屬性和自身須要的權責主張選擇合適的開源協議；下載並使用這些軟件的用戶，原則上，要求遵照開源協議的要求。git

衆所周知，安卓系統是基於Linux的。而Linux自己是基於GPL(GNU General Public License)v2開源協議的。GPL協議規定，只要這種程序在總體上或者其某個部分來源於遵循GPL的程序，該程序的總體就必須按照GPL流通，不只該修改文本的源碼必須向社會公開，並且對於這種程序的流通不許許附加修改者本身做出的限制。github

用通俗的語言來說，只要一個軟件使用了採用GPL開源協議的開源軟件，則在分發、傳播、發佈過程當中，必須一併開放源代碼。則這個軟件也就成爲了GPL開源協議的軟件。這被稱爲GPL協議的「傳染性」。算法

筆者曾經研究過一個開源的位圖輪廓矢量化算法名曰：Potrace。由於高效的算法被普遍採用。因爲其創始人使用GPL協議，所以，全部基於此算法的軟件，也都清一色的使用了GPL協議。npm

按照這個邏輯，基於Linux的安卓，也應該開源全部的技術代碼，即遵循GPLv2協議。然而，這在現實中並無發生，緣由是安卓系統自己並非遵循GPL協議的，而是採用了對商業友好的APL(Apache Software License)。該協議不強制要求後續代碼開源，也爲安卓上層軟件、驅動等商業活動打好了基礎。微信

那麼如今問題變成了，爲何基於GPL協議的軟件開發的安卓能夠採用APL呢？說好的「傳染性」呢？babel

首先說明，「傳染性」的邊界在哪？Linux內核的做者Linus以及內核開發人員屢次強調普通系統調用爲不是 GPL 的做用範圍。你們在 Linux 內核的源碼 COPYING 文檔中也能夠找到這些文字。這些澄清爲 Linux 用戶空間的程序採用非 GPL 的受權許可證打好了基礎。oop

好的，既然系統調用能夠不是GPL的管轄範圍。這裏面谷歌作了一件事情，就是把原來在內核層的驅動剝離出來，在內核中留有調用接口。並把驅動等部分提高到用戶空間，造成HAL(Hardware Abstraction Layer)。一方面起到了對硬件驅動層進行抽象，防止有問題的驅動對於內核的影響，同時也把GPL的影響控制在「內核層」。

上圖是 Openfoundry繪製的安卓受權許可證結構。僅僅內核部分使用了GPL2.0。所以，構建在用戶空間上的應用因爲聽從的APL協議，不強制要求開源，避免了商業軟件和GPL中開源要求的衝突。

此次谷歌對華爲暫停合做的軟件正位於用戶空間，如GMail，Google Map，Youtube，更新推送等。

因爲中國用戶對這些應用以及底層服務沒有很強的依賴，並且國內的安卓在用戶空間這一層已經有很強的用戶生態，故而問題不大。

而對於境外用戶，因爲用戶對這些應用已經極爲依賴，另外，當地的應用也或多或少地依賴這些底層服務，同時國內的應用尚且沒有在境外有充分的佈局。所以，目前的情況，會使得後續境外的華爲用戶，無軟件可用。

那麼，可否重建境外的軟件生態呢？答案是並不容易。

一方面，這些軟件並不開源，沒法從源代碼找到軟件運做邏輯。另外一方面，即使按照黑盒方式構建出相似軟件，也有法律和信任方面的問題。總而言之，這不是單純的技術問題。

所以，筆者謹慎的推測，華爲若是決定在海外挽回移動市場份額，推廣自主操做系統、重建軟件生態、打破壟斷的局面，將是一件很是艱苦的任務，並且真的須要各方面的通力配合。不光要靠華爲的努力，也須要生態鏈上的企業共同努力。

同時，對於依賴於閉源的操做系統的服務和軟件，一樣有被釜底抽薪的機率，雖然這種狀況出現的機率極低，可是風險的規模也註定和企業自身的體量正相關。

常見的開源許可

除了上面提到的GPL、APL等，還有一些常見的開源協議。當咱們進行軟件開發和使用其餘開源軟件時候，毋需以審慎的態度對待。隨着國內對知識產權保護的認識逐漸提升，保護愈來愈嚴格，這方面的風險是每個軟件做者須要考慮到的，若是選擇了一個開源協議的軟件，須要對相應的權責做出響應，不然可能會承擔法律的風險。固然，除了義務，也有對於免責的聲明，好比MIT協議：因爲使用此軟件形成的問題，做者能夠不負責。

阮一峯老師在這篇文章對翻譯了Paul Bagwell對這些開源協議的選擇邏輯。

這裏面，NodeJS中的ISC協議近乎等於BSD協議。

對於更復雜的狀況網友phodal總結了更多的狀況：

還有一個來自於GcsSloop博文中基於場景的選擇圖

能夠根據編寫時候的場景進行選擇：

這個網站總結了主流的開源協議。有一個幫助你選擇開源協議的網站，供你們參考。

下面列出了主流的開源協議的權責義務：

主流的開源軟件的選擇，也許是咱們的一個參考，下面的表中列出了一些流行軟件的開源許可。供你們參考。

協議	軟件
MIT	babel、.net core、rails、ThinkJS
GPL	Bash、GIMP、Potrace
APL	AOSP

許可覆蓋

你們在接觸NodeJS開發時候，使用npm初始一個軟件的時候，lisence默認是ISC。這也致使了更多的NodeJS軟件是使用ISC這個開源協議，或者更進一步選擇更爲寬鬆的MIT協議。因爲這都是比較寬鬆的協議，若是底層依賴或者想法借鑑了更爲嚴格的協議軟件。這個協議就是不合適的，由於阻斷了開源協議的約束傳播，就像你把一個類的Private屬性變成了Public，基於此構建的軟件也會忽視掉底層的協議。對於此，尤爲是作類庫的開發者更須要注意。