甲骨文與谷歌就 Android 代碼問題發(fā)起的訴訟，距今已有將近 10 個年頭。經(jīng)歷了三次審判和兩次上訴，這場官司終于還是鬧上了美國最高法院。期間兩家科技巨頭已經(jīng)動用了無數(shù)的人力和訴訟費用，以及努力向非技術(shù)專業(yè)的陪審團成員解釋其中的緣由。不過當(dāng)?shù)貢r間周三上午，這場曠日持久的戰(zhàn)斗有望最終落幕。

　　（圖 via ExtremeTech）

　　據(jù)悉，當(dāng)谷歌最初開發(fā) Android 移動操作系統(tǒng)時，便決定與 Java 實現(xiàn)兼容。作為對比，蘋果 iOS 那邊使用了面向?qū)ο蟮?Objective-C 代碼方案。

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

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

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

　　經(jīng)歷 10 年的時間，兩家公司的高管都已經(jīng)發(fā)生了較大的變動。當(dāng)谷歌于 2010 年作出應(yīng)對時，涉及的還是 7 大專利和 1 大版權(quán)主張。

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

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

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

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

　　對于需要被經(jīng)常調(diào)用的冗長代碼來說，API 能夠極大地解放程序員的工作量，讓他們無需重復(fù)發(fā)明輪子，即可特定基礎(chǔ)上構(gòu)建代碼。

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

然而這些基礎(chǔ)的軟件包，已經(jīng)涵蓋了 java.lang 和 java.util，可為數(shù)學(xué)運算或日期 / 時間等功能提供支持。

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

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