article – Florence 弗羅侖司

舊文重新上架 << 從 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 類+商業條款」的典型略有不同，因此本文將從多重自由開源條款授權的緣由談起，來說明在面對這種軟體時，可以採用什麼樣的基本態度來選擇條款，以及如何適當地標示後續散布的授權聲明內容。閱讀全文〈多重自由開源條款授權軟體之條款選擇與授權標示〉

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

本篇文章原載於自由軟體鑄造場的法律專欄，非常感謝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〉

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

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

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

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

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

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