第一份中文版自由開源授權條款「COPU 開源公共許可協議 v.1.0」草稿淺析

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

感謝Lucien在本文寫作期間參與討論。

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

上週,中國開源軟件推進聯盟(China OSS Promotion Union, COPU,註一)發布了「COPU 開源通用許可協議 V.1.0(以下簡稱「COPU-1.0」,註二)」的草稿,整份授權條款由簡體中文撰寫而成,為全球第一份中文的自由開源授權條款,因此本期的法律專欄將對 COPU-1.0 草稿做一個概要的介紹。不過由於中國大陸的用語跟台灣有所不同,為了避免辭彙轉換過程無法精確表達原簡體中文的詞意,因此本文在涉及說明 COPU-1.0 草稿內容時,將優先採用草稿中的用語,還請讀者自行參照本文末所附的辭彙對照表,來了解 COPU-1.0 草稿中辭彙相對於台灣的一般用詞(註三)。

【草擬背景與目的】

根據中國開源軟件推進聯盟官方的新聞稿(註四),由於中國當地社群對於既有的自由開源授權條款大多不了解,許多專案並不知道該如何選擇授權條款,而即使選擇了,可能也不是那麼切合該專案的狀況,導致在後來的運用上產生了一些問題;此外,目前常見的自由開源授權條款均是以英文撰寫而成,這對於中國大陸的社群成員來說並不容易了解,同時在商業運用上也發生過,因為企業審核英文授權條款的時間較長,而導致自由開源專案與企業的合作時程必須推延二個月的狀況。鑑於這些問題,因此中國開源軟件推進聯盟與北大法學院專家合作,制訂出 COPU-1.0 的草稿,一方面協議採用中文撰寫,解決英文所造成的隔閡問題,另外一方面,目前公開草稿內容、徵求當地社群成員意見,期望透過這樣的互動,來提升中國大陸社群對於智慧財產相關議題的關注。

閱讀全文〈第一份中文版自由開源授權條款「COPU 開源公共許可協議 v.1.0」草稿淺析〉

簡論自由開源軟體的著作權適格及其態樣

本文原本刊登在自由軟體鑄造場的法律專欄,主筆是Lucien,以Lucien之前為”IFOSS Law Book“第二版所撰寫的「台灣專章」為基礎來延伸撰文,我負責閱讀與提供德文資料、共同討論與潤飾文字,因此Lucien為本文的第一作者。

這篇文章以大型的自由開源軟體專案(Free and Open Source Software Project, FOSS Project)為客體,討論FOSS Project應該屬於我國著作權法上的的哪一種著作型態:共同著作?衍生著作?抑或者是編輯著作?FOSS Project對應到這些不同的著作型態會產生結構不同的著作權人組成與著作權保護期間,但是這樣的問題並沒有被充份討論過,因此這篇文章嘗試進行這樣的邏輯分析。

文中提到德國著作權法第9條結合著作(Compound Work/Collective Work),是一個台灣著作權法所沒有的著作型態,但是我覺得相當適合套用在大型、融合許多第3元件的FOSS Project上,若是要為自由開源軟體在台灣著作權法上爭取一個明確身份的話,德國著作權法這樣的規定相當值得參考。

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

林誠夏、葛冬梅/文

自由開源軟體專案 (Free and Open Source Software Project, FOSS Project),其在著作權法上的保護地位,與一般電腦程式無異,因電腦程式受法律保護所必須具有的創意性與科學性,在 FOSS Project 上一項也不缺少,然而,FOSS Project 的撰寫與創作過程,卻迥異於一般傳統的私有軟體 (proprietary software),以至國際間許多與自由開源軟體相關的司法訴訟,其在進行初始法律關係的分析時,亦不乏從其著作權類型如何歸屬討論起,例如 2011 年德國柏林地方法院 AVM vs Cybits 一案的判決,便曾在言詞辯論時,就嵌入式韌體裝置上各元件應歸類於哪一種著作類型而展開討論(註一)。 閱讀全文〈簡論自由開源軟體的著作權適格及其態樣〉

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

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

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

從自由開源軟體授權看庶民式法律時代的開展契機

這一陣子因為太陽花學運有感,因此與Lucien共同完成了這篇文章,寫作時間有些倉促,內容也許諸多不周,歡迎批評指教。

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

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

