授權方式的複雜度

考量是否採用開放原始碼模式時，瞭解公眾授權是不可或缺的一環。如果對公眾授 權的規範不夠瞭解，實務上可能存在風險而不自知。公眾授權的運作如何與商業模式搭 配讓開放原始碼軟體得以獲利，也日益受到重視。另外，實務上因授權細節的差異引發 糾紛的相關案例，在本節中則值得一併瞭解。

首先，雙軌授權模式讓採用開放原始碼模式者能夠獲利，對於開放原始碼軟體能否 在商業環境下持續發展特別重要，有必要先提出說明。一般認為，開放原始碼模式在直 覺上與既有的獲利模式相違背，因此如何從開放模式中獲利，一直受到懷疑。授權方式 對開放模式的重要性除了規範當事人間相關權利義務外，部分原因在於適當的授權策略 可能是目前開放原始碼模式最有效的獲利方法。例如，相對於知名度較高的 Linux 廠商 如 Red Hat 及 Cygnus 等成功範例證明了透過服務獲利的可行性，有人認為，真正值得 注意的反而是像 MySQL 及 Gluecode 之類的公司，在缺乏當年 IPO 水漲船高的協助下，

這些公司以雙軌授權方式穩定獲利，才算是通過市場的考驗。雙軌模式對開放社群與商 業用途採取差別待遇，讓商業客戶成為主要的收入來源，以開放社群做為擴大市佔率的

118 Id., at 70-71, 90.

119 Id., at 72.

基地，因此，建立了一種既開放又能獲利的商業模式¹²⁰。雙軌授權間的關係可藉由下圖 表示：

圖四 雙軌授權模式¹²¹

其次，採用開放原始碼模式者必須注意到授權許可的複雜度可能導因於授權種類的 繁多¹²²及條款的演進，實務上發生自由軟體基金會與 Apache 基金會就授權相容性的爭 議，可供參考。例如，GPL、LGPL、BSD 及開放原始碼定義下的數十種授權許可，分 別可符合各種不同的需求，程式設計師必要時可自創新的公眾授權許可，同一份授權許 可隨著時代的演進，也可能出現不同的版本，這些因素提高了選擇授權方式與深入細節 上的難度。在實務上，由於 SCO 案提高了開放原始碼社群對智慧財產權議題的警覺度，

Apache 軟體基金會於是在 2004 年二月，將 2000 年公布的 1.1 版授權許可更新為 2.0 版，

推出新版的目的在於：允許其他軟體專案可以重複使用該授權許可、授權許可得以指到 同一份資料而不需要包含在每個檔案中、澄清外來原始碼貢獻時的授權條件、原始碼涉 及專利時需取得授權、及標示 Apache 著作權權利歸屬時，可以在授權許可之外以其他 檔案表示。整個改版的目的除了簡化部分實務操作面的不便，藉此，Apache 基金會也 希望與其他開放原始碼的授權模式相容，並保有 Apache 原本同時幫助非營利組織及商

120 See Joe Barr, Matt Asay introduces Open Source Business Conference, Mar. 15, 2004, at http://www.newsforge.com/article.pl?sid=04/03/12/1955258 (visited Mar. 17, 2004).

121 FINK,supra note 11, at 41.

122 關於常見幾種授權的比較，如 GPL、BSD、MPL、NPL、SCSL 等，可參見 Natasha T. Horne , Open Source Software Licensing: Using Copyright Law to Encourage Free Use, 17GA.ST.U.L.REV. 863 (2001).

業團體的理念¹²³。對於此次改版，自由軟體基金會則表示新版的公眾授權與 GPL 並不 相容¹²⁴，「相容」的意義是該公眾授權下的軟體得以和 GPL 下的軟體合併構成更大的軟 體，而持續符合 GPL 條款的規範¹²⁵。

自由軟體基金會主張 Apache 基金會的授權與自己的授權方式不相容，主要爭點在 於 Apache 基金會希望預防他人故意在開放原始碼中埋入專利，但預防的條款對 GPL 而 言形同額外的限制，而不能符合相容性的規定。自由軟體基金會認為，ASL 2.0 視為一 種自由軟體的授權方式，原則上並沒有問題，但因額外附加 GPL 中所沒有的限制，造 成與 GPL 不相容，雖然 ASL 中規定專利權無適用餘地的幾種情況，與自由軟體的精神 並無抵觸，但在定義上仍構成相容性的問題。根據 GPL 第二款 b 項，軟體必須以整體 方式透過相同的 GPL 條款授權給第三人，GPL 第六款規定，原始碼再散布時，取得原 始碼的第三人即取得 GPL 下相同的授權，散布時不得對該第三人加上 GPL 條款中原本 所無的限制¹²⁶。在著作權的範圍內，Apache 基金會表示可以理解上述條款的用意，目 的在於確保 GPL 下的創作始終維持在 GPL 領域內，但兩個基金會追求的目標不完全相 同，Apache 基金會希望專注於社群內協力開發上的支援，對於外來的授權許可，Apache 基金會需要的是確保社群內的程式設計師免於被追訴的風險，同時，Apache 基金會希 望盡量擴大原始碼的應用，讓非開放原始碼陣營也有權利善用 Apache 下的原始碼。對 於開放原始碼社群，Apache 同樣希望 GPL 規範下的軟體可以自由使用 Apache 授權下的 原始碼，這是為什麼 ASL 第四款中規定，使用者可以在自行修改的部分增加著作權聲 明，也可以針對修改的部分或對衍生著作的整體，提供額外或不同的授權條款，以供使 用、複製或散布。為了確保使用者及貢獻者免於專利訴訟，ASL 第三款中要求明確的專

