這是本文件的舊版！
GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍
林誠夏／文
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 類別的授權元件都是如此，然而、GPL 類別的授權程式，其在預先釋出程式改作權的同時，也要求收受程式的後手必須以遵守 GPL 授權條款其他的義務性要求 (obligation) 來作為得到授權的交換條件，而其中一個重要的義務性要求，便是如果新的軟體專案內含 GPL 授權元件的程式碼，那原則上就是整個專案 (as a whole) 會被認定為 GPL 授權元件的衍生程式，從而這個軟體專案再釋出時，便必須依足 GPL 授權條款的各項授權規定，以提供後手程式原始碼的方式來進行散布。GPL 授權條款這樣的要求相較於著作權法的預設，是大為擴張了法律原本對於衍生程式的抽象定義與解釋範圍，然而、以授權條款或是契約約定去補充法律規定本身之不足處，本就是私法行為下契約自由主義所容許的作為。但是、為了避免這樣的擴張機制引發了過大的爭議與產生避用 GPL 授權元件的迴避效應，GPL 授權條款本身也明文表達了一個授權拘束性的例外規定，那就是、具有「獨立性與可區分性（Separate and Independent，註三）」的軟體元件，並不會因為僅與 GPL 授權元件同在一個軟體專案的架構下運作，就被歸類為 GPL 授權元件的衍生著作。而若是符合「Separate and Independent」這樣的例外規定，此時軟體專案便可以被認定為是一個統合的聚合作品 (aggregation)，此時散布整個聚合的軟體專案時，就只需要提供該 GPL 授權元件的程式原始碼，而不必然及於其他自行編寫具獨立運作的個別元件。那麼、接下來的問題就是，所謂的「獨立性與可區分性」，是不是已經有一個公定標準，或是多數 GPL 授權元件的開發者皆已得到共識的範圍？
Linus Torvalds 認為運作上的依賴性才是辨析程式衍生關係的最大特徵
「獨立性與可區分性」的判斷目前並沒有司法判決上統一的公定標準，但是若干的 GPL 著名元件的開發社群，確實有藉由不間斷討論與辯駁的過程，漸漸凝聚共識與統一說法的態勢。舉目前影響力最大的自由軟體專案 Linux Kernel 為例，其原始創作人與精神領袖 Linus Torvalds 也曾就這個議題，於 2001 年至 2004 年間，在網路信件往返的討論串裡給過若干的評論與建議（註四），簡要來說、這段評論內容的重點可以歸納為以下三點：
- 以 GPL-2.0 授權條款釋出的 Linux Kernel 確實具有授權拘束性，其他基於 Linux Kernel 所撰寫出來的衍生程式，不論其為驅動程式 (driver) 或是 Kernel 的修補程式 (patch) 皆無例外。
- 其他開發者為 Linux Kernel 所撰寫的 Kernel 模組 (Kernel Module) 以及修補程式，其著作權利歸屬於個別的創作者，然一旦因為運作上的高度依賴性特徵，而被認定為 Linux Kernel 的衍生程式，則再釋出時便必須依照 GPL-2.0 的遊戲規則來進行散布。
- 舉長篇小說來做比喻，若讀者需要讀完上篇才能看懂中篇，看完上篇、中篇才能看懂下篇，那麼中篇與下篇皆為前篇的衍生著作；而若然特定元件是針對 Linux Kernel 進行撰寫，並且若不依附於 Linux Kernel 之上便全無運作的功用，那麼該元件便不具單獨存立 (stand-alone) 的獨立性，從而也就必須被歸類為 Linux Kernel 的衍生程式，而併以 GPL-2.0 提供程式原始碼的授權方式向後散布。
其後 Linus Trovalds 更將他這樣的授權態度編寫進 Linux Kernel 的說明檔案裡（註五）成為正式的聲明。依著這份聲明，Linus Trovalds 認為其他軟體元件透過一般 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 程式產生互動關係時的呼叫方式與安裝步驟方面的資訊，而不需要提供此元件所有核心部份的程式源碼。
動態／靜態連結表彰的是元件與元件間可分割與不可分割的互動關係
而由於「單純利用 GPL 程式的獨立關係」與「基於 GPL 程式改作的關係」是較為法律面的用語，從這個時期之後、部份的自由軟體專案開發者，開始以技術面較為慣用的「動態連結 (dynamic link)」與「靜態連結 (static link)」的用語來舖陳 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 授權拘束的可能性與風險性為最大。
以下提供幾個UIO模式的重要連結，有後續問題歡迎接續討論。
1. Carsten Emde於2008年11月的演講簡報，綱舉目張的解釋了運作在Userspace下的驅動程式與Linux Kernel之間的拘束關係(重點在第八頁)： http://www.osadl.org/fileadmin/dam/presentations/FAPI-UIO-SPS-2008.pdf 2. 2006年8月UIO作法的原開發者所發布的說明頁面：http://lkml.indiana.edu/hypermail/linux/kernel/0608.3/1908.html 3. 2006年Linux Kernel開發者Greg Kroah-Hartman在其演講中批評不符合GPL授權規定的專屬驅動程式：http://www.kroah.com/log/linux/ols_2006_keynote.html 4. 2004年4月Linus發表他對GPL授權拘束性的意見和立場：http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/COPYING.modules?view=co 5. 2004年1月LWM.net上面討論Userspace驅動程式的技術內容：http://lwn.net/Articles/66829/ 6. 2007年發表的德文博士論文：「病毒般的影響力：開放源碼軟體領域的開發風險（Der virale Effekt: Entwicklungsrikien im Umfeld von Open Source Software）」，以Creative Commons 姓名標示-非商業性-禁止改作 德國2.0版的授權方式授權散布： http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/3081
註一：相類的名詞包括早期以批判角度立論的「擴散效應 (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 衍生程式的授權拘束性範圍。
轉：(1)可代換(2)透過UI INTERFACE→靜態連結、動態連結。
合：依個案來定，一個 GPL 條款個自解讀的年代。
何謂 GPL 的授權拘束性？VIRUS EFFECT？互惠性？→衍生著作、取得改作權的前提，COPYRIGHT TO COPYLEFT→一言以蔽之、衍生著作，何謂著作權法上的衍生著作？CODE EMBEDDED→互相存取→連結、互動關係→work based on the program, work use the program→刪除法、除外法：什麼是work use the program，而不是USE的、就極可能是BASED ON→LINUS TORVALDS、看完第一本小說、才能看完新寫的那一本小說→哪些是USE？(1)可代換、(2)透過UI INTERFACE→DYNAMIC LINK、STATIC LINK。
要解決的問題：1、何謂改作、何謂修改？2、靜態連結、動態連結；3、授權拘束性的範圍。(兼論到AGPL-3.0與GPL-3.0其實在衍生著作上的判斷並無二致)
這提出的四個問題，判斷核心的概念都是「哪一種利用Samba的互動關係，會被視為Samba的衍生作品，因而後續散布時會被要求得依GPL-3.0規定的授權方式來提供程式原始碼。」
進階的、關於Static Link與Dynamic Link之間的差異則可以參考我之前就這個議題所撰寫的相關問覆：http://www.openfoundry.org/tw/forum?func=view&catid=8&id=669#670
好的、那麼我們照著上面討論到的這些原則來回覆你的問題：
2、軟體專案的原始碼中有呼叫到Samba 3.6 (GPLv3)compile出來的binary, 使用system()來呼叫, 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許, 我的原始碼與samba的原始碼是否要公開？ 我的原始碼是否同樣需以GPLv3發佈？
透過網路散布是沒有問題的、Samba部份的原始碼必須隨同binary code一同散布、自行撰寫的部份則要看互動狀況來判定，如果純粹透過system call的方式來呼叫Samba本來提供的呼叫介面，則風險性降低，但若是自行撰寫的程式僅能用來呼叫Samba，也並無其他可代換Samba的程式可供代換的話（例如部份網站CMS可用PostgreSQL來代換MySQL），則風險性會再升高。若是狀況確屬於後者，則建議還是要考量以GPL-3.0的方式來將自己撰寫的程式原始碼與Samba一併釋出，因為Samba這個專案的著作權利目前受到「軟體自由託管機構(Software Freedom Conservancy, http://sfconservancy.org/)」的代管，這是一個對於軟體自由理念要求嚴謹的權利代管機構，其代理Samba專案的權利人發動自由軟體侵權訴訟的動機與可能性都非常高。
這部份相關的報導與資訊，可以參照葛冬梅小姐所撰寫的「從 BusyBox 案談起：台灣業者侵權利用自由軟體所面對的法律風險」專文：http://www.openfoundry.org/tw/legal-column-list/2277--busybox-
3、我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的library, static linking完後產生binary(執行檔), 請問我透過網路散佈此binary是否允許, 我自己的library原始碼與samba的原始碼是否要公開？ 我的library原始碼是否同樣需以GPLv3發佈？
兩者的原始碼都需要提供、新撰寫的程式碼也必須以GPL-3.0來向外發佈。
4、我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的binary (使用system來呼叫), 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許？ 我自己的binary的原始碼與samba的原始碼是否要公開？ 我的binary原始碼是否同樣需以GPLv3發佈？
此題的回覆與問題2是相同的，一般判斷軟體相依性，固然有孰主孰從的不同，但此亦並非唯一的判斷參考項目，在LGPL-3.0裡有這麼一段文字：
If you modify a copy of the Library, and , in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:
如您對LGPL3函式庫進行修改行為，並且、在您修改之後，此「衍生函式庫」的某些功能必須仰賴特定「應用程式」的特有程序、函式才能進行呼叫(意指非一般傳統上「應用程式」將單純數字變數導入函式庫呼叫結果的運用關係)，那麼為了不使此修改過的「衍生函式庫」受到私有「應用程式」拘束而斫喪函式庫的某些功能(因此一修改過的「衍生函式庫」、其某些修改過的功能乃接受特定「應用程式」的呼叫後方可供給，但此呼叫行為可能不同於傳統方式以數字或簡單函數進行呼叫，或許此「應用程式」是以較複雜的函式對函式庫進行呼叫，如此一來若失去此特定「應用程式」的配合，則此「衍生函式庫」某些功能便陷於無用)，抑或發生「應用程式」拑制此衍生函式庫的未來修正改版可能性的狀況(理由同上、若「衍生函式庫」的某些功能會因與特定「應用程式」失去連結便淪於無用，則此「衍生函式庫」在獨立改版運用的可能性上便受到限縮，殆因此一「應用程式」多為不開放原始碼之「私有軟體」，若此「衍生函式庫」的某些功能有賴特定的「應用程式」方可進行呼叫，則無異於具「自由開放性」的「衍生函式庫」之改版發展受到私有軟體所拑制)，則對原LGPL3函式庫為修改者須擇一滿足下列條件，才能將此衍生作品再行傳散出去。
a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
a) 「衍生函式庫」續用LGPL3為其散布時的授權條款，但您須盡相當的誠信保證義務，確保此「衍生函式庫」經修改的某些功能，不須受限特定「應用程式」的配合即可發揮效用，意即此一修改過的功能仍可被其他「應用程式」所呼叫取用，否則
b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
b) 請您逕將修改過的「衍生函式庫」以GPL3為其散布時的授權條款，須特別了解的是、如此一來您的「衍生函式庫」便須受到較為嚴格的義務性要求所拘束，而不適用LGPL3所添附較為軟性的折衷條款(此處令修改LGPL3函式庫的衍生作品改用GPL3的理由為，因修改者並不能確保此「衍生函式庫」所有功能於嗣後傳散完整無缺之故，是以要求其以GPL3來進行散布，因在GPL3較為嚴格的義務性要求運行之下，此時與「衍生函式庫」連結運作的「應用程式」亦須「開放程式原始碼」，如此一來、便不生嗣後「衍生函式庫」再行改版後喪失某些功能的可能性，因「衍生函式庫」與其所連結的「應用程式」在GPL3的運作下皆須「開放程式原始碼」，是以此「衍生函式庫」的未來發展不致受到私有的「應用程式」所拘束)。
簡要來說這段文字規定的是，若是修改者將新功能加到LGPL-3.0授權的函式庫裡，但個功能就是設定來被這個修改者自行編寫的其他應用程式所呼叫，那麼此時LGPL-3.0額外要求：(1)修改者需要把這個新功能如何被其他應用程式呼叫的資訊披露出來，以確保這個功能日後也可以被其他人編寫的應用程式來呼叫；(2)直接把整個函式庫轉以GPL-3.0授權，因為這樣一來、GPL-3.0的授權拘束性較強，會連帶使得呼叫這個新功能的應用程式也得依 GPL-3.0來授權並開放程式原始碼。
從這段文字我們可以看到，自由軟體基金會有意識的將這類「呼叫關係倒轉」的程式互動方式，視為潛在的GPL授權義務性規避手法，從而可以知道，採取這樣的作法其GPL的侵權風險性並不一定能降低，有時反而會因為引發權利人的注意、軟體社群的討論，而讓後續產生爭議的可能性更為提高。
5、如果上述四種情形換成是GPLv2的授權, 情況是否會有所不同呢？
原則上在衍生著作的判定上，GPL-2.0與GPL-3.0相去不遠，所以若是不考慮Tivo條款、軟體專案授權條款、及其他細項，那麼以上所述說的四個判斷都不會有結論的不同。
