GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由軟體元件被產業化利用的比率愈見頻繁，因此授權拘束性所帶來的爭議也愈來愈受到重視，本文便是針對這個議題，先依著作權法的預設說明、再照 GPL 授權條款的文意解釋，接著舉 Linux Kernel 的實際運作狀況佐證，一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準，及此標準在軟體元件的連接關係 (linking) 上，所可能擴散的拘束性範圍。
預先取得原作者同意是合法改作的前提
依我國著作權法第 28 條的規定：「著作人專有將其著作改作成衍生著作或編輯成編輯著作之權利。」所以、若是軟體元件並非自己從無到有重新撰寫，而是取用他人既有的成果來加以改寫與利用，就必須先取得該元件原始權利人的預先同意才可以進行。類似的規則在美國法是規定在其著作權法第 101 條 17 項 1 款（註二），其述明新作品是基於原作品而另行改作者皆為衍生著作 (A “derivative work” is a work based upon one or more preexisting works.)，然而、在軟體著作這個領域裡，何謂「基於原作品另行改作 (work based on the original work)」的定義與範圍向來有難以清楚界定的難處，這是因為在一個中型、大型的軟體專案裡，各元件彼此間，常常是以互相呼叫、互相存取的方式來協同運作，而不同元件程式碼在撰寫上，也並不一定是各作者基於共同創作的共識下去協力開發的，所以、若非在個案裡就不同元件的「互動與依存關係」來做判定，否則、很難直觀的去辨別各元件間是否真的存有「前後接力、彼此依賴」的緊密連結關係，而可以將整個軟體專案論為哪一個特定元件的衍生著作。
GPL 擴張了衍生程式的抽象定義與解釋範圍
由於自由開源軟體皆容許後手得以自行「研究、修改、重製、再散布」該程式，所以自由軟體元件的原始著作權人，都已經將這個「容許改作的同意」預先授權給得到程式的後手了，不論是 BSD、MIT、MPL、CDDL，或是 GPL 類別的授權元件都是如此，然而、這些自由開源軟體的授權條款，其在預先釋出程式改作權的同時，也會要求收受程式的後手，必須以遵守條款其他義務性要求 (obligation) 來作為得到授權的交換條件！而 GPL 類別的授權元件，其最為人熟知與影響最為深遠的義務性要求，便是如果新的軟體專案內含 GPL 授權元件的程式碼，那原則上就是整個專案 (as a whole) 會被認定為 GPL 授權元件的衍生程式，從而這個軟體專案再釋出時，便必須依照 GPL 條款的各項授權規定，以提供後手程式原始碼的方式來進行散布。GPL 授權條款這樣的要求相較於著作權法的預設，是大為擴張了法律原本對於衍生程式的抽象定義與解釋範圍，然而、以授權條款或是契約約定去補充法律規定之不足處，本就是私法行為下契約自由主義所容許的作為。但是、為了避免這樣的擴張機制引發過大的爭議與產生避用 GPL 授權元件的迴避效應，GPL 授權條款也明文表達了一個授權拘束性的例外規定，那就是、具有「獨立性與可區分性（Separate and Independent，註三）」的軟體元件，並不會因為僅與 GPL 授權元件同在一個軟體專案的架構下運作，就被歸類為 GPL 授權元件的衍生著作。所以、若是符合「Separate and Independent」這樣的例外規定，此時軟體專案便可以被認定為一個統合的聚合作品 (aggregation)，此時散布整個聚合的軟體專案時，就只需要提供該 GPL 授權元件的程式原始碼，而不一定要將 GPL 的授權拘束性及於其他自行編寫且獨立運作的個別元件。那麼、接下來的問題就是，所謂的「獨立性與可區分性」，是不是已經有一個公定標準，或是多數 GPL 授權元件的開發者皆已得到共識的參考範圍？
Linus Torvalds 認為運作上的依賴性才是衍生關係的最大特徵
「獨立性與可區分性」的判斷目前並沒有司法判決上統一的公定標準，但是若干的 GPL 著名元件的開發社群，確實有藉由不間斷討論與辯駁的過程，漸漸凝聚共識與統一說法的態勢。舉目前影響力最大的自由開源軟體專案 Linux Kernel 為例，其原始創作人與精神領袖 Linus Torvalds 也曾就這個議題，於 2001 年至 2004 年間，在網路信件往返的討論串裡給過若干的評論與建議（註四），簡要來說、這段評論內容的重點可以歸納為以下三點：
1、以 GPL-2.0 授權條款釋出的 Linux Kernel 確實具有授權拘束性，其他基於 Linux Kernel 所撰寫出來的衍生程式，不論其為驅動程式 (driver) 或是 Kernel 的修補程式 (patch) 皆無例外。
2、其他開發者為 Linux Kernel 所撰寫的 Kernel 模組 (Kernel Module) 以及修補程式，其著作權利歸屬於個別的創作者，然若是因為運作上的高度依賴性特徵，而被認定為 Linux Kernel 的衍生程式，則再釋出時便必須依照 GPL-2.0 的遊戲規則來進行散布。
3、Linus Torvalds 舉長篇小說來做比喻，若讀者需要讀完上篇才能看懂中篇，看完上篇、中篇才能看懂下篇，那麼中篇與下篇皆為前篇的衍生著作；而相若於此、假設某個特定元件是針對 Linux Kernel 進行撰寫，並且不依附於 Linux Kernel 之上便全無運作的功用，那麼該元件便不具單獨存立 (stand-alone) 的獨立性，從而也就必須被歸類為 Linux Kernel 的衍生程式，而併以 GPL-2.0 提供程式原始碼的授權方式向後散布。
其後 Linus Torvalds 更將他這樣的授權態度編寫進 Linux Kernel 的說明檔案裡（註五）成為正式的聲明。依著這份聲明，Linus Torvalds 認為其他軟體元件透過一般 system call 的方式來呼叫 Linux Kernel 的功能，並不會讓這個元件直接被定義為 Linux Kernel 的衍生程式，因為這樣的互動方式僅是透過一個既成的介面 (interface) 來與 Linux Kernel 產生交流，因此僅是一種單純利用 (use the program) Linux Kernel 功能的互動方式，而不代表此元件與 Linux Kernel 之間具有「不可分割運作的衍生關係」。自此之後、許多軟體社群的成員認為其他元件與 GPL 授權元件的互動關係原則上有兩種，一種是基於 GPL 程式改作 (work based on the program) 的衍生關係，此時 GPL 授權程式的授權拘束性會擴散至衍生程式；另一種是其他元件單純利用 (work using the program) GPL 程式進行功能展現的獨立關係，而若是判定是獨立關係的話，則 GPL 授權程式的授權拘束性不會擴散到這些獨立元件，從而這些獨立元件在與 GPL 授權程式合併散布時，僅需要提供與 GPL 程式產生互動關係時的呼叫程序與安裝步驟方面的資訊，而不需要提供此元件所有核心部份的程式源碼。
▲ 圖1：Linux Kernel 源碼第一層目錄下 COPYING 檔案內含的授權聲明
動態／靜態連結表彰的是元件間可分割與不可分割的互動關係
而由於「單純利用 GPL 程式的獨立關係」與「基於 GPL 程式改作的衍生關係」是較為法律面的用語，從這個時期之後、部份的自由開源軟體專案開發者，開始以技術面較為慣用的「動態連結 (dynamic link)」與「靜態連結 (static link)」等用語來舖陳 GPL 授權拘束性的內容。動態連結指的是程式元件間「浮動的、可取代的，無必然連結性」的互動關係，若軟體專案裡失去某個 GPL 授權元件的連結關係，但該專案仍具有大部份的執行功能，僅部份的功能表現因失去此一 GPL 授權元件，而顯得沒有完全版本那麼優異，那麼這大抵便是動態連結的互動關係；而靜態連結指的是程式元件之間「必然的、無可取代的，有固定連結性」的互動關係，若軟體專案裡失去該 GPL 授權元件的連結關係，則該專案喪失大部份或是核心的執行功能，那這大抵便是靜態連結的互動關係。其實不論是動態連結或是靜態連結，都不是專有的法律用語或是技術詞彙，但因為這二個名詞言簡意賅並且是軟體開發者慣用並可實作的技術方法，所以漸漸的就約定成俗成為了辨別 GPL 程式授權拘束性的慣用方法，許多開發者以「元件間動態連結的互動方式」，來對應「單純利用 GPL 程式的獨立關係」，另以「元件間靜態連結的互動方式」，來對應「基於 GPL 程式改作的衍生關係」，然而、這究竟是一種較為直觀且簡略的比擬方式，事實上在 GPL 授權條款的本文，並沒有任何一個章節有登載動態連結與靜態連結這樣的辨別條件與定義內容，所以動態連結、靜態連結這樣簡要的判斷條件，是可以做為 GPL 授權拘束性初階的基本辨別方式，但是在大型商業用軟體專案或是元件互動性複雜的個案上，建議還是應該回歸 GPL 授權條款的原始定義，依元件實際互動的方式來做細節上的評判（註六）。
實務上對 GPL 衍生程式可資操作的基本判別流程
綜上所述、關於 GPL 衍生程式的判定標準，以及其授權拘束性的擴散範圍，可以歸納出三個可資操作的基本判別流程：
- 該軟體專案中是否內含 GPL 授權元件的程式碼？若是如此，該專案是否已明確適用該 GPL 元件授權人認同的獨立與可區分機制，來利用這個元件？
- 軟體專案裡的其他元件是透過靜態連結，抑或是動態連結的方式與該 GPL 授權元件進行互動？
- 若是採用動態連結的互動方式，則此 GPL 授權元件所提供的功能是否居於整個軟體專案的核心地位？是否失去此一 GPL 授權元件的連結，則整個軟體專案的多數功能便不復完整？
以上三個基本判別流程可以用「原則 VS. 例外」的比較邏輯來理解，第一階段、軟體專案中若是內含 GPL 授權元件的程式碼，則原則上 GPL 元件的授權拘束性已經啟動，該軟體專案裡的其他元件會受到 GPL 授權條款所拘束，然而、例外的狀況是，雖然該軟體專案內含 GPL 授權元件的程式碼，但是其他元件得以主張是以「獨立與可區分」的方式來利用這個 GPL 授權元件，便可例外地不受到 GPL 授權拘束性所及；接著、進入了第二階段的判別流程，軟體專案裡的其他元件究竟是透過靜態連結的方式，抑或是動態連結的方式來與 GPL 授權元件互動？原則上若是靜態連結的互動方式，則因為元件與元件之間傾向是高度相依的融合 (merge) 關係，此時整個軟體專案會被認定是 GPL 授權元件的衍生作品，而在後續散布時會被要求全部得依照 GPL 授權條款的方式，提供整體專案的程式源碼；而若是其他元件是以動態連結的機動方式呼叫 GPL 元件的功能表現，那麼這時候才會進入第三階段的判別流程，個案的去判別該 GPL 授權元件所提供的功能，在質的一方面，於整個軟體專案裡是否居於重要的核心地位？或是就量的方面，是否 GPL 元件一經抽離之後，就會造成軟體專案多數的功能不復完整？如果此二個子問題的答案皆為「是」，則此 GPL 元件的授權拘束性仍然有可能及於整個軟體專案，而若此二個子題的答案皆為「否」，則此元件的授權拘束性原則上不及於其他元件，但使用者在散布它時，仍應提供其他元件與此 GPL 授權元件間，連結呼叫與互動對應程序方面的必要資訊。透過以上三個流程的自我檢驗，GPL 授權元件的使用者便可知悉該元件，所可能為整個專案帶來授權拘束的基本可能性與風險性，其實際的操作步驟請參照下圖所示：
▲ 圖2：GPL 授權拘束性基本判別流程示意圖
Android 因中介隔層例外地主張獨立性與可區分性
此外、關於 GPL 對於衍生程式的判定標準還有一個時興的子議題，那就是近年業界不乏利用中介隔層 (middle layer) 的方式，來區隔 GPL 元件所可能帶來的授權拘束性，最顯著的例子、就是 Google Android 所規劃出來的中隔平台。Google Android 平台的授權架構，底層為 GPL-2.0 授權的 Linux Kernel，而中介隔層採用的是 BSD 類別或是 LGPL-2.1 類別授權的函式庫 (library)，以及 Apache-2.0 授權的 runtime system，而此中介隔層之上還有中介應用程式及函式庫的溝通框架 (application framework)，最上層才是讓個別廠商自行開發的應用程式 (application program)。透過這樣中介隔層的機制，Google Android 平台上層的應用程式僅與中層的函式庫溝通與互動，而底層 Linux Kernel 也僅與中層的函式庫溝通與互動，從而上層的應用程式並不會直接與底層的 Linux Kernel 直接溝通，故而以此點來主張這些應用程式在執行上與功能表現上，具有不一定受到 Linux Kernel 影響的「獨立性與可區分性」；除此之外、更重要的一點是：Google Android 中介隔層的函式庫與 runtime system，完全以無授權拘束性或是弱授權拘束性的自由軟體元件來營建。也就是說、中介隔層部份依其授權方式，對外是可以提供程式源碼並允許後續散布的，理論上這樣的中介隔層便具有實作上「可移植的可能性」，若是有程式開發者願意花費時間將此中介隔層移植至其他非 Linux Kernel 的作業系統上去運作，並非完全沒有可能，而既然中介隔層與採用 GPL-2.0 授權的 Linux Kernel 之間具有「可移植、可拆解」的「獨立性與可區分性」，那也就有機會被認定為除外於 GPL 授權元件的衍生程式範圍，而不用受到 GPL-2.0 授權條款的擴散拘束（註七）。
▲ 圖3：Google Android 平台中介隔離的授權架構圖
Google Android 平台這種中介隔離 GPL 授權拘束性的作法，在業界也不乏見其他的類似作法（註八），然而這些中隔手法、也並非完全不會引發授權爭議，舉 Google Android 平台為例，其之所以可以成功運行，第一點是由於 Google Android 平台中介隔層的架構完整、佈局嚴密，所以不易被自由開源軟體社群的參與者，直接視之為以簡陋的中隔介面惡意規避 GPL 授權條款的義務性規定；第二點、也是最重要的一層因素，是因為 Linux Kernel 核心開發群與其精神領袖 Linus Torvalds，對於 GPL-2.0 授權條款在衍生程式範圍上的解釋態度較為寬鬆，其認為 Linux Kernel 之上存有不必然受到 Kernel 授權狀態拘束的獨立使用者空間 (user space)，所以取用 Linux Kernel 的 Google Android 平台便可依此觀點對 Linux Kernel 進行中隔處理。而雖然 Linux Kernel 多數核心開發群同意這樣的觀點，但並不能類推其他以 GPL 授權其軟體元件的自由開源軟體社群，都會同意以此種中介隔層的方式，能將 GPL 元件的授權拘束性完全隔離掉，所以、若是要將日後可能產生的法律爭訟與侵權風險降到最低，在很多不同狀況的案例上，還是得依所使用 GPL 授權元件的細部資訊，來進行個案式的判斷。
是否開啟 GPL 授權拘束性仍需考究實務的個別情況
單純在專案裡利用 GPL 授權元件並不必然會開啟其授權拘束性，有時候授權拘束性的疑慮和恐懼，其實是被使用者誤解並且過度擴大解讀了（註九）。本文初始之所以採用「牽一髮而動全身」這樣的說法來比擬 GPL 元件的授權拘束性，便是利用簡明的比喻提醒讀者，個別的 GPL 元件若是採用動態連結的方式來與其他元件互動，或是專案開發者也能夠找到其他授權方式的元件將其所負責的功能代換掉，這些跡象都可以證明該元件實際上與整個軟體專案在開發上的關聯不深，就像一拔而起的單一毛髮，並不會將其 GPL 的授權拘束特性傳導到專案的其他部份；然而、若是該 GPL 授權元件是採用靜態連結的方式來與其他元件互動，或是在功能表現上居於專案的核心定位，那麼此一 GPL 授權元件在運作上便與整個軟體專案密不可分，從而並不是那麼輕易地可以被更換、代替，此時就像是一串與頭皮緊密連結 (link) 的毛髮，無法輕易拔除並且關聯撼動全身，那麼該軟體專案的其他元件便會被視為是 GPL 授權元件的衍生作品，從而整體專案便進入了 GPL 授權拘束特性的擴散範圍。
但無論如何，目前關於 GPL 授權拘束性的擴散範圍，全球仍然沒有確定的司法判決是就此議題進行細節釐清與範圍界定的。所以此議題相關的評論與看法，並沒有一個完全權威並可據以簡單判斷的遵循法則，有時複雜的狀況、也仍然處於「一個 GPL 授權拘束性、個自解讀」的灰色地帶。本文僅先就此議題原則性的重要指南進行論述，提供一至三個基本步驟來讓讀者自我完成簡易驗證之用，而若是特定 GPL 授權元件的採用關係，是涉及大型商用專案或是元件互動性複雜的狀況，則建議還是應該個案式的依元件實際互動的方式，以專案分析的方式來做細節上的評判。
其他與此議題相關的重要參考文章羅列如下，以供對此議題有興趣的讀者，可以據此查證原典：
- Linus Torvalds 於網路討論串裡，發表其對 GPL 授權拘束性的意見與立場：http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
- Lawrence Rosen 所著專文「General Public License, Explained」，說明 GPL 授權元件的授權拘束性範圍，以及推廣「License Inheritance」此一嶄新名詞：http://www.sitepoint.com/public-license-explained/
- Carsten Emde 於 2008 年 11 月的演講簡報，綱舉目張的解釋了運作在 user space 下的驅動程式與 Linux Kernel 之間的授權拘束性關係：http://www.osadl.org/fileadmin/dam/presentations/FAPI-UIO-SPS-2008.pdf
- Greg Kroah-Hartman 於其 2006 年提供的演講中，批論不提供程式源碼的專屬驅動程式，違反了 GPL 條款的授權拘束性：http://www.kroah.com/log/linux/ols_2006_keynote.html
- Greg Kroah-Hartman 於 2006 年 8 月發表 UIO 作法的說明頁面：http://lkml.indiana.edu/hypermail/linux/kernel/0608.3/1908.html
- Jonathan Corbet 2004 年 1 月 於 LWN.net 的報導，討論 user space 驅動程式的技術內容：http://lwn.net/Articles/66829/
註一：相類的名詞包括早期以批判角度立論的「擴散效應 (tainting effect)」、「感染特性 (viral effect)」，至 Patrick J. Moran 於 2003 年美國太空總署 (NASA) 的研究報告中，改以較中庸而不帶評議立場的「授權攫取性 (License Capture)」稱之，本文選用 Lawrence Rosen 所推廣之「License Inheritance」一詞，以表彰此一特性原始的立意良善，其導引 GPL 授權元件的後續版本皆需「承繼」原始著作權利人預設的方式，以提供程式源碼的方式來釋出衍生作品，但實際施行上、也對使用者帶來若干不得不去遵從的「拘束」，故稱之為「授權拘束性」。
註二：A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.
註三：這樣的條款文字出現在 GPL-2.0 第 2 條 第 2 項：”If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.”；以及 GPL-3.0 第 5 條 第 2 項：”A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”。
註四：原始討論串內容已因空間轉址而失聯，但資訊亦已被大量轉錄至許多 Linux Kernel 相關網站，如右列連結即為一例：http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
註五：說明檔案名為 COPYING，其儲放於 Linux Kernel 程式源碼第一層面錄下：「NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”.」
註六：程式元件間互動與溝通的方式有許多不同的變體，部份自由軟體社群的開發者認為，元件透過網際網路的方式來呼叫 GPL 授權元件，應可以避開 GPL 授權拘束性的擴散範圍，甚至進一步主張透過 unix socket，或是 pipe 的方式來進行溝通，也可能產生一樣的除外效果；然而、若是依 GPL 授權條款的文義與目的性解釋，此種方法仍然有一定風險會被視為 GPL 義務性要求的規避，而產生後續法律爭議的風險。例如 2007 年末新編撰的 AGPL-3.0 (GNU AFFERO GENERAL PUBLIC LICENSE version 3)，便是針對網路連結的呼叫方式來進行補強，其將網路連結 AGPL-3.0 衍生元件的方式定義為程式散布的方式之一，遂大幅度的擴張了 AGPL-3.0 衍生程式的授權拘束性範圍。
註七：此種中介隔離的互動架構在 GPL-2.0 授權條款裡並沒有明文述及，但在 GPL-3.0 裡開始有簡要的描述，一般對此機制的通俗用語為「well defined interface」，其於 GPL-3.0 授權條款的主要描述位於第 1 條第 3 項 (b) 款：serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form.
註八：另一種硬體裝置驅動程式 (driver) 方面的 UIO 中介隔離模式 (the user space I/O system)，其實也與 Google Android 平台的作法十分類同，其也是在應用程式及 Linux Kernel 之間隔一層以 LGPL、BSD、MIT 等，可以為 GPL-2.0 授權方式「吸納同化 (merge)」的函式庫程式做為中介，然後再將驅動程式內含的重要演算法撰寫在應用程式的層級，以運作在 user space 的方式，間接透過中介的函式庫來與 Linux Kernel 進行互動與存取，透過這樣的區隔方式，也有許多自由軟體專案的程式開發者認為，寫在應用程式層級的驅動程式，有機會不被列入 Linux Kernel 授權拘束性的擴散範圍。
註九：相關的評論與說明，可參照 Lawrence Rosen 所著專文「General Public License, Explained」：http://www.sitepoint.com/public-license-explained/
