您好~
我想請問一下:
1. LGPL2.1裡, 怎麼才會被定義為"work that uses the Library"? 使用動態連結算在此定義下嗎?
2. 如果程式利用靜態連結的方式使用LGPL函式庫(未修改), 這樣提供程式的目的碼以及LGPL函式庫的程式碼即可 嗎?
3. 如果使用者修改LGPL函式庫，並與使用者自己寫的程式連結在一起，不論靜態或動態連結, 都要釋出程式的原始碼嗎?
煩請解答一下,謝謝^^

Hi Kurapika,

我先簡短的回覆，細節可以後續討論。

先做定義限縮，我取的是大部份自由軟體開發社群的多數看法：

靜態連結：程式與LGPL2.1函式庫之間必然的連結關係，若喪失這個連結關係，則該程式喪失大部份的功能。

動態連結：程式與LGPL2.1函式庫之間可取代的連結關係，若喪失這個連結關係，則該程式仍具大部份的功能，僅部份的功能在表現上沒有連結之後優異。

在這個基礎上去回覆你的問題：

1、LGPL2.1裡, 怎麼才會被定義為"work that uses the Library"? 使用動態連結算在此定義下嗎?

答覆：單純呼叫LGPL2.1函式庫並取得數據的行為，是為“work that uses the library“，一般動態連結的利用方式，符合這個定義。

2、如果程式利用靜態連結的方式使用LGPL2.1函式庫(未修改), 這樣提供程式的目的碼以及LGPL函式庫的程式碼即可嗎?

答覆：不、多數網路社群的看法是，此時需要提供該程式與LGPL2.1函式庫全部的程式原始碼，並且就該程式與LGPL2.1函式庫之間如何呼叫進行說明與描述。一般看法是認為靜態連結的利用方式，會開啟LGPL2.1授權函式庫的「授權拘束性」，因為這種狀況照授權條款文字會被解讀為「However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.」所以這樣的狀況，依照LGPL2.1的文義解釋，散布該靜態連結成果之後，需要同時散布該自行編寫程式的程式原始碼，該LGPL2.1授權函式庫的程式原始碼，以及它們之間呼叫方式的描述資訊。

3、如果使用者修改LGPL2.1函式庫，並與使用者自己寫的程式連結在一起，不論靜態或動態連結, 都要釋出程式的原始碼嗎?

(1)如果是以動態連結的方式利用這個LGPL2.1授權的函式庫，那麼要釋出的對象是「該修改過LGPL2.1函式庫的程式原始碼」。

(2)如果是以靜態連結的方式利用這個LGPL2.1授權的函式庫，那麼要釋出的對象是「該程式與LGPL2.1函式庫全部的程式原始碼，並且就該程式與LGPL2.1函式庫之間如何呼叫進行說明與描述。」

其實、關鍵點在於，靜態連結的方式，會讓自己編寫的程式被視為該LGPL2.1授權函式庫的衍生程式(derivative work)，而若如此、該衍生程式就會被LGPL2.1條款要求後續散布也一併需要用LGPL2.1來授權釋出。

當然、這邊討論的是LGPL2.1的狀況，若是LGPL3的狀況，則有其他類型化的應用方式，可參照拙著「更為彈性中庸的 LGPL3」：https://www.openfoundry.org/tw/legal-column-list/1166--lgpl3

謝謝！

20110420 1655 LUCIEN C.H. LIN

多謝LUCIEN的回答~
再借標題問一下,
如果我使用的某個component A為GPL V2授權,
其與以LGPL V3授權的component B以static link方式連結在一起,
這樣會有GPL violation的問題嗎?

另外兩個GPL component以static link在一起會不會也有GPL violation的問題呢?

謝謝~

Hi Kurapika，

好久不見！

回覆這個問題前我先界定幾個前提：

1、原則上static link的連結方式，會讓二隻程式變成同一個作品，多數見解認為這是merge類的結合關係；當然、也有持反對見解的狀況，但那都是比較難辨別的hard case。

