谷歌有限責任公司訴甲骨文美國公司案（Google LLC v. Oracle America, Inc.），593 U.S. ___ (2021)，[1]是一起以電腦程式性質為焦點的著作權法案件。該案的訴爭對象是Java程式語言的部分應用程式介面（下簡稱API），以及大約11,000條原始碼。這些介面及程式碼最早由Sun系統公司所開發，目前甲骨文公司通過其附屬的甲骨文美國公司對其享有著作權。谷歌在其開發的安卓（Android）作業系統的早期版本中使用了上述介面及程式碼，但是在後來發布的安卓版本當中不再使用上述有著作權負擔的原始碼。至於甲骨文的API，谷歌雖承認存在使用行為，但主張其構成合理使用。
| 谷歌有限責任公司訴甲骨文美國公司案 | |
|---|---|
 | |
| 辯論：2020年10月7日 判決：2021年4月5日 | |
| 案件全名 | 谷歌有限責任公司訴甲骨文美國公司案（Google LLC v. Oracle America, Inc.） |
| 訴訟記錄號 | 18-956 |
| 引註案號 | 593 U.S. ___ |
| 既往案件 |
|
| 後續案件 | On remand, Oracle Am., Inc. v. Google LLC, No. 2017-1118, 2021 WL 1941874 (Fed. Cir. May 14, 2021) |
| 提出問題 | |
| |
| 法庭判決 | |
| 谷歌對Java SE應用程式介面的複製，以內容上僅使編程人員得以將其積累的知識運用於新的、具有轉換性的程式為限，在法律上構成對該介面的合理使用。 | |
| 最高法院法官 | |
| 法庭意見 | |
| 多數意見 | 布雷耶 聯名：羅伯茨，索托馬約爾，卡根，戈薩奇，卡瓦諾 |
| 不同意見 | 托馬斯 聯名：阿利托 |
| 巴雷特沒有參與該案件。 | |
| 適用法條 | |
| 17 U.S.C.§102(b)；17 U.S.C. §107 | |
甲骨文公司發起訴訟，認為API屬於受著作權保護的內容，並以此為由主張谷歌賠償該公司88億美元，作為銷售侵權軟體及許可費的賠償。雖然在地方法院的兩次訴訟中，陪審團都作出了有利於谷歌的裁決，但聯邦巡迴區上訴法院推翻了這兩項判決，宣稱API受著作權保護，谷歌在安卓中使用甲骨文的API不屬於合理使用範圍。谷歌於2019年向美國最高法院提出上訴，最高法院同意於2019工作年度就介面是否受著作權保護及合理使用的問題對本案進行審理。由於2019冠狀病毒病疫情，本案的審理被推遲到2020年度。2021年4月，美國最高法院以6票對2票的比例作出判決。在假定API受著作權保護的基礎上，法院就合理使用原則的四個要素對谷歌的行為進行審查，認定四項的結果都傾向谷歌。因此，法院推翻了上訴法院的裁決，並將案件發回重審。[2]
許多電腦程式和軟體庫（尤其是開源的程式）在開發過程中都利用了來自商業程式或競爭對手的API。開發者重新設計介面的功能，以便實現不同系統或平台之間互操作性的要求。因此，本案對於科技和軟體行業具有重大意義。
背景
Sun系統公司從1990年12月起開始開發Java系統。[3] 該系統包括一種新的程式語言，一台虛擬機器，以及一組用於處理該語言的函式庫。[4]通過API，編程人員得以呼叫函式庫，獲知其應該向庫函式提供哪些資訊，可以期望獲得什麼結果。因此，他們不必再耗費精力研究他們所用的函式庫如何實現其功能。通過這些函式庫的共同作用，程式設計師就可以在Java虛擬機器上編寫並執行程式。就通常方式而言，在任意的Java虛擬機器上運用一套通用的函式庫，即可滿足互操作性的要求。正如Sun所標榜的那樣：「編寫一次，執行無阻（write once, run anywhere）」，程式設計師只需要建立一種版本的軟體，便可依託一組通用於所有Java虛擬機器的介面，在所有支援Java的電腦平台上執行。
Java語言於1995年向公眾公布。通過「Sun社群代碼許可」（Sun Community Source License），原始碼可以免費使用。但是，使用了Java原始碼的程式必須遵守Java的編程規範，商業性改編程式必須要得到Sun的許可。[5][6]雖然人人都可以運用該語言編程，Sun仍將標準版Java平台（Java SE）和微縮版Java平台（Java ME）的函式庫作為預先編譯的Java位元組碼，附帶其API一併提供給使用者，同時提供技術相容性套件（TCK）以檢查特定的實現是否符合Java的規範要求。[7]
2006-2007年間，來自編程人員越來越大的壓力迫使Sun改變了多種Java包的許可方式：使用帶有類路徑例外的GNU通用公共許可，向開發人員開放了創作改編程式所必要的權限，並賦予其在不同許可下發布應用程式的能力。這些改變的結果是，Sun於2007年首次發布了開源版的Java開發組件（OpenJDK）。Sun仍然保持了對語言和標準本身的高度控制，並且向商業使用者授權TCK等必要組件。[6] 與此同時，Sun轉變了其商業模式，與諾基亞、摩托羅拉、Research in Motion（即後來的黑莓公司）等企業簽署了許可協定。[8]
2003年，安迪·魯賓、里奇·邁納、尼克·希爾斯和克里斯·懷特基於發展手機平台的目的創立了安卓有限公司。[9][10]谷歌於2005年收購了安卓公司。[10]在安卓系統的開發過程中，谷歌希望能夠加入Java SE的函式庫。谷歌的執行董事長埃里克·施密特與Sun的總裁喬納森·I·施瓦茨就Java函式庫在安卓系統中的運用進行了談判。Sun的許可費要價在3000-5000萬美元之間。施密特表示谷歌本來願意付許可費，但對Sun共同控制安卓系統的要求感到顧慮。[11][12][13]根據谷歌方面的說法，Sun希望對安卓系統能有更多的掌控權，對安卓系統的語言進行開源，讓第三方能夠更好利用其代碼。[11]甲骨文公司則聲稱，Sun之所以拒絕提供許可，是擔心谷歌會以分叉的方式創造谷歌專用的Java語言，導致與其他運用Java語言的程式無法互操作。這種行為無疑是對Java語言賴以立足的「編寫一次，執行無阻」原則的「咒詛」。[14]
在這段時間，Sun提供的OpenJDK服務仍不像Java SE版本那樣成熟完備。谷歌沒有尋求Java的使用許可，而是以淨室設計的方式開發了一套Java SE的函式庫——也就是說，谷歌在不接觸Sun的原始碼的前提下，完全從頭開始開發了一套代碼。這些庫構成了安卓的Dalvik虛擬機器的核心。從虛擬機器的一部分當中可以發現37個API以及大約11500行被認為在Java中占有核心地位的代碼。這些代碼來自於Apache Harmony專案，該專案由Apache軟體基金會(ASF)主導，旨在提供淨室的Java開源實現。在此之前，Apache基金會曾試圖向Sun尋求許可，使Apache Harmony成為官方支援的Java實現方式，但出於其所使用的Apache許可與Java的GNU許可不相容以及其他原因，未達成一致。Apache試圖取得Java TCK的權限，以便利用Sun自己的實現方式對Harmony專案進行驗證，也未能成功。[15][16]谷歌曾聲稱其使用Apache的代碼是為了保障滿足編程者對其系統與Java SE互操作性的要求，但在第二次上訴庭審當中，谷歌又表示，其使用這些代碼是出於其商業考慮，希望能儘快完成安卓系統，避免無謂地重新開發代碼。2011年，Apache基金會不再維持對Apache Harmony的控制，谷歌接管了對這些庫的控制權。
2007年11月5日，谷歌發布了安卓平台的測試版，並在一周後發布了其軟體開發套件，在工具包當中他們載明使用了Java的某些技術。[17][18][19]同一天，Sun的總裁施瓦茨向谷歌表示祝賀。[20]庭審期間，施瓦茨表示，儘管他們在安卓發布的時候就知道谷歌可能規避了他們的許可要求，他們仍然「決定咬牙支援安卓，讓所有支援安卓的人都知道，我們與他們共享同樣的價值觀。」[8]
2009年4月，甲骨文宣布了其收購Sun的計劃；收購於2010年1月完成。[21]Java語言讓甲骨文得以打入硬體行業。甲骨文的執行長拉里•埃里森更是將Java語言稱作「我們所買下的最重要的軟體資產」。[22]在收購Sun之後，甲骨文繼續發展Java，並且尋求發放許可的機會。
2013年，谷歌發布了安卓系統的4.4版本（KitKat），以Android Runtime作為執行時庫，取代了Dalvik虛擬機器。Android Runtime由谷歌自己研發，與Java的原始碼毫無關係。[23]但是，直至訴訟時為止，安卓仍然在繼續使用Java SE的API。直到2016年發布的新版本Android Nougat作業系統中，谷歌才完全將經由Apache Harmony管道獲得的代碼換成了開源的OpenJDK代碼。[24][25]
依據1976年修訂的美國著作權法，電腦程式屬於文字作品的一種，只要具有獨創性且被固定於有形的表達載體，即受到著作權法的保護。
與其他類型作品一樣，對電腦程式的保護不僅限於字面複製。程式的「結構、序列與組織方式」（structure, sequence and organization，簡稱SSO）同樣受到保護。但是，對非字面元素的保護受到相當大的限制。除了公有領域的內容以外，僅具有功能性的內容也不受保護。但這一邊界存在模糊性。在1996年的蓮花公司訴寶藍公司案當中，最高法院以4票對4票的平局預設了下級法院關於使用者介面不受著作權保護的結論，但未形成有說服力的判例[26]（使用者介面目前可通過專利保護）。在1992年的CA科技公司訴Altai公司案中，聯邦第二巡迴上訴法院開創了「抽象—過濾—比較測試法」（Abstraction-Filtration-Comparison test）[27]，以區分受著作權法保護的內容與不受著作權保護的僅具有功能性或者是位於公有領域的內容。當然，通過電腦程式呈現的圖文、聲音等仍然可以作為視聽作品保護。
依據現行美國著作權法，出於包括批評、評論、新聞報道、教學、研究等在內的目的而使用他人作品的合理使用行為不侵犯著作權。在個案判斷是否為合理使用時，必須考慮到下列因素：（1）使用的目的和性質，包括這種使用是具有商業性質或者是為了非營利的教育目的；（2）有著作權作品的性質；（3）同整個有著作權作品相比所使用的內容和數量；以及（4）這種使用對有著作權作品的潛在市場或價值所產生的影響。[28]
在後來的司法實踐中，使用的目的和性質在多大程度上具有「轉換性」（transformative）往往受到極大關注。在1994年的坎貝爾訴阿卡夫-羅斯音樂公司案中，儘管嘻哈組合2 Live Crew對羅伊·奧比森名曲《噢，美麗女人》（Oh, Pretty Woman）的戲仿具有營利性，聯邦最高法院仍然認定該行為具有轉換性，構成合理使用。[29]因此，僅證明複製行為具有商業目的，不一定能說明該行為不是合理使用。
第一階段訴訟：API的著作權法屬性及專利法的適用
本案的第一階段從2010年起一直持續至2015年。甲骨文關於API可受到著作權保護的主張獲得了支援，但其關於專利侵權的主張則遭到拒絕。
2010年8月13日，甲骨文向加利福尼亞北區聯邦地區法院起訴谷歌侵犯著作權及專利權。依據甲骨文方面的說法，谷歌在明知沒有Java許可的情況下仍堅持開發安卓系統、挪用Java的API，構成對甲骨文著作權的侵犯。甲骨文同時引證其名下7個由Sun開發、與Java相關聯的在先專利。其認為，谷歌在僱傭Sun公司的前雇員開發安卓系統時本應留心這些專利。因此，甲骨文一方面主張金錢賠償，另一方面也主張針對谷歌使用涉侵權材料的行為下發禁制令。[30][31]
本案被交由威廉·阿爾索普（William Alsup）法官審理。他將本案分為三部分處理：著作權問題，專利問題及損害賠償。
著作權問題的訴訟於2012年4月16日開始。這一階段的訴訟包含以下幾個相互獨立的侵權請求：一條九行長的rangeCheck函數式，若干個測試檔案，Java (API)的結構、序列及組織方式，以及API文件。
甲骨文主張，谷歌經由Apache Harmony專案所得的37條API資料均構成侵權。[12] 經過兩周質證後，陪審團於2012年5月7日作出認定，認為谷歌就API的代碼、SSO及文件而言均滿足侵權的要件。但是，就谷歌的行為是否屬於合理使用，陪審團內部未能達成一致。陪審團同時認為，儘管Sun及甲骨文的行為可能為谷歌創設了不需要向前者申請許可的信賴，但谷歌在開發安卓系統的時候實際上並未依託上述信賴。[32]甲骨文方面向法院請求依法裁決（judgement as a matter of law, JMOL），在陪審團未達成一致的情形下對谷歌的合理使用抗辯不予受理，並推翻陪審團關於8份安全性相關檔案不侵權的認定（雖然陪審團認定不存在侵權，但谷歌在訴訟中承認存在字面複製）。阿爾索普法官同意了上述請求。谷歌就rangeCheck函數式的問題提交了一份類似的依法裁決請求，但遭到了法官的拒絕。[33]
專利問題的訴訟於2012年5月7日開始。[34]訴訟涉及甲骨文的兩項專利：6,061,520號專利（執行靜態初始化的方法及系統）[35]，以及RE38104號專利（解析資料參照的方法及裝置）[36]。谷歌主張了不侵權抗辯：針對前一專利，谷歌認為，其使用語法分析是為了靜態初始化的最佳化，而非專利所涉的「類比執行」；針對後一專利，谷歌認為其指令並不包含符號參照。本階段訴訟的陪審團成員與著作權階段訴訟相同[34]；2012年5月23日，該陪審團就全部專利侵權主張均作出了不侵權的認定。[37][38][39]
2012年5月31日，阿爾索普法官就前兩階段的訴訟作出了最終判決。與陪審團就API所作的認定不同，他認為API並不屬於著作權法的保護範圍：
「在著作權法的框架下，只要用於執行方法的特定代碼是不同的，則人人皆可任意編輯其自己的代碼，以實現Java API所涉方法能夠實現的功能與要求。即使聲明代碼或方法的標題行是相同的，亦無關緊要。」[12]
阿爾索普法官同意陪審團關於rangeCheck函式與8份安全檔案存在著作權侵權的認定，但裁定甲骨文僅得以主張不超過150,000美元的法定賠償。[40][41]
經由上述裁決及案件雙方的協商，裁定賠償金的訴訟階段不再開啟。2012年6月，雙方同意，谷歌就涉嫌侵權的小部分代碼無須支付法定賠償金。[42][43]
地區法院審理結束後不久，雙方均就阿爾索普法官裁決中未予受理的部分請求依法裁決，結果，甲骨文就該裁決提出上訴，谷歌則就字面侵權問題提出交叉上訴。由於該案涉及專利問題，上訴自動交由聯邦巡迴區上訴法院管轄。[44][45]案件於2013年12月4日進行了審理。[46][47] 2014年5月9日，上訴法院給出了判決。[48]
上訴法院認為，著作權法為一切「固定於有形表達載體中的獨創性作品」提供保護。依據立法歷史解釋，著作權法中的文字作品也包括「電腦程式，只要其凝結了編程人員超出思想而構成獨創表達的創作」。獨創性是著作權法提供保護的首要條件。所以，法院「首先審查該表達是否為編程者獨創」，而在這一問題上谷歌已然承認自己的不利地位。法院由此得出結論，認為「甲骨文的API軟體套件整體是新穎的、獨創的，（其法律地位）類似於分類表」，推翻了地區法院關於API的結構、序列及組織方式不受著作權保護的結論。就谷歌提出交叉上訴的字面侵權請求，法院同樣作出了對甲骨文有利的判決，認為該複製行為並非「可忽略不計」之過。上訴法院將案件發回地區法院進行重審，以確定谷歌的使用行為是否適用合理使用抗辯。[48][49]
第二階段訴訟：合理使用
根據上訴法院的指令，地區法院於2016年5月9日再次開庭，在API受到著作權保護的前提下，審理谷歌的行為是否屬於合理使用。[52][53]2016年5月23日，雙方完成最終陳述，陪審團開始審議。甲骨文主張的賠償額高達90億美元。[54][55][56][57][58][59]2016年5月26日，陪審團認定安卓系統當中實現的37個Java API為合理使用，不構成對甲骨文的侵權。[60]甲骨文宣布將會上訴，[61]但在此之前，其先是提出否決陪審團認定的依法裁決請求，[62]後又請求重新審理，[63][64]但均未獲成功。2016年10月26日，甲骨文正式提起上訴。[65]
聯邦巡迴區上訴法院於2017年審理了甲骨文的上訴。2018年3月27日，法院作出了有利於甲骨文的裁決。[66]
判決首先分析了法官和陪審團在審判合理使用問題時分別應起的作用；接著將關注點聚焦於其假定陪審團已然解決的事實問題，以及這些事實問題對法律問題的影響。[66]上訴法院指出，在類似本案這種事實和法律問題相混合的案件中，陪審團的作用僅限於對事實做出決定。上訴法院應當審查陪審團採取合理標準所應得的結論是否與實際認定的結論相符，以及下級法官的裁決在法律上是否正確併合理。對法律與事實混合問題的標準審查涉及三部分：「一、確定案涉問題應適用的法律標準，以及與該標準相關的事實的類型；二、找出現有案件已掌握的事實；三、評估所發現的事實是否通過與涉案問題相應的法律測試。」
判決未再討論事實問題，而是直接認定，谷歌逐字複製了37個Java API包的聲明代碼及11,500行受著作權保護的代碼，同時也複製了Java API包的結構、序列及組織方式。谷歌亦承認複製的軟體具有創造性和原創性。就法律問題而言，上訴法院綜合衡量了既有認定合理使用的四項標準，並認為，即使陪審團決定的所有事實都對谷歌有利，谷歌對Java代碼的使用仍不屬於合理使用。
- 就涉案行為的目的及性質而言，谷歌的使用不符合「轉換性使用」的要求，因為其使用目的與著作權人原有的使用相同，甚至沒有些微的更改或重寫。即使從建立新平台的意義上說，安卓系統的使用也沒有轉換性，因為市場上早有其他基於Java的智慧型手機。
- 就著作權作品的性質而言，上訴法院暫且採納了陪審團的認定，認為API包雖具有一定新穎性，但其同樣具有相當的功能性，由此應作出對谷歌有利的判決。儘管如此，法院援引了聯邦第九巡迴上訴法院的意見，認為這一要素在合理使用的權衡中並不具決定性。法院認為，過於強調這一要素將與國會立法長期以來對軟體著作權的保護態度相衝突。
- 該使用不滿足最小限度複製的要求，因為在被複製的11,500行代碼中，只需要170行即可實現谷歌的目的。即便將第三方互操作性的問題納入考慮，法院仍然認為，谷歌並未做出實質性的努力以實現第三方互操作性的目的，甚至試圖隔斷安卓系統與其他Java專案的互操作性。[14]
- 這種使用可能對Sun和甲骨文的市場造成損害，因為可以預見，甲骨文將不得不與一款由自己所屬電腦語言衍生所得的免費產品開展價格競爭，付出大幅折扣以及本不期望的合同條款作為代價。
與谷歌的合理使用主張相反，法院認定，谷歌的行為一方面意在加強其安卓平台對通常熟悉Java的現有開發人員的吸引力，另一方面也是為了避免重寫代碼的重複勞動——他們本應這麼做，而且真正實現API功能的代碼僅占了170行。法院指出，僅僅「讓自己變得輕鬆」，顯然不屬於合理使用的有效理由。同時，安卓向公眾免費提供的事實也不能改變谷歌商業性使用目的的認定。[67] Oracle甲骨文有專門用於吸引程式設計師的許可計劃及商業化的平台，向希望在競爭性平台中使用API或將其嵌入電子裝置的人收取許可費。為貫徹「編寫一次，執行無阻」的理念，甲骨文對被許可方提出了嚴格的相容性要求。[68]
最終，上訴法院將案件發回地方法院，以確定谷歌應支付給甲骨文的損害賠償金額。[67]
最高法院
谷歌於2019年1月向美國最高法院提交了調卷令狀請求，挑戰上訴法院作出的兩項有利於甲骨文的裁決。谷歌將本案的重點集中於：API等軟體介面是否受到著作權保護，以及谷歌對Java API的使用是否如同陪審團認定的那樣屬於合理使用。[69]在2019年4月的一份判令中，最高法院要求美國司法部副部長提交一份法院之友意見書，以概述政府對本案的立場。[70]川普政府支援甲骨文，敦促法院拒絕頒發調卷令。微軟、Mozilla公司、紅帽公司等企業則提交了支援谷歌的意見書。[71]IBM、電腦與通訊行業協會、網際網路協會、汽車維護協會以及由超過150名學者和電腦專業人士組成的團體也提交了支援谷歌的意見書，警告稱，有利於甲骨文的判決將整體性損害電腦行業。[72]
最高法院於2019年11月15日批准了調卷令，原本預定於2020年3月24日審理此案。[73][74][75]但由於COVID-19流行，最高法院於2020年3月16日推遲了3月的庭辯日程；並於後來宣布將包括本案在內的幾個案件由2019—20年度推遲到2020—21年度的第一周審理。[76][77][78]鑑於聯邦地區法院曾推翻陪審團的事實認定，最高法院後來又要求各方就谷歌提出的第七修正案問題另外提交意見書。[79]
最高法院於2020年10月7日聽取了口頭辯論。由於COVID-19持續流行，口頭辯論通過電話會議進行。[80]露絲·貝德爾·金斯伯格法官在此前一個月去世，其繼任者埃米·科尼·巴雷特法官的任命尚未被確認，因此巴雷特法官並未參與本案。[81]依據對庭審的觀察報道，法官在著作權問題上似乎支援甲骨文，但他們也尊重微軟支援谷歌的論點（微軟的意見書辯稱，傾向甲骨文的裁決可能會顛覆軟體行業）。法官們的部分問題亦聚焦於著作權法的思想—表達二分原則以及合併原則如何適用於API。尼爾·戈薩奇法官還重點關注了第七修正案的問題，以及聯邦巡迴區法院推翻陪審團裁決是否正確的問題。[80][82]
最高法院於2021年4月5日，以6票對2票的多數判決谷歌對Java API的使用屬於合理使用，推翻了聯邦巡迴區上訴法院的判決，並將案件發回進一步審理。史蒂芬·布雷耶法官撰寫了法庭多數意見。
判決認可了上訴法院關於合理使用審查的意見，認為合理使用兼具事實問題和法律問題兩面性，陪審團僅認定事實問題，但能否根據事實得出合理使用的結論仍然由法官決定。也因此，上訴法院推翻陪審團裁決的行為與憲法第七修正案「由陪審團裁決的事實……不得重新審查」的規定並不衝突，谷歌要求由陪審團對合理使用作最終決定的主張沒有法律依據。
布雷耶假定API受到著作權保護，進而直接對衡量合理使用的四個因素進行了審查：[83][84]
- 受著作權保護作品的性質：布雷耶認為，API僅作為聲明代碼而非具體的實現，在著作權法的語境下，它發揮類似於杜威十進制圖書分類法的「組織功能」，這一性質導致合理使用更易適用。[85]
- 使用的目的和性質：布雷耶表示，谷歌使用並改造Java API的行為「目的在於擴充基於安卓系統的智慧型手機的功能和實用性」，而這「創造了一個能讓程式設計師輕鬆使用的新平台」。[84]他還寫道，谷歌對Java API的使用「僅以實現智慧型手機程式的實用性所需為限」。[84]
- 被複製受保護內容的數量和實質性：布雷耶認為，谷歌只使用了大約0.4%的 Java原始碼，可忽略不計。針對實質性的問題，他寫道，谷歌沒有複製Java實現功能所需的核心代碼：「谷歌複製這些代碼，不是因為它們多麼有創造力或多麼美觀，甚至（某種程度上）也不是因為它們自身的目的。谷歌複製這些代碼只是因為程式設計師已經習慣了使用Java SE，如果沒有它們，將很難……吸引程式設計師使用……安卓系統。」[84]
- 複製行為的市場效應：布雷耶認為，谷歌在複製Java API時，尚不清楚安卓系統是否會成功，安卓系統不應被視為 Java 的替代品，而應為在不同平台上執行的產品。[84]布雷耶進一步表示，如果判決支援甲骨文，「可能會對公眾造成威脅」，因為「只有甲骨文將掌握關鍵內容。這一結果很可能為甲骨文（或其他擁有電腦介面著作權的公司）帶來極高的利益。……（但是）這種控制力與作為著作權法基礎的激勵創造的目標相衝突，而不是進一步助益該目標。」[83]
布雷耶就此認定，谷歌對API的使用滿足所有四個因素的要求，谷歌的使用「只是允許使用者將他們積累的才能用於新的轉換性的平台所必需的」。[83]既然谷歌的複製行為構成合理使用，沒有違反著作權法，[81]那麼認定API是否受著作權保護亦不再必要。
克拉倫斯·托馬斯大法官撰寫了一份反對意見，塞繆爾·阿利托大法官亦聯名支援該意見。[86]托馬斯寫道，多數意見在實施代碼和聲明代碼之間劃分了一種國會立法者未曾允許的區別，進而，「這種扭曲的分析導致了以下結果：很難想像聲明代碼還能在什麼情況下受到著作權保護。」[24]他進一步表示，在他自己的合理使用分析下，「谷歌對受著作權保護代碼的使用絕非合理。」[87]
影響
谷歌與甲骨文的訴訟為科技行業密切關注。鑑於API的大量使用，如果司法判決有利於甲骨文，可能對過去和未來的軟體開發都產生重大影響。[88]包括谷歌及其他基於安卓系統的開發人員在內，反對上訴法院判決的人或是從互操作性、對軟體創新的影響等各方面提出了他們的擔憂，或是指出，既有介面的著作權人可能以其權利惡意挾持那些善意信賴相應標準開放性的下游開發者。如果API受到著作權保護，下游企業將不得不故意採用不相容的標準以免面臨複雜的訴訟風險。而這與當前的行業趨勢——提高不同服務之間的互操作性，允許程式之間的交流，為終端使用者建設更加一體化的平台——是不相容的。[69][89]
《連線》雜誌以Linux作業系統為例：Linux是完全開源的，但它所採用的POSIX是一套模仿Unix作業系統以實現高度互操作性的API。編程人員只需要編寫一組代碼，就可以在具有相同API的任何系統上編譯，即使系統的計算架構不同。如果甲骨文勝訴，則Unix的當前所有者Micro Focus公司可能會向所有試圖將基於POSIX的作業系統的開發者尋求賠償。[90]
行業和法律專家們擔憂甲骨文的勝利可能會對軟體開發產生寒蟬效應：著作權所有者將得以阻止對API實施反向工程、開發可以互操作的替代產品，而這種做法在開源軟體開發中很常見。[91][92][93]但專家同時擔心，對谷歌有利的判決會削弱對代碼開發者的著作權保護，讓資源豐富的企業能輕易開發改進小企業的產品，減損對行業創新的激勵。[94][95]
參考文獻
外部連結
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
