登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
討論區
GPL許可證相關問題 (1 位瀏覽者) (1) Guest
Go to bottom Favoured: 1
最先
前一個
1
TOPIC: GPL許可證相關問題
#819
GPL許可證相關問題 2013/02/16 22:47  (6 Years, 9 Months ago) Karma: 0  
我寫了一隻PHP程式
後來用 GPL 開放原始碼 給大眾使用

但後來發現有人用我的程式(它有修CSS) 參加比賽 聲稱是自己做的
請問這樣有沒有觸犯GPL條款?

還有 GPL 是否可以反悔?
如不想用GPL後 改用 MPL 或轉為閉源程式??

或者是將新版本的程式閉源??

另外問:有哪些許可證是可以附加其他限制條例的?
secret715 (User)
Junior Boarder
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
Last Edit: 2013/02/17 12:59 By secret715.
 
The administrator has disabled public write access.  
#820
Re:GPL許可證相關問題 2013/02/18 14:13  (6 Years, 9 Months ago) Karma: 10  
Hi secret715,

新春愉快!

首先、以我對GPL授權條款的認知和法律邏輯的解讀,GPL授權的程式是不允許次級授權(sublicense)的。我近期剛好也會撰寫這個題目的法律文章,預定在下週二之後發布,文章的內容,主要就是要說明不同的開源授權,修改程式碼之後能不能以自己個人的名義再散布出去,其實也有細部的不同。

一般文獻常將sublicense翻譯成「再授權」,但就我個人的觀點,這並不是一個很好的譯法,因為很多人就文義會以為sublicense就是relicense,但實際上,「再授權(sublicense)」與「重新授權(relicense)」不是同一個概念。前者、sublicense是一個法律詞彙,代表「被授權人轉以授權人的地位,將某個他從別人身上取得的權利,轉授權給其他的被授權人。」後者、relicense是一個口語詞彙,代表某個東西之前被授權過,但可能以改變對象的方式授權給其他人,或是以改變內容的方式,重新授權給同一個人。

(1)sublicense的內涵有兩個重點:

A、轉授原作者的權利給其他人

sublicensor轉授來自original licensor的權利給其他的licensee,例如A程式本來是作者甲以Apache-2.0授權釋出的,甲將這個A程式以Apache-2.0的方式散布給乙,而由於Apache-2.0允許sublicense,所以乙「可以用自己的名義」將這個A程式,或是修改A程式之後衍生的B程式,以GPL-3.0的方式「轉授權」給丙。

B、轉授權的範圍不超過原作者本來的授權範圍

「sub-」這個字首在英文的字義裡有「附屬、次級」的意思,從這邊我們可以了解到,sublicensor轉授權給其他人的權力範圍,不會比他直接從original licensor那邊得到的權利還大。

而以GPL-2.0授權條款的內容為解說:

1、GPL-2.0說明非依GPL-2.0,不得對GPL-2.0授權的程式為任何重製、修改、轉授權,或散布的動作。(You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License.)

然而,這句話並不能被直接反推,認為按照GPL-2.0就必然可以對程式進行「轉授權(sublicense)」方式的利用。GPL-2.0的條款內容,就是沒有明白像MIT授權條款一樣,容許修改者就修改後的程式直接以修改者自己的名義授權出去。

2、GPL-2.0清楚規定,修改別人的GPL程式,必須對修改資訊作清楚的交待。

You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.這段文字清楚的指出,如果修改了他人以GPL-2.0授權散布的檔案,那麼必須在之後的散布,清楚交待哪一個檔案被修改了,它的修改日期,以及必要的相關資訊。

所以說,「如果有人用您的程式參加比賽,但聲稱完全是由他自己開發,且完全刪去您原來的授權聲明,那麼這種行為確實是觸犯 GPL 授權條款的相關規定的。」

一般我們在GPL授權專案,被改作後常見的授權聲明,大多會標示為:

