登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
討論區
請教GPLv3的問題 (1 位瀏覽者) (1) Guest
Go to bottom Favoured: 0
TOPIC: 請教GPLv3的問題
#679
請教GPLv3的問題 2011/08/17 11:46  (8 Years, 3 Months ago) Karma: 0  
Dear Sir,

我是個newbie, 感謝提供了這樣的平台, 讓我可以了解Open source community, 但仍有一些問題想請教, 我大致分成幾點來描述提問, 謝謝

我想提供一支tool (binary形式)透過網路散佈公開給大家使用, 作法如下:

1. 原始碼中有呼叫到Samba 3.6 (GPLv3)的library中的function, static linking完後產生binary(執行檔), 請問我透過網路散佈此tool是否允許, 我的原始碼 與samba的原始碼是否要公開? 我的原始碼是否同樣需以GPLv3發佈?

2. 原始碼中有呼叫到Samba 3.6 (GPLv3)compile出來的binary, 使用system()來呼叫, 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許, 我的原始碼 與samba的原始碼是否要公開? 我的原始碼是否同樣需以GPLv3發佈?

3. 我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的library, static linking完後產生binary(執行檔), 請問我透過網路散佈此binary是否允許, 我自己的library原始碼 與samba的原始碼是否要公開? 我的library原始碼是否同樣需以GPLv3發佈?

4. 我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的binary (使用system來呼叫), 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許? 我自己的binary的原始碼 與samba的原始碼是否要公開? 我的binary原始碼是否同樣需以GPLv3發佈?

如果上述四種情形換成是GPLv2的授權, 情況是否會有所不同呢? 謝謝
youhas (User)
Fresh Boarder
Posts: 1
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#680
Re:請教GPLv3的問題 2011/08/19 16:04  (8 Years, 3 Months ago) Karma: 10  
Hi youhas,

歡迎提問!

關於你所提出的四個問題,判斷核心的概念都是「哪一種利用Samba的互動關係,會被視為Samba的衍生作品,因而後續散布時會被要求得依GPL-3.0規定的授權方式來提供程式原始碼。」

關於衍生作品的定義,一般著作權法的定義為「以改寫的方式就原著作另為創作」,但因軟體專案常常是不同元件互相呼叫互相存取,所以這個判斷標準便不是僅就程式本身的改寫與否來做判斷,而轉到了就「程式與程式間的連結關係、互動關係」來做判別。

GPL-3.0授權條款的定義,較諸通則的法律預設會較為嚴格:

「A “covered work” means either the unmodified Program or a work based on the Program.(「GPL-3.0轄下的軟體程式」,意指以GPL-3.0為其釋出時之授權條款的原軟體程式,以及「修改」自此種軟體程式後產生之「基於原程式修改所得之衍生作品」二類,而不論原軟體程式亦或其「衍生作品」,因其皆轄於GPL-3.0的約制之下,故其後的重製、散布、修改的各項權利義務關係須悉依GPL-3.0條款內容而定。) 」

簡要並直觀一點的解釋方法就是,軟體專案裡若內含了GPL-3.0授權的程式碼,那麼這個軟體專案日後在再釋出時,就會被認定為GPL-3.0授權程式的衍生作品,而必須得用GPL條款來進行釋出。

除非!其他程式與這個GPL-3.0的程式間的互動方式,是符合以下「Separate and Independent」的定義,而可以被認定是一個彙編作品,這時候、你在散布整個新彙編的軟體專案時,就只要提供該GPL-3.0軟體的程式原始碼,而不用及於其他自行編寫的部份:

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.(有時「GPL3轄下程式」的原始碼經過編譯後,會與本質上有所分別且具獨立性的其他軟體進行應用上的結合與互動,所謂具獨立性的軟體意指、這些軟體在本質上並非「GPL3轄下程式」的延伸,其亦非必然須與「GPL3轄下程式」進行結合方可運作。此時「GPL轄下程式」常與此些獨立程式包裹式地存放於同一儲存媒介併行散布(例如CD-ROM、DVD-ROM),然而其究非彼此間不可或缺的緊密結合關係(例如結合成一個不可分割的大程式)。自由軟體基金會稱此種包裹式的合併方式為「程式聚合的散布型態」,只要個別程式間的授權關係並不彼此干涉影響(舉例來說、不能因為聚合專案中某些私有軟體的特殊要求,而影響到其中GPL-3.0程式的授權態樣),那麼GPL-3.0授權條款的拘束力亦不及於聚合專案內的其他獨立程式。)


