最近一樁纏綿十年的案子，因為臨審將近，又被大家翻出來。那就是甲骨文和谷歌API 侵權之爭。這樁案子起源於2009 年，甲骨文斥資74 億美元收購發明了Java 的Sun Microsystems。次年甲骨文提起了對谷歌的訴訟，理由是Android 非法複製了11000 行代碼，侵害了Java 版權專利。

谷歌自然是不肯的。於是過去十年，兩大公司從美國舊金山聯邦法院，辯論到聯邦巡迴上訴法院，再到最高法院，雙方輪流不服，輪流上訴。

從谷歌視角來說，經歷了一審勝訴、二審敗訴、最高法院拒絕審理、再審勝訴、再再審敗訴。最新的消息是，最高法院計劃在3 月24 日左右再審。

這場訴訟在網絡、媒體上也是討論得沸反盈天。近日，外媒arstechnica 報導指出，甲骨文的發家史其實就是一部抄襲史，通過抄襲IBM 的SQL 發了財。甲骨文發言人回應，絕無此事。

那麼，這其中到底有什麼樣的故事？

十年訴訟，輪流上訴

這一場史詩級的版權訴訟，不僅是因為訴訟雙方耗費了漫長時間和經歷——過去有幾樁類似的版權案件都不了了之，可能會讓谷歌損失數十億美元，並且，這樁案件將對整個軟件行業產生巨大影響，谷歌提醒美國最高法院稱，甲骨文有可能成為壟斷勢力。

先簡單回顧一下訴訟歷史：

• 2010 年，甲骨文起訴谷歌侵犯了7 件與Java 相關的專利和版權，要求谷歌賠償約數十億美元的損失。
• 2012 年5 月，美國舊金山聯邦法院（或稱加州北區法院）的法官裁定，Java API 不受版權保護，任何人都可以免費使用；10 月，甲骨文上訴。
• 2014 年，美國聯邦巡迴上訴法院推翻了一審部分結論，稱必須尊重軟件的版權保護。
• 谷歌上訴，2015 年6 月，美國最高法院拒絕就受理谷歌上訴。起訴訟重返舊金山聯邦法院，由該院就谷歌另外提出的“合理使用”的觀點進行庭審。
• 2016 年5 月，舊金山聯邦法院複審，判決谷歌公司的行為合理，免付版權賠償。
• 甲骨文上訴，2018 年3 月，上訴法院再次裁決谷歌侵權，甲骨文索要88 億美元賠償。
• 2019 年11 月，在78 名計算機科學家的陳情下，美國高院受理了谷歌的上訴，將對此前裁決複審。

你或許也注意到，舊金山聯邦法院和上訴法院在十年內分別堅定支持谷歌、甲骨文，是這場拉鋸戰這麼持久的原因。

甲骨文的訴訟點不是谷歌抄襲了Java 語言，而是使用過線，在沒協議的情況下抄襲了版權屬於甲骨文的37 個JavaAPI 段。所以這場漫長的訴訟焦點在於，API 是否也受版權法的保護，或者說在多大程度上獲得版權保護。

谷歌特別理直氣壯地表示，它沒有做錯任何事情，因為版權法的版權保護並不包括“系統”和“操作方法”。谷歌認為，它複製的Java 方面——函數名、參數類型等等——完全符合這些例外，版權的合理使用原則允許這種複制。根據加州聯邦法院的記錄，谷歌從Java API 中復制了37 個包、616 個對像類和6088 個函數。

計算機軟件的保護邊界一直是一個很難判定的問題。起初多數國家並不贊成版權法保護程序，美國是最早的推動者，在它強大的政治與經濟壓力下，各國逐步接受了程序應當作為作品受到保護的要求。計算機程序分為源程序和目標程序。API 介於源程序和目標程序之間。

關於API 應不應該受保護，網友@ozzee 表示，“就像你不能給字典版權一樣，你也不能給API 版權。如果我擁有所有英語單詞的版權，而且我要求你必須使用我的紙張、空氣和設備來說出這些單詞，你會怎麼想？給了API 版權，一個開發者就會被API 供應商所束縛。”