2013 (c) BBB Project, developed by Mr.B and Mr.A, the previous version of BBB Project is AAA Project on SourceForge under GPL-2.0 (sourceforge.net/AAA/).

以上面這個授權聲明來作解說,Mr. A是專案的原始創作人,他將其創作的A專案以GPL-2.0的方式釋出,Mr. B是專案A衍生專案B的創作人,而依據GPL-2.0的規定,Mr.B在散布B專案時,應該要在授權聲明上將Mr.A與其A專案一併標示出來,才會符合GPL-2.0對授權標示方面的要求。

所以,如果您以GPL-2.0授權的專案被人改作後,卻刪去應該歸於您的標示,那是可以聯絡這個專案的改作人,請他就這部份進行檢討與改善的。

----

另外的問題是:使用GPL釋出軟體之後是否可以反悔?如不想繼續使用GPL這樣的授權方式的話,改用MPL或轉為一般私有授權軟體(Proprietary Software)的方式是否可行?或是直接在新的版本進行這樣的授權轉換?

嗯…前者、是沒有辦法的,自由開源授權在解釋上,以及後續條款的明文規定下,是禁止將授權嗣後撤回的(irrevocable)。新的授權條款例如GPL-3.0與Apache-2.0都有這樣的說明,但是、沒錯,您其實可以透過新版本的釋出,改變新的授權方式。例如AAA-1.0版時用MIT授權、AAA-2.0版時用GPL-2.0授權,AAA-3.0版時用MPL-1.1授權,然後AAA-4.0版時用商業專屬授權。重點是、之前以MIT取得1.0版的使用者,將可以繼續依照MIT的方式來使用1.0版本的程式,之前以GPL-2.0取得2.0版的使用者,將可以繼續依照GPL-2.0的方式來使用2.0版本的程式,然而,如果他們要使用新版本的程式碼,就必須依照新版本的授權方式,而不能依MIT或是GPL-2.0的授權方式,來使用新版程式新加的功能與程式碼。

這方面的資訊我與鑄造場的同仁葛冬梅小姐曾合著過一篇專文,自由軟體專案授權方式的轉換:https://www.openfoundry.org/en/legal-column-list/8195-2010-11-22-18-38-45,如果您有興趣,不妨可以參考之前整理的內容。

希望上述的資訊對您有所幫助,如後續再有相關或衍生問題,歡迎隨時接續討論!

敬祝 順心健康、新年快樂



20130218 14:15 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.  
#821
Re:GPL許可證相關問題 2013/02/18 17:21  (6 Years, 9 Months ago) Karma: 0  
謝謝您的回覆!

不過很抱歉,我忘了跟您說我的授權條款是 GPL v3 (不過看你們的文章差異好像主要是再新增條款部分)

另外
1.『透過新版的釋出,可改變此程式授權條款』 若原始碼一樣、版本號一樣,這樣是否還能改變授權條款?(你們的文章是寫 原始碼一樣 但版本號不同 就可以改變程式的授權條款)


2.續#819(也就是本帖的第一樓)的第一個問題,若是我的程式原本並沒有在每個檔案上加授權聲明,而是只有在放置 GPL 條款的檔案上方加
『此程式使用
GNU通用公共許可證 Version 3---(GNU GENERAL PUBLIC LICENSE Version 3)
發佈
(包括其一切原始碼、圖片等...)』 這樣行嗎?


3.我在他使用的程式版本上並沒有附上我的『標示』,如本程式由XXX製作,事後可以要求他補上嗎?


4.接問題3 若是我的『標示』顯示在程式使用的畫面最上方,且連到我的程式官方網站,這樣可以嗎? (還有『標示』有沒有限制大小呢?)


5.有哪些許可證是可以附加其他限制條例的?


