擔保條款

GPL 條款中規定授權人得自行提供擔保或補償，但一般程式設計師在無償貢獻原始 碼的情況下，多半採取 GPL 預設的免除擔保條款，因此，使用者面對開放原始碼軟體，

必須在免費取得與自行負擔風險間衡量。開放原始碼社群宣稱開放原始碼軟體的品質優 良，卻又不願意提供擔保，看似矛盾，實則不然，程式設計師追求品質與願意負擔訴訟 風險，必須當成兩件不同的事情看待¹⁵³。另外，相較於專屬軟體的授權合約，開放原始 碼未提供擔保似乎是一項弱點，不過如果深究，可以發現一般專屬軟體的合約對消費者 的保障，實際上可能沒有消費者想像的多，例如，軟體造成損害，其賠償額度以當初購 買成本為限，超出金額則不在賠償範圍之內。因此，評估時如考量開放原始碼可以免費 取得，實際上缺乏擔保似乎並不影響一般人採用開放原始碼的意願，開放原始碼軟體出 現瑕疵，使用者除了回報問題並寄望下一版改良外，很少聽到因瑕疵造成損害而引發糾 紛。

151 See Ben Kremer, Open source software: What is it and how does it work?, Feb. 17, 2004, at

http://www.freehills.com/CA256AD900137BAA/page/Listing-ait-Open+source+software:+What+is+it+and+ho w+does+it+work%3F00201A46?opendocument&1=50-Publications~&2=~&3=~&REFUNID=~undefined (visited May 16, 2004).

152 See Dennis M. Kennedy, A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture, 20ST.LOUIS U.PUB.L.REV.345, 373 (2001).

153 See Robert W. Gomulkiewicz, How Copyleft Uses License Rights to Succeed in the Open Source Software, 36 Hous. L. Rev. 179, 192 (1999).

在 SCO 案中，缺乏擔保條款成了 SCO 質疑開放原始碼模式可靠度的一項論點。在 SCO 案之前，是否採用開放原始碼軟體，一般考量的是軟體的成熟度、是否符合需求、

後續維護的成本等，較少顧慮原始碼是否侵害他人智慧財產權或埋入不良的功能，而可 能引發後續的糾紛，畢竟原始碼置於光天化日之下，如果蓄意侵害他人權利，事跡敗露 可能只是遲早而已。但受到 SCO 案的影響，開放原始碼軟體的權利瑕疵擔保，逐漸受 到重視而成為是否採用的參考。針對這個問題，如前所述，部分採用開放原始碼的商業 團體開始提供不同程度的擔保，以消除客戶的疑慮。

要減少外界對開放原始碼缺乏擔保的疑慮，或許在商業策略之外的另外一種可能 是，在公眾授權契約中要求程式設計師擔保其創作未侵害他人著作權。程式設計師如果 本身為程式的創作者，在創作主義下即擁有著作權，擔保未侵害他人著作權應沒有太大 負擔，因為創作前並沒有類似專利檢索的查證義務。不過，考量無償貢獻原始碼卻需要 負擔擔保責任，仍可能降低採取開放原始碼模式的意願，因此，已知的公眾授權並未如 上所述，要求創作者負擔瑕疵擔保責任，甚且，將軟體專利納入考慮，要求創作者擔保 未侵害他人專利，實務上則可能更是難以實行。考量這些因素，可預期開放原始碼社群 對軟體的擔保或補償，未來可能仍以商業團體為主，而較難要求大部分獨立無償的程式 設計師負擔，商業團體保留部分獲利做為補償損害或定紛止爭的資源，似乎是比較可行 的作法。使用者面對缺乏商業團體擔保的軟體，事實上也應該不用特別顧慮，對重量級 的開放原始碼軟體來說，創作者為提高市場佔有率或自己的知名度，自然會負擔應有的 注意義務，審慎遵守智慧財產權法的相關規定。例如，SCO 案發生後，Torvalds 思考如 何讓 Linux 系統防範於未然、避免受到下一個 SCO 攻擊時，曾建議開發團隊及相關人 士採取簽名背書的作法，在經手的原始碼上寫下自己的大名，為原始碼的流通與版本的 更迭留下軌跡，如此一來，不僅多年後如果涉訟其舉證相對容易，串連每個人都有一些 信得過的朋友的信任關係，也將築起一道阻擋不實指控的強韌防線，如果落實這種作 法，將來一般使用者拿到原始碼軟體，不僅信任程度可能提高，對開放原始碼模式的運

作機制也將更加瞭解¹⁵⁴。巧合的是，歷史似乎總是重複出現，當年 BSD 開發團隊與 AT&T 之間爭訟的原因之一，即在於原始碼的權利歸屬不清，軟體開發程序缺乏適當的紀錄，

以致於雙方最後必須以訴訟方式逐一檢驗權利的歸屬，相對地，Linux 系統過去雖然並 非沒有相關記錄，但有仍有許多有待補強的地方¹⁵⁵。

再從法制面分析，即使目前缺乏擔保條款在實務上，似乎受到程式設計師與使用者 兩邊所接受，而維持公眾授權的現況也沒有太大問題。不過隨著資訊相關法制的變革，

