請問:

目前使用LGPL的SOURCE CODE來開發C#應用程式(Winform)，在整合過程中並未修改LGPL的SOURCE CODE只是單純調用.

1.若開發整合完成了是否可以不公開整合原始碼只公開LGPL的SOURCE CODE ?
2.若整合LGPL的SOURCE CODE則調用部分是採用libary (DLL)則是否需要在軟體原始碼上加註任何說明 ?
3.在何種情況下需要公開自己所開發原始碼呢 ??

因為不同的整合方式，會影響其他部份原始碼是否也必須採用LGPL，因此是否可以描述一下，問題 1. 指的是透過什麼樣的技術方法來整合呢？

整合的方式為加入Source code當作參考,沒有修改只是調用,在自己寫的應用程式裡調用,

舉例來說

1.程式部份 : 軟體裡沒有檔案壓縮程式,調用source code的壓縮與解壓縮來處理檔案
2.介面部分 : 若有控制項類型的 source code 如樹狀顯示,調用source code顯示樹狀結構

以上的source code 都是 LGPL且只調用並未修改裡面的code.

Hi Ted,

粗略看了一下，您的三個問題其實可以濃縮成為一個問題，那就是：

「自行編寫的程式與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介面資訊即可。

希望以上的回覆對您有所幫助。

有後續問題歡迎接續討論。

20090928 1530 自由軟體鑄造場 林誠夏

首先,先謝謝您的回答!!但是還有一點小小的疑問
靜態連結〈Static link〉或是動態連結〈Dynamic link〉部分

本身自己寫的程式可以獨立運作就算沒有OPEN SOURCE也可以執行,但是這點很難判定,簡單來說

若沒有OPEN SOURCE那就會少了某些功能,而這些功能可能也會影響到其他部分,

舉個例子
程式本身是 A
OPENSOURCE 是 B
部分功能是 C

若要執行C的時候必須要 A -> B -> C
但是就算沒有B , A本身是可以獨立運作的

這樣來說到底應該是靜態還是動態呢??

Hi Ted,

關於靜態連結及動態連結的定義和判準確實有它爭議的地方。

要先說明的是，下面關於「靜態連結」及「動態連結」的解釋，並不是任何已經被明確定義的技術名詞或是法律名詞，而是我個人閱讀部份的自由軟體討論論壇、自由軟體著名開發者相關文章後，所了解到較多人同意的共識，或者也說不上是共識，比較像是較多人認可的解釋。

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

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

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

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

希望上面的回答對您有所幫助。

敬祝 順心開心

20090928 1654 自由軟體鑄造場 林誠夏

Ted wrote:
首先,先謝謝您的回答!!但是還有一點小小的疑問
靜態連結〈Static link〉或是動態連結〈Dynamic link〉部分

本身自己寫的程式可以獨立運作就算沒有OPEN SOURCE也可以執行,但是這點很難判定,簡單來說

若沒有OPEN SOURCE那就會少了某些功能,而這些功能可能也會影響到其他部分,

舉個例子
程式本身是 A
OPENSOURCE 是 B
部分功能是 C

若要執行C的時候必須要 A -> B -> C
但是就算沒有B , A本身是可以獨立運作的

這樣來說到底應該是靜態還是動態呢??

請問在靜態與動態連結部份是否有公定的標準呢??

如您所說的程式開啟時並未開啟才為動態,那如果是控制項類型的不就永遠算是靜態類型了嗎??
舉例來說"按鈕"這個控制項若是我使用一些LGPL的特殊造型按鈕再開啟程式時一定會顯示,但是功能並未使用,所以只要是控制項類型的皆為靜態類型的連結嗎??

就手機程式的例子來說電話簿雖然啟動時不會連結,不過打電話時會連結因為會顯示撥號人姓名之類的,
所以說沒有這個功能還是可以打電話,但是就無法得知撥號人與來電人,這樣不是就失去手機軟體的功能
且打電話是屬於韌體在控制並不是軟體在控制,軟體只是提供一些方便使用的UI介面,所以在界定如果只
依照程式開啟時是否有連結好像很難判斷.是否有標準或是準則可以參考呢??

我也有到國外網站上看不過好像難以有個標準,因為我的OPENSOURCE算是控制項程式開啟時雖然有連結
不過並未使用就跟手機例子相同,在手機程式開啟時電話簿已經連結了只是並未使用,等到使用者使用時
電話簿才有作用.這樣是否為靜態連結呢??

不好意思~~一直麻煩您回答問題,謝謝.

Hi Ted，

第一個問題：靜態連結與動態連結是否有公定的標準。

沒有。

