甲骨文诉谷歌案

**Google 有限責任公司訴甲骨文美國公司案**（_Google LLC v. Oracle America, Inc._），593 U.S. \_\_\_ (2021)，是一起以電腦代碼性質為焦點的著作權法案件。該案的訴爭物件是 Java 程式語言的部分應用程式介面（下簡稱 API），以及大約 11,000 條原始碼。這些介面及代碼最早由 Sun 系統公司所開發，目前甲骨文公司通過其附屬的甲骨文美國公司對其享有著作權。Google 在其開發的安卓（Android）作業系統的早期版本中使用了上述介面及代碼，但是在後來發布的安卓版本當中不再使用上述有著作權負擔的原始碼。至於甲骨文的 API，Google 雖承認存在使用行為，但主張其構成合理使用。

甲骨文公司發起訴訟，認為 API 屬於受著作權保護的內容，並以此為由主張 Google 賠償該公司 88 億美元，作為銷售侵權軟體及許可費的賠償。雖然在地方法院的兩次訴訟中，陪審團都作出了有利於 Google 的裁決，但聯邦巡迴區上訴法院推翻了這兩項判決，宣稱 API 受著作權保護，Google 在安卓中使用甲骨文的 API 不屬於合理使用範圍。Google 於 2019 年向美國最高法院提出上訴，最高法院同意於 2019 工作年度就介面是否受著作權保護及合理使用的問題對本案進行審理。由於 2019 冠狀病毒病疫情，本案的審理被推遲到 2020 年度。2021 年 4 月，美國最高法院以 6 票對 2 票的比例作出判決。在假定 API 受著作權保護的基礎上，法院就合理使用原則的四個要素對 Google 的行為進行審查，認定四項的結果都傾向 Google。因此，法院推翻了上訴法院的裁決，並將案件發回重審。

許多電腦程式和軟體庫（尤其是開源的程式）在開發過程中都利用了來自商業程式或競爭對手的 API。開發者重新設計介面的功能，以便實現不同系統或平台之間互操作性的要求。因此，本案對於科技和軟體行業具有重大意義。

## 背景

### Java 的開發

Sun 系統公司從 1990 年 12 月起開始開發 Java 系統。 該系統包括一種新的程式語言，一台虛擬機器，以及一組用於處理該語言的函式庫。通過 API，編程人員得以呼叫函式庫，獲知其應該向庫函式提供哪些資訊，可以期望獲得什麼結果。因此，他們不必再耗費精力研究他們所用的函式庫如何實現其功能。通過這些函式庫的共同作用，程式設計師就可以在 Java 虛擬機器上編寫並執行程式。就通常方式而言，在任意的 Java 虛擬機器上運用一套通用的函式庫，即可滿足互操作性的要求。正如 Sun 所標榜的那樣：「編寫一次，執行無阻（write once, run anywhere）」，程式設計師只需要建立一種版本的軟體，便可依託一組通用於所有 Java 虛擬機器的介面，在所有支援 Java 的電腦平台上執行。

Java 語言於 1995 年向公眾公布。通過「Sun 社群代碼許可」（Sun Community Source License），原始碼可以免費使用。但是，使用了 Java 原始碼的程式必須遵守 Java 的編程規範，商業性改編程式必須要得到 Sun 的許可。雖然人人都可以運用該語言編程，Sun 仍將標準版 Java 平台（Java SE）和微縮版 Java 平台（Java ME）的函式庫作為預先編譯的 Java 位元組碼，附帶其 API 一併提供給使用者，同時提供技術相容性套件（TCK）以檢查特定的實現是否符合 Java 的規範要求。