軟件業都很關注這起訴訟，不少公司都是站在谷歌這邊。微軟、IBM曾警告稱，甲骨文的做法可能會給行業帶來混亂。如果拷貝是侵權行為，不僅會給許多軟件公司帶來法律上的麻煩，還會對客戶不利。APIs廣泛存在於軟件業，這使得相互競爭軟件產品也可以互操作，這意味著客戶的轉換成本更低，軟件初創企業進入門檻也更低，因為如果一個新產品與客戶已經知道和使用的軟件產品是兼容，就更容易銷售。

今年1 月份，谷歌提交了一份名為“friend of the court”的法律文件簡報，其中Mozilla，Medium，Cloudera，Reddit 等公司都一起呼籲聯邦法院應該允許API 繼續不受版權保護，或者說合理使用。

甲骨文其身不正？

而在起訴谷歌抄襲Java 之前，甲骨文或許還要先收拾下黑歷史。外媒arstechnica 報導稱，甲骨文的發家史其實就是一部抄襲史，通過抄襲IBM 的SQL 發了財。如果屬實，這些歷史與它現在API 版權問題上的立場無疑是矛盾的，不利於勝訴。

軟件公司一直在復制他們競爭對手APIs。如果有人應該理解這種複制的重要性，那必然有甲骨文。甲骨文在20 世紀70 年代開始銷售的第一款產品就是，基於當時新的SQL 的數據庫。而SQL 是由IBM 發明的，甲骨文似乎沒有獲得使用它的許可。

諷刺的是，如果甲骨文贏了這場法律戰，也就是扼殺了40 年前的自己，未來的初創企業將無法像甲骨文40 年前那樣——產品能與一個成熟的競爭對手兼容，將互操作性作為賣點。

arstechnica 認為，甲骨文對SQL 的複制與穀歌對Java 的複制非常相似。為什麼這麼說？

SQL 的語言看起來是這樣的： “select customer_name, ship_date from orders where product_id=17 and state=’CA’.”。

從上可知，第一，SQL 有一個簡單的、類似英語的語法。沒有編程或數據庫管理背景的人可以通過閱讀這個語句大致了解它的作用。第二，SQL 是一個申訴式編程語言（Declarative Language）：用戶指定他們在尋找什麼信息，但是他們讓數據庫系統來決定如何找到這些信息。也就是說，SQL 是一個對非程序員都很友好的語言，稍加練習，就可以編寫SQL 查詢來完成一系列任務。

1974 年，一小群IBM 研究人員在一個叫做System R 的軟件包中實現這些想法。與此同時，IBM 的研究人員發表了描述工作的研究論文。這些出版物非常詳細，包括完整的SQL 語言規範。System R 做出來了，但在接下來的幾年就只是在IBM 內部使用。直到20 世紀80 年代初，IBM 才對外提供了一個基於SQL 的商業數據庫。

Larry Ellison

而大約在1977 年， Larry Ellison 和他的聯合創始人發現了SQL 語言，他們當時開了一家名為Software Development Laboratories 的軟件諮詢公司，然後想轉型到數據庫銷售公司。Larry Ellison意識到，如果甲骨文數據庫能與IBM 的SQL 標準完全兼容，可信度會更高。

SQL 的設計者Donald Chamberlin 在1995年接受過一個採訪，其中提到，Larry Ellison 在1978年打電話給過他，想了解更多IBM 研發SQL 的細節，包括錯誤代碼值。Chamberlin本人是很樂意分享的，但是他的老闆拒絕了這件事，表示錯誤代碼是保密的。

不過因為IBM 的白皮書展示了足夠的細節，足以克隆IBM 的數據庫技術，甲骨文在1979年發布了第一個版本的數據庫。其時，該公司反复宣揚該產品起源於IBM。“甲骨文的用戶界面就是SQL ”一位早期的甲骨文宣傳員說。

因為比IBM 提前兩年上市，甲骨文一下聲名大噪，並在未來幾年保持著SQL 數據庫領導者的地位。

後來System R 內部還討論過IBM 公佈SQL 的細節是否是一個錯誤，這讓甲骨文吃掉了許多應該屬於IBM 的市場份額。但也有內部人士認為，發表研究論文之後，才讓IBM 意識到這項技術很重要，所以從一開始就很認真對待。

“如果我們沒有發表那些論文，它就會失敗，”1995年，IBM 的老員工Mike Blasgen 說。“IBM 很有可能會忽略它。”

