淺論程式源碼與目的碼在自由開源軟體授權條款裡的同與異

本文原刊於自由軟體鑄造場的法律專欄,一樣是與Lucien共同撰寫,尤其感謝Lucien的補充潤飾,讓整篇文章的內容有趣、易讀多了。

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

程式源碼 (Source Code) 與目的碼(Object Code,註一)是軟體程式存在的兩種基本型態,前者指的是電腦程式可供後續增編修改的格式,有時可被直接執行,但多半時候必須經編譯或界定程序之後才能被執行,後者則是能夠直接供電腦機器判讀的執行檔格式,但因已經過編譯程序,故除非經過反組譯或是還原工程,否則一般人無法直接觀察目的碼,來了解該電腦程式的演算過程及運算邏輯 (algorithm)。一般來說,軟體程式可以擇一或是同時透過這兩種型態來被散布,就法律論理上,其在著作權法上是被視為是同一作品不同形態的表現,故其表現形式雖不同,但法律定位完全相同。過去電腦程式目的碼是不是能受到著作權法保障是有疑慮的,畢竟這樣的著作格式並不如同一般受著作權保護的客體:詩、詞、書、畫、文章、音樂、電影般,能被直接閱讀、聆聽、感受,和了解,不過美國於 1983 年 Apple Computer, Inc. v. Franklin Computer Corp. 一案中,承審法官在反覆的論理之後,判定目的碼亦為美國著作權法保護的客體之一,同時,因其無法為人類直接了解之故,更進一步認定其與程式源碼具有同一性關係(註二)。此一判決也影響其他各國就此議題的認識,此後多數法律見解皆偏向於將程式源碼與目的碼,視為電腦程式的一體兩面,故表現的方式雖有差異,但被著作權法保護的本質與地位相同。這樣的解讀態度適用在一般私有軟體 (proprietary software) 上,固然不會有太大的問題,畢竟私有軟體在授權使用上的基本規則為「權利人保留所有權利 (all rights reserved)」,故使用他人電腦程式時,未經授權方同意的方式,基本上都是不被法律所允許的,然而,許多的自由開源軟體 (Free and Open Source Software) 專案及其授權條款,蘊含著一種盡量將程式源碼提出來讓後手使用者增刪修改並便利應用的態度,故在其授權條款中,可以看到許多的內容是明確地針對程式源碼或目的碼所作的,略有差異的義務性要求,此項特點多為一般使用者所不知或忽略,而這方面的資訊,也正是本文希望透過特定條款的例示與說明,所要傳達給大家的。 閱讀全文〈淺論程式源碼與目的碼在自由開源軟體授權條款裡的同與異〉

[簡報] COSCUP 2014

今年在 COSCUP 2014 的演講意外地有兩場,一場是我自己本來就預計要投的,說明如何尋找授權資訊,另外一場則是跟NVidia的法務Helen Tieh一起進行。後者是個意外,因為一些機緣認識了Helen,而又因為跟她聊到台灣這邊的自由開源活動,提到COSCUP,聊到最後竟然就聊出了一場演講來,兩人後來為了講什麼題目、如何分配時間、協調兩人的內容等等也花了不少時間討論。

【7/19】

題目:穿越灌木叢林找到授權資訊 Make a Painstaking Investigation to Find Out the Accurate Licensing Statements of FOSS Projects

pdf檔:http://www.slideshare.net/tmk2005/20140719ls-37181327
odp檔:http://www.slideshare.net/tmk2005/20140719ls
授權:CC-BY 3.0 unported – http://creativecommons.org/licenses/by/3.0/ 閱讀全文〈[簡報] COSCUP 2014〉

正確尋找自由開源軟體的授權資訊

這篇文章與Lucien一起撰寫完成,原載於自由軟體鑄造場的法律專欄中,是因應我投稿COSCUP2014演講主題而寫的,不過由於撰寫期間一堆工作撞在一起,所以撰文時間很短、完成度不高。在COSCUP2014的演講中,我有額外增加了一些簡單的搜尋挫敗實例,比較有趣、易懂些,不過這篇文章就沒有這些簡單實例的說明了。

COSCUP2014 的演講簡報可以到這篇文章來下載。

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

利用自由開源軟體元件來開發自己專案的好處在於,使用者只要能了解所取用元件的授權方式,便可以毋須重新撰寫,而逕予取用這些元件,作為新專案的基石,並在既成的成果上,據以更深入的開發自己所需要的功能!然而,由於許多自由開源軟體的授權元件,開始時多是由網路志工和社群成員自發性的投入撰寫,所以雖然開發者本身,非常願意透過某一個選定的自由開源軟體授權方式來傳遞和分享這些程式碼,但卻極可能在編撰的過程中,未能明確地標示相關程式碼的授權資訊,也或者標示的方式,隨著專案與開發者的不同而有所改變,對於不少使用者來說,找到正確的授權資訊並據以安心的利用,並不是一件容易的事情。但是在這些看似雜亂的標示中,其實仍然有一些基本規則可以依循。本文會就辨識授權資訊的基本規則加以闡釋,並針對常見的問題與標示不清的狀況加以說明,讓讀者可以大要了解,如何在茫茫的軟體程式碼與各項說明資訊中,找到特定自由開源軟體元件正確的授權資訊! 閱讀全文〈正確尋找自由開源軟體的授權資訊〉

第一份中文版自由開源授權條款「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」草稿淺析〉

《失根的年代》之一:藍色的烙印

我出生在民國六十年代初期,是一個生長在政治傾向深藍家庭的小孩,我的童年與青少年時期是在台灣的戒嚴之下度過。我記憶的總統是蔣經國,而我當年在念國中時,女生的頭髮必須剪到在耳上一公分才算及格。這個藍色的烙印嵌入我靈魂的深處,伴隨著我到目前為止四十多個年頭,不時地在我的生命中浮現出來。

我的父親是位退伍軍人,同時也是黃復興黨部(註一)的黨員,他一生忠黨愛國,對於中國共產黨、民進黨與台獨思想等,是深惡痛絕。在政局與社會動盪不安的民國三十年代,為了讓自己可以三餐溫飽,還是個十五、六歲毛頭小子少的父親,也跟許多人一樣去從軍,並隨著國民政府一起遷徙到了台灣。在數十年軍旅生涯的影響下,即使父親非常聰穎,也喜歡閱讀各類書籍,但是個性也不免變得封閉、權威與不知變通,因此父親與家人的溝通方式不是雙向,而是是單向,他的決定就是溝通對象的決定。他對於我的家庭管教訂一些規矩:小三開始到小六畢業為止,每天練書法一小時;到國中畢業為止,每天9點必須上床睡覺;到大學畢業為止,不能交男朋友,不能打工;大學寒暑假在家住的期間,不能在外過夜,必須回家睡覺(註二)。他對於「民主」、「自由」等概念的理解,是來自於主動閱讀與自我思考延伸的結果。還記得我還是小學生的時候,有次學校要調查學生家庭背景狀況,問卷調查表上密密麻麻一堆字,有許多我不知道該如何回答的問題,我因此拿回家給父親看。那張大紙上的問題我至今都忘了,除了一題:家中的管教方式?答案有有民主、權威等等幾個選項,當時的我並不理解什麼是權威、什麼是民主,不過父親直接告訴我勾民主,因此,我在父親的指示下乖乖地勾了民主。當時我滿心歡喜,覺得自己有個民主的父親,真是件非常值得驕傲的事情! 閱讀全文〈《失根的年代》之一:藍色的烙印〉

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

本文原本刊登在自由軟體鑄造場的法律專欄,主筆是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 與常見授權條款相容性淺析〉