這是本文件的舊版！
稍稍鬆綁的堅持－LGPL
林誠夏／文 2006-01-19
LGPL 的英文全文是「GNU Lesser General Public License（註一）」，那麼顧名思義，LGPL 在內容上是較為寬鬆的「GPL (GNU General Public License)」，所以說、LGPL 的基本架構與義務性要求都與 GPL 如出一轍，例如 Copyleft 的授權循環拘束機制，不得向收受程式者收取軟體授權金等特色皆幾近相同，不過、既然名為「寬鬆」，那必然也會有若干獨立於 GPL 授權條款的不同之處。例如：1、在適用上 LGPL 授權條款只能適用於具有函式庫 (library) 性質的軟體程式；2、單純使用 LGPL 授權的函式庫並不必然開啟其授權條款的拘束性，也就是說、其他元件只是透過定式介面呼叫 LGPL 授權函式庫的功能，則這些元件並不必然會被視為 LGPL 函式庫的衍生程式，從而其個別的授權方式，也不會受到 LGPL 授權條款的拘束。此二點可說是 LGPL 與 GPL 之間最大的特色差異，以下便就此二點進行補充論述。
◎ LGPL 授權條款僅能適用於具有函式庫性質的軟體程式
LGPL 是自由軟體基金會 (Free Software Foundation, FSF) 針對函式庫類別程式（註二）所特別撰寫出來的自由軟體授權條款，它稍微弱化了 GPL 追求全面性軟體自由 (Software Freedom) 的目標，這是因為 GPL 授權條款具有一項常被戲稱「感染性 (viral effect)」的特點，那就是取用了 GPL 授權元件的部分程式碼之後，再行編寫出來的修改作品或是衍生作品，便受到 GPL 授權條款的拘束，而必須在後續散布上承繼 GPL 的授權規則，作為這個修改作品或是衍生作品的授權條款。在這方面，LGPL 針對函式庫性質的程式，研擬了一套更為切合現實的推廣態度，只要授權的對象是函式庫類別的元件，那麼在某些特殊的使用需求下，LGPL 提供程式的開發者與撰寫者，另一種較之 GPL 更為寬鬆而有彈性的授權分享方式。
這是因為函式庫性質的程式，本就極容易以連結 (link) 的方式被呼叫取用，來提供各種類別的儲存資訊與運算結果給其他的軟體元件。那麼如果依 GPL 授權條款本來的預設，軟體元件與函式庫程式彼此的連結利用關係若是緊密而不可分離，那在定義上很可能這些軟體元件便會被歸類於 GPL 授權函式庫的衍生作品，而在後續散布上必須受到 GPL 授權條款的一體拘束，由於這樣的特點、許多軟體元件的開發者與編寫者可能便會因此怯步，而完全不敢取用 GPL 授權的函式庫程式來進行專案開發。所以考慮到 GNU Project 轄下部份函式庫程式的應用推廣，LGPL 授權條款以 GPL 為修改範本，律定單純的函式庫呼叫關係並不會開啟 LGPL 授權函式庫的授權拘束性，以降低程式開發者對這些函式庫程式的授權拘束疑慮，進而提升 GNU Project 轄下函式庫的使用佔有率，擴大這些函式庫程式的使用對象，導引更多使用者能接觸了解它們，而不是在接觸之初就因為 GPL 較為嚴格的授權拘束特性而退避三舍。而從 LGPL 授權條款推出之後，部份以其授權的專案確實在使用率及參與度都有一定程式顯著的提升，舉例來說、GLIBC (the GNU C Library) 當初就是因為這樣的考量，而採用 LGPL 作為其專案的授權條款（註三）。
◎ 透過定式介面與流程呼叫 LGPL 函式庫不會開啟其授權拘束性
是以，LGPL 條文的重點其實就在於訂立規則界定「基於函式庫」與「使用函式庫」行為的分野。所謂「基於函式庫」指稱與 LGPL 函式庫連結的他函式庫基礎乃衍生自 LGPL 函式庫的一部分，因而承襲 GPL 的感染性特點，會拘束此一連結函式庫也須以 LGPL 做它的授權條款；而「使用函式庫」則意指對於 LGPL 函式庫的單純利用關係，或者是微量取用（註四）亦可不受拘束。以上僅是原則性的解釋，詳細的分辨標準仍得進一步視個案而定。
LGPL 當然還有其他的特色，像是修改 LGPL 函式庫所產生的衍生作品，衍生作品本身仍然得是函式庫才能續用 LGPL 授權條款，若其為獨立的軟體程式，則只能轉而受到 GPL 授權條款的拘束；此外、使用 LGPL 授權條款的函式庫被允許在任何時候轉而使用 GPL 為其授權條款，但此轉換行為並不可逆轉。由此可看出來 LGPL 與 GPL 之間既合作又競爭的共生關係，而 LGPL 就前段所說其為一種與現實折衝妥協的過渡帶，論到自由軟體基金會的原意還是希望更多人使用 GPL 授權條款來保障軟體的自由性持續散布。從 LGPL 的生成可以看到自由軟體授權模式由理想到與現實切合的調合觀點，從遠一點的角度來觀察，這種稍微折衷的調和模式有擴大其規模的可能性與未來性，值得日後持 續的追蹤與觀察。
註一：LGPL 在 2.0 版本之前的全稱為「GNU Library General Public License」，因為其可適用的對象限定在具有函式庫性質的軟體程式，然而、自由軟體基金會後來發現，由於名稱直接顯示為 Library，故許多使用者誤以為只要是函式庫性質的程式，使用 GNU 相關條款釋出時就必然要選擇 LGPL，其實就自由軟體基金會推動軟體自由 (Software Freedom) 理念的立場，其仍然希望部份的函式庫程式能以 GPL 釋出，而不是授權拘束性弱化後的 LGPL，故於 LGPL-2.1 版本之後，自由軟體基金會改以「GNU Lesser General Public License」來全稱 LGPL，而不再將 library 一詞直接顯示於條款名稱內。
註二：函式庫 (Library) 在資訊科學裡的定義，是某些元件的集合，這個元件負責不同的流程和功能，而可以利用這些元件間的相互運作，運用在研發軟體程式上。
註三：GLIBC 的官方網站為：http://www.gnu.org/software/libc/index.html，其選用 LGPL 的歷史緣由及相關的政策說明，可參照 GNU Project 專文「Why you shouldn't use the Lesser GPL for your next library」：http://www.gnu.org/licenses/why-not-lgpl.html。
註四：所謂的微量取用像是目的碼僅用了數字參數、資料結構層級、小巨集及一些內嵌功能（十行以內），雖然定義上符合衍生作品的範疇，但被認為微乎其微，所以不至於非得受到 LGPL 授權條款的選用拘束。
