釋出源碼時常見的考慮因素與授權條款的選擇:以單一著作權人的軟體專案為例

最近接觸到一個想要釋出源碼的專案,該專案程式碼的著作權利全部歸屬於單一著作權人,因此這個專案可以選擇的自由開源授權條款很多,能變化出來的授權模式(licensing model)也十分多樣,不過由於著作權人的目的相當單純,主要就是希望釋出源碼。不過一個軟體專案釋出源碼還會產生附帶的效應,這些效應會隨著授權條款的改變有所不同,為此我簡單整理了一下採用自由開源模式授權出來的專案可能會產生哪些重要的效果,以及有哪些條款可以產生這些效果,內容不見得完整,但是可以用來初步了解一些常見的考慮因素與授權條款之間的關係。。

當然,每一個軟體專案的狀況不一樣,要考慮的因素也不盡相同,因此以下內容對於軟體專案著作權人單一或單純的情況較為適用,例如:著作權人僅有二人,而這二位著作權人剛好為好友,對於軟體專案未來的規劃想法一致,很容易取得共識。若是專案著作權人為不易產生共識的多數,又或者專案利用到GPL授權的第三方程式碼時等狀況,這時候本文內容的參考價值就沒那麼高。不過若是一個軟體專案還處在初期開發階段,是否採用第三方程式碼尚未確定,專案將如何被散布利用也還在規劃當中,本文的內容則可以在討論、選擇授權條款/模式時,一個蠻好的參考資料。

由於專利是另外一個專門的議題,因此這篇文章也沒有將專利授權納入考量因素之內。

最後,由於篇幅有限,因此以下內容並沒有針對個別授權條款的內容與特性多加說明與闡釋,對於個別授權條款的內容與性特請參見所附連結的文章。

1. 希望軟體專案具有快速的擴散性與高度的發展性

可以採用BSD、MIT、Apache-2.0這些單一條款來授權。

這些條款的特色在於使用者義務很少,僅有在散布的時候必須保留著作權聲明與免責聲明,但是並沒有義務一定要將程式源碼提供給予取得程式的後手。由於義務規定如此少,因此這些條款授權的軟體很適合用來開發閉源的商業產品。Windows作業系統中有應用許多自由開源軟體 (FOSS),這些FOSS大多都是BSD、MIT或Apache-2.0等條款授權的。不過相對地,這樣的授權特性雖然有利於專案的散布,但也同時便利其他開發者修改後發展出其他的應用或功能。

BSD介紹:
http://www.openfoundry.org/tw/legal-column-list/524–bsd

MIT介紹:
http://www.openfoundry.org/tw/legal-column-list/513–mit

Apache-2.0介紹:
http://www.openfoundry.org/legal-column-list/8581-the-elaborate-license-apache-20?lang=tw

閱讀全文〈釋出源碼時常見的考慮因素與授權條款的選擇:以單一著作權人的軟體專案為例〉

GPL 與常見授權條款相容性淺析

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

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

GPL 是被廣泛採用的自由開源授權條款,不過由於 GPL 具有授權拘束性,衍生程式必須仍然適用相同條款授權(註一),所以在利用上會需要注意與之結合的程式碼授權內容是否相容,因為與之結合的程式碼一旦成為 GPL 衍生程式,就代表著在散布時必須要透過 GPL 條款來授權散布,若是其原本的授權內容與 GPL 不相容,會讓使用者無法同時符合兩份條款的義務規定,進而可能發生侵權利用的狀況。

因此本文將以 GPL-2.0 與 GPL-3.0 這兩份授權條款為中心,來說明目前常見授權條款是否與之相容,進而讓讀者了解哪些常見授權條款的程式碼可以與這兩份 GPL 條款的程式碼結合之後一起散布(註二)。

LC_201401_img1
▲ 圖1:GPL 衍生程式結構示意圖。

閱讀全文〈GPL 與常見授權條款相容性淺析〉

自由開源軟體預設的不附隨保證與擔保特性

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

