Google、甲骨文史詩級版權訴訟案，10 年 API 之爭下週開審

最近一樁爭訟十年的案子，因臨審將近又被大家翻出來，就是甲骨文和 Google API 侵權之爭。

這樁案子起源於 2009 年，甲骨文斥資 74 億美元收購發明 Java 的 Sun Microsystems。次年甲骨文對 Google 提告，理由是 Android 非法複製 1.1 萬行程式碼，侵犯了 Java 專利。

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

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

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

這到底是什麼故事？

十年官司，輪流上訴

這場史詩級版權官司，不僅因雙方耗費漫長時間和金錢──過去有幾樁類似版權案件都不了了之，可能會讓 Google 損失數十億美元，且這樁案件將對整個軟體業產生巨大影響，Google 提醒美國最高法院，甲骨文有可能成為壟斷勢力。

先簡單回顧一下官司史：

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

讀者或許注意到，舊金山聯邦法院和上訴法院十年內分別堅定支援 Google 或甲骨文，是這場拉鋸戰持久的原因。

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

Google 理直氣壯地表示，沒有做錯任何事，因版權法版權保護並不包括「系統」和「作業方法」。Google 認為，複製的 Java 方面──函數名、參數類別等──完全符合這些例外，版權的合理使用原則允許這種複製。根據加州聯邦法院紀錄，Google 從 Java API 複製 37 包、616 個物件類和 6,088 個函數。

電腦軟體保護邊界一直是很難判定的問題。起初多數國家並不贊成版權法保護程式，美國是最早推動者，在強大的政治與經濟壓力下，各國逐步接受程式應當作作品受保護。電腦程式分為起源程式和目的程式。API 介於起源程式和目的程式。

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

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

今年 1 月，Google 提交名為「friend of the court」的法律檔案簡報，其中 Mozilla、Medium、Cloudera、Reddit 等公司都呼籲聯邦法院應允許 API 繼續不受版權保護，或說合理使用。

甲骨文其身不正？

而控告 Google 抄襲 Java 之前，甲骨文或許還要先收拾一下自己不光彩歷史。外媒 arstechnica 報導，甲骨文的發家史其實就是一部抄襲史，透過抄襲 IBM 的 SQL 發財。如果屬實，這些歷史與現在 API 版權問題立場無疑矛盾，不利勝訴。

軟體公司一直在複製競爭對手的 APIs。如果有人該理解這種複製的重要性，那必然是甲骨文。甲骨文在 1970 年代開始銷售的第一款產品就是基於當時新的 SQL 程式庫。而 SQL 是 IBM 發明，甲骨文似乎沒有獲得使用許可。

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

arstechnica 認為，甲骨文複製 SQL 與 Google 複製 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 內部使用。直到 1980 年代初，IBM 才對外提供基於 SQL 的商業程式庫。

▲ Larry Ellison。（Source：Flickr/Oracle PR CC BY 2.0）

而約 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 許可，相關人員似乎都認為甲骨文不需要許可。

Google 與 Java 的過往

Google 不管怎麼說都曾嘗試與 Sun 建立授權關係。2005 年 8 月，Google 低調收購 Android ，開始研發手機作業系統，同年 Google 找過 Sun Microsystems 討論許可協定，並達成暫時協定──Google 向 Sun 支付 2,800 萬美元（一說是 4,000 萬美元），獲得與 Java 相關的專利、Java 商標和其他資產的使用授權。另外，Google 堅稱，從未嘗試獲得 Java 介面版權，在他們看來，法律對此並沒有要求。

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

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

Google 後來宣布 Android 是基於 Java 語言時，Sun 首席執行長 Jonathan Schwartz 當時還挺高興的，他公開表示，「我只是想和其他同事一起衷心祝賀 Google 推出新 Java / Linux 手機平台 Android。」

可能是力量懸殊，總之 Sun 當時並沒有找 Google 麻煩，而 2009 年被甲骨文收購後，立刻變了態度。2010 年 1 月，Sun 交易結束，不久甲骨文就控告 Google。當年 1 月，多位前 Sun 高層從甲骨文離職，包括前首席執行長 Jonathan Schwartz、XML 發明人 Tim Bray、前 CTO James Gosling，其中 Tim Bray 加入 Google Android 開發團隊。

對比 Google 和 IBM，有滿大的差別：Google 複製 Sun 已問世的產品，甲骨文複製 IBM 尚未發表的產品，從 IBM 白皮書學來。

Cornell Tech 法學教授 James Grimmelmann 今年 1 月接受採訪時表示，從版權角度來看，兩者沒有太大差別。如果複製 API 侵犯版權，那麼從檔案複製 API 也侵犯版權。根據版權法，IBM 的論文是「受保護的作品」。「如果 SQL 規格有版權，那麼無論從軟體還是白皮書複製，版權法都適用。」

甲骨文一直以來的控訴點是 Google 抄襲甲骨文 API，可能在他們的視角，自己複製 SQL 與 Google 複製 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 年 Android 7.0，Google 捨棄了私有 SunJDK 轉用開源 OpenJDK；2017 年 I/O 大會，Google 宣布 Kotlin 取代 Java 成為 Android 一級開發語言。兩年後 Google 表示，超過 50% 專業 Android 開發人員使用 Kotlin 開發應用程式，最新 Stack Overflow 開發人員調查，Kotlin 列為第四大最受歡迎程式設計語言。

一邊倒批判甲骨文

對外界批評其抄襲 SQL 的言論，甲骨文並不認可，稱「把蘋果和花椰菜放在一起比，完全脫離事實，這是不正確的假設。」

這還沒完，執行副總裁 Ken Glueck 在官網發表題為《別理躲在幕後的人》（Pay No Attention to That Man Behind the Curtain）一文，言辭犀利，炮轟 Google 和支持者，「裝出獲得大規模支持的現象，但背後可能不過是利益交易。」

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

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

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

除了微軟和 IBM，前 100 大科技公司的 98 家都沒有提交任何簡報。

這篇文章一出，原 Sun 員工、現任 Google 首席 Java 架構師 Joshua Bloch 坐不住了，在 Twitter 回擊：抹黑對 java 貢獻巨大的 Doug Lea 是無用的，他 14 年前接受 Google 一筆小額捐款，但立即分給參與 Java 程式測試的優秀本科生。甲骨文，你不感到羞恥嗎？

開發者雖然並不一定都認同 Google 說法，但對甲骨文的態度都一致：強烈反對。

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

大部分人都認為複製 API 的說法很荒謬，如果甲骨文贏了，軟體互動方式將永遠改變。「甲骨文或許會收到大筆版權費，透過剝削其他開發者和公司」，但長遠來說，對 Java 的應用和生態也會造成影響：