LGPL概略探討

LGPL的限制聽起來比GPL的鬆綁一些
但相信還是很多情況是讓人無所適從
所以這篇主要是作個筆記，記錄一下自己看到的一些看法

以下筆記來自：自由軟體鑄造場 林誠夏

=========================================
「自行編寫的程式與LGPL函式庫連接〈Link〉後，會不會與該函式庫結合〈Combine〉為一不可分割或很難分割的整體〈As a whole〉，而被認為整體皆為LGPL函式庫的衍生作品〈Derivative work)，導致整個結合作品都要受到LGPL授權條款的拘束。」

所以、首先要探討的是，您自行編寫程式與此LGPL函式庫的調用/連結關係，行為上的判定是靜態連結〈Static link〉或是動態連結〈Dynamic link〉？

依照一般的通說，靜態連結指的是程式開啟時必然會開啟程式與該LGPL函式庫的連結關係，也就是說程式執行時對此LGPL函式庫有依賴性，若是少了這個函 式庫則整體程式幾乎沒有獨立的運作功能。在這種狀況之下，此個別編寫的程式與LGPL函式庫會被認為是一體程式，而需要整個專案都以LGPL授權的方式才 能再散布，在散布時也要提供「整個專案(自行編寫部份+LGPL函式庫)」的程式原始碼。

而若是您用dll般動態連結的方式來取用這個LGPL授權的函式庫，則表示該專案在開啟時並不會必然性的去取用/調用/連結LGPL函式庫的功能，只有在 需要某些特定功能時才去「動態式的呼叫」LGPL函式庫來得到資訊，這樣的狀況、若是除卻此一LGPL函式庫，但原來自行編寫的程式仍然具有可獨立運作的 基本功能的話，那可以視此程式與LGPL函式庫間僅為動態連結的存取關係，從而即使合併散布，但自行編寫的方式依自行律定的授權方式，而LGPL的部份則 依LGPL授權條款的方式散布，散布者原則上僅需提供LGPL函式庫部份的程式原始碼，以及該自行編寫程式與LGPL函式庫之間如何進行呼叫的 information exchange介面資訊即可。

====================================================
1、主程式啟動時直接啟動該LGPL函式庫的連結，這是靜態連結。

2、主程式啟動時並未啟動該LGPL函式庫的連結，僅在需求時才例外的呼叫LGPL的函式庫，例如一個多媒體檔案的播放程式，播放大部份媒體檔案時可以直接執行，但在播放某些特殊編碼的檔案時，才例外地去呼叫額外的LGPL函式庫來支援，這是動態連結。

所以上面的說法，常常又被簡化為：若除卻此LGPL函式庫，則主程式部份還具有基本功能者，為動態連結的利用結構；除卻此LGPL函式庫，則專案失卻主要功能者，為靜態連結的利用結構。

至於什麼才是「主要功能」或是「基本功能」，則解讀上更為見人見智。原則上必須要視個案來判定，舉個案來說，若釋出的載體是手機的話，手機的主要功能就是 撥打電話，若是除卻此一LGPL函式庫的連結造成電話無法撥打的話，那當然手機程式與此LGPL函式庫間是靜態連結的依賴關係；而若是此一LGPL函式庫 是電話簿的管理程式，若失去此一函式庫的連結，至不濟是電話簿的功能無法啟動，則「有可能」僅被判定為「動態連結」而不開啟LGPL授權條款的授權拘束 性，然而、這裡用的措詞只是「有可能」，實際上的狀況，還是要依個案來作進一步的分析。

=============================================================
我們同仁也曾經就LGPL使用Code的比例做過討論，我個人就這個議題查找的結果是，並沒有哪一個著名hacker會特別用程式碼的「比例」來判定「依賴性〈Dependency〉」。

其實LGPL授權條款裡有特別規定，原則上使用者不能去刪減該LGPL授權函式庫的功能，如果使用者主張只是單純使用這個函式庫的功能的話。

比方說您的程式只用到這個LGPL函式庫的a、b、c部份的功能，LGPL授權條款特別要求您在散布時，不要將函式庫本來有的d、e、f、g、h等功能刪 掉，LGPL授權條款向有保持該LGPL函式庫完整性的要求，因為就算您不用這些額外的功能，或許下一個得到該函式庫的使用者可能會想使用。

所以照「LGPL函式庫單純被使用原則上不能被刪改」的特性來說，該函式庫程式碼的比例會愈來愈高，這是LGPL授權預設機制所使然，在這樣的條件下，以程式碼的比例來判定依賴性也並不合理，所以從邏輯分析上、從授權者共識來說，應該都不會有這方面的問題