侵害著作權

原始碼受著作權保護，使用他人的原始碼或將自己的原始碼公開，首要的問題在於 是否侵害他人的著作權或自己的著作權受到侵害，開放原始碼對一般專屬軟體公司及開 放原始碼社群在侵害著作權的議題上，是否各有不同的考量？或者對兩者而言存在相同 的疑慮？對於著作權侵害的問題，有哪些實務案例可供參考？實務上又該如何降低使用 開放原始碼軟體或採用開放原始碼模式的風險？這些問題是本章一開始希望探討的問 題。

首先，軟體開發過程中必須避免侵害他人原始碼的著作權，這一點並非開放原始碼 社群特有的問題。原始碼的貢獻來自四面八方時，似乎較難確保原始碼並未侵害他人著 作權。專屬軟體陣營即常以這一點理由質疑開放原始碼模式的可行性。不過事實上，開 放原始碼的效益普及開來，傳統封閉式軟體同樣面臨原始碼來源的控管問題。例如，2003 年 IBM 併購加拿大一家軟體公司時，發現接收的專屬原始碼中含有數十個開放原始碼

軟體，併購金額隨即下降兩千萬美元¹⁰⁶。對資訊業而言，傳統專屬軟體可能含有開放原 始碼的程式，而硬體可以燒入軟體執行特定功能，因此，開放原始碼授權的糾紛除了可 能出現在專屬軟體上，也可能出現在硬體中，或者，出現在不同的開放原始碼授權之間。

SCO 案把這個問題聚焦在鎂光燈下，讓原始碼的控管逐漸成為實務上不可忽視的議題，

在資訊相關產業內，不管是否屬於開放原始碼社群，可能都無法置身事外。

軟體公司在尚未瞭解開放原始碼模式之前，往往對開放原始碼產生許多誤解。例 如：一般專屬軟體公司主要顧慮的是自己開發的程式如果沾上開放原始碼，是否必須被 迫跟著開放？有些反對開放原始碼的廠商抓著這種心裡將開放原始碼模式貼上「具病毒 感染力」的標籤，希望不知者因而躊躇不前。事實上，開放原始碼提供的是一種選擇，

如果併入外部的原始碼供自己內部使用，則沒有必須跟著開放的問題，但如果涉及再散 布，一般公眾授權為了防範搭便車的行為，則要求必須對外公開自己創作改良的部份。

至於細節的部份，應視不同的授權條款而定，例如，LGPL 允許其他程式以連結方式加 以散布、利用其原始碼，而無須公開自己的原始碼。

原始碼來源的問題並非只是存在於開放陣營與專屬軟體公司之間，即使理念接近的 開放原始碼社群中，也可能發生類似的著作權糾紛。實務上曾出現兩個知名的開放原始 碼團隊就原始碼疑遭剽竊發生爭執，可資參考。2003 年八月，網站伺服器軟體佔有率最 高的 Apache 軟體基金會成立新的開發計劃 Geronimo，吸引不少程式設計師加入，同年 十一月，Apache 軟體基金會收到另一家開放原始碼軟體公司 JBoss 的律師函¹⁰⁷，信中表 示，JBoss 注意到彼此的原始碼有多處雷同，而且之前曾經反映但未得到 Apache 的具體 回應。在資訊界，新一代的系統架構有兩大主流，一是微軟主導獨占的.NET 技術，一 是 Sun 創立且受大部分廠商支持的 J2EE 技術，JBoss 公司早期即投入 J2EE 陣營，並以

106 See O'Reilly Developer Weblogs, Who are the copyright infringers in open source?, at http://www.oreillynet.com/pub/wlg/4291#infringers (visited Apr. 1, 2004).

107 Letter from TESTA, HURWITZ & THIBEAULT, LLP, to Mr. Greg Stein, Chairman, The Apache Software Foundation (Oct. 31, 2003), available at

http://nagoya.apache.org/eyebrowse/[email protected]&msgId=11 19494&attachId=1 (visited May 6, 2004).

開放原始碼模式成功佔有一席之地，Apache 基金會在社群內享有盛名，新成立的 Geronimo 即針對 J2EE 技術而來，希望延續旗下資源再下一城，因而，無可避免地立刻 對包括 JBoss 在內的其他廠商形成競爭壓力。

開放原始碼軟體因將原始碼完全公開，不同軟體開發團隊彼此互相學習、模仿的情 形就屢見不鮮，而在互相學習中求進步本也就是開放原始碼運動的主要目的之一。但彼 此採用的公眾授權條款如果不同，相對地在授權的範圍或效力上也容易出現爭執。

Apache 和 JBoss 之間的爭議即肇因於此。JBoss 在律師函中列出程式碼實質相同或類似 之處，表示從某些程式碼片段的註解相同可推測 Geromino 的原始碼應從 JBoss 程式衍 生而來，此外，有些原始碼的變數名稱也與 JBoss 相同，而且相關的檔案又在核心範圍 內，因此 JBoss 認為最可能的原因便是 Geromino 直接抄襲 JBoss 原始碼而來。JBoss 的 軟體採用限制較少的 LGPL 授權方式，但衍生著作仍須遵守規定繼續使用 LGPL 授權，