這次問的問題有點多,若耗費您太多時間,對您說聲抱歉。
secret715 (User)
Junior Boarder
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#822
Re:GPL許可證相關問題 2013/02/21 15:07  (6 Years, 9 Months ago) Karma: 10  
Hi secret715,

原來你使用的版本是GPL-3.0,不過、GPL-3.0就轉授權(sublicense)這點在推論上與GPL-2.0並沒有太大的差異,而在修改標示方面,GPL-3.0一樣明訂:修改他人的GPL-3.0授權元件,必須清楚交待誰修改了它,以及其相關的修改日期。(The work must carry prominent notices stating that you modified it, and giving a relevant date.)所以此處也與GPL-2.0並無兩致。

以下是你追加討論的部份:

1、若新版程式與舊版程式的原始碼完全相同,甚至連版本號也相同,是不是還能夠改變其適用的授權條款?

理論上並沒有說不行,只是、一般來說較建議在這種狀況下,就給這個程式一個新的版本號,會是一個比較清楚讓人好理解的作法!

我們舉例來說,專案名稱為「TIVOK」,第一個版本為「TIVOK 1.0」版,採「MIT License」釋出,之後、雖然程式碼沒有改,也可以稱一個新的版本為「TIVOK 2.0」版,改採「GPL-2.0」或是其他授權方式釋出。此種作法的好處在於,不致讓使用者在查授權資訊的時候產生誤會,目前坊間有一些程式授權狀態的驗證軟體與服務,例如BLACKDUCK或是FOSSOLOGY,這些程式的授權資訊資料庫會註解「TIVOK 1.0」為「MIT License」,而「TIVOK 2.0」版為「GPL-2.0」授權,那麼當查找者可以確認所使用的版本是1.0版時,他們就可以安心使用MIT授權的方式來使用它,反之、如果確認所使用的版本是2.0版時,就可以安心使用GPL-2.0的方式來使用;但是、若是您同一個「TIVOK 1.0」版,之前採MIT License,之後採GPL-2.0,但釋出的時間又有前後的差異,這種狀況會是比較容易造成誤會的,雖然理論上這就是「雙重授權(Dual-license)」,也就是說這些程式碼同時採用MIT與GPL-2.0的方式釋出,只是標註的時間不同,但就是因為標註的時間不同,也許會讓使用者在查找上產生誤會和不確定感,所以、我們在撰文時才會建議,即使是程式碼完全沒有修改,亦不妨給該軟體專案一個新的版本號,再去適用新的授權方式,這樣會是一個避免產生誤解的方式。

例如,「TIVOK 1.0」版,可以使用「MIT License」釋出,其相同程式碼的專案亦是要採用商業服務的授權方式,不妨稱這個商業服務的專案為「TIVOK 1.5」版,採用商業授權的協議來運作,然後其後的「TIVOK 2.0」版,也可以改採GPL-2.0、GPL-3.0這種Copyleft的授權方式,來與「TIVOK 2.5」版的商業授權版本來配合,也就是說,透過這樣的方式,可以讓使用者捉到版本與版本間的傳承關係與授權機制的轉變,「x.0版本」邏輯上皆為自由開源授權,而「x.5」版本皆為商業服務授權,慢慢建立這樣的授權配置之後,軟體專案的授權布局便可愈見清晰,而不易產生誤解。

2、採用GPL釋出程式專案時,若並未在每一個檔案標頭(header file)都註解其採用GPL授權,而是統一在根目錄處置放一個說明檔,此種作法是否已充份表述?

可以的,GPL授權條款並沒有約束每一個創作人,一定要每個檔案都去標註該程式碼的授權狀態,只是、這雖然不是義務,但是一個「作了會比較好的方法」,因為之後別人改作你的程式時,他可能不會整包程式碼都拿去,而可能只是取用其中幾個檔案或是函式檔,如果你本來有將簡要的授權資訊寫在這些重要檔案的檔頭資訊裡,那就會讓整個改作狀態變得「有跡可尋」,而如果該改作者「刻意將這些檔頭資訊拿掉」,日後若發生侵權糾紛的話,他所為的刻意刪除資訊的行為,也有機會被承審法官認為是「明知並故意」侵權的主觀象徵。