進階的、關於Static Link與Dynamic Link之間的差異則可以參考我之前就這個議題所撰寫的相關問覆:https://www.openfoundry.org/tw/forum?func=view&catid=8&id=669#670

好的、那麼我們照著上面討論到的這些原則來回覆你的問題:

1、軟體專案的原始碼中有呼叫到Samba 3.6 (GPL-3.0)library中的function,static linking完後產生binary(執行檔), 請問我透過網路散佈此tool是否允許, 我的原始碼與samba的原始碼是否要公開? 我的原始碼是否同樣需以GPLv3發佈?

要提供、須以GPL-3.0發佈。

因為Static Link會被視為程式與程式之間高互依性的融合(merge)關係,此時整個軟體專案會被視為Samba 3.6的衍生作品,而在後續散布時會被全部依照GPL-3.0的授權方式來散布,也就是說、這個Binary標案裡相關的程式,都會在散布後、被一併要求依GPL-3.0的規定來提供程式原始碼。

2、軟體專案的原始碼中有呼叫到Samba 3.6 (GPLv3)compile出來的binary, 使用system()來呼叫, 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許, 我的原始碼與samba的原始碼是否要公開? 我的原始碼是否同樣需以GPLv3發佈?

透過網路散布是沒有問題的、Samba部份的原始碼必須隨同binary code一同散布、自行撰寫的部份則要看互動狀況來判定,如果純粹透過system call的方式來呼叫Samba本來提供的呼叫介面,則風險性降低,但若是自行撰寫的程式僅能用來呼叫Samba,也並無其他可代換Samba的程式可供代換的話(例如部份網站CMS可用PostgreSQL來代換MySQL),則風險性會再升高。若是狀況確屬於後者,則建議還是要考量以GPL-3.0的方式來將自己撰寫的程式原始碼與Samba一併釋出,因為Samba這個專案的著作權利目前受到「軟體自由託管機構(Software Freedom Conservancy, https://sfconservancy.org/)」的代管,這是一個對於軟體自由理念要求嚴謹的權利代管機構,其代理Samba專案的權利人發動自由軟體侵權訴訟的動機與可能性都非常高。

這部份相關的報導與資訊,可以參照葛冬梅小姐所撰寫的「從 BusyBox 案談起:台灣業者侵權利用自由軟體所面對的法律風險」專文:https://www.openfoundry.org/tw/legal-column-list/2277--busybox-

3、我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的library, static linking完後產生binary(執行檔), 請問我透過網路散佈此binary是否允許, 我自己的library原始碼與samba的原始碼是否要公開? 我的library原始碼是否同樣需以GPLv3發佈?

兩者的原始碼都需要提供、新撰寫的程式碼也必須以GPL-3.0來向外發佈。

4、我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的binary (使用system來呼叫), 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許? 我自己的binary的原始碼與samba的原始碼是否要公開? 我的binary原始碼是否同樣需以GPLv3發佈?

此題的回覆與問題2是相同的,一般判斷軟體相依性,固然有孰主孰從的不同,但此亦並非唯一的判斷參考項目,在LGPL-3.0裡有這麼一段文字:

If you modify a copy of the Library, and , in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:

如您對LGPL3函式庫進行修改行為,並且、在您修改之後,此「衍生函式庫」的某些功能必須仰賴特定「應用程式」的特有程序、函式才能進行呼叫(意指非一般傳統上「應用程式」將單純數字變數導入函式庫呼叫結果的運用關係),那麼為了不使此修改過的「衍生函式庫」受到私有「應用程式」拘束而斫喪函式庫的某些功能(因此一修改過的「衍生函式庫」、其某些修改過的功能乃接受特定「應用程式」的呼叫後方可供給,但此呼叫行為可能不同於傳統方式以數字或簡單函數進行呼叫,或許此「應用程式」是以較複雜的函式對函式庫進行呼叫,如此一來若失去此特定「應用程式」的配合,則此「衍生函式庫」某些功能便陷於無用),抑或發生「應用程式」拑制此衍生函式庫的未來修正改版可能性的狀況(理由同上、若「衍生函式庫」的某些功能會因與特定「應用程式」失去連結便淪於無用,則此「衍生函式庫」在獨立改版運用的可能性上便受到限縮,殆因此一「應用程式」多為不開放原始碼之「私有軟體」,若此「衍生函式庫」的某些功能有賴特定的「應用程式」方可進行呼叫,則無異於具「自由開放性」的「衍生函式庫」之改版發展受到私有軟體所拑制),則對原LGPL3函式庫為修改者須擇一滿足下列條件,才能將此衍生作品再行傳散出去。

a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or

a) 「衍生函式庫」續用LGPL3為其散布時的授權條款,但您須盡相當的誠信保證義務,確保此「衍生函式庫」經修改的某些功能,不須受限特定「應用程式」的配合即可發揮效用,意即此一修改過的功能仍可被其他「應用程式」所呼叫取用,否則