2006-2007 年間，來自編程人員越來越大的壓力迫使 Sun 改變了多種 Java 包的許可方式：使用帶有類路徑例外的 GNU 通用公共許可，向開發人員開放了創作改編程式所必要的權限，並賦予其在不同許可下發布應用程式的能力。這些改變的結果是，Sun 於 2007 年首次發布了開源版的 Java 開發組件（OpenJDK）。Sun 仍然保持了對語言和標準本身的高度控制，並且向商業使用者授權 TCK 等必要組件。 與此同時，Sun 轉變了其商業模式，與諾基亞、摩托羅拉、Research in Motion (即後來的黑莓公司）等企業簽署了許可協定。

### 安卓系統的開發

2003 年，安迪・魯賓、里奇・邁納、尼克・希爾斯和克里斯・懷特基於發展手機平台的目的創立了安卓有限公司。Google 於 2005 年收購了安卓公司。在安卓系統的開發過程中，Google 希望能夠加入 Java SE 的函式庫。Google 的執行董事長埃里克・施密特與 Sun 的總裁喬納森・I・施瓦茨就 Java 函式庫在安卓系統中的運用進行了談判。Sun 的許可費要價在 3000-5000 萬美元之間。施密特表示 Google 本來願意付許可費，但對 Sun 共同控制安卓系統的要求感到顧慮。根據 Google 方面的說法，Sun 希望對安卓系統能有更多的掌控權，對安卓系統的語言進行開源，讓第三方能夠更好利用其代碼。甲骨文公司則聲稱，Sun 之所以拒絕提供許可，是擔心 Google 會以分叉的方式創造 Google 專用的 Java 語言，導致與其他運用 Java 語言的程式無法互操作。這種行為無疑是對 Java 語言賴以立足的「編寫一次，執行無阻」原則的「咒詛」。

在這段時間，Sun 提供的 OpenJDK 服務仍不像 Java SE 版本那樣成熟完備。Google 沒有尋求 Java 的使用許可，而是以淨室設計的方式開發了一套 Java SE 的函式庫 —— 也就是說，Google 在不接觸 Sun 的原始碼的前提下，完全從頭開始開發了一套代碼。這些庫構成了安卓的 Dalvik 虛擬機器的核心。從虛擬機器的一部分當中可以發現 37 個 API 以及大約 11500 行被認為在 Java 中占有核心地位的代碼。這些代碼來自於 Apache Harmony 專案，該專案由 Apache 軟體基金會 (ASF) 主導，旨在提供淨室的 Java 開源實現。在此之前，Apache 基金會曾試圖向 Sun 尋求許可，使 Apache Harmony 成為官方支援的 Java 實現方式，但出於其所使用的 Apache 許可與 Java 的 GNU 許可不相容以及其他原因，未達成一致。Apache 試圖取得 Java TCK 的權限，以便利用 Sun 自己的實現方式對 Harmony 專案進行驗證，也未能成功。Google 曾聲稱其使用 Apache 的代碼是為了保障滿足編程者對其系統與 Java SE 互操作性的要求，但在第二次上訴庭審當中，Google 又表示，其使用這些代碼是出於其商業考慮，希望能儘快完成安卓系統，避免無謂地重新開發代碼。2011 年，Apache 基金會不再維持對 Apache Harmony 的控制，Google 接管了對這些庫的控制權。

2007 年 11 月 5 日，Google 發布了安卓平台的測試版，並在一周後發布了其軟體開發套件，在工具包當中他們載明使用了 Java 的某些技術。同一天，Sun 的總裁施瓦茨向 Google 表示祝賀。庭審期間，施瓦茨表示，儘管他們在安卓發布的時候就知道 Google 可能規避了他們的許可要求，他們仍然「決定咬牙支援安卓，讓所有支援安卓的人都知道，我們與他們共享同樣的價值觀。」

2009 年 4 月，甲骨文宣布了其收購 Sun 的計劃；收購於 2010 年 1 月完成。Java 語言讓甲骨文得以打入硬體行業。甲骨文的執行長拉里・埃里森更是將 Java 語言稱作「我們所買下的最重要的軟體資產」。在收購 Sun 之後，甲骨文繼續發展 Java，並且尋求發放許可的機會。

2013 年，Google 發布了安卓系統的 4.4 版本（KitKat），以 Android Runtime 作為執行時庫，取代了 Dalvik 虛擬機器。Android Runtime 由 Google 自己研發，與 Java 的原始碼毫無關係。但是，直至訴訟時為止，安卓仍然在繼續使用 Java SE 的 API。直到 2016 年發布的新版本 Android Nougat 作業系統中，Google 才完全將經由 Apache Harmony 管道獲得的代碼換成了開源的 OpenJDK 代碼。

### 美國著作權法的規定

#### 電腦程式的著作權保護

依據 1976 年修訂的美國著作權法，電腦程式屬於文字作品的一種，只要具有獨創性且被固定於有形的表達載體，即受到著作權法的保護。

與其他類型作品一樣，對電腦程式的保護不僅限於字面複製。程式的「結構、序列與組織方式」（structure, sequence and organization，簡稱 SSO）同樣受到保護。但是，對非字面元素的保護受到相當大的限制。除了公有領域的內容以外，僅具有功能性的內容也不受保護。但這一邊界存在模糊性。在 1996 年的蓮花公司訴寶藍公司案當中，最高法院以 4 票對 4 票的平局預設了下級法院關於使用者介面不受著作權保護的結論，但未形成有說服力的判例（使用者介面目前可通過專利保護）。在 1992 年的 CA 科技公司訴 Altai 公司案中，聯邦第二巡迴上訴法院開創了「抽象 — 過濾 — 比較測試法」（Abstraction-Filtration-Comparison test），以區分受著作權法保護的內容與不受著作權保護的僅具有功能性或者是位於公有領域的內容。當然，通過電腦程式呈現的圖文、聲音等仍然可以作為視聽作品保護。

#### 合理使用

依據現行美國著作權法，出於包括批評、評論、新聞報導、教學、研究等在內的目的而使用他人作品的合理使用行為不侵犯著作權。在個案判斷是否為合理使用時，必須考慮到下列因素：（1）使用的目的和性質，包括這種使用是具有商業性質或者是為了非營利的教育目的；（2）有著作權作品的性質；（3）同整個有著作權作品相比所使用的內容和數量；以及（4）這種使用對有著作權作品的潛在市場或價值所產生的影響。

在後來的司法實踐中，使用的目的和性質在多大程度上具有「轉換性」（transformative）往往受到極大關注。在 1994 年的坎貝爾訴阿卡夫 - 羅斯音樂公司案中，儘管嘻哈組合 2 Live Crew 對羅伊・奧比森名曲《噢，美麗女人》（_Oh, Pretty Woman_）的戲仿具有營利性，聯邦最高法院仍然認定該行為具有轉換性，構成合理使用。因此，僅證明複製行為具有商業目的，不一定能說明該行為不是合理使用。

## 第一階段訴訟：API 的著作權法屬性及專利法的適用

本案的第一階段從 2010 年起一直持續至 2015 年。甲骨文關於 API 可受到著作權保護的主張獲得了支援，但其關於專利侵權的主張則遭到拒絕。

### 地區法院第一次審理

2010 年 8 月 13 日，甲骨文向加利福尼亞北區聯邦地區法院起訴 Google 侵犯著作權及專利權。依據甲骨文方面的說法，Google 在明知沒有 Java 許可的情況下仍堅持開發安卓系統、挪用 Java 的 API，構成對甲骨文著作權的侵犯。甲骨文同時引證其名下 7 個由 Sun 開發、與 Java 相關聯的在先專利。其認為，Google 在僱傭 Sun 公司的前雇員開發安卓系統時本應留心這些專利。因此，甲骨文一方面主張金錢賠償，另一方面也主張針對 Google 使用涉侵權材料的行為下發禁制令。

本案被交由威廉・阿爾索普（William Alsup）法官審理。他將本案分為三部分處理：著作權問題，專利問題及損害賠償。

著作權問題的訴訟於 2012 年 4 月 16 日開始。這一階段的訴訟包含以下幾個相互獨立的侵權請求：一條九行長的 rangeCheck 函數式，若干個測試檔案，Java (API) 的結構、序列及組織方式，以及 API 文件。

甲骨文主張，Google 經由 Apache Harmony 專案所得的 37 條 API 資料均構成侵權。 經過兩周質證後，陪審團於 2012 年 5 月 7 日作出認定，認為 Google 就 API 的代碼、SSO 及文件而言均滿足侵權的要件。但是，就 Google 的行為是否屬於合理使用，陪審團內部未能達成一致。陪審團同時認為，儘管 Sun 及甲骨文的行為可能為 Google 創設了不需要向前者申請許可的信賴，但 Google 在開發安卓系統的時候實際上並未依託上述信賴。甲骨文方面向法院請求依法裁決（judgement as a matter of law, JMOL），在陪審團未達成一致的情形下對 Google 的合理使用抗辯不予受理，並推翻陪審團關於 8 份安全性相關檔案不侵權的認定（雖然陪審團認定不存在侵權，但 Google 在訴訟中承認存在字面複製）。阿爾索普法官同意了上述請求。Google 就 rangeCheck 函數式的問題提交了一份類似的依法裁決請求，但遭到了法官的拒絕。

專利問題的訴訟於 2012 年 5 月 7 日開始。訴訟涉及甲骨文的兩項專利：6,061,520 號專利（執行靜態初始化的方法及系統），以及 RE38104 號專利（解析資料參照的方法及裝置）。Google 主張了不侵權抗辯：針對前一專利，Google 認為，其使用語法分析是為了靜態初始化的最佳化，而非專利所涉的「類比執行」；針對後一專利，Google 認為其指令並不包含符號參照。本階段訴訟的陪審團成員與著作權階段訴訟相同；2012 年 5 月 23 日，該陪審團就全部專利侵權主張均作出了不侵權的認定。

2012 年 5 月 31 日，阿爾索普法官就前兩階段的訴訟作出了最終判決。與陪審團就 API 所作的認定不同，他認為 API 並不屬於著作權法的保護範圍：

> 「在著作權法的框架下，只要用於執行方法的特定代碼是不同的，則人人皆可任意編輯其自己的代碼，以實現 Java API 所涉方法能夠實現的功能與要求。即使聲明代碼或方法的標題行是相同的，亦無關緊要。」
> 
> 

阿爾索普法官同意陪審團關於 rangeCheck 函式與 8 份安全檔案存在著作權侵權的認定，但裁定甲骨文僅得以主張不超過 150,000 美元的法定賠償。

經由上述裁決及案件雙方的協商，裁定賠償金的訴訟階段不再開啟。2012 年 6 月，雙方同意，Google 就涉嫌侵權的小部分代碼無須支付法定賠償金。

### 上訴法院第一次判決

地區法院審理結束後不久，雙方均就阿爾索普法官裁決中未予受理的部分請求依法裁決，結果，甲骨文就該裁決提出上訴，Google 則就字面侵權問題提出交叉上訴。由於該案涉及專利問題，上訴自動交由聯邦巡迴區上訴法院管轄。案件於 2013 年 12 月 4 日進行了審理。 2014 年 5 月 9 日，上訴法院給出了判決。

上訴法院認為，著作權法為一切「固定於有形表達載體中的獨創性作品」提供保護。依據立法歷史解釋，著作權法中的文字作品也包括「電腦程式，只要其凝結了編程人員超出思想而構成獨創表達的創作」。獨創性是著作權法提供保護的首要條件。所以，法院「首先審查該表達是否為編程者獨創」，而在這一問題上 Google 已然承認自己的不利地位。法院由此得出結論，認為「甲骨文的 API 軟體套件整體是新穎的、獨創的，（其法律地位）類似於分類表」，推翻了地區法院關於 API 的結構、序列及組織方式不受著作權保護的結論。就 Google 提出交叉上訴的字面侵權請求，法院同樣作出了對甲骨文有利的判決，認為該複製行為並非「可忽略不計」之過。上訴法院將案件發回地區法院進行重審，以確定 Google 的使用行為是否適用合理使用抗辯。

2014 年 10 月，Google 請求美國聯邦最高法院聽審此案； 最高法院於 2015 年 6 月拒絕了該請求。

## 第二階段訴訟：合理使用

### 地區法院第二次審理

根據上訴法院的指令，地區法院於 2016 年 5 月 9 日再次開庭，在 API 受到著作權保護的前提下，審理 Google 的行為是否屬於合理使用。2016 年 5 月 23 日，雙方完成最終陳述，陪審團開始審議。甲骨文主張的賠償額高達 90 億美元。2016 年 5 月 26 日，陪審團認定安卓系統當中實現的 37 個 Java API 為合理使用，不構成對甲骨文的侵權。甲骨文宣布將會上訴，但在此之前，其先是提出否決陪審團認定的依法裁決請求，後又請求重新審理，但均未獲成功。2016 年 10 月 26 日，甲骨文正式提起上訴。

### 上訴法院第二次判決

聯邦巡迴區上訴法院於 2017 年審理了甲骨文的上訴。2018 年 3 月 27 日，法院作出了有利於甲骨文的裁決。

判決首先分析了法官和陪審團在審判合理使用問題時分別應起的作用；接著將關注點聚焦於其假定陪審團已然解決的事實問題，以及這些事實問題對法律問題的影響。上訴法院指出，在類似本案這種事實和法律問題相混合的案件中，陪審團的作用僅限於對事實做出決定。上訴法院應當審查陪審團採取合理標準所應得的結論是否與實際認定的結論相符，以及下級法官的裁決在法律上是否正確併合理。對法律與事實混合問題的標準審查涉及三部分：「一、確定案涉問題應適用的法律標準，以及與該標準相關的事實的類型；二、找出現有案件已掌握的事實；三、評估所發現的事實是否通過與涉案問題相應的法律測試。」

判決未再討論事實問題，而是直接認定，Google 逐字複製了 37 個 Java API 包的聲明代碼及 11,500 行受著作權保護的代碼，同時也複製了 Java API 包的結構、序列及組織方式。Google 亦承認複製的軟體具有創造性和原創性。就法律問題而言，上訴法院綜合衡量了既有認定合理使用的四項標準，並認為，即使陪審團決定的所有事實都對 Google 有利，Google 對 Java 代碼的使用仍不屬於合理使用。

1. 就涉案行為的目的及性質而言，Google 的使用不符合「轉換性使用」的要求，因為其使用目的與著作權人原有的使用相同，甚至沒有些微的更改或重寫。即使從建立新平台的意義上說，安卓系統的使用也沒有轉換性，因為市場上早有其他基於 Java 的智慧型手機。
2. 就著作權作品的性質而言，上訴法院暫且採納了陪審團的認定，認為 API 包雖具有一定新穎性，但其同樣具有相當的功能性，由此應作出對 Google 有利的判決。儘管如此，法院援引了聯邦第九巡迴上訴法院的意見，認為這一要素在合理使用的權衡中並不具決定性。法院認為，過於強調這一要素將與國會立法長期以來對軟體著作權的保護態度相衝突。
3. 該使用不滿足最小限度複製的要求，因為在被複製的 11,500 行代碼中，只需要 170 行即可實現 Google 的目的。即便將第三方互操作性的問題納入考慮，法院仍然認為，Google 並未做出實質性的努力以實現第三方互操作性的目的，甚至試圖隔斷安卓系統與其他 Java 專案的互操作性。
4. 這種使用可能對 Sun 和甲骨文的市場造成損害，因為可以預見，甲骨文將不得不與一款由自己所屬電腦語言衍生所得的免費產品開展價格競爭，付出大幅折扣以及本不期望的合同條款作為代價。

與 Google 的合理使用主張相反，法院認定，Google 的行為一方面意在加強其安卓平台對通常熟悉 Java 的現有開發人員的吸引力，另一方面也是為了避免重寫代碼的重複勞動 —— 他們本應這麼做，而且真正實現 API 功能的代碼僅占了 170 行。法院指出，僅僅「讓自己變得輕鬆」，顯然不屬於合理使用的有效理由。同時，安卓向公眾免費提供的事實也不能改變 Google 商業性使用目的的認定。 Oracle 甲骨文有專門用於吸引程式設計師的許可計劃及商業化的平台，向希望在競爭性平台中使用 API 或將其嵌入電子裝置的人收取許可費。為貫徹「編寫一次，執行無阻」的理念，甲骨文對被許可方提出了嚴格的相容性要求。

最終，上訴法院將案件發回地方法院，以確定 Google 應支付給甲骨文的損害賠償金額。

## 最高法院

Google 於 2019 年 1 月向美國最高法院提交了調卷令狀請求，挑戰上訴法院作出的兩項有利於甲骨文的裁決。Google 將本案的重點集中於：API 等軟體介面是否受到著作權保護，以及 Google 對 Java API 的使用是否如同陪審團認定的那樣屬於合理使用。在 2019 年 4 月的一份判令中，最高法院要求美國司法部副部長提交一份法院之友意見書，以概述政府對本案的立場。川普政府支援甲骨文，敦促法院拒絕頒發調卷令。微軟、Mozilla 公司、紅帽公司等企業則提交了支援 Google 的意見書。IBM、電腦與通信行業協會、網際網路協會、汽車維護協會以及由超過 150 名學者和電腦專業人士組成的團體也提交了支援 Google 的意見書，警告稱，有利於甲骨文的判決將整體性損害電腦行業。

最高法院於 2019 年 11 月 15 日批准了調卷令，原本預定於 2020 年 3 月 24 日審理此案。但由於 COVID-19 流行，最高法院於 2020 年 3 月 16 日推遲了 3 月的庭辯日程；並於後來宣布將包括本案在內的幾個案件由 2019-20 年度推遲到 2020-21 年度的第一周審理。鑑於聯邦地區法院曾推翻陪審團的事實認定，最高法院後來又要求各方就 Google 提出的第七修正案問題另外提交意見書。

最高法院於 2020 年 10 月 7 日聽取了口頭辯論。由於 COVID-19 持續流行，口頭辯論通過電話會議進行。 露絲・貝德爾・金斯伯格法官在此前一個月去世，其繼任者埃米・科尼・巴雷特法官的任命尚未被確認，因此巴雷特法官並未參與本案。依據對庭審的觀察報導，法官在著作權問題上似乎支援甲骨文，但他們也尊重微軟支援 Google 的論點（微軟的意見書辯稱，傾向甲骨文的裁決可能會顛覆軟體行業）。法官們的部分問題亦聚焦於著作權法的思想 — 表達二分原則以及合併原則如何適用於 API。尼爾・戈薩奇法官還重點關注了第七修正案的問題，以及聯邦巡迴區法院推翻陪審團裁決是否正確的問題。

### 判決

最高法院於 2021 年 4 月 5 日，以 6 票對 2 票的多數判決 Google 對 Java API 的使用屬於合理使用，推翻了聯邦巡迴區上訴法院的判決，並將案件發回進一步審理。史蒂芬・布雷耶法官撰寫了法庭多數意見。

判決認可了上訴法院關於合理使用審查的意見，認為合理使用兼具事實問題和法律問題兩面性，陪審團僅認定事實問題，但能否根據事實得出合理使用的結論仍然由法官決定。也因此，上訴法院推翻陪審團裁決的行為與憲法第七修正案「由陪審團裁決的事實…… 不得重新審查」的規定並不衝突，Google 要求由陪審團對合理使用作最終決定的主張沒有法律依據。

布雷耶假定 API 受到著作權保護，進而直接對衡量合理使用的四個因素進行了審查：

1. 受著作權保護作品的性質：布雷耶認為，API 僅作為聲明代碼而非具體的實現，在著作權法的語境下，它發揮類似於杜威十進位圖書分類法的「組織功能」，這一性質導致合理使用更易適用。
2. 使用的目的和性質：布雷耶表示，Google 使用並改造 Java API 的行為「目的在於擴充基於安卓系統的智慧型手機的功能和實用性」，而這「創造了一個能讓程式設計師輕鬆使用的新平台」。他還寫道，Google 對 Java API 的使用「僅以實現智慧型手機程式的實用性所需為限」。
3. 被複製受保護內容的數量和實質性：布雷耶認為，Google 只使用了大約 0.4% 的 Java 原始碼，可忽略不計。針對實質性的問題，他寫道，Google 沒有複製 Java 實現功能所需的核心代碼：「Google 複製這些代碼，不是因為它們多麼有創造力或多麼美觀，甚至（某種程度上）也不是因為它們自身的目的。Google 複製這些代碼只是因為程式設計師已經習慣了使用 Java SE，如果沒有它們，將很難…… 吸引程式設計師使用…… 安卓系統。」
4. 複製行為的市場效應：布雷耶認為，Google 在複製 Java API 時，尚不清楚安卓系統是否會成功，安卓系統不應被視為 Java 的替代品，而應為在不同平台上執行的產品。布雷耶進一步表示，如果判決支援甲骨文，「可能會對公眾造成威脅」，因為「只有甲骨文將掌握關鍵內容。這一結果很可能為甲骨文（或其他擁有電腦介面著作權的公司）帶來極高的利益。……（但是）這種控制力與作為著作權法基礎的激勵創造的目標相衝突，而不是進一步助益該目標。」

布雷耶就此認定，Google 對 API 的使用滿足所有四個因素的要求，Google 的使用「只是允許使用者將他們積累的才能用於新的轉換性的平台所必需的」。 既然 Google 的複製行為構成合理使用，沒有違反著作權法，那麼認定 API 是否受著作權保護亦不再必要。

克拉倫斯・托馬斯大法官撰寫了一份反對意見，塞繆爾・阿利托大法官亦聯名支援該意見。托馬斯寫道，多數意見在實施代碼和聲明代碼之間劃分了一種國會立法者未曾允許的區別，進而，「這種扭曲的分析導致了以下結果：很難想像聲明代碼還能在什麼情況下受到著作權保護。」 他進一步表示，在他自己的合理使用分析下，「Google 對受著作權保護代碼的使用絕非合理。」

## 影響

Google 與甲骨文的訴訟為科技行業密切關注。鑑於 API 的大量使用，如果司法判決有利於甲骨文，可能對過去和未來的軟體開發都產生重大影響。包括 Google 及其他基於安卓系統的開發人員在內，反對上訴法院判決的人或是從互操作性、對軟體創新的影響等各方面提出了他們的擔憂，或是指出，既有介面的著作權人可能以其權利惡意挾持那些善意信賴相應標準開放性的下游開發者。如果 API 受到著作權保護，下游企業將不得不故意採用不相容的標準以免面臨複雜的訴訟風險。而這與當前的行業趨勢 ——​​提高不同服務之間的互操作性，允許程式之間的交流，為終端使用者建設更加一體化的平台 —— 是不相容的。

《連線》雜誌以 Linux 作業系統為例：Linux 是完全開源的，但它所採用的 POSIX 是一套模仿 Unix 作業系統以實現高度互操作性的 API。編程人員只需要編寫一組代碼，就可以在具有相同 API 的任何系統上編譯，即使系統的計算架構不同。如果甲骨文勝訴，則 Unix 的當前所有者 Micro Focus 公司可能會向所有試圖將基於 POSIX 的作業系統的開發者尋求賠償。

行業和法律專家們擔憂甲骨文的勝利可能會對軟體開發產生寒蟬效應：著作權所有者將得以阻止對 API 實施反向工程、開發可以互操作的替代產品，而這種做法在開源軟體開發中很常見。 但專家同時擔心，對 Google 有利的判決會削弱對代碼開發者的著作權保護，讓資源豐富的企業能輕易開發改進小企業的產品，減損對行業創新的激勵。

## 參考文獻

## 外部連結

* 美國最高法院判決全文 （頁面存檔備份，存於網際網路檔案館）