Oracle律師將Android中重新實作Java API與複製《哈利波特》的內容進行了比較， PDF格式

美國最高法院將於今年初審理一個重要案件。 甲骨文與谷歌，這將決定 API 在智慧財產權法下的法律地位。 如果法院在甲骨文數十億美元的訴訟中支持甲骨文，它可能會抑制競爭並鞏固科技巨頭的主導地位，也許包括谷歌本身。

同時，Oracle的業務最初是建立在IBM開發的SQL程式語言的實現之上的，即使現在該公司也透過Amazon S3的API提供雲端服務，這也是完全正常的。 自產業誕生以來，API 重新實現一直是電腦科學發展的自然組成部分。

甲骨文指責谷歌非法複製 Java API，包括與語法結構相關的命名命令清單。 Android作業系統專門相容於Java API，讓Java程式設計師更容易將軟體和知識轉移到新平台。 為此，Android 準確地複製了相應的 Java API 命令和語法結構。 爭論 Oracle 認為，Java API 的這種「重新實現」可以比喻為複製作者的作品，例如文學小說《哈利波特》（這 Oracle律師舉的一個真實例子），和 Google 侵犯了 Oracle 關於 Java API 指令名稱和結構的版權.

但 Java API 並不是唯一的 API，Android 也不是唯一的重新實作。 在當今的IT產業，API無所不在，重新引入API對於維持競爭、防止大公司壟斷至關重要 想 查爾斯‧杜安 (Charles Duane) 是 R Street 研究所技術與創新政策主任。

Duane 給出了流行的 Amazon S3 儲存平台的範例。 為了能夠從 S3 寫入和檢索文件，Amazon 開發了全面的、 詳細的API 與服務互動。 例如，要取得已儲存檔案的清單（清單對象）我們發送一個 GET 指令，指定主機和型別參數 編碼類型, 延續標記 и x-amz-日期。 要使用 Amazon S3，軟體必須準確使用這些參數名稱和許多其他特定參數名稱。

GET /?Delimiter=Delimiter&EncodingType=EncodingType&Marker=Marker&MaxKeys=MaxKeys&Prefix=Prefix HTTP/1.1
Host: Bucket.s3.amazonaws.com
x-amz-request-payer: RequestPayer

亞馬遜是雲端服務市場中明顯的領導者，其競爭對手提供了 S3 API 的重新實現，同時他們必須模仿命令名稱、參數標籤、類型前綴 x-amzS3 API 的語法結構和一般組織。 換句話說，Oracle 聲稱的所有內容均受版權保護。

提供 Amazon S3 API 副本的公司包括 還有Oracle本身。 為了相容性，Amazon S3 相容性 API 複製了 Amazon API 的大量元素，直至 x-amz 標籤。

甲骨文聲稱其行為的合法性是基於開源Apache 2.0許可證，該許可證允許免費複製和修改程式碼。 例如， 適用於 Java 的亞馬遜 SDK 還附帶 Apache 2.0 授權。

但問題是智慧財產權法是否適用於 API 之類的東西。 這是最高法院必須做出的決定。

API是誰發明的？

「子程式庫」的術語和概念首次出現在Herman Goldstein 和John von Neumann 所著的《電子計算儀器的規劃和編碼問題- 第二部分，第三卷》（普林斯頓大學高級研究所，1948 年）一書中。 複製到 archive.org。 第三卷內容：

這是對在記憶體中儲存程式的電腦程式方法的首次描述（以前不存在）。 它被廣泛分發給當時正在嘗試創建自己的電腦的大學。 最重要的是，這本書包含一個關鍵想法： 大多數程式將使用通用操作，帶有例程的程式庫將減少新程式碼和錯誤的數量。 這個想法被 Maurice Wilkes 進一步完善，並在 EDSAC 機器中付諸實踐，他因此獲得了 1967 年圖靈獎。

左邊是EDSAC子程式庫

下一步是創建高階函數和成熟的軟體接口，正如 Maurice Wilkes 和 David Wheeler 在《為電子數位計算機準備程式》（1951 年）中所做的那樣。

該術語本身 應用程序界面 (API) 出現於 60 世紀 XNUMX 年代末期。

簡報的作者 《API 主觀簡史》 Joshua Block 給出了幾個程式設計介面、指令集和子程式庫的範例：它們是如何建立和隨後使用的。 這個想法是重用是 API 的重點。 這就是它們最初被創建的目的。 開發人員總是有機會複製和重新製作其他人的 API：

API
創造者
年
重新實施
年

FORTRAN 函式庫
IBM
1958
優尼華克
1961

IBM S/360 ISA
IBM
1964
阿姆達爾公司
1970

標準C庫
AT&T/貝爾實驗室
1976
馬克威廉斯公司
1980

Unix系統呼叫
AT&T/貝爾實驗室
1976
馬克威廉斯公司
1980

VT100 Esc 序列
DEC
1978
希思傑
1980

IBM PC BIOS
IBM
1981
鳳凰科技
1984

MS-DOS命令列介面
Microsoft微軟
1981
FreeDOS項目
1998

海斯 AT 命令集
海斯微
1982
錨點自動化
1985

後記
土磚
1985
GNU/GhostScript
1988

SMB
Microsoft微軟
1992
桑巴項目
1993

Win32
Microsoft微軟
1993
葡萄酒項目
1996

Java 2 類別庫
週日
1998
谷歌/安卓
2008

Web API 美味
免費
2003
通知板
2009

來源： 《API 主觀簡史》

複製和重複使用 API（函式庫、指令集）不僅是正確的，而且這種程式設計方法是電腦科學規範中直接推薦的。 甚至在複製 S3 程式介面之前，Oracle 本身就多次這樣做過。 而且，Oracle的業務最初是建立在IBM開發的SQL程式語言的實作之上的。 Oracle 的第一個旗艦產品是 DBMS，主要是從 IBM System R 複製而來。在本例中，我們討論的是 SQL 的重新實現，作為 DBMS 的「標準 API」。

對 API 施加智慧財產權可能會造成影響每個人的法律雷區。 API 實作和 其他雲端服務。 許多技術標準（例如 Wi-Fi 和網際網路協定）都包含 API。 程式設計介面必須以某種形式在互聯網上的每台電腦和伺服器上重新實作。 甲骨文的版權理論幾乎可以使你用電腦所做的任何事情都變得非法。

為了避免這些深遠的後果，Oracle 和維持其論點的上訴法院試圖將版權侵權限制在某些與原始版本「不相容」的 API 重新實現。 但也部分重新實現 是司空見慣的。 即使在 S3 API 的副本中，Oracle 也指出了與原始 Amazon API 的許多「差異」和不相容性。

Oracle 訴訟的主要危險在於，它可能會阻止小型科技公司創建與 S3 等主流平台相容的系統版本。 如果沒有這種相容性，程式設計師將被有效地排除在該公司的產品之外。

產業代表和開發商只能希望理性佔上風， 評審了解程式設計的基礎知識.

來源： www.habr.com