2.4 自由軟體制度與智財制度之比較
2.4.2 自由軟體制度展現排他權之外的誘因
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
2.4.2 自由軟體制度展現排他權之外的誘因 自由軟體發展與智財權制度互動之觀察
48
權262，這與網際網路上許多分享知識的部落格等禁止「盜文」等規定類似，都 是希望讓使用該知識的人知道最開始是誰創作的。自由軟體的這些特質與學術 著作相當的類似，學術著作的倫理是絕對地禁止抄襲與剽竊等行為，引用他人 的文章必須註明出處，不可歪曲解讀他人的意見，而學術著作之報酬，除去以 論文所交換之學位或是研究計畫經費等立即報酬外，「學術研究的價值並非來 自於研究成果的直接獲利，而是公開出版以後經過學界肯定的回饋」263，這個 回饋量化後就是論文的被引用數（cited number），是在過了許多年後才可看出 之延遲的名聲報酬。「延遲報酬」可說是自由軟體相較於智財權在誘因上一特 殊性質，本文在下節將把自由軟體的誘因或可說創作之動機做一整理討論。
2.4.2 自由軟體制度展現排他權之外的誘因
智慧財產權訂立類似有體財產權的排他權來提供創作者誘因，其目的在於 誘使更多的創作與發明出現，促進社會文化的進步與發展，而排他權只能說是 一個為了達成目的之手段或誘因，不能說智慧財產權的目的就是要保護創作者 的私益264。自由軟體成功的創作模式，已經證明了以排他權保護立即的獲利是 不一定需要的265。自由軟體的開發模式可說是在智財權基本手段的排他權外，
存在著某些誘因與動機促使軟體工程師願意放出自己努力的成果卻不要求立即 的對價補償，本文整理如下。
1. 好軟體都是起源於軟體工程師要解決的切身之痛266。這是自由軟體界 非常有名的一句話，由 Eric Raymond 提出，其原始來源為諺語「需 求為發明之母」。軟體工程師自身對於某個功能有需求，如果找不到
262 見本文 2.3.2 節所介紹之 Jacobsen v. Katzer 案。
263 張容綺，同前註 22，頁 9。
264 謝銘洋，同前註 238，頁 17；實務見解參見智慧財產法院 98 民專上字第 18 號判決:「專利法
第1 條固規定其立法目的在於鼓勵、保護、利用發明與創作，以促進產業發展，究其本質，在
於由國家提供一定時間之獨占保護，給予專利權人從事發明及創作之誘因，於專利權期間屆滿，
專利權人即將其發明及創作貢獻予社會公眾，供相關領域之人得以利用該發明及創作，進行深 度研發，使科技與產業持續進展，是以專利法之最終目的旨在促進產業發展，而以公共利益為 保護目的，至於對於專利權人之一定時間內的保護，僅為促進產業發展之一種手段」。
265 Bernd Carsten, The impact of open source development on the social construction of intellectual property, in FREE/OPEN SOURCE SOFTWARE DEVELOPMENT 259, 267(2005), “This story has simply been proven wrong by open source software.”
266 Raymond, supra note 79, at 3, “Every good work starts by scratching a developer’s personal itch”;
Steven Weber, THE SUCCESS OF OPEN SOURCE 74-75 (2004);
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
2.4.2 自由軟體制度展現排他權之外的誘因 自由軟體發展與智財權制度互動之觀察
49
易於取得的替代方案（不論是私有軟體或自由軟體），則可能自行開 發後以自由軟體授權條款釋出，並期望他人可以加入參與開發或給予 意見，亦或類似本文 2.2.2 範例中小華在現有的自由軟體專案中開發 自己想要的功能。這一類的需求不是以公司商業模式去觀察市場的角 度而為消費者量身訂做的需求，一般軟體工程師在為公司撰寫此類私 有軟體時，通常只是為了經濟收入遵循公司的指示267，對公司所指派 開發的軟體沒有自身需要也沒有特殊情感268。此處的切身之痛是指軟 體工程師個人的、日常的需求，常常是其家庭或是某個興趣所需，但 缺乏替代的方案，那乾脆自己來完成269。因為要解決的是自己的問題，
所以開發的過程會更有熱忱，符合前述同儕生產自發性的要件，也造 成自由軟體的平均品質可能比可替代的私有軟體要高（例如 Linux 與 Windows）270。那麼為什麼這些工程師會願意將自己的成果以自由軟 體方式貢獻給他人呢？一個理由是反正把無形的知識分享出去自己也 沒什麼損失271，這一點更奠基於前述基於興趣的個人非營利開發，在 一般私有軟體公司中以營業秘密保護的原始碼是不會也不能有這個想 法的。
2. 開發自由軟體的過程為一種社交行為。人是生活在群體中的，我們都 需要社交活動。Stallman 在兒童時期患有自閉症， 1970 年代的駭客 共享文化就是其社交的歸宿，發起自由軟體運動的一大理由就是捍衛 其所認同的駭客文化。自由軟體開發者會在網路上討論開發過程，技 術問題以外，商業、智財權等各面向也是其所關注之議題，而形成自 由軟體社群。軟體工程師的工作型態使其長期在電腦前，工程師的訓 練與工作型態也使其較不善於社交，工程師透過網路協作開發自由軟 體以及討論開發過程，這就是他們社交的方式，是他們的生活型態272。
267 Lessig, supra note 96, at 176.
268 Weber, supra note 266, at 73; Raymond, supra note 74-75, at 3;
269 Lessig, supra note 96, at 173. 該文則提出他人研究數據所呈現之另一觀點：工作所需(33%)、
非工作所需(30%)、兩者(5%)。
270 Raymond, supra note 79, at 3.
271 Lessig, supra note 96, at 173.
272 See Weber, supra note 266, at 81-82; 蘇孝恆，見前註 72。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
2.4.2 自由軟體制度展現排他權之外的誘因 自由軟體發展與智財權制度互動之觀察
50
3. 公司直接雇用軟體工程師對自由軟體做開發。公司自身就以自由軟體 營利，大量利用自由軟體作為其對外服務之核心，所以其對自由軟體 有直接的需求，而以一般公司的管理階層來指示旗下的軟體工程師開 發符合公司未來需求之自由軟體，而軟體工程師就像一般開發私有軟 體從該公司得到報酬，Red Hat、IBM、Mandriva、Ubuntu 等都是這 類型的公司273。
4. 新的嘗試與個人技術知識的磨練。一般公司的私有軟體開發很可能是 無趣與規律性的維護某些常規性工作，這些工程師下班後可能會以興 趣導向從事自由軟體的開發，而以新的嘗試去挑戰一些其認為可能很 酷的構想與令人振奮的功能，這些是上班時所無法得到的，也可磨練 其個人技術274，甚至一些新的創業公司就是由此而來。自由軟體開放 原始碼，這對於學生或是想提升自我實力的軟體工程師都是絕佳的磨 練方式。藉由觀察一個自由軟體專案的內部架構，並對其做出貢獻，
這個過程本身就可以使創作者在揣摩他人的寫作技巧中提升自己的程 式寫作能力275。
5. 樂在其中。如果軟體工程師覺得開發自由軟體比看電視跟玩遊戲有趣，
那他們就會去做276，與遊戲過關類似，那是一種因自我實現而產生的 樂趣277。在家中完成自由軟體的成就感是與在公司被老闆要求完成工 作不同的278，那就像是自己設計並完成一件木工家具所得到成就感般，
動手自製（Do it Yourself: DIY）就是自由軟體開發的樂趣所在。
6. 懷著對社群的認同與感激之利他行為。創作者本身可能長期的使用自 由軟體，並對社群產生認同感，享受自由軟體為其所帶來的便利，所 以就算不是自己的需求也願意對其奉獻。這是一種使創作者感覺有在 幫助他人的利他行為279。
273 Lessig, supra note 96, at 172, 183-184.
274 Weber, supra note 266, at 73-74.
275 Lerner & Tirole, supra note 259, at 57-58;蕭澤嵐，同前註 250，頁 62。
276 See Lessig, supra note 96, at 175.
277 Eric von Hippel, Open Source Software Projects as User Innovation Networks, in PERSPECTIVES ON FREE AND OPEN SOURCE SOFTWARE 267, 273 (2005); 蕭澤嵐，同前註 250，頁 62。
278 Lerner & Tirole, supra note 259, at 58.
279 Lessig, supra note 96, at 175; Lee, supra note 10, at 54.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
2.4.2 自由軟體制度展現排他權之外的誘因 自由軟體發展與智財權制度互動之觀察
51
以上各點都是立即性的報酬，除了公司直接給雇員金錢上的報酬外，其 餘大都是經濟以外之報酬，且又以心理上的滿足為主，以下則屬前節所 述之延遲報酬。
7. 能力證明與就業考量。貢獻過某一個自由軟體，代表著該軟體工程師 對其有一定的熟悉程度。公司對於與自家產品有相關連的自由軟體專 案自然有所研究，如果在尋找人才的過程中有人參與過相關自由軟體 的開發當然就是相關經驗的證明280。自由軟體是公開流通的，所以可 成為公開衡量技術能力之標準，各家私有軟體的開發屬於各公司的營 業秘密範疇，與其他公司溝通討論時不一定能夠了解，但是自由軟體 就可以成為不同公司間的共通語言與標準。
8. 名聲報酬。完成並公布之自由軟體經過一段時間後得到社群的肯定，
就如同學術論文過了幾年後得到大量的讚賞與引用一般，創作者因此 而在相關領域成名，可能會在相關主題的活動中應聘演講等。名聲上 的滿足主要是想要得到社群或同儕之認同（peer recognition）281。 Jacobsen v. Katzer 案中原告所爭執的條款就是原作者之屬名條款，希 望使用該軟體的使用者知道原作者是誰，而不是被他人中間攔截將此 名聲報酬佔為己有。
9. 使用者對軟體品質之回報與再創作。對原作者而言可以得到使用者的 回應，就像是本文 2.2.2 中小華的例子，小華對軟體開發了新的功能，
並將其回報給原作者整合，而就算是小明這類的一般使用者，也可以 將其意見或是測試的結果回報給原作者。測試與除錯是軟體開發相當 耗費時間的一環，軟體工程師通常不願意去作，自由軟體的開發模式 則有很多使用者願意免費幫忙測試與除錯282。使用者的回報的累積，
也就形成了自由軟體發展最大的特質：同儕創作。
280 See Lerner & Tirole, supra note 259, at 58; 蕭澤嵐，同前註 250，頁 63；呂佩芳、楊智傑，同 前註247，頁 110。
281 Id.; Lee, supra note 10, at 55; 蕭澤嵐，同前註; 呂佩芳、楊智傑，同前註。
282 張容綺，同前註 22，頁 10。