這裡稍微簡述一下GPL授權條款在GPL授權標示上一定要作的幾個動作:

(1) 散布GPL授權程式時,一定要附隨散布一份GPL授權條款的全文。(Give all recipients a copy of this License along with the Program.)

所以,大部份的專案會在釋出包的根目錄下,放入一個名為COPYING的純文字檔,該文字檔的內容就是GPL授權條款的全文內容。

(2) 如果個別檔案被修改過,必須要標註修改人為何,以及修改日期為何。(The work must carry prominent notices stating that you modified it, and giving a relevant date.)

因應於此,許多專案會在釋出包的根目錄下,放置一個名為README、REVISION、或直接稱為MODIFICATION的純文字檔,說明哪些檔案有被更動過,以及更動日期是什麼時候。

(3) 如果該程式安裝時有人機互動介面,並且會透過這個介面來顯示個別元件的授權聲明,那麼採用到的GPL元件,必須適當的透過這個介面,讓其GPL授權條款的內容呈現給程式的安裝者與使用者。(If the work has interactive user interfaces, each must display Appropriate Legal Notices.)

在GPL授權方式方面的標示義務,大致上便是如此!

此一問題進一步的參考資訊,可以參照葛冬梅小姐所撰右列專文,如何提供 GPL 元件的程式源碼:www.openfoundry.org/tw/legal-column-list/8782-how-to-distribute-gpl-source-code

3、他人改作你本以GPL-3.0釋出的程式,後續散布時並沒有附上應有的「標示」,如「本程式原始版本由XXX製作,採GPL-3.0於www.yyy.zzz釋出。」能夠在事後請他補充標示嗎?

沒有問題,如前所述、依照GPL-3.0的授權義務性規定這也是應該的。你可以聯繫專案的改作人補行這個標示的動作。

4、若是要求上述「標示」必須顯示在程式操作畫面的最上方,且點擊此一標示能連結至原版程式的官方網站,這樣的要求是否符合GPL-3.0授權條款的運作規則?

這樣的要求爭議是比較大的,因為GPL-3.0律定:採用GPL-3.0釋出程式時,關於這些軟體權利的行使,不得向後手課予或要求GPL-3.0條款本身所無之限制。(You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.)進一步說,GPL-3.0已經有預設授權標示方面的規定了,進一步要細節去要求程式的改作者,進行條款本身沒有描述到的標示義務,很有可能、就會被認為是GPL-3.0此處所說的「條款本身所無之限制」,而被認為是無效的要求。而且歷史上類似的故事曾經有發生過,就是四款BSD授權條款與GPL-2.0是否相容的爭議,因為四款的BSD授權條款要求在授權聲明的標示上有一些細部的規定,而自由軟體基金會認為這些細部要求在GPL-2.0條款裡是沒有的,所以認為四款BSD條款與GPL-2.0不相容。

如果真的要立一些特殊的標示的話,我的建議是應用GPL-3.0第7條第3項b)款的額外添附條款(Additional Terms)!基本上、整份GPL-3.0的條款都是不能被使用者變動的,但是第7條這6款額外添附條款,是GPL-3.0不得變動中的折衷機制,也就是說、使用GPL-3.0釋出自己程式的使用者,可以自主加上這6款額外條款,而其中的b)款,指的是:「原專案的著作人,可以指定程式散布時某些聲明內容是不能被後手刪去的。」(Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it.)透過這款額外添附條款,你可以將你原始專案的網址、運用狀態,甚至你個人的簡介都寫到程式的說明資訊裡,並且要求後手散布改作作品時,也要保留這些聲明。雖然此款似乎也不能指定後手一定要將網址或是資訊內嵌到改作物的操作介面上,但你可以要求如果其改作物有著作權與資訊的說明頁面,一定要將你要求的顯明資訊擺進去。這樣也算是某一程度達到你期待的目標。

