Android在爭議中逃離Linux內核的GPL約束【轉】

爲這個題材起名，我思考了許久，GPL 是著名的開放源代碼許可協議，Linux 內核開源項目正是在 GPL 的庇佑之下，十多年來在服務器、PC 端以及各類嵌入式設備上成績斐然，是當之無愧的當代計算機軟件的基石，說 GPL 表明着 Linux 的開源精神，絕不爲過。然而，現實世界中，GPL 開源烏托邦和商業社會的叢林法則之間存在劇烈的衝突，其中犬牙交錯，艱難成長，從中引起的思考，與你們共享。

Linux 內核的 GPL 約束

總所周知，Linux 內核以 GNU 通用公共許可證第二版（GPL V2）的受權使用協議下發行。GNU 通用公共許可證是一種 「Copyleft」 形式的「版權」，保障任何人都可以對 Linux 內核以及其衍生產品的使用、修改和從新發布的權力，前題是不能修改發佈條款。什麼意思呢，任何 Linux 內核的衍生產品（Derived Work）必須遵循 GPL 協議進行發佈。然而問題的核心在於什麼是 Linux 內核的衍生產品，其中有幾個致命問題，業界爭論了十年有多。

一、使用 Linux 內核的頭文件定義，進行系統調用的程序是否會被定性爲衍生產品？

二、連接使用了其餘 GPL 的類庫的程序是否會被定性爲衍生產品？

三、Linux 內核動態載入的模塊 LKM（Loadable Kernel Modules）是否會被定性爲衍生產品，以 LKM 形式開發的 Linux 驅動程序是否是衍生產品？

若是上述問題答案均爲「是」，GPL 將爲 Linux 打造一個的「封閉」 的開源世界，什麼意思呢？一個 Linux GPL的操做系統核心運行在 「 內核空間 」 ，上層的類庫、框架、服務、應用運行在 「 用戶空間 」 。用戶空間上的任何服務不可避免的須要Linux 內核的頭文件，進行系統調用，所以，中間層服務必須遵循 GPL 進行開放源代碼。調用中間服務層的框架或者其餘服務使用了 GPL 的類庫，所以，也必須是 GPL 的。同理，上層應用也被 「 傳染 」 ，必須是 GPL 的。因而，從內核到驅動到中間服務到上層應用，造成了一個 GPL 一體化軟件受權的軟件發佈總體。能夠認爲，這個總體上任何開發成果都是 GPL 的，除非極少數的例外程序可以證實自身獨立於系統的GPL環境。這樣的一個「軟件閉包」排斥的商業化的軟件模塊以及「想要錢」普通開發者，將整個軟件世界 劃分爲「 GPL 與 GPL 兼容的」的和非 GPL 的，每一個開發從業者面臨着選擇，要麼 Linux+GPL ，要麼 Linux 與你無關。

從新回到這三個問題，第一個問題，曾經被 Linux 內核的做者 Linus Torvalds 以及內核開發人員屢次澄清普通系統調用爲非 GPL 的做用範圍，甚至固化在 Linux 內核的源碼 COPYING 文檔中，爲 Linux 用戶空間的程序採用非 GPL 的受權許可證打下了基礎。

第二個問題，具備明確的答案，是。這也是爲什麼 GPL 被抨擊爲具備「病毒感染」的特性，一旦程序使用了 GPL 的模塊，自己即被傳染，程序必須成爲 GPL。若是主程序與 GPL 類庫是靜態連接（Static Link）的關係，業界通常認爲主程序必須限定爲 GPL。而對主程序動態連接（Dynamic Link）GPL類庫主程序通常認爲也必須是GPL的，若要打贏官司，必須證實主程序與GPL模塊之間具備「獨立性和可區分性」（Separate and Independent），才能逃離 GPL 的約束。GPL官方網站上的有這樣的 FAQ：

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the software as it is actually run includes the library.

 若是一個類庫以 GPL 的許可證受權進行發佈（不是 LGPL），是否意味着任何使用該類庫的軟件必須以 GPL 或者 GPL 兼容的許可證下進行發佈？

是，由於軟件包含了該類庫才能運做。

