分類: legal column

多重自由開源條款授權軟體之條款選擇與授權標示

這幾年的諮詢回覆中，關於多重自由開源授權模式的問題增多，其中很多人都會附帶問到產品中該如何標示才好，因此這次就將如何選擇條款與相關的授權標示一併加以說明。原文發表於自由軟體鑄造場的法律專欄。

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

常接觸自由開源軟體的讀者應該都聽過雙重授權 (dual-licensing) 或多重授權 (multiple-licensing) 模式，也就是一個自由開源軟體透過多份不同的條款來授權散布，而軟體的使用者因此可以選擇最貼近自己需求的條款來後續散布這個軟體。這樣的多重授權模式常被應用在商業化利用的自由開源軟體上，最常看到的條款組合模式是以一份 GPL 類條款搭配商業授權條款來釋出，由於 GPL 類條款具有較為嚴格的授權拘束性，衍生程式的源碼必須在散布時也同時提供出來，對於不能履行這項義務的使用者來說，這時候就必須選擇洽談商業授權內容，在給付一定的授權金之後，使用者就可以獲得散布衍生程式無需提供源碼的授權條款。因此在這種「GPL 類+商業條款」的多重授權模式下，使用者通常只需要確認衍生程式源碼是否可以在散布時提供出來，就能決定要採用哪一種授權條款，而在相關產品的授權資訊標示上也因此相對地單純（註一）。不過在多重授權模式中，還有一種的態樣是透過多份自由開源授權條款來散布，在面對這種多重自由開源條款授權的軟體時，使用者條款在選擇條款的考量標準與授權標示上，均與上述「GPL 類+商業條款」的典型略有不同，因此本文將從多重自由開源條款授權的緣由談起，來說明在面對這種軟體時，可以採用什麼樣的基本態度來選擇條款，以及如何適當地標示後續散布的授權聲明內容。 閱讀全文〈多重自由開源條款授權軟體之條款選擇與授權標示〉

自由開源商用產品面對第三人專利問題的應對之方

本篇文章原載於自由軟體鑄造場的法律專欄，非常感謝Lucien共同撰寫，增加了這篇文章的深度。

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

在自由開源軟體的商業應用過程中，軟體專利侵權的潛在風險一直是個受到矚目的議題，因為依各國著作權法及電腦程式保護專法的規定，著作權性質的保謢標的多是限定在著作的表現形式上，故而重新撰寫且完全不抄襲他人的程式碼，將有機會主張新創作的程式，是一個全新的創作，而不受到他人既定程式的著作權利拘束，這也是 GNU 計畫 (GNU Project: GNU is Not Unix) 當初設立起步的主要思維：透過群策群力的方式，不加抄襲但重新創作具 Unix 系統所有功能的全新電腦作業系統，來讓後續的應用不受到既定 Unix 作業系統的拘束；然而在專利權的領域裡，因為其保護的標的多為抽象，且可實施在不同載體的技術方法和步驟，故第三人專利的議題在自由開源商用領域可能引發的效應，往往讓商業使用者憂心，畢竟，自由開源軟體專案允許多人共工的模式，一方面確實是加速了軟體專案的開發效率與期程，然而，開發流程裡是不是有開發者誤用或因疏忽寫入第三人既存，且受軟體專利保護的演算法，而讓整體專案後續曝露在專利侵權的風險下，這方面的推論，理論上亦有可能成真。 閱讀全文〈自由開源商用產品面對第三人專利問題的應對之方〉

受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析

這篇文章原本刊登於自由軟體鑄造場的法律專欄，感謝Lucien對本篇文章所提供的意見。

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

所謂的受雇人，簡單來說，就是在一間公司或組織聘用來在負責一定職務工作的員工，因此受雇於一間公司來專職開發軟體、韌體的工程師，就是受雇人，而該公司就是雇用人（註一）。若是這間公司利用 GPL 元件來開發產品，軟體工程師可以自由散布產品程式碼嗎？工程師在產品中所撰寫開發的程式碼，其權利是屬於工程師本身、還是該公司？這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時，可能會產生的，因此本文將先從著作權法相關的規定談起，並且說明實際雇傭關係的運用狀況，進而釐清這些可能的疑問。 閱讀全文〈受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析〉

淺談自由開源軟體個人終端使用者之善意保護

本篇文章原文發表在原文發表在由軟體鑄造場的法律專欄，與Lucien共同協力完成！

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

自由開源軟體近年被廣泛地運用在各類的資通訊產品與服務中，不過由於其為眾人協作的作品，故有時也會聽到資服業者，轉述終端使用者的疑慮，認為若產品中的自由開源軟體在共工撰寫的過程裡，可能隱有侵權重製、改作的糾紛，那麼產品使用者，是不是也會因此連帶被法律風險所波及？但其實從實務運作與法學論理上來看，身為單純的使用者，若對所購置產品侵權的風險不具合理的認知期待性，則其購買使用的行為，並不必然附隨有高度的侵權責難，這一點不論產品是否有嵌入自由開源軟體來使用，皆然。本文以下即從善意保護制度、侵權實務現況，以及自由開源軟體授權條款中的特殊規定等角度著手，來為讀者分析解釋這樣的概念。 閱讀全文〈淺談自由開源軟體個人終端使用者之善意保護〉

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

這篇基本是由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〉

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

本文原刊於自由軟體鑄造場的法律專欄，一樣是與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) 專案及其授權條款，蘊含著一種盡量將程式源碼提出來讓後手使用者增刪修改並便利應用的態度，故在其授權條款中，可以看到許多的內容是明確地針對程式源碼或目的碼所作的，略有差異的義務性要求，此項特點多為一般使用者所不知或忽略，而這方面的資訊，也正是本文希望透過特定條款的例示與說明，所要傳達給大家的。 閱讀全文〈淺論程式源碼與目的碼在自由開源軟體授權條款裡的同與異〉

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

這篇文章與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」草稿淺析〉

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

本文原本刊登在自由軟體鑄造場的法律專欄，主筆是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 一案的判決，便曾在言詞辯論時，就嵌入式韌體裝置上各元件應歸類於哪一種著作類型而展開討論（註一）。 閱讀全文〈簡論自由開源軟體的著作權適格及其態樣〉