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

法律源地

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

 

法律源地

Google 在 2010 年啟動 WebM 計畫(註一),這是一套開放、免費的影音編碼格式,不僅其中的程式碼採用自由軟體授權條款釋出,其中的專利技術也採用公眾授權的方式開放他人免費利用,Google 並在 2011 年 1 月表示會於 Chrome 瀏覽器裡移除對於 H.264 影音編碼格式的支援(註二),擴大宣示朝著開放影音格式的政策邁進。但與 WebM 有競爭關係的 H.264 影音編碼格式其實也在去年宣佈,對於免費網站採取永久不收取授權金的政策(註三),乍看之下,這似乎也是一種另類的開放專利授權。但是,這些專利影音編碼格式在授權政策上的變動,真的會如同表面上所看到那樣開放與美好?只要是應用在免費網站上,網站經營者就可以隨意選擇 WebM 或 H.264 格式來實作到影音軟體中,而無須擔心任何後續可能產生的專利授權問題?針對這些疑問,本文將會加以說明,並提出一些建議措施。
1980 年代以降,由 Richard M. Stallman 領軍的自由軟體運動及其後 GNU/Linux 的成功,使世人了解到共工開發、同儕生產 (peer production) 的可能性;並且,史丹佛大學 Lawrence Lessig 教授亦啟動創用 CC (Creative Commons) 計畫,使文字、圖片、聲音、影像等程式碼以外的著作權素材,亦得以類似的方式提供眾人利用;此外,維基媒體 (Wikimedia) 基金會的旗下網站也利用公眾授權模式(註一),納入眾力編輯而成為全球第五大網站(註二)。開放源碼的公眾授權模式在自由軟體理念推廣者的努力以及人人皆得近用網際網路的環境助長之下,已被證實是一種可行的生產模式(註三)。於是,其他領域,包括生命科學領域在內,也開始進行相關的嘗試。

Microsoft Public License (MS-PL) 與 Microsoft Reciprocal License (MS-RL) 是由美商微軟公司 (Microsoft Corporation) 所編撰(註一),於 2007 年 10 月通過開放源碼促進會 (Open Source Initiative, OSI) 的審核,屬於符合開放源碼十項定義 (Open Source Definition, OSD) 的開放源碼授權條款(註二)。除此之外,自由軟體基金會 (Free Software Foundation, FSF) 也認可這兩份條款符合四大自由,是該基金會所認定的自由軟體授權條款(註三)。但由於這兩份授權條款制定的時間較晚,所以一開始知名度並不高,利用這兩份條款來開發軟體專案的社群參與者亦不多,原則上是以 Microsoft 自行釋出的軟體專案為主,不過由於 MS-PL 給予使用者相當大範圍的使用權利,因此漸漸地有不少開發者會利用 MS-PL 授權的軟體,使 MS-PL 這份授權條款的能見度與使用率逐漸攀升,因此本文將介紹 MS-PL 這份條款的重要內容,讓讀者對於來自傳統封閉大本營 Microsoft 所撰寫並推廣的自由開源軟體授權條款,有個概要的認識。而由於 MS-RL 與 MS-PL 是兩份架構相近的雙生條款,因此本文也將會針對 MS-RL 與 MS-PL 不同的重點特色加以說明(註四)。
Artistic License 2.0(以下簡稱 Artistic-2.0)這份條款並不像 GPL、LGPL、BSD 或 MIT 等條款如此地廣為人知,不過對於有在接觸 Perl 這個高階直譯式程式語言與相關專案的開發者來說,對於 Artistic 系列條款就應該一點也不陌生,因為第一版的 Artistic-1.0(註一)便是由 The Perl Foundation(TPF,註二)所起草,並且適用於 Perl 程式語言及其相關的軟體專案,不過由於第一版本的 Artistic 規定有些許模糊不清的地方,並且授權狀態不相容於使用比例較為普遍的 GPL 授權條款,所以 TPF 經過多年的討論與意見蒐集之後,於 2006 年正式發布細心修訂之後的 Artistic-2.0。
本文上篇的文章連接頁面如右:https://www.openfoundry.org/tw/legal-article-/8195-2010-11-22-18-38-45

【新版釋出、授權更改】

那麼、既然我們無法用事後撤銷的方式來改變已經釋出的自由軟體授權狀態,當日後專案有授權轉換的需求產生時,究竟應該透過怎麼樣的做法來達到授權變更的目的呢?目前實務上推行的方式,簡單來說就是八個字:「新版釋出、授權更改」。

更多文章...

第 10 頁, 共 26 頁

10