究竟抄寫多少的 GPL 程式碼便會受其拘束？
葛冬梅／文 2006-03-24 發布 2012-05-15 修改
對於 GPL（註一）授權義務有所了解的人都知道，一旦一個程式包含原以 GPL 授權的程式碼，其後所開發出來的程式，原則上便也必須採用 GPL，作為後續散布此程式的授權條款。舉 GPL-2.0 為例、其第 0 條第 1 段與此規定相關的原文是這樣寫的：“… that is to say, a work containing … or a portion of it, …“。從近年多數討論串及重量級自由開源軟體專案開發者的發言內容來進行分析（註二），GPL-2.0 此一規範的說明大抵是：「將 GPL 授權程式碼內置到其他軟體專案裡，此軟體專案便有機會被認定為 GPL 授權程式的衍生作品，而其後此軟體專案的授權運用方式，亦會一體受到 GPL 授權條款的拘束。」然而、僅憑上述的規範內容套用到開發實務上，其實界限相當模糊，究竟包含多少 GPL 授權程式碼的行數，會被認定為 “a portion of it” 的拘束範圍？若無行數量化質化方面的客觀標準，這樣的規定會否顯得過於嚴苛？長久以來，各方對於 GPL-2.0 此段文字的詮釋總是眾說紛云。
若是依照 GPL 撰寫者 Richard Stallman 所表示的最嚴格標準，其認為其他軟體專案即使僅抄寫一行 GPL 授權的程式碼，也會構成 “a portion of it” 的拘束範圍！然而、這樣嚴格的解釋角度，並沒有被所有自由開源軟體領域的開發者與應用者所接受，而且比對 2007 年改版釋出的 GPL-3.0 授權條款，可以在第 2 條第 1 項的地方，看到右列文字：”This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.” 也就是說、GPL-3.0 已在條款內文裡明示著作權法裡的合理使用 (fair use) 機制，是一併受到 GPL-3.0 授權條款的尊重的，而在多數的狀況下、單單一行程式碼方式的微量取用，可能都符合合理使用的抗辯事由，所以、究竟軟體專案裡，包含多少 GPL 授權程式碼時，會一併受到其授權方式的拘束，還是得回歸個案認定的流程，而並沒有一個統一的答案，這讓此一問題的解說顯得更加撲朔迷離。
那麼、由於此一問題尚未接受過各國法院審判程序的檢驗，因此到目前為止仍處於眾說紛云的階段，實務上的參照重點、便就回歸到程式著作權人的解釋立場。為什麼呢？因為目前各國的著作權制度，皆賦與著作權利人很大的權限，基本上著作權法上的授權架構，除了合理使用及公益導向的強制授權機制外，其他的作品使用權利皆保留在著作權利人身上，所以該項作品能夠被他人如何利用，原則上還是得尊重著作權利人的授權態度，故若是個別自由軟體開源專案裡，該創作人及創作團體已明確表達「即使僅包含一行的 GPL 授權程式碼亦會開啟其授權拘束性」，雖然這樣的嚴格授權態度，可能會在實際案例裡，受到使用者合理使用訴求的抗辯，然大型商業化使用的狀況時，為了避免產生後續的爭議起見，建議是以其他可替用的自由開源軟體元件，來取代此種授權態度的程式碼。
實務上除了尊重個別專案開發者的授權態度外，亦不乏有人開始替不同的技術方法做定性分類，也就是說、部份自由開源軟體元件的應用者，開始對程式元件間不同的呼叫對應方式進行分類，進一步並試圖透過這些分類，來界定個別程式元件與 GPL 授權元件間的相依性與衍生性。在這些分類方式之中，迄今引發最多熱烈討論的就是：對於 GPL 程式碼的動態連結 (dynamic link) 與靜態連結 (static link) 的利用方式，是否落入 GPL 條款裡 “a portion of it” 的認定範圍，而必須一體受到 GPL 授權方式的拘束？
一般的狀況下、若是採取靜態連結 GPL 授權程式碼的利用方式，這代表該程式對於這些 GPL 授權程式碼，在功能執行上具有不可分割的依賴關係，實際運作上、程式的編譯過程亦往往會將這些 GPL 授權的程式碼，直接一起編入為單一的目的碼 (binary code)，因此這種情況下所開發出來的軟體專案，許多自由開源專案的開發者便認為，確實已構成 GPL 定義下 “a portion of it” 的拘束範圍。而若是採取動態連結 GPL 授權程式碼的利用方式，由於此種方式是待主程式有額外的功能需求時，才透過呼叫程序來存取 GPL 授權元件，額外地將其載入記憶體來取得其功能或資訊。而在編譯過程中、亦可不要將這些 GPL 授權的程式碼與主程式一併編入為單一的目的碼，因此有部份自由開源專案的開發者便認為，採用這種方式所開發出來的軟體專案，不至於構成 GPL 定義下 “a portion of it” 的拘束範圍（註三）。
然而、其實靜態、動態連結兩者，皆不能說是範圍十分清楚的技術名詞或是法律名詞，其目前仍為一個通俗性的區分標準，在應用上是可以協助大家理解 GPL 授權程式碼的授權拘束性範圍，然而、實際的授權條款裡，並沒有就此兩名詞的理蘊做出精確的定義與解釋。因此筆者對此議題的建議是，一般社群式的自由開源軟體專案，若對於 GPL 授權拘束性方面，並不想預設繁複的區隔規劃，那麼簡易的二分法就是全然避用 GPL 授權的程式碼，或是將整個專案全盤採用 GPL 授權的方式來進行後續開發；而若是未來設有技轉期望、或是涉及大型商業化散布的應用方式，則應該在產品設計階段，就預計選用專案的授權方式及權利人的授權態度先進行初步研究，若有衍生問題亦應詢求此方面專家來協助釋疑，以降低未來衍生授權爭議的可能性。
註一：有關 GPL 的進一步介紹，請參見，葛冬梅，讓人既愛又頭痛的 GNU GPL：http://www.openfoundry.org/index.php?option=com_content&task=view&id=525&Itemid=56，自由軟體鑄造場電子報第 33 期。
註二：Linus Torvalds 認為程式元件間運作上的依賴性才是衍生關係的最大特徵，以 Linux Kernel 上的驅動程式 (driver) 來說，其認為便是運作上與 Linux Kernel 有高度依賴特徵的例子，而應被認定為 Linux Kernel 的衍生程式，以至釋出時必須依照 GPL-2.0 的遊戲規則來進行散布。相關討論串內容可參照右列網址：http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html。
註三：有關 GPL 授權拘束性的進一步分析與說明，請參見，林誠夏，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上）：http://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01，自由軟體鑄造場電子報第 181 期；GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）：http://www.openfoundry.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02，自由軟體鑄造場電子報第 183 期。
