受保護的內容: COSCUP 2024 演講：GPL 授權條款的典型侵權糾紛
受密碼保護的文章不會產生內容摘要。
標籤: license
舊文重新上架 << 從 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
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中文解譯〉
第一份中文版自由開源授權條款「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 的草稿，一方面協議採用中文撰寫，解決英文所造成的隔閡問題，另外一方面，目前公開草稿內容、徵求當地社群成員意見，期望透過這樣的互動，來提升中國大陸社群對於智慧財產相關議題的關注。
釋出源碼時常見的考慮因素與授權條款的選擇：以單一著作權人的軟體專案為例
最近接觸到一個想要釋出源碼的專案，該專案程式碼的著作權利全部歸屬於單一著作權人，因此這個專案可以選擇的自由開源授權條款很多，能變化出來的授權模式(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
自由開源軟體不收取授權金之特性
本文原刊登於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
不收取授權金是自由開源軟體的一大特性，這其中牽涉到的智慧財產權種類包括了著作與專利兩類，雖然法律專欄在過去發表過許多相關的文章，不過都是屬於細部的分析，並未有統合性的介紹，也沒有對於這個特性形成的緣由加以說明，因此本文將針對這些過去所未說明過的部份進行統合性的介紹，同時針對常被併同提起的商標權加以說明，供想要深入了解自由開源授權特性與成因之讀者參考。
GPL 與常見授權條款相容性淺析
本文原刊登於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GPL 是被廣泛採用的自由開源授權條款，不過由於 GPL 具有授權拘束性，衍生程式必須仍然適用相同條款授權（註一），所以在利用上會需要注意與之結合的程式碼授權內容是否相容，因為與之結合的程式碼一旦成為 GPL 衍生程式，就代表著在散布時必須要透過 GPL 條款來授權散布，若是其原本的授權內容與 GPL 不相容，會讓使用者無法同時符合兩份條款的義務規定，進而可能發生侵權利用的狀況。
因此本文將以 GPL-2.0 與 GPL-3.0 這兩份授權條款為中心，來說明目前常見授權條款是否與之相容，進而讓讀者了解哪些常見授權條款的程式碼可以與這兩份 GPL 條款的程式碼結合之後一起散布（註二）。
▲ 圖1：GPL 衍生程式結構示意圖。