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

最近接觸到一個想要釋出源碼的專案,該專案程式碼的著作權利全部歸屬於單一著作權人,因此這個專案可以選擇的自由開源授權條款很多,能變化出來的授權模式(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 與常見授權條款相容性淺析〉