一直以來，甲骨文似乎都沒有試圖從IBM 那裡獲得SQL 許可，相關人員似乎都認為甲骨文不需要許可。

谷歌與Java 過往

而谷歌，不管怎麼說曾經試圖與Sun建立授權關係。2005年8月，谷歌低調收購安卓，開始研發手機操作系統，同年谷歌找過Sun Microsystems討論過許可協議，並達成了一個暫時協議——谷歌向Sun支付2800萬美元（一說是4000萬美元） ，獲得與Java相關的專利、Java商標和其他資產的使用授權。另外，谷歌堅稱，他們從未試圖獲得Java界面的版權，在他們看來，法律對此並沒有要求。

但是協議很快破裂，谷歌后來稱主要原因不是價格，而是 Sun 對安卓平台發展的控制力度超出了谷歌的意願。因此，谷歌決定在沒有 Sun 許可的情況下構建自己的Java 版本。

這意味著谷歌要從Java 語言的功能規範開始，也就是Java 語言的規則，包括關鍵字、語法以及標準函數的名稱和參數類型。谷歌沒有像甲骨文複製SQL 一樣複製這些功能的代碼，工程師們而是從頭開始編寫自己的代碼，並產生了與Sun 的Java 代碼相同的結果。

谷歌后來宣布安卓是基於 Java 語言時，Sun 公司的首席執行官 Jonathan Schwartz 當時還挺高興的，他公開表示，“我只是想和其他同事一起衷心祝賀谷歌推出的新Java/Linux 手機平台安卓。”

可能是力量懸殊，總之Sun 當時並沒有找谷歌的麻煩，而2009年該公司被甲骨文收購後，就立馬轉了做法。2010年1月，Sun 交易結束，不久甲骨文就起訴了谷歌。值得關注的一點是，當年1月後，多位前Sun 高管從甲骨文離職，其中包括前Sun 首席執行官Jonathan Schwartz、XML 發明人Tim Bray、前Sun CTO James Gosling，其中Tim Bray 加入了谷歌安卓開發團隊。

對比谷歌和IBM 的複制，有一個挺大的差別：谷歌複製了Sun 已經問世的產品，甲骨文複製了一個IBM尚未發布的產品，學的是IBM 發佈白皮書。

Cornell Tech 法學教授James Grimmelmann 在今年1月接受采訪時表示，從版權角度來看，兩者沒有太大差別。如果復制API 是侵犯版權的，那麼從文檔中復制API 也是侵犯版權的。根據版權法，IBM 的論文是“受保護的作品”。”如果SQL 規範是有版權的，那麼無論是從軟件還是白皮書中復制的，版權都適用。

甲骨文一直以來的起訴點是谷歌抄襲了甲骨文的API 。可能在他們的視角中，自己對SQL 的複制與穀歌對Java 的複制是不同的。

事實上，1979年，IBM 的SQL 確實還沒有一個龐大的支持功能庫供甲骨文複製。因此，甲骨文這一套“語言複製”可以，“API 複製”不行的理論倒也符合他們的立場。

但是Grimmelmann 認為，在編程語言和API 之間在法律上區別對待是沒有意義的。“SQL 本質上是一個通用數據庫API，有9個核心動詞、參數，以及一些格式和語法。”

目前尚不清楚版權法會怎麼區分核心語言和API。例如，在執行加法運算時，Java 可能要求用戶調用這樣的API 函數:” n =sum(a，b)；”而不是通過” n = a+b；”。如果版權法要保護前者，後者符號“+”也應該得到保護。

從根本上說，API 是一種計算機程序之間相互通信的語言，而像SQL 或Java 這樣的語言也可以說是一種API。成熟的計算機語言往往比其他API 有更複雜的語法規則。但是潛在的版權元素——關鍵字、參數類型、語法規則——很多是相似的。如果API 中的函數名稱可以被版權保護，那麼計算機語言中的關鍵字似乎也可以被版權保護，包括“select”、“from”和“where”等SQL 關鍵字。

