自由開源商用產品面對第三人專利問題的應對之方

本篇文章原載於自由軟體鑄造場的法律專欄,非常感謝Lucien共同撰寫,增加了這篇文章的深度。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

在自由開源軟體的商業應用過程中,軟體專利侵權的潛在風險一直是個受到矚目的議題,因為依各國著作權法及電腦程式保護專法的規定,著作權性質的保謢標的多是限定在著作的表現形式上,故而重新撰寫且完全不抄襲他人的程式碼,將有機會主張新創作的程式,是一個全新的創作,而不受到他人既定程式的著作權利拘束,這也是 GNU 計畫 (GNU Project: GNU is Not Unix) 當初設立起步的主要思維:透過群策群力的方式,不加抄襲但重新創作具 Unix 系統所有功能的全新電腦作業系統,來讓後續的應用不受到既定 Unix 作業系統的拘束;然而在專利權的領域裡,因為其保護的標的多為抽象,且可實施在不同載體的技術方法和步驟,故第三人專利的議題在自由開源商用領域可能引發的效應,往往讓商業使用者憂心,畢竟,自由開源軟體專案允許多人共工的模式,一方面確實是加速了軟體專案的開發效率與期程,然而,開發流程裡是不是有開發者誤用或因疏忽寫入第三人既存,且受軟體專利保護的演算法,而讓整體專案後續曝露在專利侵權的風險下,這方面的推論,理論上亦有可能成真。 閱讀全文〈自由開源商用產品面對第三人專利問題的應對之方〉

淺析自由開源軟體專案與其個別元件授權條款之差異

本文原刊登於自由軟體鑄造場的法律專欄

這是一篇有趣的文章,文章靈感來自於近日跟一位業界工程師所聊到的一段話,當時他表示有些自由開源軟體專案的授權還蠻複雜的,因為專案整體標示的是一種授權,但是裡面卻可能包含許多其他不同授權的程式碼,一不注意的話,可能就會誤解授權義務規定,而有侵權利用的狀況產生。這讓我想到,前一陣子處理的諮詢問題中,剛好也有開發者誤認元件授權條款跟專案整體授權條款一樣,最後必須置換元件的實例,因此而有了撰寫這篇文章的想法。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

有經驗的開發者在利用自由開源軟體時,會主動了解軟體專案所適用的授權條款,以遵守授權義務規定的方式來應用自由開源軟體。但是,不少開發者可能容易忽略的是,有些自由開源軟體專案裡,還可能包含或附帶與主專案框架不同授權條款的元件,若是應用專案的方式涉及到這些元件的話,便可能會在實際應用上產生完全不同的效果。

【個案實例】

1、關鍵引擎採用 LGPL-2.1 授權的 GPL-2.0 專案:VLC

這幾年很受到歡迎的多媒體播放器與其框架專案VLC,就是一個很顯著的例子。VLC專案整體採用 GPL-2.0 授權,但是為了讓 VLC 可以持續地被應用在 Linux、Windows、Mac OS X、Android 等不同平台上,該專案的開發者在 2011 年決定,要將 VLC 的關鍵引擎改用 LGPL-2.1 來重新授權(註一),這是因為 LGPL-2.1 對於函式庫的利用方式有著較為彈性的規定,使用者只要在合於授權規定的方式內,透過函式庫既定的介面來與其互動存取資料,則新開發出來的軟體,就可以適用非 LGPL-2.1 條款的方式來授權散布,甚至必要時也有機會採取封閉源碼的方式來授權新軟體。因此當開發者僅利用到 LGPL-2.1 函式庫或程式碼的話,就有著根據 LGPL-2.1 授權規定來開發私有軟體 (proprietary software) 的彈性空間(註二),但若是開發者確實是利用到整個 VLC 專案的程式碼,包括 LGPL-2.1 授權的函式庫,以及 GPL-2.0 的播放框架時,便可能必須一體遵守 GPL-2.0 的規定,因此時 GPL-2.0 授權的程式碼,也一併經引用而成為後續衍生專案不可分割的一部份了。

閱讀全文〈淺析自由開源軟體專案與其個別元件授權條款之差異〉