b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.

b) 請您逕將修改過的「衍生函式庫」以GPL3為其散布時的授權條款,須特別了解的是、如此一來您的「衍生函式庫」便須受到較為嚴格的義務性要求所拘束,而不適用LGPL3所添附較為軟性的折衷條款(此處令修改LGPL3函式庫的衍生作品改用GPL3的理由為,因修改者並不能確保此「衍生函式庫」所有功能於嗣後傳散完整無缺之故,是以要求其以GPL3來進行散布,因在GPL3較為嚴格的義務性要求運行之下,此時與「衍生函式庫」連結運作的「應用程式」亦須「開放程式原始碼」,如此一來、便不生嗣後「衍生函式庫」再行改版後喪失某些功能的可能性,因「衍生函式庫」與其所連結的「應用程式」在GPL3的運作下皆須「開放程式原始碼」,是以此「衍生函式庫」的未來發展不致受到私有的「應用程式」所拘束)。


簡要來說這段文字規定的是,若是修改者將新功能加到LGPL-3.0授權的函式庫裡,但個功能就是設定來被這個修改者自行編寫的其他應用程式所呼叫,那麼此時LGPL-3.0額外要求:(1)修改者需要把這個新功能如何被其他應用程式呼叫的資訊披露出來,以確保這個功能日後也可以被其他人編寫的應用程式來呼叫;(2)直接把整個函式庫轉以GPL-3.0授權,因為這樣一來、GPL-3.0的授權拘束性較強,會連帶使得呼叫這個新功能的應用程式也得依GPL-3.0來授權並開放程式原始碼。

從這段文字我們可以看到,自由軟體基金會有意識的將這類「呼叫關係倒轉」的程式互動方式,視為潛在的GPL授權義務性規避手法,從而可以知道,採取這樣的作法其GPL的侵權風險性並不一定能降低,有時反而會因為引發權利人的注意、軟體社群的討論,而讓後續產生爭議的可能性更為提高。

5、如果上述四種情形換成是GPLv2的授權, 情況是否會有所不同呢?

原則上在衍生著作的判定上,GPL-2.0與GPL-3.0相去不遠,所以若是不考慮Tivo條款、軟體專案授權條款、及其他細項,那麼以上所述說的四個判斷都不會有結論的不同。

一些說明如上,如後續更有疑問或是其他想法,歡迎接續討論!



敬祝 順心健康、事事如意

20110819 1550 Lucien C.H. Lin

----------

youhas wrote:
Dear Sir,

我是個newbie, 感謝提供了這樣的平台, 讓我可以了解Open source community, 但仍有一些問題想請教, 我大致分成幾點來描述提問, 謝謝

我想提供一支tool (binary形式)透過網路散佈公開給大家使用, 作法如下:

1. 原始碼中有呼叫到Samba 3.6 (GPLv3)的library中的function, static linking完後產生binary(執行檔), 請問我透過網路散佈此tool是否允許, 我的原始碼 與samba的原始碼是否要公開? 我的原始碼是否同樣需以GPLv3發佈?

2. 原始碼中有呼叫到Samba 3.6 (GPLv3)compile出來的binary, 使用system()來呼叫, 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許, 我的原始碼 與samba的原始碼是否要公開? 我的原始碼是否同樣需以GPLv3發佈?

3. 我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的library, static linking完後產生binary(執行檔), 請問我透過網路散佈此binary是否允許, 我自己的library原始碼 與samba的原始碼是否要公開? 我的library原始碼是否同樣需以GPLv3發佈?

4. 我修改了Samba 3.6的原始碼, 使它呼叫我自己compile出來的binary (使用system來呼叫), 將samba的binary與我自己的binary包成tar 透過網路散佈是否允許? 我自己的binary的原始碼 與samba的原始碼是否要公開? 我的binary原始碼是否同樣需以GPLv3發佈?

如果上述四種情形換成是GPLv2的授權, 情況是否會有所不同呢? 謝謝
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