可能逐漸浮現不同的衝突或考量。以美國「統一電腦資訊交易法」(UCITA, Uniform Computer Information Transactions Act)為例，如果法案由統一法的層次逐漸落實到各州 州法，以其「電腦資訊」定義的範圍廣義，開放原始碼的公眾授權應涵蓋在內，則開放 原始碼的實際運作將受到 UCITA 的規範。UCITA 基本精神之一在於彌補一般軟體授權 的不足，在規範有所缺漏的情況下納入契約中應有的預設條款，因此，如果將 UCITA 適用到開放原始碼的公眾授權，預設條款可能有違開放社群的本意，例如，UCITA 可能 對授權期間、擔保範圍、默示擔保或其他限制有所規定，讓目前創作者在缺乏擔保條款 下仍負擔部分責任。以 BSD 授權為例，授權條款規定包括直接損害在內的任何侵害，

都不在擔保的範圍之內。由於直接損害對契約的成立有根本上的重要性，如果預先免 除，可能會讓法院對公眾授權的效力產生不同的認定¹⁵⁶。不過，UCITA 並非完全對開放 原始碼模式不利，其中仍可能產生正面的效果，例如，贊成使用者未簽名的拆封合約有 效，將有助於支持公眾授權契約的強制力¹⁵⁷。

契約中提供擔保條款，目的之一在於降低交易風險，並促成交易，軟體授權異於其 他一般有體財產的交易之處，在於交易客體本質上難以確保毫無瑕疵。軟體需要以人工

154 See Linus Torvalds, RFD: Explicitly documenting patch submission, May 24, 2004, at

http://www.newsforge.com/article.pl?sid=04/05/24/1214237 (visited May 26, 2004); Jay Lyman, Linux kernel developers to log their trust, May 24, 2004, at http://www.newsforge.com/article.pl?sid=04/05/24/1555237 (visited May 26, 2004).

155 See Jan Stafford, Usenix president: Linux needs better paper trail, May 24, 2004, at

http://searchenterpriselinux.techtarget.com/qna/0,289202,sid39_gci966588,00.html (visited May 26, 2004).

156 See Kennedy, supra note 152, at 374.

157 Id., at 369.

撰寫，細微的邏輯錯誤可能當掉整個程式，以及軟體功能不斷增加所帶來的複雜度，都 是無法保證軟體百分之百沒有臭蟲的原因，即使大型軟體公司具備各種資源及理由將瑕 疵降至最低，也盡量只提供最低限度的擔保，便可看出臭蟲瑕疵像是軟體本質上揮之不 去的不定時炸彈，誰也難以保證到底。如前所述，使用者必須在購買專屬軟體取得少量 的擔保及缺乏擔保但免費的開放原始碼軟體之間選擇，自行評估承受多少風險以及付出 多少對價來降低風險，相對地，程式設計師則必須評估需要取得多少對價以提供風險的 擔保，在雙方評估之間是風險的配置問題。開放原始碼社群既然缺乏對價填補承擔風險 所需要的付出，採取拒絕擔保將風險完全轉嫁到使用者身上，便不難理解，加上使用者 自己有選擇接受與否的自由，不提供擔保的正當性又提高一些。軟體瑕疵的風險在雙方 你情我願的情況下，其分配或許可以自然形成一種的平衡，例如，維繫企業每天正常運 作者採專屬軟體，非關鍵性應用則採開放原始碼軟體等。因此，類似 UCITA 法律介入 的風險即在於破壞上述的平衡，雖然立意良好，但可能在降低交易風險的同時，卻無助 於交易的促成。

本文認為，促進市場交易是目的，降低交易風險只是一種可能的手段，過去在買賣 雙向對價關係中所形成的擔保概念，不必然可以直接適用於開放原始碼模式的單向授權 關係，法律應回到最初規範的目的，思考過去的手段是否在新的情境下依舊有益於目的 的達成，才能類推適用。在防弊的思維下，把風險擺在使用者這一端，可能有違消費者 保護的精神，把風險擺在程式設計師那一端，則可能壓制了創作後分享的意願，看起來 思考上沒有出路。實則，在防弊之外或許可以朝興利的另外一個方向思考，例如，開放 原始碼模式的特性之一為榮譽制度，許多程式設計師貢獻心力為的是建立個人的名聲、

擴大影響力，並得到同儕的肯定會或追隨，在這種情況下，後續是否寄望經濟上的利益 在所不問，其個人名聲的累積已成為追求的目標，內在已具有足夠的動機加以經營、維 護。能夠反映個人名聲的因素包括社群參與的程度、原始碼創作的品質、數量、重要性 等，如果制度運作上能凸顯出這些貢獻度，讓個人的名聲與開放原始碼軟體的優劣產生 連結，則軟體瑕疵可能自然地在另外一種誘因下降低。在榮譽制度的強化下，使用者依 舊承擔使用軟體的風險，創作者也沒有提供額外的擔保，但因為找出適當的誘因提升軟

體的品質，開放原始碼模式下的交易風險將有機會降低，同時有益於交易的促成。或許 可以說，程式設計師採取姜太公釣魚的模式，在使用者願者上鉤的交易中並非一無所 獲，其取得的對價其實是名聲的累積而非經濟上的收入，因此，制度的設計如果刺激正 確的誘因，例如，建立百大優質開放原始碼軟體的榮譽制度或獎金制度，程式設計師可 能自然願意不斷提升魚餌的品質。