黑白兩分的解讀模式,通常並不十分適用於自由開源軟體授權條款 (Free and Open Source Software license, FOSS license) 的內容解析,因為其論理與轉譯之間,常有灰色難以完整譯解的區段。對於單方面的軟體工程師或是法律從業者,可能在理解與應用上都不是那麼容易上手,這是因為許多著名條款的編撰過程,是透過科技人與法律人不間斷的對話,而共同修訂出草稿,再經過反覆的辯論與釋疑,才逐步達到共識完成定稿。著名的 GNU GENERAL PUBLIC LICENSE Version 3 (GPL-3.0) 是如此;而在開放內容領域方面國際化的「創用CC 授權條款 (Creative Commons License)」,亦是透過此種不斷調整對話的方式來完成編撰!可以說,要真正透徹了解自由開源軟體授權條款的內容與細節,必須兼有軟體工程學與法律學上的基礎知識,而除此之外,部份的自由開源軟體授權條款及其共工模式還有一個特點,是使用者單單觀察條款本身所可能忽略掉的,就是這些公眾授權條款雖然具有一般傳統法律文書的外觀,論其本質與撰寫過程,卻具有從下到上,草根性民主參與的反轉意義。

Clay Shirky- How the Internet will (one day) transform government - Talk Video - TED_1395719295526
▲ 圖1:”How the Internet will (one day) transform government” by Clay Shirky in TEDGlobal

閱讀全文〈從自由開源軟體授權看庶民式法律時代的開展契機〉

自由開源軟體不收取授權金之特性

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

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

不收取授權金是自由開源軟體的一大特性,這其中牽涉到的智慧財產權種類包括了著作與專利兩類,雖然法律專欄在過去發表過許多相關的文章,不過都是屬於細部的分析,並未有統合性的介紹,也沒有對於這個特性形成的緣由加以說明,因此本文將針對這些過去所未說明過的部份進行統合性的介紹,同時針對常被併同提起的商標權加以說明,供想要深入了解自由開源授權特性與成因之讀者參考。

閱讀全文〈自由開源軟體不收取授權金之特性〉

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月所撰寫的這篇文章則是針對第五個特性。

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

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

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

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

自由開源軟體侵權爭端案例文章彙整

近來在整理法律專欄中,跟自由開源軟體侵權相關的文章,也同時將鑄造場網站上相關的新聞報導也做了整理。在鑄造場工作了這麼多年,雖然沒有一案不漏地介紹過所有侵權爭端案例,不過重要的案件都沒有漏掉。只是其中有些文章沒有做後續更新,因此資料仍是舊的,是比較可惜的地方。

【新聞報導】

一、BusyBox 侵權案件(違反GPL)

「Monsoon Multimedia 與 BusyBox 的 GPL 侵害訴訟達成和解」
http://www.openfoundry.org/tw/foss-news/1287

「SFLC 控告 Verizon 違反 GPL 散佈開放源碼軟體」
http://www.openfoundry.org/tw/foss-news/1334

「BusyBox 開發者與 Xterasys 取得 GPL 侵權訴訟和解」
http://www.openfoundry.org/tw/foss-news/1353 閱讀全文〈自由開源軟體侵權爭端案例文章彙整〉

從開放源碼的理想到提供源碼的義務

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

過去在為商業公司的員工進行教育訓練課程時,都會介紹自由開源軟體具有「開放程式源碼」的授權特性,講久了,卻發現關於這一個特性卻沒有寫過介紹文章,所以才興起了我要撰寫這篇文章的念頭。不過寫完之後才發現,這篇文章不僅是在釐清「開放源碼」與「提供源碼」這兩個概念,也順便將自由軟體到開放源碼的歷史做了一個簡要的介紹,所以若是有人想要快速了解從四大自由到開放源碼間的歷史由來,本文可以當作一個入門的文章來閱讀。

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

開放源碼(Open Source,註一)是現在許多人在接觸自由開源軟體時,第一個會接觸到的詞,它代表此類程式在散布時,皆能夠從散布者手上取得程式源碼。不過常見到的是,部份使用者會將這個詞,誤解為使用自由開源軟體所必須遵守的義務,認為一旦取得、持有自由開源軟體就必須主動公開手上所持有的程式源碼。其實開放源碼理想與提供源碼義務是兩個不同、但有所關聯的概念:開發者因為認同自由開源軟體理念,而主動公開其所撰寫的程式源碼,並授權給予他人來利用,所以他人才有機會以更深層的方式,利用到其所散布的自由開源軟體,這是屬於實踐開放源碼理想的過程;而當使用者取得自由開源軟體的程式源碼,部份條款要求其得在散布軟體的同時提供源碼給予後手,則是屬於履行授權義務的過程。本文以下將從自由軟體與四大自由談起,介紹相關的歷史背景與授權條款中提供源碼義務的內容,來說明開放源碼與提供源碼所代表的意義,以釐清兩個概念之間的關係。 閱讀全文〈從開放源碼的理想到提供源碼的義務〉

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

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

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

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

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

【個案實例】

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 授權的程式碼,也一併經引用而成為後續衍生專案不可分割的一部份了。

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