受保護的內容: COSCUP 2024 演講：GPL 授權條款的典型侵權糾紛
受密碼保護的文章不會產生內容摘要。
標籤: FOSS
舊文重新上架 << 從 Copyright 到 Copyleft：GPL 的誕生、成長與未來 >>
有社群朋友在 2022 年 6 月跟我詢問這篇文章何處可以下載,由於鑄造場
網站上的下載連結已經失效,因此我找出塵封的文章,更新了聯絡的 email 與
日期後,將此文章放在我的網誌上供有興趣的人下載。
若沒記錯，這篇文章是應該是是 2005 年完成的，當年剛開始在自由軟體鑄造場工作，一群人豪情壯志地想要出一系列自由開源軟體相關的書籍，不過最終只有規劃中的第二本完成了內容。
第二本是以法律的角度來談自由軟體，透過不同作者、不同主題、不同角度，來帶領讀者了解自由開源軟體在法律面所呈現出來的態樣。原書預定的第三篇就是我的這篇文章，目的在於透過盡可能的白話文字來讓一般人也可以概要了解 GPL 第二版授權條款 (GNU General Publice License Version 2.0, GPL-2.0) 的內容。
但是礙於諸多因素，這本書最終沒能付梓印刷成實體紙本，所以到了 2006 年中，我們將書的內容放到了鑄造場的網站上，經所有作者同意採用「創用CC 姓名標示－非商業性－禁止改作 授權條款 台灣 2.0 版」來散布，希望可以讓有需要的人閱讀到這些內容。不過後來鑄造場計畫結束，OpenFoundry 網站在一段時間之後也無法正常維護，所以這本書文章的下載連結內容均已遺失，無法真實下載到文章內容，只能瀏覽書的單篇文章標題：
https://www.openfoundry.org/tw/events-and-conferences/cat_view/214-/209-/231-2005-ossf-books
近來有社群朋友向我詢問這篇文章，所以我將當媽之後幾乎塵封的硬碟翻了出來，尋著當年的資料夾架構邏輯，找到了許多不甚合乎邏輯的相關檔案名稱，最終確認翻出了這篇文章。十分感謝 Lucien C.H. Lin 定期幫我更換儲存硬碟，所以文章內容至今完好無缺。
這篇文章撰寫完成於十多年前，雖然在這段時間的相關用詞、觀念、實務發展與現實環境都有很大的轉變，但是由於沒有時間琢磨內文修改刪增，因此內文還是跟當年一樣，只有加上一些額外的說明文字與更新資訊，特此說明。
最後歪樓的感謝一下這位詢問文章的社群朋友，讓我在這麼多年後再度更新了一篇網誌！
多重自由開源條款授權軟體之條款選擇與授權標示
這幾年的諮詢回覆中，關於多重自由開源授權模式的問題增多，其中很多人都會附帶問到產品中該如何標示才好，因此這次就將如何選擇條款與相關的授權標示一併加以說明。原文發表於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
常接觸自由開源軟體的讀者應該都聽過雙重授權 (dual-licensing) 或多重授權 (multiple-licensing) 模式，也就是一個自由開源軟體透過多份不同的條款來授權散布，而軟體的使用者因此可以選擇最貼近自己需求的條款來後續散布這個軟體。這樣的多重授權模式常被應用在商業化利用的自由開源軟體上，最常看到的條款組合模式是以一份 GPL 類條款搭配商業授權條款來釋出，由於 GPL 類條款具有較為嚴格的授權拘束性，衍生程式的源碼必須在散布時也同時提供出來，對於不能履行這項義務的使用者來說，這時候就必須選擇洽談商業授權內容，在給付一定的授權金之後，使用者就可以獲得散布衍生程式無需提供源碼的授權條款。因此在這種「GPL 類+商業條款」的多重授權模式下，使用者通常只需要確認衍生程式源碼是否可以在散布時提供出來，就能決定要採用哪一種授權條款，而在相關產品的授權資訊標示上也因此相對地單純（註一）。不過在多重授權模式中，還有一種的態樣是透過多份自由開源授權條款來散布，在面對這種多重自由開源條款授權的軟體時，使用者條款在選擇條款的考量標準與授權標示上，均與上述「GPL 類+商業條款」的典型略有不同，因此本文將從多重自由開源條款授權的緣由談起，來說明在面對這種軟體時，可以採用什麼樣的基本態度來選擇條款，以及如何適當地標示後續散布的授權聲明內容。 閱讀全文〈多重自由開源條款授權軟體之條款選擇與授權標示〉
受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析
這篇文章原本刊登於自由軟體鑄造場的法律專欄，感謝Lucien對本篇文章所提供的意見。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
所謂的受雇人，簡單來說，就是在一間公司或組織聘用來在負責一定職務工作的員工，因此受雇於一間公司來專職開發軟體、韌體的工程師，就是受雇人，而該公司就是雇用人（註一）。若是這間公司利用 GPL 元件來開發產品，軟體工程師可以自由散布產品程式碼嗎？工程師在產品中所撰寫開發的程式碼，其權利是屬於工程師本身、還是該公司？這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時，可能會產生的，因此本文將先從著作權法相關的規定談起，並且說明實際雇傭關係的運用狀況，進而釐清這些可能的疑問。 閱讀全文〈受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析〉
不負責任之一氣呵成OFL-1.1中文解譯
本中文解譯僅在於輔助中文母語者了解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 的演講簡報可以到這篇文章來下載。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
利用自由開源軟體元件來開發自己專案的好處在於，使用者只要能了解所取用元件的授權方式，便可以毋須重新撰寫，而逕予取用這些元件，作為新專案的基石，並在既成的成果上，據以更深入的開發自己所需要的功能！然而，由於許多自由開源軟體的授權元件，開始時多是由網路志工和社群成員自發性的投入撰寫，所以雖然開發者本身，非常願意透過某一個選定的自由開源軟體授權方式來傳遞和分享這些程式碼，但卻極可能在編撰的過程中，未能明確地標示相關程式碼的授權資訊，也或者標示的方式，隨著專案與開發者的不同而有所改變，對於不少使用者來說，找到正確的授權資訊並據以安心的利用，並不是一件容易的事情。但是在這些看似雜亂的標示中，其實仍然有一些基本規則可以依循。本文會就辨識授權資訊的基本規則加以闡釋，並針對常見的問題與標示不清的狀況加以說明，讓讀者可以大要了解，如何在茫茫的軟體程式碼與各項說明資訊中，找到特定自由開源軟體元件正確的授權資訊！ 閱讀全文〈正確尋找自由開源軟體的授權資訊〉
簡論自由開源軟體的著作權適格及其態樣
本文原本刊登在自由軟體鑄造場的法律專欄，主筆是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