降低開源授權爭訟風險的三大要點

這篇基本是由Lucien主筆，我則是參與架構跟內容討論、以及最後的修校，原文發表在原文發表在由軟體鑄造場的法律專欄。

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

近十年來，自由開源授權軟體元件 (Free and Open Source Software, FOSS) 被大舉運用到商業應用的環境裡，然而，FOSS 的授權規則，亦相當程度賦含了自由分享的理念，故其中不少義務性要求與條件，並不能全然依照傳統商業授權的定式與慣習來進行，而若取之為應用的商業公司過於疏忽了義務性要求方面的條件，在貢獻者與商用者立場產生嚴重期待落差時，難免會引發原始權利人出來主張其開源授權的成果遭到濫用，進而提升到法庭上授權爭訟的衝突狀態。因為如此，許多 FOSS 商業應用者無不自問：究竟應該完成哪些義務性條件的遵守，才能有效降低開源授權爭訟的相關風險？這樣的問題，多數 FOSS 的研發社群朋友，並不會給過予一個界限分明的答案，一來並非所有 FOSS 專案撰寫的程式開發者，都能清楚依據著作權法主張其權利範圍與義務要求，二來許多程式開發者，更重視的是開源取予協調 (give and take) 的尊重與感受，故其並不想要在相關議題上過於闡釋，以免對 FOSS 專案的互惠分享範圍自我設限（註一）。然而，自由開源軟體授權條款的型態甚多（註二），其相關的義務性要求亦有些許分殊，若是能有更簡便的要項能夠遵守，則亦將有助於降低開源授權爭訟的相關風險，故本文依據司法實務以及所能接觸到的和解資訊，整理以下三大要點，提綱挈領地進行資訊分享。 閱讀全文〈降低開源授權爭訟風險的三大要點〉

開放字型授權條款 OFL-1.1

CC_BY-NC-ND.svg

20240405補充：

這幾年來網誌疏於管理，所以直接留言詢問OFL-1.1的問題我也沒有回應。未來應該會多花些時間在網誌上，不過這不代表我能夠回答所有的問題：在時間與能力範圍允許的狀況下我會回應，若是沒有回應到的網友，也還請諒解我個人的時間與能力有限。

~~~~~~~~ 以下原文開始 ~~~~~~~~

之前既然將條款英文解譯成為中文內容，索性就寫了文章介紹一下OFL-1.1的內容，原文發表在由軟體鑄造場的法律專欄。在華文世界中，字型一直是很重要，但仍然有許多問題的一塊領域，也許往後該多花點時間來關注，也多寫些相關的文章。

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

在資訊科學領域中，電腦字型是相當重要的一環，因為許多軟體的功能都必須依靠著電腦字型的呈現，才可以被一般使用者順暢地了解與用，缺少了使用者可以了解的字型，這些軟體的應用範圍將大為受限。但是由於字型的特性與應用方式跟軟體程式並不相同，是自成一格的專業領域，因此相對於軟體程式碼來說，字型的授權內容較少被討論，適合用來授權字型的自由開源條款也非常稀少，也因此我們會看到有些字型是直接適用 GPL、Apache-2.0 等授權條款來釋出。不過 GPL、Apache-2.0 這些授權條款原本是以程式碼為客體所制定出來的，其中的內容並無法完全直接套用到字型的應用情況，常常必須透過專業人士的額外解釋，才能夠釐清使用者如何做才是遵守授權規則。為此，開始有組織制定出專門適用於字型的授權條款，以避免這種將程式碼授權條款應用到字型上的水土不服症狀。本文所要介紹的 SIL Open Font License（OFL，註一）就是一份專門適用於電腦字型的授權條款，OFL 承襲了自由開源的自由精神，並且針對字型的特有的應用情況來加以規範，並且提供了詳細的說明文件，因此是一份從內容本身到週邊資訊都非常完整翔實的字型授權條款。 閱讀全文〈開放字型授權條款 OFL-1.1〉

不負責任之一氣呵成OFL-1.1中文解譯

創用 CC 授權條款

本中文解譯僅在於輔助中文母語者了解OFL-1.1，並非是官方認可的內容。OFL-1.1官方認可的語文版本是英文版，因此在發生侵權糾紛時，將是以英文版為解決糾紛的依據規定。

======

以下OFL-1.1的中譯文乃是一氣呵成寫完，沒有任何的檢查，說不定還有錯字，不過先丟到網誌來，給自己做個紀錄。

另外，翻到最後一段免責聲明部份，很偷懶地用 …… 帶過，一方面因為免責聲明大同小異，二方面因為這部份幾乎都是採用美國法下的授權免責用語，拗口的要命，翻成中文連我自己也看不懂，還需要另外的白話文來解釋這些文字所代表的法律意義，因此我就省略這部份不翻了。

OFL-1.1全文：http://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web
OFL-1.1的FAQ：http://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ_web
OFL官網：http://scripts.sil.org/OFL

~~~~~~~~~~ 本文與譯文開始 ~~~~~~~~~~

Copyright (c) <dates>, <Copyright Holder> (<URL|email>),
with Reserved Font Name <Reserved Font Name>.
Copyright (c) <dates>, <additional Copyright Holder> (<URL|email>),
with Reserved Font Name <additional Reserved Font Name>.
Copyright (c) <dates>, <additional Copyright Holder> (<URL|email>).

（以上為著作權聲明區塊，慣例上均採用英文，內容也不難，因此未轉為中文。） 閱讀全文〈不負責任之一氣呵成OFL-1.1中文解譯〉

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

本文原刊於自由軟體鑄造場的法律專欄，一樣是與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

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