這是本文件的舊版！
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) 來作為得到授權的交換條件，其中一個重要的義務性要求，便是如果新的軟體專案
註一：相類的名詞包括早期以批判角度立論的「擴散效應 (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”.
起：從著作權法本來的觀點，看本國的、看米國的，然而、何謂BASED ON？
承：GPL的CODE→LINUX TORVALDS→不得不然的依賴性。
轉：(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規定的授權方式來提供程式原始碼。」
GPL-3.0授權條款的定義，較諸通則的法律預設會較為嚴格：
「A “covered work” means either the unmodified Program or a work based on the Program.(「GPL-3.0轄下的軟體程式」，意指以GPL-3.0為其釋出時之授權條款的原軟體程式，以及「修改」自此種軟體程式後產生之「基於原程式修改所得之衍生作品」二類，而不論原軟體程式亦或其「衍生作品」，因其皆轄於GPL-3.0的約制之下，故其後的重製、散布、修改的各項權利義務關係須悉依GPL-3.0條款內容而定。) 」
簡要並直觀一點的解釋方法就是，軟體專案裡若內含了GPL-3.0授權的程式碼，那麼這個軟體專案日後在再釋出時，就會被認定為GPL-3.0授權程式的衍生作品，而必須得用GPL條款來進行釋出。
除非！其他程式與這個GPL-3.0的程式間的互動方式，是符合以下「Separate and Independent」的定義，而可以被認定是一個彙編作品，這時候、你在散布整個新彙編的軟體專案時，就只要提供該GPL-3.0軟體的程式原始碼，而不用及於其他自行編寫的部份：
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.（有時「GPL3轄下程式」的原始碼經過編譯後，會與本質上有所分別且具獨立性的其他軟體進行應用上的結合與互動，所謂具獨立性的軟體意指、這些軟體在本質上並非「GPL3轄下程式」的延伸，其亦非必然須與「GPL3轄下程式」進行結合方可運作。此時「GPL轄下程式」常與此些獨立程式包裹式地存放於同一儲存媒介併行散布(例如CD-ROM、DVD-ROM)，然而其究非彼此間不可或缺的緊密結合關係(例如結合成一個不可分割的大程式)。自由軟體基金會稱此種包裹式的合併方式為「程式聚合的散布型態」，只要個別程式間的授權關係並不彼此干涉影響(舉例來說、不能因為聚合專案中某些私有軟體的特殊要求，而影響到其中GPL-3.0程式的授權態樣)，那麼GPL-3.0授權條款的拘束力亦不及於聚合專案內的其他獨立程式。）
進階的、關於Static Link與Dynamic Link之間的差異則可以參考我之前就這個議題所撰寫的相關問覆：http://www.openfoundry.org/tw/forum?func=view&catid=8&id=669#670
好的、那麼我們照著上面討論到的這些原則來回覆你的問題：
1、軟體專案的原始碼中有呼叫到Samba 3.6 (GPL-3.0)library中的function，static linking完後產生binary(執行檔), 請問我透過網路散佈此tool是否允許, 我的原始碼與samba的原始碼是否要公開？ 我的原始碼是否同樣需以GPLv3發佈？
要提供、須以GPL-3.0發佈。
因為Static Link會被視為程式與程式之間高互依性的融合(merge)關係，此時整個軟體專案會被視為Samba 3.6的衍生作品，而在後續散布時會被全部依照GPL-3.0的授權方式來散布，也就是說、這個Binary標案裡相關的程式，都會在散布後、被一併要求依GPL-3.0的規定來提供程式原始碼。
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條款、軟體專案授權條款、及其他細項，那麼以上所述說的四個判斷都不會有結論的不同。
