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

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

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

因應網路時代與雲端應用而生的 AGPL-3.0 授權條款

此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文結尾所給予的建議。

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

GNU Affero General Public License 3.0 (AGPL-3.0) 是自由軟體基金會於 2007 年 11 月 19 日所發布的一份自由開源軟體授權條款(註一)。這份授權條款與 GPL-3.0 為孿生條款,因為這兩份條款僅在第 13 條有所不同,其餘的規定則一模一樣。但這第 13 條的不同差異處,就讓 AGPL-3.0 與 GPL-3.0 的拘束特性有著很大的分別,這也讓許多提供網路服務的公司對於這份條款避之唯恐不及。但 AGPL-3.0 在使用上真的如此令人恐懼?其中的條款內容究竟如何?在利用自由開源軟體元件的同時,又應該以什麼樣的態度與立場來面對 AGPL-3.0?本文將會針對這些問題一一說明 。

閱讀全文〈因應網路時代與雲端應用而生的 AGPL-3.0 授權條款〉

如何提供 GPL 元件的程式源碼

GPL 授權條款制定的目的,是希望人人都可以研究、修改與散布程式,為了要達到這個目的,取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下,也有可能透過逆向工程來將程式還原到源碼的形式,但這畢竟非常不便,也不是常態,很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中,提供程式源碼是一項非常重要的義務,針對程式的研究與修改,透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者,都可以順利取得相對應的程式源碼,GPL 設有一套規定散布者如何提供程式源碼的規定,來保障這些源碼可以持續地被後手取得。

此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文所給予的修正。

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

GPL 授權條款制定的目的,是希望人人都可以研究、修改與散布程式,為了要達到這個目的,取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下,也有可能透過逆向工程來將程式還原到源碼的形式,但這畢竟非常不便,也不是常態,很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中,提供程式源碼是一項非常重要的義務,針對程式的研究與修改,透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者,都可以順利取得相對應的程式源碼,GPL 設有一套規定散布者如何提供程式源碼的規定,來保障這些源碼可以持續地被後手取得。

閱讀全文〈如何提供 GPL 元件的程式源碼〉

自由開源軟體侵權警告與因應流程

希望這篇文章可以幫助到想要了解如何面對侵權警告的人,進而在未來可以正確合法地利用自由軟體。此外,文章架構雖然是與Lucien一起討論出來的,不過Lucien才是主筆,我只有負責部份的潤飾工作而已,因此第一作者是Lucien

++++++++++++++++ 文章開始 ++++++++++++++++

自由開源軟體雖然可以被自由地修改與散布,但其仍然是受到著作權保護的客體,所以若是使用者的利用方式不符合其授權條款所預設的遊戲規則,嚴重時仍然會引發後續的司法訴訟與糾紛。然而、其實許多爭端在開始時仍然具有溝通協商的空間與可能性,本文主要便是就自由開源軟體被不當利用時,所可能收受到的警告信內容來進行披露,並對後續的處理方式,做一個概念的引導及處理流程的建議。

閱讀全文〈自由開源軟體侵權警告與因應流程〉