因此對 JBoss 而言，Apache 基金會採用自己的 ASL (Apache Software License)¹⁰⁸散布 Geromino 而含有其原始碼，已違反 LGPL 條款的規定。LGPL 不允許原始碼以封閉形式 改良散布，Apache 的授權雖然仍為開放模式，不抵觸 LGPL 的精神，但 Apache 的 ASL 公眾授權類似 BSD，其限制不多，JBoss 的程式碼如果併入 Geromino，後續可能採取不 同的授權條款釋出，而違反當初 JBoss 採用 LGPL 的用意。JBoss 雖然保留 Apache 善意 侵害的可能，但要求 Apache 必須拿出對策妥善處置。Apache 基金會經過密切討論後認 為¹⁰⁹，JBoss 指控的一部分原始碼反而來自於 Apache 基金會先前的軟體，因此，應該注 意的是 JBoss 而不是 Apache，JBoss 該檢查其是否違反 ASL 公眾授權的規定。至於部份 雷同的程式碼則出於同一人之手，程式設計師以不同的授權將同一份作品貢獻到不同的 開發計劃並未違法，因為程式設計師未轉讓其所有權。另外，Apache 基金會認為還有 一部分的程式碼則毫無關連。

108 See Apache Software Foundation, Apache License, Version 2.0, at http://www.apache.org/licenses/ (visited Apr. 1, 2004)

109 See Apache Software Foundation, Board of Directors Meeting Minutes, Jan. 21, 2004, at

http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_01_21.txt (visited Apr. 1, 2004).

從以上案情可以看出，同樣在開放理念下，不同團體仍可能發生侵害著作權或違反 授權條款的情況，因此，採取開放原始碼模式時，除了留意著作權可能受專屬軟體公司 侵害外，對開放原始碼社群的成員也應注意。專屬軟體因原始碼封閉的關係，惡意侵害 著作權的比例可能較高，開放原始碼社群因原始碼開放的關係，惡意侵害的比例可能較 低，但即使是善意侵害，侵害著作權的結果仍為原始碼所有權人所不欲見。事實上，當 專屬原始碼軟體將開放原碼據為私有時，還比較容易進行價值對立的二元判斷，開放原 始碼社群往往可以口徑一致對外，但當社群內出現類似 Apache 與 JBoss 的爭議時，往 往夾雜著理念細節上的歧異，而較難判定內鬨中的是非，在這種情況下，可能必須求諸 於授權條款的細節，並回歸著作權法的規定，以保障原始碼所有人的權益。

法律風險的控管除了提高注意義務外，軟體問題的解答可能回到軟體技術本身¹¹⁰。 面對偵測原始碼來源及處理不同公眾授權的難處，2003 年一家新的軟體公司(Black Duck) 開始研究如何有效管理內部專屬原始碼與外來開放原始碼的合併或隔離，在這之前，開 放原始碼協會創始人 Eric Raymond 曾開發比對工具，協助程式設計師從大海撈針中找 出可疑的程式碼，Black Duck 公司所做的，則進一步納入公眾授權的偵測。尤其對許多 公司，法務單位對於資訊人員是否採用新的開放原始碼軟體，可能所知不多，如果疏於 智慧財產權的風險管理，等到事後出了問題，以軟體工程「越晚發現、越難解決」的原 則，再處理可能已緩不濟急。另外，在全球人力成本結構的轉變下，將軟體開發工作外 包已成趨勢，如何確保回收的程式沒有侵害他人智慧財產權，一樣是將來無可迴避的問 題¹¹¹。據估計，在社群最大集散地 SourceForge.net 上，2004 年初時約有七萬四千個開 發專案，註冊人數超過七百七十萬人，每週並以約 2~3%的速度成長，一週的軟體下載 量約三到四百萬次，這些統計尚未包括其他獨當一面的重要網站¹¹²。在公眾授權部分，

110 學者 Paul Goldstein 在探討著作權演進的書中（Copyright’s Highway），第六章標題為 The Answer to the Machine Is in the Machine，討論技術問題回到技術本身解決的可能性，在此採取類似觀點。

111 See Steven J. Vaughan-Nichols, Black Duck Hunts Open Source's Legal Pitfalls, Jan. 16, 2004, at http://www.eweek.com/article2/0,4149,1442452,00.asp (visited Apr. 1, 2004).

112 See, e.g., The Linux Kernel Archives, at http://www.kernel.org (visited Apr. 1, 2004); Apache Software Foundation , at http://www.apache.org (visited Apr. 1, 2004); MySQL, at http://www.mysql.org (visited Apr. 1,

約三分之二的軟體專案採用 GPL，其他三分之一可能採用開放原始碼協會認證通過的三 十多種授權之一，或者採用其他自創或散見的二十幾種授權¹¹³。如果忽略原始碼的控 管，開發軟體時所承擔的風險可能隨著開放原始碼數量的增加而提高。

原始碼的開放，固然增加了抄襲的誘因及引起新的著作權爭議，不過，整體而言，

開放模式――從網路到程式碼到其他著作――也會降低剽竊他人智慧財產的難度，因為 在一個開放環境裡這種行為比較容易遭人發現。例如，2003 年中一家出版社發現 SCO 未經授權，將其網路上開放但未允許散布的電子書，整章納入 SCO 自己的線上文件庫，

SCO 於 2004 年與出版社達成和解¹¹⁴。部分人士對於 SCO 一邊指控他人剽竊其原始碼，

一邊剽竊他人的著作，提出不少批評，並認為 SCO 在法院裡的可信度將因此受到影響。

同樣的，開放原始碼的軟體一旦發生抄襲或被抄襲的問題，因其原始碼是公開的，是非 的斷定也相對較為容易。

最後，以開放原始碼模式開發軟體時除了上述幾項考量外，現有著作權法對軟體的 保護範圍也值得注意。軟體的著作權侵害除了針對原始碼，程式設計上的其他要素也可 能成為侵害的對象。軟體中可受著作權保護的內容，受不同判例的影響，有寬、窄兩種

最後，以開放原始碼模式開發軟體時除了上述幾項考量外，現有著作權法對軟體的 保護範圍也值得注意。軟體的著作權侵害除了針對原始碼，程式設計上的其他要素也可 能成為侵害的對象。軟體中可受著作權保護的內容，受不同判例的影響，有寬、窄兩種