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 轄下部份函式庫程式的應用推廣，自由軟體基金會以 GPL 為範本修改出 LGPL，律定單純的函式庫呼叫關係並不會開啟 LGPL 授權函式庫的授權拘束性，以降低程式開發者對這些函式庫程式在授權拘束性方面的疑慮，進而提升 GNU Project 轄下函式庫的使用佔有率，擴大這些函式庫程式的使用對象，導引更多使用者能熟悉了解它們，而不是在接觸之初就因為 GPL 較為嚴格的授權拘束特性而退避三舍。而從 LGPL 授權條款推出之後，部份以其授權的專案確實在使用率及參與度都有一定程式顯著的提升，舉例來說、GLIBC (the GNU C Library) 當初就是因為這樣的考量，而採用 LGPL 作為其專案的授權條款（註三）。

【透過定式介面與流程呼叫 LGPL 函式庫不會開啟其授權拘束性】

進一步來說，LGPL 與 GPL 相較，其於授權拘束性方面最大的分別，就在於界定「基於函式庫 (work based on the library)」的利用關係，與「使用函式庫 (work that uses the library)」的利用關係，此兩個重要概念 LGPL 與 GPL 有著寬嚴不同的解讀差異。就 LGPL 的定義來說，所謂「基於函式庫」指的是新的軟體元件是直接取用 LGPL 授權程式碼所改寫出來的修改作品 (modification) 或是衍生作品 (derivative work)，此時新元件多直接內含 LGPL 授權的程式碼，因此仍然會被要求直接承繼 LGPL 的授權拘束特性，於元件再散布時，只能選用 LGPL 的授權方式來進行散布。附帶一提的是，此時散布者也可以將此元件的授權狀態轉變為 GPL 後再行向外散布，這是因為 LGPL 與 GPL 授權程式，其實有著「單行道 (one-way)」式的轉換關係，依照條款規定的預設，LGPL 程式的散布者可以將程式轉換為 GPL 授權之後再行散布（註四），然而此一轉換行為不可逆轉，也就是說、GPL 授權的程式，是不能夠被散布者改以 LGPL 的方式再向後散布的。

再談到「使用函式庫 (work that uses the library)」的利用關係，這個概念指的是其他的軟體元件並非衍生自 LGPL 授權的函式庫，而僅是在資訊存取或是數據分析上與這些函式庫產生互動，如果是這樣的利用關係的話，原則上便不會開啟 LGPL 函式庫的授權拘束特性。從上述 LGPL 對這兩個概念的定義範圍來看，不少的程式開發者便認為，在 LGPL 授權函式庫上發展「動態連結 (dynamic link)」的應用程式，便應不會受到 LGPL 授權拘束性的限制。這樣的看法原則上是沒有問題的，因為一般來說軟體元件間動態連結的利用方式，便是透過一個定式介面或流程，來對函式庫程式進行呼叫以取得資訊，此種互動關係之下，呼叫元件不必然會預嵌被呼叫函式庫的程式碼（註五），而亦符合 LGPL 對於「使用函式庫」行為的相關定義。然而、具體個案中，細部上還是要去看此呼叫元件與 LGPL 函式庫之間的互動關係，是否具有必然的相依性或是衍生性，才能做更精準的分析與界定。

由上面的這些論述可以看得出來，LGPL 授權條款與 GPL 授權條款之間，既合作又競爭的共生關係。我們可以說 LGPL 為自由軟體基金會推出，處於 GPL 授權方式與私有軟體 (proprietary software) 授權方式之間中庸妥協的緩衝條款，而論以自由軟體基金會的推廣原意，其仍是期待更多的軟體開發者，願意採用 GPL 授權條款來釋出其所編寫的軟體專案，以保障並擴大軟體自由理念的影響範圍。不過、從近年許多大型自由開源軟體專案的授權演變來看，重要的自由開源文書處理軟體 OpenOffice 在移交予 Apache Software Foundation 進行管理之前，一直都是採用 LGPL 的方式釋出，其衍生專案 LibreOffice 目前也仍然採用 LGPL 的授權方式來進行維護，而 Qt 這個表現優異的跨平台 C++ 應用程式開發框架，更於 4.5 版之後，改用 LGPL-2.1 的授權方式替換原先 GPL-2.0 的預設方式，從這種種跡象來看，LGPL 此種折衷 GPL 之後產生的授權模式，無疑的已在歷史上取得其發展與存續的地位，其未來與 GPL 授權條款之間的競合關係，仍然非常值得進行持續的追蹤與觀察。

---

註一：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 的官方網站為：https://www.gnu.org/software/libc/index.html，其選用 LGPL 的歷史緣由及相關的政策說明，可參照 GNU Project 專文「Why you shouldn't use the Lesser GPL for your next library」：https://www.gnu.org/licenses/why-not-lgpl.html。

註四：修改 LGPL 函式庫所產生的新軟體元件，此元件本身仍然必須具有函式庫的性質，才能夠接續採用 LGPL 授權條款來進行散布，而若新元件已不再具有函式庫程式的運作特性，則依照 LGPL 授權條款的規定，此時新元件只能轉以 GPL 授權條款的方式，才能夠進行後續散布。

註五：在內嵌必要資訊方面，LGPL-2.1 規劃了「微量取用」的除外機制。例如個別元件僅引用了 LGPL 函式庫程式的數字參數、資料結構層級、小巨集或十行之內的微量程式碼，雖然從外觀來說算是取用了部份 LGPL 函式庫的授權程式碼，但其用量微乎其微，所以得以例外主張不受到 LGPL 授權義務性的拘束。(If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.)