初02:什麼是費用?

本文採用「Creative Commons 姓名標示-禁止商業利用-相同方式分享 3.0 台灣 授權條款及其以後的版本」來授權。

答:在自由開源授權的領域中提到費用這個名詞,通常是與著作權授權金、專利權授權金等這類授權金相對來看的,所以簡化來說,一筆金額若不是授權金的話,通常就可以稱它是費用。

因為著作權人不收取授權金,所以自由開源軟體沒有著作權授權金,再加上現在網路發達,自由開源軟體都是透過網路釋出程式源碼,並且不收取費用,所以任何人都可以自由免費地下載來利用。因此,對於一般單純的使用者,或者因為興趣而參與自由開源專案的開發者來說,都不會需要因為利用到自由開源軟體而支付任何費用,也因此在這些情況下,自由開源軟體等同於免費的軟體。

你可以閱讀下面文章來了解相關資訊:
問01:自由開源軟體是免費的嗎?
初01:什麼是著作權授權金?

初01:什麼是著作權授權金?

本文採用「Creative Commons 姓名標示-禁止商業利用-相同方式分享 3.0 台灣 授權條款及其以後的版本」來授權。

答:著作權授權金是為了合法利用著作而付出的金額

白話來說,著作權授權金是為了取得利用著作的合法地位、而付給著作權利人的一筆金額,例如為了要在自己製作的 YouTube 短片中插入一段音樂,就必須先透過合法的管道,支付一筆授權金給音樂的著作權利人,然後才能合法地將這段音樂利用到自製的短片中。

自由開源軟體的著作權人不收取著作權的授權金,所以著作權授權金額為零。

另外在中文還會看到權利金這個詞,主要是從英美法系來的概念。在英美智慧財產法中,權利人可以收取的費用可以大分為 “licensing fee” 跟 “royalty” 這兩類,前者通常指一次性收取的金額,後者通常指分次收取的金額,這兩個詞常見的中文翻譯就是授權金與權利金:

licensing fee –> 授權金
royalty –> 權利金

英美法系之所以會有這兩詞的區別,源自於他們的歷史發展,但在台灣因為沒有這樣的歷史背景,所以一般單用授權金這一個詞,來概括指稱所有為了取得合法利用權利而支付的金額。

不管是 “licensing fee” 或是 “royalty”,自由開源軟體的著作權利人都不會收取,所以我們會在授權條款的英文原文內容中看到 “royalty free” 的文字,這就代表著不收取任何的授權金或是權利金,而當我們用一般常用的中文語彙來表達這個概念時,就是「不收取著作權授權金」。

問01:自由開源軟體是免費的嗎?

本文採用「Creative Commons 姓名標示-禁止商業利用-相同方式分享 3.0 台灣 授權條款及其以後的版本」來授權。

自由開源軟體 (Free and Open Source Software, FOSS) 是免費的嗎?這個問題並沒有辦法透過簡單的「是」或「不是」來回答,因為一般人對於「免費」這個詞的概念並不一致。所以接下來我會透過四個不同的角度,來說明附隨在自由開源軟體上所可能產生的費用,最後再來回答這個問題。

你可以閱讀下面文章來了解跟本篇文章相關的資訊:
初01:什麼是著作權授權金?
初02:什麼是費用?

1、沒有著作權授權金

自由開源軟體最大的一項特色,就是著作權人不收取授權金,所以拿到程式源碼的人可以下載、修改、編譯、安裝、執行或者再散布這些源碼,不需要另外得到著作權人的許可,也不需要另外再向著作權人支付授權金。

授權金在傳統利用軟體的方式中佔有很重要的地位,很多軟體在完成之後,就像是一個待價而沽的商品,等著有人願意付出授權金來換取利用的權利,一旦有許多人願意付出授權金,軟體著作權人就可以靠著收取授權金來長期營利。商業軟體公司就是依靠這樣的模式在賺取利潤,我們日常熟悉的微軟作業系統就是一個有名的例子。不過這樣的散布模式增加了軟體取得的成本,阻礙軟體的流通,降低軟體被改良的機會。

但是自由開源軟體是為了促進軟體的改良而產生的一種軟體類型,為了加速改良的過程,軟體就必須盡可能地被散布出去,也盡可能地讓有修改能力的工程師接觸到這個軟體、檢視軟體、並且進而主動改良軟體,所以自由開源軟體沒有著作權授權金的限制,軟體成本因而降低、軟體流通速度加快,軟體被改良的機會因此增加。這就是自由開源軟體沒有著作權授權金的初衷。

2、可能會有散布費用

不過當軟體被使用者拿到,他想要將這個軟體再散布給其他人時,這位使用者是可以收取費用的。因為既然著作權人已經不收授權金,任何人也都可以直接從著作權人處拿到軟體源碼,阻礙軟體流通與利用的一大障蔽已經去除,所以下游使用者再散布軟體時,是否收費以及收費的高低,就不是那麽重要,因此絕大部分的自由開源授權條款並沒有限制使用者收取散布費用。

不過,仍然有些條款有輕度的限制,例如 GPL 系列的條款都有一項合理散布工本費用的規定。以 GPL-2.0 (GNU General Public License version 2.0) 為例,若是使用者要將 GPL-2.0 軟體再散布給其他人,可以選擇先散布軟體的執行檔或是二進位格式,拿到執行檔或二進位格式的後手若是還想要源碼的話,可以另外向使用者索取源碼,這時候使用者有義務必須將源碼提供給後手,在此同時,使用者可以向後手收取合理的工本費用 (…for a charge no more than your cost of physically performing source distribution…)。

上面這規定出自於 GPL-2.0 的第 3 條第 1 項第 b) 款,原文規定相當詳細,不過限於文章篇幅的關係,本文對於這個規定不多做說明(註一1)。