另外，為了減小版權影響，2016年的安卓7.0，谷歌捨棄了私有的SunJDK 而轉用開源的OpenJDK；2017年I/O 大會上，谷歌宣布Kotlin 取代Java 成為Android 一級開發語言。兩年後，谷歌表示，超過50% 的專業Android 開發人員現在使用該語言開發他們的應用程序，在最新的Stack Overflow 開發人員調查中，它被列為第四大最受歡迎的編程語言。

一邊倒地批判甲骨文

對於外界關於其抄襲SQL的言論，甲骨文並不認可，該司稱，“把蘋果和花椰菜放在一起比較，完全脫離事實，這是一個不正確的假設。”

這還沒完，執行副總裁Ken Glueck 在官網發布了一篇題為《別理會躲在幕後的人》的博客，言辭犀利，炮轟谷歌和它的支持者，“偽裝出一種獲得大規模支持的現象，但背後可能不過是利益交易。”

“這不是關於創新的案件，而是盜竊。”Glueck表示，在軟件行業，竊取其他開發人員的軟件代碼並不常見，而一些複製的行為也是版權者出於雙方利益，一起合作，Java 並不是拒絕選擇，而是授權許可在版權方手裡。

“谷歌試圖尋求外部團體的支持，拉上其他公司登上friend of the court 簡報，製造案件有重大意義和爭議、大眾甲骨文的訴求阻礙著創新的印象。”

另外，他還提到谷歌遞交的26份簡報，其中7份簡報的實體有從從谷歌獲得“實質性貢獻（substantial contributions）”的評價；8份簡報背後的機構或個人與穀歌之間有著贈款、應付款、近似結算收益（ cy pres settlement proceeds）或僱用關係；2份簡報實體與穀歌之間有明顯商業往來；1份由幾名前美國政府僱員提交的簡報，這些人都曾在一家由谷歌前高管經營的小型政府機構工作過……這些團體涉及美國圖書館協會、EFF 和Python 軟件基金會，以及83名計算機科學家，包括前Java 執行委員會成員Doug Lea。

“除了微軟和IBM，前100家科技公司中的其他98家公司可都沒有提交任何一份簡報。”

這篇文章一出，原Sun 員工、現谷歌首席Java 架構師Joshua Bloch 坐不住了，在推特上回懟：給對java貢獻巨大的Doug Lea潑髒水是無用的，他是14年前接受了谷歌的一筆小額贈款，但立即分給了那些參與Java 程序測試的優秀本科生。“甲骨文，你不感到羞恥嗎？”

開發者中雖然並不一定認同谷歌的說法，但面對甲骨文的態度基本是一致的——強烈反對。

一位開發者表示，甲骨文似乎是忘記或不知道簡報的提交者並非一定要公正。事實上，簡報是否被接受取決於提交者是否給出了合理的理由。一些辯護狀純粹是學術性的，他們是在告訴法庭他們將如何受到判決的影響。”

大部分人都認為拷貝API 的說法是荒謬的，如果甲骨文贏了，軟件交互方式將會被永遠改變，“甲骨文或許會一時收穫大筆版權費，通過剝削其他開發者和公司的方式”，但是長遠來說，對於java的應用和生態也會造成影響：

“Larry摧毀了大家對於Java 作為一個開放平台的信任。”

“如果說有人在損害 Java 的利益，那就是甲骨文。在這場訴訟後，人們在選擇Java 之前會三思而行。API 版權保護將是IP 歷史上的一個新低點。”

在2010年這場訴訟之前，API 不受版權保護是行業潛規則。但若甲骨文勝利，將會打開潘多拉魔盒。也許法院最終會裁​​定API 版權延伸到編程語言的核心特性，或者他們會找到一個法律來區分普通的API 和編程語言版權。但不管怎樣，不確定性很大。灰色地帶要明晰，需要數年的訴訟和數百萬美元的法律費用。

谷歌有兩種可能勝訴的方式，第一是絕大多數人所期待的，法院裁定API 不能獲得版權。第二，最高法院可以認為API 版權要具體問題具體分析，而谷歌的複制屬於合理使用範圍內。這雖能使谷歌免於寫給甲骨文10位數的支票，但仍可能將軟件行業拖入法律泥潭。

合理使用，是多麼見仁見智的主觀標準啊。舉報這種行為可能會增多，而大多公司並沒有谷歌的積澱和法律資源去耗官司，所以未來不容樂觀。