在我跟Lucien所進行的企業演講中,通常一開始會先說明自由開源軟體的基本授權特性,而在經過多年的討論與反芻之後,目前我們歸納出來的自由開源軟體授權特性有六項:

  1. 開放程式源碼
  2. 不限制授權對象與使用地域
  3. 不收取授權金
  4. 授權不可撤回
  5. 不附隨擔保
  6. 釋放四大自由給予後手

不過並非每一項特性都有專論文章來說明,此外又或者是即使有相關主題的文章,但是由於早期撰寫文章時,對於跟主題相關內容的掌握度並不夠,所以文章內容並不完整,所以我從2013年11月開始,針對這六大特性來撰寫法律專欄文章,補強過去所有沒有談到的內容,因此2013年11月的「從開放源碼的理想到提供源碼的義務」就是針對第一個特性所撰寫的文章,而2013年12月所撰寫的這篇文章則是針對第五個特性。

接下來幾個月應該還會有這樣的文章出現,也許下一篇會寫跟第三個特性有關的文章吧!

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

自由開源軟體在散布的過程中,並不收取使用上限定時間、範圍,與對象的授權金(註一),而雖然非授權金性質的其他收費名目是可以要求的,但在大部分的狀況下ー例如透過公開的網路空間平台提供下載,也不會收取其他費用,也就是原則上,自由開源軟體的授權人並不會因為散布自由開源軟體獲得任何的金錢利益,因此相對地,這些授權人並不承諾自由開源軟體的功能一定完美無缺、不會造成使用者有任何損失。這種不附隨保證或擔保承諾,是自由開源軟體的一大特性。不過,這樣的特性,並不等於自由開源軟體的授權人或使用者,可以免除遵守各國法律的強制規定與禁止規定,因此,當授權人或使用者違反法律的強制規定與禁止規定時,還是一樣必須依照法律的要求來負擔一定的責任。本文以下將會針對自由開源軟體這種不附隨保證與擔保的特性加以說明,同時也將舉例說明違反強制、禁止規定的狀況,以協助讀者更進一步了解自由開源軟體的授權特性。

閱讀全文〈自由開源軟體預設的不附隨保證與擔保特性〉

從產品租賃來看 GPL 的散布定義與範圍

此篇文章原載於自由軟體鑄造場網站上的「法律專欄」,與林誠夏共同撰寫完成。

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

GPL 授權條款有著許多不同於傳統軟體授權方式的相關規定,其中散布程式的時候必須提供源碼的規定,則是影響最大、也最常被違反的一項。這項義務與其他 GPL 條款中所規定的義務一樣,都是透過散布行為而被開啟,也就是說,程式被利用或移轉的方式若不是 GPL 條款所定義的散布行為,散布者就可以自由選擇是否要去遵守其他後續的相關義務規定。因此散布的內涵有著左右 GPL 義務規定是否被啟動的重要地位。

在單純的例子裡,大家都可以輕易理解什麼是散布,例如甲從網路下載了 GPL 程式 A 之後,再將程式 A 拷貝到朋友乙的電腦中,這時候程式 A 就是從甲的手中被散布到了乙的手中,因此依照 GPL 規定,甲負有將程式 A 源碼提供給乙的義務。但是隨著資訊科技的發展與商業交易行為的多樣化,使用者可能在利用銀行自動化設備與租借嵌入式裝置的同時,而間接利用到、或者甚至間接占有了 GPL 程式一段期間,例如前一陣子才停止網路電視服務的壹多傳媒,該服務出租網樂通機上盒給予客戶,客戶只要自行將顯示螢幕與網路線接到機上盒,就可以收看所提供的網路電視節目,這個機上盒為嵌入式的 Linux 作業系統,有利用到很多 GPL 程式,但是壹多媒體在最初時並沒有釋出機上盒的程式源碼,因而引發後續爭議,就是一個典型的例子。這種透過出租產品與提供服務,所造成程式碼移轉的行為,是否也屬於 GPL 所規定的散布程式碼的行為?針對這個問題,本文將會針對目前被廣泛採用的 GPL-2.0 與 GPL-3.0 說明相關規定,並嘗試釐清問題的癥結點,期望可以拋磚引玉的讓大家對這個議題,有一些基本的認識。

閱讀全文〈從產品租賃來看 GPL 的散布定義與範圍〉