Oracle 律師比較了 Java API 的重新實現 Android 抄襲《哈利波特》的內容 PDF格式

美國最高法院將於今年初審理一起重大案件 甲骨文與谷歌，將根據智慧財產權法決定API的法律地位。如果法院對甲骨文數十億美元的訴訟作出裁決，這可能會抑制競爭並鞏固科技巨頭（可能包括谷歌本身）的主導地位。

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

Oracle 指控 Google 非法複製 Java API，包括與語法結構關聯的命名命令清單。作業系統 Android 它專門與 Java API 相容，以便 Java 程式設計師能夠更輕鬆地將軟體和知識遷移到新平台。為此， Android 精確複製了相關的Java API指令和語法結構。 爭論 Oracle 的觀點是，這種對 Java API 的「重新實現」可以比喻為複製作家的作品，例如文學小說《哈利波特》（這是 Oracle 律師給予的真實案例），和 谷歌侵犯了 Oracle 對 Java API 指令名稱和結構的版權.

但Java API並不是唯一的API， Android ——並非唯一的重新實現。在現代IT產業，API無所不在，重新實現對於維持競爭和防止大型企業壟斷至關重要。 想 R 街研究所技術與創新政策主任查爾斯‧杜安 (Charles 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-amz，S3 API的語法結構和一般組織。換句話說，Oracle 所聲稱的一切都受版權保護。

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

Oracle 聲稱其行為的合法性是基於開源 Apache 2.0 許可證，該許可證允許自由複製和修改程式碼。例如， 適用於 Java 的 Amazon SDK 還附帶 Apache 2.0 授權。

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

誰發明了 API？

「子程式庫」這個術語和概念最早出現在 Herman Goldstine 和 John von Neumann 合著的《電子計算儀器的規劃和編碼問題》第二部分第三卷（普林斯頓大學高等研究院，1948 年出版）一書中。 在archive.org上複製。第三卷內容：

這是首次對程式儲存在記憶體中的電腦程式方法進行描述（以前不存在這種方法）。它在當時正試圖創建自己的電腦的大學中廣泛傳播。最重要的是，這本書包含以下關鍵思想： 大多數程式都會使用常見的操作，帶有例程的程式庫將減少新程式碼和錯誤的數量。這個想法被莫里斯·威爾克斯進一步發展，並在 EDSAC 機器中付諸實踐，他因此於 1967 年獲得了圖靈獎。

EDSAC 子程序庫在左側

下一步是創建高階函數和成熟的程式設計接口，這是由莫里斯·威爾克斯 (Maurice Wilkes) 和大衛·惠勒 (David Wheeler) 在他們的書《為電子數字計算機準備程式》(1951) 中完成的。

該術語本身 應用程序界面 （API）出現於 60 年代末期。

演講作者 “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

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

後記
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft微軟
1992
Samba 專案
1993

Win32
Microsoft微軟
1993
葡萄酒項目
1996

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

美味 Web API
免費
2003
通知板
2009

來源： “API 的簡要主觀歷史”

複製和重複使用 API（函式庫、指令集）不僅是正確的做法，也是電腦科學規範中直接推薦的程式方法。甚至在複製 S3 的 API 之前，Oracle 本身就已經多次這樣做了。而且，Oracle的業務最初是建立在IBM開發的SQL程式語言的實作之上的。 Oracle 的第一個旗艦產品是一個很大程度上複製自 IBM System R 的 DBMS。在這種情況下，我們討論的是將 SQL 重新實作為 DBMS 的「標準 API」。

將智慧財產權置於 API 之上可能會形成一個對所有人都有害的法律雷區。 API 實作和 其他雲端服務。許多技術標準，例如 Wi-Fi 和互聯網協議，都包含 API。 API 必然會以某種形式在互聯網上的每台電腦和伺服器上重新實作。甲骨文的版權理論幾乎可以使你用電腦進行的任何操作都變得非法。

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

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

行業代表和開發人員只能希望，在這裡，常識佔上風， 評審了解程式設計的基礎知識.

來源： www.habr.com