5、有哪些自由開源授權條款是可以附加其他限制條款的?

基本上,所有的自由開源授權條款的內容,你都可以拿來改作,只是一旦你更改了授權條款的內容,後續應用上,你便不能再稱其為原來的授權條款。例如、你可以拿BSD授權條款來改為AAA授權條款,將自己的程式以AAA條款釋出,也可以拿GPL-3.0授權條款來改為BBB條款,將自己的程式以BBB條款釋出,但這些改作過的條款,泰半與原來的授權條款便不再相容了。會這樣發展的原因是,自由開源授權強調的是一種多人共工的發展模式,所以條款預設的架構就是大家都用同一份條款、同一份規則,這樣專案經過許多人的修改與改作後,仍然有可能與原本的程式碼,或是之後延展出來的程式碼,在同一個規則下相容。

而如果說授權條款本身即設有「附加限制條款」的,目前看來大概就是GPL-3.0、LGPL-3.0,以及AGPL-3.0,於前述的第7條項下設有「額外添附條款(Additional Terms)」,讓使用者能在這6款的限度下去調用,然而、也就僅限於此預設6款的內容。

如果你對於這些額外添附條款有進一步了解的興趣的話,可以進一步參照拙譯,GPL-3.0-非官方正體中文翻譯:lucien.cc/lucien/doku/doku.php?id=notes_and_translations:foss_license_translations:gnu_general_public_license_version_3

不過在此特別聲明,自由軟體基金會並不允許任何人將GPL授權條款進行翻譯並進行運用,其所發布之英文版本方為具解釋性的唯一可參照版本,所以這裡的非官方譯文,僅是讓大家可以據以討論、參考之用,並不具任何法律效力。

與額外添附條款相關的文字我亦節錄在下,供你可以直接閱讀。

----

散布者在取得原權利人同意或是滿足其預設的要求條件後,能夠添附以下六款「額外添附條款」至GPL3授權條款內,再依此複合狀態的授權規定將程式再行散布出去,此六款「額外添附條款」的實際內容如下:

a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or

1、宣告與GPL3本文第十五條及第十六條有別的免責條款或所謂的責任限定條款;

b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or

2、要求後手在程式的後續傳遞過程中保留原權利人合理的相關法律聲明,比如顯名式的著作人格權保留或其他合理聲明等;

c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or

3、禁止後手刻意混淆修改作品與原作品的同一性,或是由原程式的著作人要求修改者,須以不同的版本號或清楚的聲明宣示此衍生作品為一修改物,以公示釐清修改版本並非出於原程式著作人之手,而不至於將修改版本日後的技術瑕疵或法律爭議無辜地歸咎於程式的原作者;

d) Limiting the use for publicity purposes of names of licensors or authors of the material; or

4、禁止後手在未經允許的狀況下,以原程式著作人的名聲為後續版本進行宣傳或為修改程式的品質背書;

e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or

5、原權利人明示其在商標法的允認範圍內,禁止收受程式的後手使用者在未經允許的前提之下運用這些商標及相關的各式商品服務標記。

f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

6、原權利人可添附「損害發生補償條款(契約責任禁止添加條款)」。有時後續散布GPL程式者,會與收受程式者議定不同於GPL原始散布狀態的契約責任,這些契約責任的內容甚至可能波及程式的原始著作權利人,或是其他參與程式修改的接續作者也得擔負這些額外的責任。如果擔心這樣的事情發生,原權利人便可據本項規定添加「損害發生補償條款(後續契約責任添加禁止條款)」再將程式釋出,來加以明示防堵,意即、程式的著作權利人得利用此項聲明,明文表示、若程式後續散布者與他人簽訂契約散布此一程式,後續卻讓其負擔權益上的損害,則此程式的後續散布者便須依照「損害發生補償條款」的規定,補償其因此而產生的權益損失。