第三個問題，是硬件廠商和 Linux 內核開發社區之間一場曠日持久的爭論的中心。最著名的，莫過與圖形顯示設備廠商 AMD/ATI、NVidia 出自硬件規格保密以及知識產權的考慮，長期以二進制軟件包的方式獨立發佈圖形驅動，涉嫌違反了Linux內核開放源代碼的軟件受權協議 GPL，至今還是 Unity 與 Gnome 3 等依賴於硬件圖形加速的新型桌面技術發展上的一大陰影。主要的 Linux 內核維護者 Greg Kroah-Hartman 曾經嚴厲的批判過，內核中的二進制軟件包發佈的模塊是非法的、不道德的。

 

說 到此處，能夠看到 GPL 下的 Linux，存在着開源精神和商業機密以及知識產權保護相關的商業精神存在尖銳對立，對硬件廠商以及其餘商業軟件開發者來講，既不能忽視Linux廣闊的 商業市場，也不能放棄產品規格以及知識產權保護，二者都會傷害其立命之本。在早年的一份嵌入式操做系統選型的研究報告指出，Linux 相對於其餘的 BSD 的 Unix Like 操做系統，因爲 GPL 的約束限制，不具備商業優點。（參見引用3）。一言以蔽之，業界有 GPL 的恐懼症。

然 而，在移動互聯網蓬勃發展的今天，一個 Linux 的發佈版本，Android 在各類智能嵌入式設備上面大放異彩。聽說，Android 之父 Andy Rubin 極度厭惡 GPL（James Bottomley，Linux SCSI 子系統的維護者說其人「Working from an extreme dislike of the GPL」），然而 Android 向世人展現了採用 GPL 受權代碼的手機也能得到巨大的市場成功。

Android：把 GPL 侷限在內核空間

下圖是 Openfoundry 繪 制的 Android 的受權許可證結構，能夠看到在 Android 多層軟件棧中，僅僅最核心的 Linux 內核使用了 GNU 通用公共許可證，在這個層次上，Google 對 Linux 內核的全部修改必須反饋回 Linux 主版本樹（Android 的內核將在 Linux 3.3 版本進行迴歸，兩個版本的 Linux 內核進行融合）。

其上層的類庫以及應用框架以及所謂用戶空間部分，大部分使用 了「 溫和 」的 Apache-2.0 軟件許可受權，容許 Android 上的開發商基於 Android 的源代碼進行開發而不向社區反饋。基於上文討論 GPL 的第一個問題，用戶空間的類庫以及程序使用 Linux 內核的系統調用不被視爲是Linux內核的衍生產品，於是得以自由採用 Apache-2.0 的軟件受權進行發佈。GPL 世界和非GPL世界的分界線在於一個叫作 Bionic Libc 的類庫。Bionic Libc 的關鍵之處在於若是 Bionic Libc 受到內核 GPL 的「感染」，將會波及非 GPL 的用戶空間的各個模塊。

Android 的 Bionic Libc 的類庫，採用 BSD 的許可證受權。在 2008 年 Google IO大會上，一份著名的 PPT：「 Android Anatomy And Physiology 」講到 Android 使用 Bionic Libc 類庫替換Linux經常使用的 Gnu glibc ，其中一個主要緣由是 「 We want to keep GPL out of user-space 」。 （這其實有點難理解，畢竟 Gnu glibc 採用的是 LGPL 而非 GPL，並基於上文 GPL 第一點的討論，使用系統調用的程序再也不被視爲 Linux 內核的衍生產品，並不須要遵循 GPL，有興趣者請看下文用戶空間驅動部分的分析） 。Bionic Libc 充滿着非議，Bionic Libc 拷貝內核頭文件的行爲，並在源碼中聲明的版權信息均遭到了 「 侵犯 Linux 內核 GPL 約束 」 的質疑。這是 Bionic 頭文件的版權信息，許多人認爲是非法的：

「This header was automatically generated from a Linux kernel header of the same name, to make information necessary for userspace to call into the kernel available to libc. It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information.」

頭文件由Linux內核的同名頭文件自動生成，用來獲取完成用戶空間系統調用的必要的信息。它只包含原頭文件中的常數、結構和宏定義，所以，不包含版權信息。

無論如何，從目前的狀況看，讓 GPL 止步於內核空間的作法是成功的，並已經獲得很大一部份內核開發者的認同。James Bottomley，Linux SCSI 子系統的維護者在 2011年 LinuxCon 大會日本站上談到  Android 的商業成功與 GPL 恐懼的時候說：

