甲骨文與穀歌就Android代碼問題發起的訴訟，距今已有將近10個年頭。經歷了三次審判和兩次上訴，這場官司終於還是鬧上了美國最高法院。期間兩家科技巨頭已經動用了無數的人力和訴訟費用，以及努力向非技術專業的陪審團成員解釋其中的緣由。不過當地時間週三上午，這場曠日持久的戰鬥有望最終落幕。

（圖via ExtremeTech）

據悉，當谷歌最初開發Android移動操作系統時，便決定與Java實現兼容。作為對比，蘋果iOS那邊使用了面向對象的Objective-C代碼方案。

顯然，搜索巨頭希望藉助強大且流行的社區的力量，讓Android 與流行的Java 編程語言實現互操作，進而獲得更大的競爭力。

為了做到這一點，該公司重構了幾個Java API，其中就包括捲入法律糾紛的37 個。

對於從Sun 那裡接過了Java 的甲骨文，是否有資格從Android 身上咬下價值數十億美元的一塊肥肉、以及谷歌的語言兼容性是否涉及侵權，就成為了雙方爭論的兩大焦點。

經歷10 年的時間，兩家公司的高管都已經發生了較大的變動。當谷歌於2010 年作出應對時，涉及的還是7 大專利和1 大版權主張。

但到2012 年的時候，爭議點已經縮減到了僅由大約11500 行代碼組成的37 個Java API 。相比之下，各大Android 版本的總代碼量在120~140 億行之間。

據說爭議代碼源於單獨的逆向工程（所謂的Clean Room）項目，當谷歌與Sun Microsystems 談崩之後，此事的重要性就變得不言而喻。

即便甲骨文是在2010 年初才收購的Sun，但它還是在當年8 月就向谷歌發起了法律訴訟。

至於這裡提到的應用程序編程接口（API），特指軟件編程中明確定義的交互集合，旨在提供各種定義庫和其它功能的快速訪問。

對於需要被經常調用的冗長代碼來說，API 能夠極大地解放程序員的工作量，讓他們無需重複發明輪子，即可特定基礎上構建代碼。

從技術上來說，谷歌能夠在Java 編程上多花點力氣，以避開捲入爭議的這37 個Java API 軟件包。

然而這些基礎的軟件包，已經涵蓋了java.lang 和java.util，可為數學運算或日期/ 時間等功能提供支持。

問題在於，谷歌通過Clean Room 項目重構了這37 組Java API 。甲骨文方面並未斷言該公司照搬全抄，而是指責其“結構、順序和組織”是如此相似，以致於侵犯了該公司的版權。

無論這些API 中的封包、類型和方法，都被命名成了相同的名稱。通過標準Java 編寫的代碼不一定可以在Android 上運行，但兩者的情況是相當接近的。