2、LGPL與GPL授權的程式如merge在一起，那麼LGPL授權的部份會被要求改以GPL的方式授權，LGPL與GPL向來就有「單行道式」的轉換關係，也就是說、LGPL授權的程式可以被改作者與散布者，重新以GPL的方式宣告，但是、這樣的轉換方式僅限於同一版本別的授權程式，例如LGPL-2.1的程式可以被重新宣告以GPL-2.0授權，LGPL-3.0的程式可以被重新宣告以GPL-3.0授權，除非該授權程式裡有加上「or later version」這個額外條件，如果原來的著作權利人有加上這個額外宣告，例如將A函式庫以「LGPL-2.1與其後版本(or later version)」的方式釋出，其他人在改作該A函式庫之後，才能以LGPL-3.0或是GPL-3.0(先將A函式庫的授權狀態由LGPL-2.1轉為LGPL-3.0，再將LGPL-3.0轉為GPL-3.0。)的方式重新授權A函式庫，此種轉換方式也適用於A函式庫的衍生程式。

3、就merge的結合狀態來說，GPL-2.0與GPL-3.0並不相容，LGPL-2.1與LGPL-3.0亦不相容。細部的分析可以參考Richard M. Stallman所撰寫的評論專文"Why Upgrade to GPL Version 3"：https://gplv3.fsf.org/rms-why.html，亦可參照不才所翻譯的非官方中譯版本：https://lucien.cc/?p=13。

所以就上面這些原則定義來解答您的提問：

1、將GPL-2.0授權的元件A與LGPL-3.0授權的函式庫B以static link的方式merge在一起，會不會產生GPL violation的問題？

會、授權上會產生衝突。

因為在授權分析上，static link會將元件A與函式庫B結合為一個新的衍生程式C(as a whole)，那麼因為GPL-2.0與LGPL-3.0都有其各自的授權拘束性(license inheritance)，GPL-2.0元件的衍生作品必須以GPL-2.0來授權散布，而LGPL-3.0函式庫的衍生作品也必須以LGPL-3.0來授權散布，那麼衍生程式C並沒有辦法同時滿足GPL-2.0與LGPL-3.0的授權狀態，因為GPL-2.0與LGPL-3.0在授權條款上就是不相容的狀態，除非這隻GPL-2.0的A元件，其實是以「GPL-2.0 or later version」的方式向外散布，若是如此、則這個衍生程式C就可以用GPL-3.0的方式來授權！(先將A程式的授權方式升級為GPL-3.0，再將其與LGPL-3.0授權的函式庫做結合，而因為LGPL-3.0的授權方式可以單向的轉換為GPL-3.0，那麼最後的衍生程式C即可統一使用GPL-3.0來向外散布。)

所以、實務上最保險的解決方法，是洽詢元件A的著作權利人，向其商議是否可以將原GPL-2.0授權的元件A，改以GPL-2.0+(GPL-2.0 or later)的方式另行授權，或是以GPL-3.0的方式授權給衍生程式C的改作人，這時候衍生程式C就可以統一用GPL-3.0來散布了。

2、將GPL-2.0與GPL-3.0的元件以static link的方式結合在一起，會不會有GPL violation的問題？

會、其實這就是RMS那篇文章(https://gplv3.fsf.org/rms-why.html)主要表達的內容，GPL-2.0與GPL-3.0都是強烈Copyleft性質的FOSS授權條款，所以單純的條款狀態是不相容的，這些元件的衝突狀態就像之前討論GPL-2.0與LGPL-3.0的關係一樣。但實務上，因為畢竟二隻程式都是以GPL的方式授權，雖然版本別不同，但在散布上必然都會有提供程式原始碼出去，所以並沒有實際訴訟是因為散布者將GPL-2.0與GPL-3.0的元件結合在一起而涉訟的，然而、這在授權分析上還是一個不相容的狀態，如果該專案是永續性的服務或產品，建議可以試著洽請該GPL-2.0授權元件的著作權利人，重新將該元件以GPL-2.0+的方式再次授權，那麼就可以完美的解決這樣的衝突。

希望上述的回覆對您有所幫助，有後續問題歡迎隨時接續討論。

20110722 1435 Lucien C.H. Lin

----------

Kurapika wrote:
多謝LUCIEN的回答~
再借標題問一下,
如果我使用的某個component A為GPL V2授權,
其與以LGPL V3授權的component B以static link方式連結在一起,
這樣會有GPL violation的問題嗎?

另外兩個GPL component以static link在一起會不會也有GPL violation的問題呢?

謝謝~