登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 本網站預計持續維運至 2021年底,網站內容基本上不會再更動。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
討論區
LGPL2.1函式庫的使用 (1 位瀏覽者) (1) Guest
Go to bottom Favoured: 1
TOPIC: LGPL2.1函式庫的使用
#669
LGPL2.1函式庫的使用 2011/04/18 15:00  (11 Years, 2 Months ago) Karma: 0  
您好~
我想請問一下:
1. LGPL2.1裡, 怎麼才會被定義為"work that uses the Library"? 使用動態連結算在此定義下嗎?
2. 如果程式利用靜態連結的方式使用LGPL函式庫(未修改), 這樣提供程式的目的碼以及LGPL函式庫的程式碼即可 嗎?
3. 如果使用者修改LGPL函式庫,並與使用者自己寫的程式連結在一起,不論靜態或動態連結, 都要釋出程式的原始碼嗎?
煩請解答一下,謝謝^^
Kurapika (User)
Senior Boarder
Posts: 19
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#670
Re:LGPL2.1函式庫的使用 2011/04/20 17:01  (11 Years, 2 Months ago) Karma: 10  
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 (Admin)
Moderator
Posts: 157
graph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#673
Re:LGPL2.1函式庫的使用 2011/07/21 17:21  (10 Years, 11 Months ago) Karma: 0  
多謝LUCIEN的回答~
再借標題問一下,
如果我使用的某個component A為GPL V2授權,
其與以LGPL V3授權的component B以static link方式連結在一起,
這樣會有GPL violation的問題嗎?

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

謝謝~
Kurapika (User)
Senior Boarder
Posts: 19
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#674
Re:LGPL2.1函式庫的使用 2011/07/22 14:36  (10 Years, 11 Months ago) Karma: 10  
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的問題呢?

謝謝~
lucien (Admin)
Moderator
Posts: 157
graph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
Go to top