兩個月前談過「分開散佈．責任轉嫁」這種用來避開 GPL 感染的一種方法，今天要談的是另外一種方法：區隔機制。

所謂的區隔機制就是在 GPL 程式與 nonGPL 程式中間插入一個中介的介面，這個介面寫得夠好，讓 nonGPL 程式透過介面與 GPL 程式互動，nonGPL 程式因此不會包含任何的 GPL 程式碼，所以 nonGPL 程式不受到 GPL 感染。而這個介面可以是 LGPL、BSD 或 Apache 等任何一份授權條款。

nonGPL 程式
   ｜
Interface
   ｜
GPL 程式

這樣一個區隔機制可以隔離 GPL 感染的邏輯很簡單：因為中間存在的介面，所以 nonGPL 程式並未包含到 GPL 程式碼，因此當然可以不用受到 GPL 感染。就筆者所知，運用這種方式的大多是嵌入式裝置的專案，Google 的 Android 手機平台可以算是目前就是這種區隔機制最著名的實例。 

4. applications
       ｜
3. application framework
       ｜
2. middleware: libraries, virtual machine
       ｜
1. Linux kernel (GPLed)

上面是 Android 架構示意圖，可以看到 Android 平台有四個層次：最底部的第 1 層是 Linux 核心、第 2 層是包含了各類函示庫與虛擬程式的中介軟體層、第 3 層是應用程式框架，而最上層則是各種應用程式（註一）。除了最底層的 Linux 核心是 GPL-2.0 授權之外，其他部分都採用 Apache License 2.0 (Apache-2.0) 授權（註二），Apache-2.0 具有 BSD License 的特性（註三）：不具有像 GPL-2.0 一樣的感染性，可以與專屬軟體的授權條款相容。而 Google 之所以採用 Apache-2.0，就是希望可以透過這麼多層次的 Apache-2.0 程式來區隔底層 GPL-2.0 授權的 Linux，其他廠商就可以在這個平台上面開發出配合的應用程式與嵌入式裝置，同時並不需要將這些產品的原始碼提供給他人，因而保持各自的營業秘密（註四）。

這樣的區隔機制聽來簡單明瞭，我們也看到 Google 這樣著名的大公司採用這種方式，所以應該是合於 GPL 的方式吧！不過還是老話一句：有討論的空間！因為若嚴格解釋的話，GPL-2.0 的感染性會一層一層地傳染延展到嵌入式裝置中的每一個程式碼上，也就是在正常的情況下，第 2 層因為與第 1 層互動，其程式會涵蓋 Linux Kernel 的程式碼，因此第 2 層的中介軟體應該被感染成為 GPL-2.0 授權，第 3 層程式與第 2 層程式互動，因而被感染成為 GPL-2.0 授權，依此類推，第 4 層的應用程式也當然因此會成為 GPL-2.0 授權的。

若這樣的平台架構不是在嵌入式裝置中，而是在個人電腦，或者是大型裝置中運作，也許還比較有機會可以說的過去（註五），但是在小型嵌入式裝置中，因為各程式的運作相當緊密，互不可分，因此持嚴格解釋 GPL-2.0 者會認為採用 Android 平台製造出來的手機，其上的程式應該都是 GPL-2.0 授權，並且因此必須提供管道讓手機持有者可以取得手機程式的原始碼。

不過也有論者認為，只要中間這些用來區隔的介面寫的夠好，定義夠完備清晰，讓 nonGPL 程式可以在不包含 GPL 程式碼的狀況下運作，如此 nonGPL 程式就可以保持其不被感染的狀態。

在 GPL-2.0 感染性方面的探討，全球目前雖然漸漸有法學者投入研究，相關議題的討論也有增加的趨勢，但距離凝聚共識標準還有相當的距離，而在沒有法院判決或其他具高度說服力見解可資參考的情況下，一向是眾說紛紜。在這種現狀下，筆者只能觀察與整理現狀事實，嘗試從中釐清抽象模糊的 GPL-2.0 感染性判斷標準。到目前為止在這過程中，筆者雖然無法歸納出清楚的判斷標準，但是卻觀察到一個現象：商業公司似乎正在主導 GPL-2.0 內涵的解釋。這樣的現象從 GPL-3.0 修改過程可以窺知端倪：商業公司在 GPL-3.0 修改討論委員會中佔有超過半數的席位。而本文所提到的區隔 GPL-2.0 感染機制雖然仍有爭議，但是 Google 依舊實作出來，等到未來 Android 手機上市，又沒有相關權利人質疑此種方式的正確性，這樣的事實狀態在經過一段時間之後，就很有可能就讓此種區隔機制成為大家所認可、合於 GPL-2.0 內涵的利用方式。

未來究竟會有什麼有趣的發展，就等 Android 手機上市之後看看吧！

---

註一：Android 平台架構請見。
註二：Apache License 2.0 原文內容請見。
註三：BSD License 的介紹請見。
註四：Android 採用 Apache 2.0 的理由請見。
註五：這部分將另撰文討論。