----

最後,其實我個人非常歡迎大家能在這個論壇,一同發掘自由開源授權的議題並進行討論,因為這本來就是我目前生涯職志有興趣做的事,也希望能在自己研究所學之餘,盡量將中道、可參據的相關資訊與知識分享出來讓國人知道,所以、並不會覺得是耗費到時間。

然而、有時候工作事務上較繁忙之時,難免回覆的速度會有所拖累,就這點、再請見諒。

祝你 新春愉快、事事如意



20130221 15:10 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.  
#823
Re:GPL許可證相關問題 2013/02/21 16:55  (6 Years, 9 Months ago) Karma: 0  
謝謝您的回覆, GPLv3 繁體中文翻譯版寫得很好,讓我更懂了 GPL v3 條款。
secret715 (User)
Junior Boarder
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
Last Edit: 2013/05/19 15:32 By secret715.
 
The administrator has disabled public write access.  
#833
Re:GPL許可證相關問題 2013/03/24 10:27  (6 Years, 8 Months ago) Karma: 0  
若使用DreamWeaver內建的程式碼來製作程式,那此程式是否能開放原始碼?
secret715 (User)
Junior Boarder
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#834
Re:GPL許可證相關問題 2013/03/25 17:06  (6 Years, 8 Months ago) Karma: 10  
Hi secret715,

這個問題很有趣,其實在國外論壇也不少人討論過,我補上以下二個問題,都可以算是類似的情況:

1、內嵌微軟新細明體的PDF文件,能不能用創用CC授權條款(Creative Commons License)向外散布?

2、GCC RUNTIME LIBRARY EXCEPTION。

再加上您提出來的這個問題:「使用DreamWeaver內建的程式碼來製作程式,那此程式是否能開放原始碼?」

----

我認為關鍵點在於,這些DreamWeaver內建程式碼如果在編寫網頁程式的過程中,會自動include到所製作出來的程式的話,那這些自動include進來的程式碼,能不能被以轉授權(sublicense),或援引著作權法關於微量取用的合理使用(fair use)抗辯,的方式來利用?如果可以,那這些程式有機會被以開放源碼的方式向外散布,如果不行,那這些程式就沒有辦法以開放源碼的方式向外散布。

舉微軟新細明體為例,微軟對其Windows Office內嵌字型的授權方式,是授權Windows Office軟體的使用者,可以自由將這些字型內嵌於作品,並進行後續的紙本列印,以及採文件格式讓人進行瀏覽。所以說,如果使用者使用Windows Office寫一篇文章,然後將文章以PDF格式散布出去,並用創用CC-BY-SA的方式釋出,原則上該文章在顯示時會內嵌部份的微軟字型,但這部份微軟已經先授權使用者可以這樣利用了,而該作品重要的內涵其實在於文章內容,亦非字型,所以文章內容後續仍然可以被人引用與改作,亦沒有違反創用CC-BY-SA的授權規則。

此處有一個重點是:Microsoft容許合法內嵌其字型的文件,是可以依一般被列印、在螢幕或是網路展示的方式,來被利用的。

----

GCC RUNTIME LIBRARY EXCEPTION全文如右所示:https://www.gnu.org/licenses/gcc-exception-3.1.html

這個除外條款的內容就是,如果您採用GCC(The GNU Compiler Collection)來編譯程式,在這個編譯的自動化過程裡,有些GCC的程式碼必然會帶到被編譯的檔案裡,雖然這些程式碼嚴格解釋下也算是GPL-3.0授權的函式或是腳本,但該專案認為使用者可以採引GCC RUNTIME LIBRARY EXCEPTION,主張該被編譯的檔案並非GCC的衍生著作,從而在授權上並不受到GPL-3.0的拘束。