以上這個合理散布工本費用的規定,在 GPL 系列條款中的每一份條款都有著相同內涵的規定,也許用詞略有不同,但是精神一樣,總之,使用者實際上所能收到的費用都必須是在合理範圍內。

實務上來說,一般個人使用者在散布軟體時原則上並不會收取散布費用,但是商業使用者則會根據他的商業模式來決定是否收取散布費用,而這個散布費用也常常因為內含在整體商業收費當中,所以我們一般並不會具體感受到有支付了一項「散布費用」給商業公司。

3、商業應用通常會產生商業收費

自由開源軟體是可以被商業應用的,一個不允許商業應用的軟體絕對不是自由或開源軟體(註二2)。在自由開源軟體被商業公司拿來應用的狀況下,因為應用方式與營利模式的不同,就會產生不同的收費模式。

最傳統的就是被應用在嵌入式產品中,例如手機、機上盒、電視機或是車載裝置中,這時候消費者購買這些產品的價格中,就包含了商業公司因為利用、散布自由開源軟體而要收取、賺取的費用。

另外許多自由開源軟體被應用在網路系統中,在瀏覽器前面的消費者有時候是免費利用這些網路服務,但是有些服務則必須付費才能利用,這時所付的費用中也就包含了商業公司利用自由開源軟體而要收取、賺取的費用。

4、可能會有專利權或是商標的授權金

自由開源軟體沒有著作權授權金,但是軟體程式中可能會應用到封閉的專利技術,這時候就可能必須要額外取得專利授權許可以及支付專利授權金。不過,對於一般個人使用者來說,若是僅個人使用軟體、並沒有涉及商業行為的話,通常不會被認定是侵權利用專利技術;但若有涉及商業利用的話,就必須要謹慎了解相關專利技術內容,以避免被認定為侵權利用專利技術。

利用自由開源軟體可能在無意中被認定是專利侵權,這在自由開源軟體領域中是一個很重要的議題,所以多家國際商業公司成立了 OIN (Open Invention Network) 這個組織來處理這個議題,有興趣的讀者可以到 OIN 官網來進一步了解(註三3)。

商標是一種辨識標誌,可以讓一項產品或是一個組織被他人辨識出來、加深印象,間接促進商業上的獲利。這樣的特性並不會影響軟體的流通跟改進,所以自由開源軟體並不禁止附隨商標標誌,也不禁止這些商標的權利人收取商標授權金。對於一般使用者來說,單純執行軟體是完全不會有利用商標的行為,所以沒有商標的問題需要擔心;對於個人開發者來說,修改、討論、散布自由開源軟體的行為,只要這些行為是單純描述事實、沒有讓人產生誤解的話,通常也不會有商標的問題需要擔心;但是,對於商業利用來說的話,可能就會有需要取得商標授權跟支付授權的狀況。

所以根據不同的情況,利用自由開源軟體是可能需要支付專利權或是商標權的授權金:一般使用者或是個人開發者,單純自己利用軟體或是自行研究修改軟體的行為,通常都不會需要擔心專利或商標授權金的問題;但若是涉及商業利用的話,就必須要進一步了解利用的方式是否需要另外取得授權許可或是支付授權金了。

5、答:利用自由開源軟體原則上是免費的、但在有些週邊的情況下會需要支付費用

對於一般單純使用者、或是因為興趣而參與自由開源專案的開發者來說,自由開源軟體專案幾乎等同於免費的軟體,因為在不用支付任何費用的情況下,就可以從網路上拿到軟體來用、或是取得源碼來研究與修改,不過在牽涉到商業利用的情況下,商業使用者可能會有週邊的專利或商標的費用需要支付,而使用者在利用到有應用自由開源軟體的商業服務時,也可能一樣需要支付費用給商業公司。

所以,簡而言之,自由開源軟體乍看之下好像是免費的,但,因為情境的不同而可能衍生出不一樣的費用名目需要使用者支付,因此自由開源軟體其實並不是免費的。

6、自由開源軟體是沒有著作權授權金的

綜合上面的說明,若是要介紹自由開源軟體在費用這部份特性的話,最精確的說法就是「自由開源軟體沒有著作權授權金」,這句話一旦出來,就有定錨的效果,也就是說,著作權授權金的金額絕對是零,因為完全不收取,也沒有金額高低的問題。至於還有哪些其他的收費名目會附隨在自由開源軟體的上面?費用高低又是如何?等等,這些都不是重點,必須要另外看個案來討論才能知道,沒有像著作權授權金那麽篤定地可以一言以蔽之。


  1. 註一:在此附上 GPL-2.0 的第 3 條第 1 項全文供參考:”You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)” ↩︎
  2. 註二:關於這個概念,可以參見自由軟體內涵說明的文章 “What is Free Software?”,https://www.gnu.org/philosophy/free-sw.html.en,最後造訪日期 2025 年 9 月 15 日;以及開源定義的內容 “The Open Source Definition”,https://opensource.org/osd,最後造訪日期 2025 年 9 月 15 日。 ↩︎
  3. 註三:OIN 官網:https://openinventionnetwork.com/,最後造訪日期 2025 年 9 月 15 日。 ↩︎

舊文重新上架 << 從 Copyright 到 Copyleft:GPL 的誕生、成長與未來 >>

有社群朋友在 2022 年 6 月跟我詢問這篇文章何處可以下載,由於鑄造場
網站上的下載連結已經失效,因此我找出塵封的文章,更新了聯絡的 email 與
日期後,將此文章放在我的網誌上供有興趣的人下載。


ODT檔請按此下載
PDF檔請按此下載


若沒記錯,這篇文章是應該是是 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中文解譯

創用 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 的演講簡報可以到這篇文章來下載。

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

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