0
| 本文作者： 陳伊莉 | 2020-03-21 20:17 |
最近一樁纏綿十年的案子，因為臨審將近，又被大家翻出來。那就是甲骨文和谷歌 API 侵權之爭。
雷鋒網AI源創(chuàng)評論了解到，這樁案子起源于 2009 年，甲骨文斥資 74 億美元收購發(fā)明了 Java 的 Sun Microsystems。次年甲骨文提起了對谷歌的訴訟，理由是 Android 非法復制了 11000 行代碼，侵害了 Java 版權專利。
谷歌自然是不肯的。于是過去十年，兩大公司從美國舊金山聯(lián)邦法院，辯論到聯(lián)邦巡回上訴法院，再到最高法院，雙方輪流不服，輪流上訴。
從谷歌視角來說，經歷了一審勝訴、二審敗訴、最高法院拒絕審理、再審勝訴、再再審敗訴。最新的消息是，最高法院計劃在 3 月 24 日左右再審。
這場訴訟在網絡、媒體上也是討論得沸反盈天。近日，外媒 arstechnica 報道指出，甲骨文的發(fā)家史其實就是一部抄襲史，通過抄襲 IBM 的 SQL 發(fā)了財。甲骨文發(fā)言人回應，絕無此事。
那么，這其中到底有什么樣的故事？
這一場史詩級的版權訴訟，不僅是因為訴訟雙方耗費了漫長時間和經歷——過去有幾樁類似的版權案件都不了了之，可能會讓谷歌損失數十億美元，并且，這樁案件將對整個軟件行業(yè)產生巨大影響，谷歌提醒美國最高法院稱，甲骨文有可能成為壟斷勢力。
先簡單回顧一下訴訟歷史：
2010 年，甲骨文起訴谷歌侵犯了 7 件與 Java 相關的專利和版權，要求谷歌賠償約數十億美元的損失。
2012 年 5 月，美國舊金山聯(lián)邦法院（或稱加州北區(qū)法院）的法官裁定，Java API 不受版權保護，任何人都可以免費使用；10 月，甲骨文上訴。
2014 年，美國聯(lián)邦巡回上訴法院推翻了一審部分結論，稱必須尊重軟件的版權保護。
谷歌上訴，2015 年 6 月，美國最高法院拒絕就受理谷歌上訴。起訴訟重返舊金山聯(lián)邦法院，由該院就谷歌另外提出的“合理使用”的觀點進行庭審。
2016 年 5 月，舊金山聯(lián)邦法院復審，判決谷歌公司的行為合理，免付版權賠償。
甲骨文上訴，2018 年 3 月，上訴法院再次裁決谷歌侵權，甲骨文索要 88 億美元賠償。
2019 年 11 月，在 78 名計算機科學家的陳情下，美國高院受理了谷歌的上訴，將對此前裁決復審。
你或許也注意到，舊金山聯(lián)邦法院和上訴法院在十年內分別堅定支持谷歌、甲骨文，是這場拉鋸戰(zhàn)這么持久的原因。
甲骨文的訴訟點不是谷歌抄襲了 Java 語言，而是使用過線，在沒協(xié)議的情況下抄襲了版權屬于甲骨文的 37 個 JavaAPI 段。所以這場漫長的訴訟焦點在于，API 是否也受版權法的保護，或者說在多大程度上獲得版權保護。
谷歌特別理直氣壯地表示，它沒有做錯任何事情，因為版權法的版權保護并不包括“系統(tǒng)”和“操作方法”。谷歌認為，它復制的 Java 方面——函數名、參數類型等等——完全符合這些例外，版權的合理使用原則允許這種復制。根據加州聯(lián)邦法院的記錄，谷歌從 Java API 中復制了 37 個包、616 個對象類和 6088 個函數。
計算機軟件的保護邊界一直是一個很難判定的問題。起初多數國家并不贊成版權法保護程序，美國是最早的推動者，在它強大的政治與經濟壓力下，各國逐步接受了程序應當作為作品受到保護的要求。計算機程序分為源程序和目標程序。API 介于源程序和目標程序之間。
關于 API 應不應該受保護，網友 @ozzee 表示，“就像你不能給字典版權一樣，你也不能給 API 版權。如果我擁有所有英語單詞的版權，而且我要求你必須使用我的紙張、空氣和設備來說出這些單詞，你會怎么想？給了 API 版權，一個開發(fā)者就會被 API 供應商所束縛?！?/p>
軟件業(yè)都很關注這起訴訟，不少公司都是站在谷歌這邊。微軟、IBM 曾警告稱，甲骨文的做法可能會給行業(yè)帶來混亂。如果拷貝是侵權行為，不僅會給許多軟件公司帶來法律上的麻煩，還會對客戶不利。APIs 廣泛存在于軟件業(yè)，這使得相互競爭軟件產品也可以互操作，這意味著客戶的轉換成本更低，軟件初創(chuàng)企業(yè)進入門檻也更低，因為如果一個新產品與客戶已經知道和使用的軟件產品是兼容，就更容易銷售。
今年 1 月份，谷歌提交了一份名為“friend of the court”的法律文件簡報，其中 Mozilla，Medium，Cloudera，Reddit 等公司都一起呼吁聯(lián)邦法院應該允許 API 繼續(xù)不受版權保護，或者說合理使用。
而在起訴谷歌抄襲 Java 之前，甲骨文或許還要先收拾下黑歷史。外媒 arstechnica 報道稱，甲骨文的發(fā)家史其實就是一部抄襲史，通過抄襲 IBM 的 SQL 發(fā)了財。如果屬實，這些歷史與它現(xiàn)在 API 版權問題上的立場無疑是矛盾的，不利于勝訴。
軟件公司一直在復制他們競爭對手 APIs。如果有人應該理解這種復制的重要性，那必然有甲骨文。甲骨文在 20 世紀 70 年代開始銷售的第一款產品就是，基于當時新的 SQL 的數據庫。而 SQL 是由 IBM 發(fā)明的，甲骨文似乎沒有獲得使用它的許可。
諷刺的是，如果甲骨文贏了這場法律戰(zhàn)，也就是扼殺了 40 年前的自己，未來的初創(chuàng)企業(yè)將無法像甲骨文 40 年前那樣——產品能與一個成熟的競爭對手兼容，將互操作性作為賣點。
arstechnica 認為，甲骨文對 SQL 的復制與谷歌對 Java 的復制非常相似。為什么這么說？
SQL 的語言看起來是這樣的： "select customer_name, ship_date from orders where product_id=17 and state='CA'."。
從上可知，第一，SQL 有一個簡單的、類似英語的語法。沒有編程或數據庫管理背景的人可以通過閱讀這個語句大致了解它的作用。第二，SQL 是一個申訴式編程語言（Declarative Language）：用戶指定他們在尋找什么信息，但是他們讓數據庫系統(tǒng)來決定如何找到這些信息。也就是說，SQL 是一個對非程序員都很友好的語言，稍加練習，就可以編寫 SQL 查詢來完成一系列任務。
1974 年，一小群 IBM 研究人員在一個叫做 System R 的軟件包中實現(xiàn)這些想法。與此同時，IBM 的研究人員發(fā)表了描述工作的研究論文。這些出版物非常詳細，包括完整的 SQL 語言規(guī)范。System R 做出來了，但在接下來的幾年就只是在 IBM 內部使用。直到 20 世紀 80 年代初，IBM 才對外提供了一個基于 SQL 的商業(yè)數據庫。
Larry Ellison
而大約在 1977 年， Larry Ellison 和他的聯(lián)合創(chuàng)始人發(fā)現(xiàn)了 SQL 語言，他們當時開了一家名為 Software Development Laboratories 的軟件咨詢公司，然后想轉型到數據庫銷售公司。Larry Ellison意識到，如果甲骨文數據庫能與 IBM 的 SQL 標準完全兼容，可信度會更高。
SQL 的設計者 Donald Chamberlin 在1995年接受過一個采訪，其中提到，Larry Ellison 在1978年打電話給過他，想了解更多 IBM 研發(fā) SQL 的細節(jié)，包括錯誤代碼值。Chamberlin本人是很樂意分享的，但是他的老板拒絕了這件事，表示錯誤代碼是保密的。
不過因為 IBM 的白皮書展示了足夠的細節(jié)，足以克隆 IBM 的數據庫技術，甲骨文在1979年發(fā)布了第一個版本的數據庫。其時，該公司反復宣揚該產品起源于 IBM?！凹坠俏牡挠脩艚缑婢褪?SQL ”一位早期的甲骨文宣傳員說。
因為比 IBM 提前兩年上市，甲骨文一下聲名大噪，并在未來幾年保持著 SQL 數據庫領導者的地位。
后來 System R 內部還討論過 IBM 公布 SQL 的細節(jié)是否是一個錯誤，這讓甲骨文吃掉了許多應該屬于 IBM 的市場份額。但也有內部人士認為，發(fā)表研究論文之后，才讓 IBM 意識到這項技術很重要，所以從一開始就很認真對待。
“如果我們沒有發(fā)表那些論文，它就會失敗，”1995年，IBM 的老員工 Mike Blasgen 說?！癐BM 很有可能會忽略它?！?/p>
一直以來，甲骨文似乎都沒有試圖從 IBM 那里獲得 SQL 許可，相關人員似乎都認為甲骨文不需要許可。
而谷歌，不管怎么說曾經試圖與 Sun 建立授權關系。2005年8月，谷歌低調收購安卓，開始研發(fā)手機操作系統(tǒng)，同年谷歌找過 Sun Microsystems 討論過許可協(xié)議，并達成了一個暫時協(xié)議——谷歌向 Sun 支付2800萬美元（一說是 4000萬美元），獲得與 Java 相關的專利、Java 商標和其他資產的使用授權。另外，谷歌堅稱，他們從未試圖獲得 Java 界面的版權，在他們看來，法律對此并沒有要求。
但是協(xié)議很快破裂，谷歌后來稱主要原因不是價格，而是 Sun 對安卓平臺發(fā)展的控制力度超出了谷歌的意愿。因此，谷歌決定在沒有 Sun 許可的情況下構建自己的 Java 版本。
這意味著谷歌要從 Java 語言的功能規(guī)范開始，也就是 Java 語言的規(guī)則，包括關鍵字、語法以及標準函數的名稱和參數類型。谷歌沒有像甲骨文復制 SQL 一樣復制這些功能的代碼，工程師們而是從頭開始編寫自己的代碼，并產生了與 Sun 的 Java 代碼相同的結果。
谷歌后來宣布安卓是基于 Java 語言時，Sun 公司的首席執(zhí)行官 Jonathan Schwartz 當時還挺高興的，他公開表示，“我只是想和其他同事一起衷心祝賀谷歌推出的新 Java/Linux 手機平臺安卓。”
可能是力量懸殊，總之 Sun 當時并沒有找谷歌的麻煩，而2009年該公司被甲骨文收購后，就立馬轉了做法。2010年1月，Sun 交易結束，不久甲骨文就起訴了谷歌。值得關注的一點是，當年1月后，多位前 Sun 高管從甲骨文離職，其中包括前 Sun 首席執(zhí)行官 Jonathan Schwartz、XML 發(fā)明人 Tim Bray、前 Sun CTO James Gosling，其中 Tim Bray 加入了谷歌安卓開發(fā)團隊。
對比谷歌和 IBM 的復制，有一個挺大的差別：谷歌復制了 Sun 已經問世的產品，甲骨文復制了一個 IBM尚未發(fā)布的產品，學的是 IBM 發(fā)布白皮書。
Cornell Tech 法學教授 James Grimmelmann 在今年1月接受采訪時表示，從版權角度來看，兩者沒有太大差別。如果復制 API 是侵犯版權的，那么從文檔中復制 API 也是侵犯版權的。根據版權法，IBM 的論文是“受保護的作品”。"如果 SQL 規(guī)范是有版權的，那么無論是從軟件還是白皮書中復制的，版權都適用。
甲骨文一直以來的起訴點是谷歌抄襲了甲骨文的 API 。可能在他們的視角中，自己對 SQL 的復制與谷歌對 Java 的復制是不同的。
雷鋒網AI源創(chuàng)評論了解到，事實上，1979年，IBM 的 SQL 確實還沒有一個龐大的支持功能庫供甲骨文復制。因此，甲骨文這一套“語言復制”可以，“API 復制”不行的理論倒也符合他們的立場。
但是 Grimmelmann 認為，在編程語言和 API 之間在法律上區(qū)別對待是沒有意義的?！癝QL 本質上是一個通用數據庫 API，有9個核心動詞、參數，以及一些格式和語法?！?/p>
目前尚不清楚版權法會怎么區(qū)分核心語言和 API。例如，在執(zhí)行加法運算時，Java 可能要求用戶調用這樣的 API 函數:" n =sum(a，b)；"而不是通過" n = a+b；"。如果版權法要保護前者，后者符號“+”也應該得到保護。
從根本上說，API 是一種計算機程序之間相互通信的語言，而像 SQL 或 Java 這樣的語言也可以說是一種 API。成熟的計算機語言往往比其他 API 有更復雜的語法規(guī)則。但是潛在的版權元素——關鍵字、參數類型、語法規(guī)則——很多是相似的。如果 API 中的函數名稱可以被版權保護，那么計算機語言中的關鍵字似乎也可以被版權保護，包括“select”、“from”和“where”等 SQL 關鍵字。
另外，為了減小版權影響，2016年的安卓 7.0，谷歌舍棄了私有的 SunJDK 而轉用開源的 OpenJDK；2017年 I/O 大會上，谷歌宣布 Kotlin 取代 Java 成為 Android 一級開發(fā)語言。兩年后，谷歌表示，超過 50% 的專業(yè) Android 開發(fā)人員現(xiàn)在使用該語言開發(fā)他們的應用程序，在最新的 Stack Overflow 開發(fā)人員調查中，它被列為第四大最受歡迎的編程語言。
對于外界關于其抄襲 SQL 的言論，甲骨文并不認可，該司稱，“把蘋果和花椰菜放在一起比較，完全脫離事實，這是一個不正確的假設?！?/p>
這還沒完，執(zhí)行副總裁 Ken Glueck 在官網發(fā)布了一篇題為《別理會躲在幕后的人》的博客，言辭犀利，炮轟谷歌和它的支持者，“偽裝出一種獲得大規(guī)模支持的現(xiàn)象，但背后可能不過是利益交易?！?/p>
“這不是關于創(chuàng)新的案件，而是盜竊?！盙lueck表示，在軟件行業(yè)，竊取其他開發(fā)人員的軟件代碼并不常見，而一些復制的行為也是版權者出于雙方利益，一起合作，Java 并不是拒絕選擇，而是授權許可在版權方手里。
“谷歌試圖尋求外部團體的支持，拉上其他公司登上 friend of the court 簡報，制造案件有重大意義和爭議、大眾甲骨文的訴求阻礙著創(chuàng)新的印象。”
另外，他還提到谷歌遞交的26份簡報，其中7份簡報的實體有從從谷歌獲得“實質性貢獻（substantial contributions）”的評價；8份簡報背后的機構或個人與谷歌之間有著贈款、應付款、近似結算收益（ cy pres settlement proceeds）或雇用關系；2份簡報實體與谷歌之間有明顯商業(yè)往來；1份由幾名前美國政府雇員提交的簡報，這些人都曾在一家由谷歌前高管經營的小型政府機構工作過……這些團體涉及美國圖書館協(xié)會、EFF 和 Python 軟件基金會，以及83名計算機科學家，包括前 Java 執(zhí)行委員會成員 Doug Lea。
“除了微軟和IBM，前100家科技公司中的其他98家公司可都沒有提交任何一份簡報?！?/p>
這篇文章一出，原 Sun 員工、現(xiàn)谷歌首席 Java 架構師 Joshua Bloch 坐不住了，在推特上回懟：給對java貢獻巨大的Doug Lea潑臟水是無用的，他是14年前接受了谷歌的一筆小額贈款，但立即分給了那些參與 Java 程序測試的優(yōu)秀本科生。“甲骨文，你不感到羞恥嗎？”
另外雷鋒網AI源創(chuàng)評論注意到，開發(fā)者中雖然并不一定認同谷歌的說法，但面對甲骨文的態(tài)度基本是一致的——強烈反對。
一位開發(fā)者表示，甲骨文似乎是忘記或不知道簡報的提交者并非一定要公正。事實上，簡報是否被接受取決于提交者是否給出了合理的理由。一些辯護狀純粹是學術性的，他們是在告訴法庭他們將如何受到判決的影響?！?/p>
大部分人都認為拷貝 API 的說法是荒謬的，如果甲骨文贏了，軟件交互方式將會被永遠改變，“甲骨文或許會一時收獲大筆版權費，通過剝削其他開發(fā)者和公司的方式”，但是長遠來說，對于java的應用和生態(tài)也會造成影響：
“Larry摧毀了大家對于 Java 作為一個開放平臺的信任?！?/p>
“如果說有人在損害 Java 的利益，那就是甲骨文。在這場訴訟后，人們在選擇 Java 之前會三思而行。API 版權保護將是 IP 歷史上的一個新低點?！?/p>
在2010年這場訴訟之前，API 不受版權保護是行業(yè)潛規(guī)則。但若甲骨文勝利，將會打開潘多拉魔盒。也許法院最終會裁定 API 版權延伸到編程語言的核心特性，或者他們會找到一個法律來區(qū)分普通的 API 和編程語言版權。但不管怎樣，不確定性很大?；疑貛б魑?，需要數年的訴訟和數百萬美元的法律費用。
谷歌有兩種可能勝訴的方式，第一是絕大多數人所期待的，法院裁定 API 不能獲得版權。第二，最高法院可以認為 API 版權要具體問題具體分析，而谷歌的復制屬于合理使用范圍內。這雖能使谷歌免于寫給甲骨文10位數的支票，但仍可能將軟件行業(yè)拖入法律泥潭。
合理使用，是多么見仁見智的主觀標準啊。舉報這種行為可能會增多，而大多公司并沒有谷歌的積淀和法律資源去耗官司，所以未來不容樂觀。
參考
https://www.oracle.com/corporate/blog/pay-no-attention-to-that-man-behind-the-curtain-030920.html
雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。
