甲骨文與谷歌就 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 上運行，但兩者的情況是相當接近的。