就是因為沒有公定的標準，所以很多事情還是得個案來看，其實靜態連結/動態連結可以說是「概念的闡述」，這個概念的核心重點在於「依賴性〈Dependency〉」。靜態連結代表自行撰寫的程式對於該LGPL授權的函式庫有很高的依賴性，所以整個專案會被LGPL授權條款解釋為LGPL程式的衍生作品〈Derivative work〉，才會在程式再散布時被要求全部內容都要依LGPL的授權規定來提供整體程式的原始碼；動態連結代表自行撰寫的程式對於該LGPL授權的函式庫只有低度的相依性，所以除卻此一LGPL函式庫的連結關係亦能運作基本的重要功能，就LGPL條款的解釋上這可以說是「單純的利用關係〈A work use the program/library〉。

補充說明一下「程式開啟就啟動或是連結」這句話，指的是程式開啟時該LGPL函式庫及程式的其他部份就被load到memory裡去運作，而不在於介面的“按鈕“是否預設就存在那邊，LGPL特殊造型按鈕的預設，不代表這個LGPL函式庫已經是靜態連結或是動態連結了，一般通說是看這個函式庫是在哪個階段被主程式load到memory裡來執行的。

希望這些回答能釐清您的困惑。

歡迎接續討論，若經由您的觀察能發掘到我個人過去所沒有觸及的點，那會是讓人非常欣慰的事，所以不用不好意思的。

敬祝 順心、快樂

20090928 1745 自由軟體鑄造場 林誠夏

Ted wrote:
請問在靜態與動態連結部份是否有公定的標準呢??

如您所說的程式開啟時並未開啟才為動態,那如果是控制項類型的不就永遠算是靜態類型了嗎??
舉例來說"按鈕"這個控制項若是我使用一些LGPL的特殊造型按鈕再開啟程式時一定會顯示,但是功能並未使用,所以只要是控制項類型的皆為靜態類型的連結嗎??

就手機程式的例子來說電話簿雖然啟動時不會連結,不過打電話時會連結因為會顯示撥號人姓名之類的,
所以說沒有這個功能還是可以打電話,但是就無法得知撥號人與來電人,這樣不是就失去手機軟體的功能
且打電話是屬於韌體在控制並不是軟體在控制,軟體只是提供一些方便使用的UI介面,所以在界定如果只
依照程式開啟時是否有連結好像很難判斷.是否有標準或是準則可以參考呢??

我也有到國外網站上看不過好像難以有個標準,因為我的OPENSOURCE算是控制項程式開啟時雖然有連結
不過並未使用就跟手機例子相同,在手機程式開啟時電話簿已經連結了只是並未使用,等到使用者使用時
電話簿才有作用.這樣是否為靜態連結呢??

不好意思~~一直麻煩您回答問題,謝謝.

首先先感謝您熱心的回答

其實最主要也是因為需要進行一些商業的開發~若有被LGPL感染而被要求釋出原始碼也是一件非常麻煩的事

所以依照目前情況來看,最大問題點還是在依賴性與連結類型,依賴性來說我認為沒有問題,SOURCE CODE

部分應該佔總共的CODE約10-20%,因為有可能只用到整個函數庫的一兩項DLL。連結類型部份且程式開啟

時並未載入記憶體,而是在使用時才進行載入,所以應該可以判定為動態連結,只是對於使用量的部分是可

以算在依賴性裡面嗎? 舉例來說某一項功能在總程式裡使用次數很頻繁或是可能為連結的程式,如同手機

電話簿功能,打電話時要用到,打簡訊要用到,沒有的話就無法選擇送信人或是撥號人,這樣的話是否判定依賴性高??

PS : 就我的程式而言LGPL SOURCE CODE 雖然佔總程式比例不大,但是有可能會使用頻繁,要依照使用者而定，但是沒有LGPL SOURCE CODE 還是可以運作只是少了某些功能，如同手機沒電話簿還是可以打只是要直接輸入號碼。

Hi Ted,

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

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

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

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

希望這些說明對您有所幫助。

敬祝 順心健康

20090929 1047 自由軟體鑄造場 林誠夏

Ted wrote:
首先先感謝您熱心的回答

其實最主要也是因為需要進行一些商業的開發~若有被LGPL感染而被要求釋出原始碼也是一件非常麻煩的事

所以依照目前情況來看,最大問題點還是在依賴性與連結類型,依賴性來說我認為沒有問題,SOURCE CODE

部分應該佔總共的CODE約10-20%,因為有可能只用到整個函數庫的一兩項DLL。連結類型部份且程式開啟

時並未載入記憶體,而是在使用時才進行載入,所以應該可以判定為動態連結,只是對於使用量的部分是可

以算在依賴性裡面嗎? 舉例來說某一項功能在總程式裡使用次數很頻繁或是可能為連結的程式,如同手機

電話簿功能,打電話時要用到,打簡訊要用到,沒有的話就無法選擇送信人或是撥號人,這樣的話是否判定依賴性高??

PS : 就我的程式而言LGPL SOURCE CODE 雖然佔總程式比例不大,但是有可能會使用頻繁,要依照使用者而定，但是沒有LGPL SOURCE CODE 還是可以運作只是少了某些功能，如同手機沒電話簿還是可以打只是要直接輸入號碼。