導讀：甲骨文一直以來的起訴點是谷歌抄襲了甲骨文的 API 。可能在他們的視角中，自己對 SQL 的複製與谷歌對 Java 的複製是不同的。
最近一樁纏綿十年的案子，因為臨審將近，又被大家翻出來。那就是甲骨文和谷歌 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 程序測試的優秀本科生。“甲骨文，你不感到羞恥嗎？”
另外AI源創評論注意到，開發者中雖然並不一定認同谷歌的說法，但面對甲骨文的態度基本是一致的——強烈反對。
一位開發者表示，甲骨文似乎是忘記或不知道簡報的提交者並非一定要公正。事實上，簡報是否被接受取決於提交者是否給出了合理的理由。一些辯護狀純粹是學術性的，他們是在告訴法庭他們將如何受到判決的影響。”
大部分人都認為拷貝 API 的說法是荒謬的，如果甲骨文贏了，軟件交互方式將會被永遠改變，“甲骨文或許會一時收穫大筆版權費，通過剝削其他開發者和公司的方式”，但是長遠來說，對於java的應用和生態也會造成影響：
“Larry摧毀了大家對於 Java 作為一個開放平臺的信任。”
“如果說有人在損害 Java 的利益，那就是甲骨文。在這場訴訟後，人們在選擇 Java 之前會三思而行。API 版權保護將是 IP 歷史上的一個新低點。”
在2010年這場訴訟之前，API 不受版權保護是行業潛規則。但若甲骨文勝利，將會打開潘多拉魔盒。也許法院最終會裁定 API 版權延伸到編程語言的核心特性，或者他們會找到一個法律來區分普通的 API 和編程語言版權。但不管怎樣，不確定性很大。灰色地帶要明晰，需要數年的訴訟和數百萬美元的法律費用。
谷歌有兩種可能勝訴的方式，第一是絕大多數人所期待的，法院裁定 API 不能獲得版權。
第二，最高法院可以認為 API 版權要具體問題具體分析，而谷歌的複製屬於合理使用範圍內。這雖能使谷歌免於寫給甲骨文10位數的支票，但仍可能將軟件行業拖入法律泥潭。
合理使用，是多麼見仁見智的主觀標準啊。舉報這種行為可能會增多，而大多公司並沒有谷歌的積澱和法律資源去耗官司，所以未來不容樂觀。（本文作者陳伊莉，來源於AI源創評論，IT大佬已獲得作者授權、經IT大佬編輯發佈，文中觀點為作者觀點、不代表IT大佬觀點。）
參考：
https://arstechnica.com/tech-policy/2020/03/before-it-sued-google-for-copying-from-java-oracle-got-rich-copying-ibms-sql/2/
https://www.oracle.com/corporate/blog/pay-no-attention-to-that-man-behind-the-curtain-030920.html
閱讀更多 IT大佬 的文章
