為這個題材起名，我思考了許久，GPL 是著名的開放源代碼許可協議，Linux 內核開源項目正是在 GPL 的庇佑之下，十多年來在服務器、PC 端以及各種嵌入式設備上成績斐然，是當之無愧的當代計算機軟件的基石，說 GPL 代表著 Linux 的開源精神，毫不為過。然而，現實世界中，GPL 開源烏托邦和商業社會的叢林法則之間存在劇烈的沖突，其中犬牙交錯，艱難成長，從中引發的思考，與大家共享。
總所周知，Linux 內核以 GNU 通用公共許可證第二版（GPL V2）的授權使用協議下發行。GNU 通用公共許可證是一種 “Copyleft” 形式的“版權”，保障任何人都能夠對 Linux 內核以及其衍生產品的使用、修改和重新發布的權力，前題是不能修改發布條款。什麼意思呢，任何 Linux 內核的衍生產品（Derived Work）必須遵循 GPL 協議進行發布。然而問題的核心在於什麼是 Linux 內核的衍生產品，其中有幾個致命問題，業界爭論了十年有多。
1、使用 Linux 內核的頭文件定義，進行系統調用的程序是否會被定性為衍生產品？
2、鏈接使用了其他 GPL 的類庫的程序是否會被定性為衍生產品？
3、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 的恐懼。
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 生態系統上的各種角色劃清彼此的作用范圍，梳理了各方在版權上的權利和義務，目前看來獲得了驚人的商業成功。然而，這種工作模式也面臨著巨大的版權爭議， 理論上存在一種可能，一旦版權模式被否決，將面臨被全盤否定的災難。