GCC RUNTIME LIBRARY EXCEPTION,其實也是經GCC開發團隊的反覆討論與思量,他們認為一開始對於GCC編譯過程自動帶入程式碼的行為並沒有被充份討論,而且一開始許多開發者也表態認為此為編譯過程中程式碼的必然引用行為,不能算是衍生行為,所以後來為了將這些爭議做一次性的處理,他們就在GCC的授權方式裡加列了此一GCC RUNTIME LIBRARY EXCEPTION,讓大家了解到編譯過程中必然的、微量的程式碼引入行為,是不會開啟GPL-3.0的授權拘束性的。

此處有一個重點是:GCC開發團隊透過GCC RUNTIME LIBRARY EXCEPTION,明白表示編譯過程中程式碼必然且微量的導入行為,是可以的,也不會啟動GPL-3.0相關的授權義務要求。

----

所以我們綜合一下上面兩個案例,可以了解:使用他人提供的工具程式來編寫程式,在編寫過程當中自然產生的程式碼或相關程式腳本,還是有可能具有著作權的保護。

如果要加入運用的話,可能有以下三個不同的立場:

1、如果該工具程式的著作權利人並不主張這些程式碼與腳本的著作權(這個狀況比較「近似」GCC RUNTIME LIBRARY EXCEPTION),那當然您可以將產生的程式以自由開源軟體的授權方式向外散布。

2、但如果該工具程式的著作權利人,並沒有說其不主張這些程式碼與腳本的著作權,那依著作權法的預設,其仍然具有這些程式碼的權利,所以就要進一步看該工具程式的使用者條款是怎麼規定這個狀況的(這個狀況比較「近似」Microsoft的字型授權)。

3、而如果這些程式碼與腳本的引用幅度並不大,各國著作權法都有規定「合理使用(Fair Use)」抗辯機制,一般來說:使用幅度微小、影響經濟利益不大、一般常見行為,上述理由綜合以觀,都有機會讓使用者據以援引合理使用的法制,而抗辯此一程式腳本的引用行為並非侵權利用。

所以如果使用DreamWeaver內建程式碼來製作程式,能主張以上一到三任一立場,我想是有機會將這些程式碼採自由開源軟體的授權方式來向後散布的。

不過是這樣,第三個立場主張合理使用,要視個案來判定,而第一、第二種方式,要看DreamWeaver的使用者條款有沒有規定,而基於DreamWeaver為需付費取得的私有軟體,我目前手上並沒有這套軟體,從而也閱讀不到它的使用者條款,如果secret715您能提供它的使用者條款給我的話,我也才有辦法做更進一步的分析。

約略如上,希望這些資訊對您有所幫助。



20130325 17:05 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.  
#835
Re:GPL許可證相關問題 2013/03/25 17:57  (6 Years, 8 Months ago) Karma: 0  
我從我的Dreamweaver找到的授權條款
secret715 (User)
Junior Boarder
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#836
Re:GPL許可證相關問題 2013/03/29 17:20  (6 Years, 7 Months ago) Karma: 10  
Hi secret715,

這張圖顯示的是該軟體的著作權利聲明(Copyright Notice),以及相關的MPEG3專利權聲明,但還不是DearmWeaver完整的「使用者條款(User Agreement)」。

一般來說使用者條款會在您第一次安裝該程式時,完整的披露出來,並在您點選「同意」之後,才會開始進行程式的安裝動作。所以如果該程式在安裝過後,受辦法透過圖形介面再次閱覽到使用者條款時,那麼可以試驗性的重新安裝一次程式,此時完整的使用者條款,就能夠再次顯示出來了。

日安、順心!



20130329 17:20 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.  
#837
Re:GPL許可證相關問題 2013/03/29 19:06  (6 Years, 7 Months ago) Karma: 0  
好的
近日去挖挖安裝程式 看看條款
secret715 (User)
Junior Boarder
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
Go to top
最先
前一個
1