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

法律源地

本網站法律源地提供相當多自由軟體授權與法律的資訊,歡迎您閱讀這些資訊。

 

法律源地

筆者在工作上,接觸過不少國內的軟體開發者有這樣的疑問:自己的程式 A(以下簡稱 A)採用甲款自由軟體授權條款釋出,但是之後想要採用另外一份不同的乙款條款來授權的話,是否可以將專案原來的甲款授權方式撤銷 (revoke),然後改為新的乙款授權條款來授權?雖然部份授權條款並沒有明文說明這方面的規定,目前也沒有司法判決明確禁止這樣的行為,不過因為自由軟體授權條款具有授權給公眾利用後不間斷散布的特性,因此從條款的授權架構與軟體社群的運作習慣分析之,筆者並不認為自由軟體授權專案具有嗣後撤銷性。
我國政府每年都會花費大筆的經費在補助科學技術的研究與發展上,許多學校老師、研究機構與私人公司都會申請這類的補助經費來研發軟體,部份計畫的成果甚至後續會進行產學合作,將成果轉換成為實際的商品供社會大眾來利用。而由於自由軟體發展到今日,已經有許多成熟與穩定的版本出現,近年常常可以看到不少的自由軟體元件被利用在政府所補助的計畫當中,一旦這樣的計畫成果走向商業化利用,這些自由軟體元件也將隨著一起成為商業產品被販售出去。

第 155 期的自由軟體鑄造場電子報中,「BusyBox 與 GPL 授權再次贏得侵權訴訟」一文報導,Westinghouse Digital Technologies(以下簡稱 Westinghouse)因使用 BusyBox 未依 GPL 規定釋出源碼,不僅被判賠 9 萬美元的侵權賠償金及原告的訴訟行政成本 4 萬 7,685 美元,其侵權產品,就是內含 BusyBox 元件的 HDTV,還被沒收並移轉給原告 Software Freedom Conservancy (SFC) 作為慈善捐贈之用。

為何違反 GPL 的規定會導致這麼嚴重的損失?企業利用自由軟體的法律風險要如何衡量?這篇文章將進一步解析本案的損害賠償方式及理由,使企業能在決策過程中更了解其中的風險與成本。

這篇文章所要談論的是關於 GPL 授權議題的一個大哉問:「針對 GPL 元件的衍生程式 (derivative works),使用者應該提供「什麼樣的源碼 (Source Code)」給收受程式的後手?」很多人認為只要單純地將本來以 GPL 授權的元件源碼提供出來即可,並不管這些提供出來的源碼,在實際上是否可以被其他開發者加以研究與修改,也未交待這些 GPL 授權元件是如何與專案裡其他的元件進行連結與互動。這樣的態度其實與 GPL 授權條款的規定並不相符,也與一些自由開源軟體開發者的理念相左。筆者將在本文引述,目前在侵權實務上具有重要地位的自由開源軟體開發者意見,說明他們認為在修改 GPL 元件後,修改者在後續散布時,應該提供什麼樣的源碼(註一)。

為了要解決工作上所需處理的授權分析問題,筆者常會需要了解一個專案究竟利用了哪些自由軟體元件,以及這些元件是採用哪一份自由軟體授權條款?這些工作通常得透過人工進行,也就是請實際開發專案的工程師提供他們的軟體架構圖,並且查詢這些軟體元件適用哪些授權條款,等到取得這些資料後,才有辦法進行後續的授權分析,以研擬授權衝突的解決方案。若涉及的自由軟體元件僅三、四個,那這樣的人工作業尚不困難,但若是牽涉到幾十個自由軟體授權元件,那就得花上好一番的功夫來進行人工作業。因此為了簡便這些授權分析的流程,近年不少團隊就此需求建置了自由軟體程式碼掃描的自動化系統,以掃描軟體專案程式碼的授權方式,並進一步列出報表以顯示該專案裡自由軟體元件的利用情形,以及所使用到自由軟體元件的授權細節。

近半年來,筆者接到的一些諮商問題,不約而同地詢問到哪裡可以找到這樣的掃瞄系統,因此透過本文來介紹幾套這類型的掃瞄系統,提供給想要了解這方面資訊的朋友一個初步的參考(註一)。但由於筆者本身並不具有程式開發的技術背景,因此介紹的內容,將僅就這類系統在授權分析方面的特點加以描述,而不針對技術細節來進行說明。

更多文章...

第 11 頁, 共 26 頁

11