We should also design more 「bright line」 systems which make the question of GPL compliance clear. The kernel’s user-space ABI is one such system; developers know that user-space code is not considered to be derived from the kernel. Making the boundary easy to understand helps to make the GPL less scary.

在遵照 GPL 的問題上，咱們必須澄清一些界線。內核的用戶空間 ABI（應用二進制接口）就是一種 GPL 的做用邊界，能讓開發者意識到用戶空間的代碼，不被定性爲內核的衍生產品，若是 GPL 的界線清晰而易懂，能夠幫助你們消除對 GPL 的恐懼。

緩解 Linux 驅動的 GPL 困境

Android 的發展離不開硬件設備廠商的支持，硬件設備廠商最關注的是 Linux 驅動的 GPL 約束問題，公開驅動程序源代碼將會泄漏設備的硬件規格和泄漏核心知識產權，這是硬件廠商 GPL 恐懼的原因。Google 竭盡全力的爲硬件設備廠家排憂艱難，保駕護航。上文提到的 「 Android Anatomy And Physiology  」，文中清晰的講到 Android 在用戶空間與內核空間之間存在着硬件抽象層  HAL（Hardware Abstraction Layer），HAL 類庫本質上一種用戶空間的驅動，其中的主要用途之一：規避 GPL。

用戶空間的驅動

Linux 是單內核操做系統（Macrokernel），這種操做系統的一大特色是驅動存活在內核，優勢是驅動與系統內核共生在相同的地址空間，運做的效率比較高， 缺點是當驅動有問題的時候，容易危及內核的工做安全。用戶區間驅動的思路是將驅動的主要業務邏輯剝離出來放到用戶空間的主驅動模塊中，內核中的驅動是個 「影子」驅動，只有透傳控制命令和數據的功能。

Android 的 HAL 至關於上圖中的主驅動，其在內核中的驅動至關於上圖中的影子驅動。規避 GPL 的硬件廠家把須要保護的商業機密以及知識產權相關的邏輯放在 HAL 層，以二進制包的方式發佈，不須要公開源代碼。

這種機制看上去很美，然而，一樣面臨着巨大的爭議。HAL 類庫與內核驅動之間經過普通的系統調用可以完成麼？若是不是普通的系統調用，用戶空間的驅動就違反了上文中的第一條，用戶空間的驅動不能得到 GPL 例外的豁免。Edward J. Naughton 2011 年 3 月撰文認爲，普通的系統調用應 被理解爲 gnu glibc 向外暴露的系統調用接口，而 Android 經過 Bionic libc 類庫暴露了更多的接口，包括原來在內核空間才能使用的接口，其目的是爲了讓用戶空間的驅動可以充分的利用內核和硬件資源。若是狀況果然如此，Bionic libc類庫是 Google 的後門，這也可能 Android 拋棄使用 gnu glibc 重寫 Bionic libc 的其中一個主要緣由。Edward J. Naughton 說：

Some of the calls exposed by Bionic are ordinarily not available to userspace because they’re excluded by the use of the #ifdef __KERNEL__ … #endif guards. If Google can define any call to the kernel from userspace as a 「normal system call」 (even those system calls ostensibly guarded by kernel matainers) simply by including it in its new C library, then a 「normal system call」 becomes whatever Google (or Oracle or Microsoft) wants it to be.

Bionic 暴露了原來在用戶空間不能使用的函數調用，這些調用本來在代碼中被 __KERNEL__ 的宏定義保護其運行在內核狀態。若是Google 只要將在 Bionic 添加暴露的接口就能夠自由的暴露 Linux 系統調用（這些系統調用明顯應該由 Linux 內核社區維護），那麼不免被其餘人效仿。

總結

總 得說來，Android 爲 GPL 下的 Linux 如何與商業社會並存與雙贏提供了一個成功的範本，嘗試爲 Linux 生態系統上的各類角色劃清彼此的做用範圍，梳理了各方在版權上的權利和義務，目前看來得到了驚人的商業成功。然而，這種工做模式也面臨着巨大的版權爭議， 理論上存在一種可能，一旦版權模式被否決，將面臨被全盤否認的災難。

相關連接：

一、鳥哥的Linux私房菜關於GPL的解釋

二、鳥哥的Linux私房菜網絡版本

三、本文原文地址：http://www.oschina.net/news/29401/android-gpl-license