123 See Apache Software Foundation, Licenses, at http://www.apache.org/licenses/ (visited Apr. 1, 2004).

124 See Free Software Foundation, GPL-Incompatible, Free Software Licenses, at

http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses (visited Apr. 1, 2004).

125 See Free Software Foundation, Various Licenses and Comments about Them, at http://www.fsf.org/licenses/license-list.html#TOCIntroduction (visited Apr. 1, 2004).

126 See Apache Software Foundation, Apache License v2.0 and GPL Compatibility, at http://www.apache.org/licenses/GPL-compatibility.html (visited Apr. 1, 2004).

利授權，並附加互惠基礎下的終止條款。在第三款中，程式設計師貢獻原始碼如涉及專 利權，則需賦予使用者永久、全球、非獨佔、無償、無授權金、且不可撤回的授權許可，

如果使用者對含有該原始碼的軟體發動專利訴訟，宣稱該軟體整體或其中一部份構成直 接或輔助性的專利侵權，訴訟發動當日，使用者在 ASL 下被授予的任何權利將立刻終 止。

相對地，GPL 第七款規定，如果使用者受限於其他因素無法符合 GPL 的規定，例 如，受到法院判決或其他合約的影響，在無法完全遵守 GPL 的情況下，使用者只有停 止散布整個軟體一途。以專利授權而言，如果沒有免除權利金的收取，則無法在 GPL 的規範下散布整個軟體。自由軟體基金會認為單以侵害專利權的聲明，尚不構成對再散 布的限制，在正式判決或禁制令之前，如果有人宣稱其專利權受到侵害，專利權人仍可 散布 GPL 下疑似侵權的軟體。ASL 在專利權人發動訴訟時即終止其權利，故在時間點 上比 GPL 嚴格，對 GPL 而言等於增加了額外的限制¹²⁷。亦即，Apache 基金會希望預防 有人故意在開放原始碼中使用自己的專利，等到事隔多年之後再對他人追索權利金¹²⁸。

上述 ASL 與 GPL 之間的相容性是一個例子，用來說明不同授權許可之間的交互影 響以及可能造成的認知差異。對程式設計師而言，加入開發專案時，需要瞭解所屬授權 條款的保障與限制，對使用者而言，不同公眾授權如何降低法律糾紛的風險，則可能影 響採用上的考量，對封閉原始碼陣營，主要顧慮則為能否合法納入他人的原始碼，並符 合其相關公眾授權的規定。

由於商業力量的加入，開放原始碼運動的法律議題比以前複雜，類似 ASL 與時俱 進的情況可能增加，就提升公眾授權的細緻度而言，授權版本的更新有其正面意義，但 對一般使用者及程式設計師而言，則可能附帶提高了理解上的難度。Moglen 表示，目 前 GPL 是自由軟體基金會 Stallman 於 1991 年時創設，沿用至今，不僅軟體界本身經歷 快速的變化，網路的生態也截然不同，例如，最顯著的變化是建立在開放原始碼之上已

127 Id.

128 See David Rubenstein, Apache Rewrites License, Feb. 15, 2004, at http://www.sdtimes.com/news/096/story4.htm (visited Apr. 1, 2004).

形成可觀的產業，因此，GPL 勢必也需要跟著調整。事實上，Moglen 與 Stallman 正著 手研議 GPL 第三版的內容¹²⁹，但改版的複雜度是一大挑戰。GPL 誕生之時，只要說服 個體戶和研究人員，讓他們相信公眾授權所帶來的好處，便能推行無礙，如今現實環境 大不相同，不僅從獨立的程式設計師到大型公司如 IBM、HP，都可能有不同的意見，

開放原始碼運動擴及全球後，對不同國家的法律也需要納入考量。受 SCO 案的影響，

大家對於如何在自由軟體下保障應有的權利、原始碼的來源是否有瑕疵等問題，顯得比 以往更為關切。過去，一般多半偏重軟體推出後的授權問題，而忽略預防勝於治療的重 要性，對於這一點，有人已開始呼籲開放原始碼社群應該多花時間留意軟體推出之前的 細節，以正本清源。例如，開放原始碼社群應如何在各方原始碼「組裝」的過程中，透 過公眾授權的規範建立防禦性機制，便值得加以探討。如果從市場機制出發，或許透過 第三人擔保的模式來降低風險也是一種可能¹³⁰。

在開放原始碼授權的選擇上如有不慎，後續可能引發合作伙伴的離去或遭遇授權轉 換的困難。例如，開放原始碼的資料庫廠商 MySQL 在 2004 年三月修改授權條款，希望 彌補與另一重要軟體 PHP 之間的裂痕，並平息在授權模式上的爭議。在網際網路上，

以 PHP 開發網頁程式搭配 MySQL 是十分常見的組合¹³¹，MySQL 之所以修正授權條款，

目的在允許 PHP 恢復以往搭贈 MySQL 元件的作法。PHP 本身同樣屬於開放原始碼軟 體，因此此一事件顯示出即使在開放陣營內部，考慮採用何種公眾授權時也不可輕率決 定。MySQL 營運策略的特殊之處在於提供兩種授權模式，針對其他開放原始碼軟體，

MySQL 採用一般公眾授權模式，針對傳統專屬軟體，則進行商業授權收取權利金。這 種雙重授權的作法只有在本身擁有全部原始碼的著作權時才適用，原本 MySQL 以 GPL

MySQL 採用一般公眾授權模式，針對傳統專屬軟體，則進行商業授權收取權利金。這 種雙重授權的作法只有在本身擁有全部原始碼的著作權時才適用，原本 MySQL 以 GPL