Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
Law & Licensing

Open Source Software license

We provide Open Source Software license and legal materials via this page.

 

Law & Licensing

GPL 類別的授權程式,最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性(License Inheritance,註一)。所謂的「授權拘束性」白話來說,指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時,如果抄寫程度佔專案程式碼的比例很大,或是此一 GPL 授權元件提供了專案的核心功能,並且專案的其他元件在互動上亦無法與其分割,則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作,嗣後使用者如果再行散布這個軟體專案,便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由開源軟體元件被產業化利用的比率愈見頻繁,因此授權拘束性所帶來的爭議也愈來愈受到重視,本文便是針對這個議題,先依著作權法的預設說明、再照 GPL 授權條款的文意解釋,接著舉 Linux Kernel 的實際運作狀況佐證,一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準,及此標準在軟體元件的連接關係 (linking) 上,所可能擴散的拘束性範圍。

自由軟體是一種人人都可以協力開發、修改與散布的軟體,不過並非所有的參與者,都清楚了解應該如何適當地標示授權相關資訊,這造成了許多自由軟體專案,在釋出時授權資訊標示不清,讓拿到軟體的後手不知道有哪些權利可以主張,也不知道有哪些義務必須遵守。而在後者的情況,更可能會讓後手在沒有被充份告知的情況下,以違反授權條款的方式來散布軟體,引發侵權糾紛。這樣的自由軟體侵權糾紛,近年在商業應用上層出不窮,同時也讓部份熱心釋出成果的自由軟體開發社群感到沮喪。所以本文將會分析一般常見授權資訊不清的型態、提出建議的標示方法,以及說明近期 Linux Foundation 針對這樣的問題,所發布的 SPDX 規格書架構,以期望能協助讀者釐清問題根源,並促成國內的自由軟體專案開發者與使用者,都能夠以更適當的方式來標示所使用自由軟體的授權資訊!

在協助處理各式各樣自由軟體授權問題的過程中,常常發現有許多廠商是在接到侵權警告信之後,才開始著手整理產品中所利用到的自由軟體元件,以及清查這些元件是採用哪一份授權條款來授權,這種事後的清整一來是非常耗時費工的,再者,這中間若有損害賠償的費用產生,廠商還可能因此必須負擔額外的金錢支出。其實這些額外的時間、人力與金錢支出,都可透過一些事前的措施來加以預防,並降低被認定為惡意侵權行為的風險,自由軟體資訊清單就是一個簡單而有效的方法。
一般公司在採購軟體、聘僱員工或者是與其他公司共同研發技術等事務的過程中,常會涉及軟體著作財產權的讓與。傳統上,著作財產權讓與多半由雙方經過協商讓與細節、達成合意、及簽訂讓與契約的程序來達成。但 copyleft 性質的開源軟體,其要求衍生著作的著作人/散布人也必須採取同樣的授權模式,才能夠進行該衍生著作的散布、流通與修改(註一)。這樣的開源軟體若套用傳統的著作財產權讓與模式,將會遇到窒礙難行的問題,甚至可能無法達到原本欲取得軟體著作財產權以達到的商業利用目的。因此,本文以下將就這些相關問題淺析之。
筆者經常到大專院校資訊相關系所,與同學進行自由軟體的推廣及交流,因此得知許多同學確實專精於程式開發,但對於軟體分類、商業模式及授權內涵並不是很熟悉,因此希望能藉由本篇文章向讀者說明自由軟體及其他相關的軟體類別及內容(註一)。本文將先簡單說明「自由軟體 (Free Software)」的內涵,再介紹相關名詞:「專屬軟體 (proprietary software)」、「免費軟體 (freeware)」、「共享軟體 (shareware)」及「公共財軟體 (public domain software)」,並說明「自由軟體」與「開放源碼軟體 (Open Source Software)」的異同處。

More Articles...

Page 9 of 26

9