yowureport

外國媒體都錯了 — Google 輸掉 Android 抄襲 Java 案其實有道理

androids

 

背景

 

上週五晚上,美國聯邦巡迴上訴法院駁回 Google 的勝訴,宣布甲骨文的 API(Application Programming Interface,應用程序接口)受著作權保護。

本訴訟是過去 10 年兩大科技訴訟之一(另一個是蘋果對三星),因此判決引起媒體廣泛迴響並不出奇。出奇的是美國的網路媒體,包括 The Verge, Business Insider 等可說是一面倒的批評聯邦巡迴上訴法院 (以下簡稱 Federal Circuit)。

The Verge 的標題是「聯邦法院逆轉 Google v. Oracle 判決,設下災難性的前例」。Business Insider 直接用 Google 的說法當標題「Google:這個甲骨文訴訟可能傷害整個軟體產業」。Vox 更是點名批判 Federal Circuit:「製造專利蟑螂混亂的那個法院又要來搞砸著作權了」。

"The court that created the patent troll mess is screwing up copyright too"

這些說法都不公平,可是台灣的媒體大部分也跟著人云亦云。事實上這次 Federal Circuit 的判決是 3-0,三位法官一面倒的駁回了地方法院的判決。而且讀完整份判決書,可以很明顯了解地方法院的判決錯誤連連。

 

判決 

到底甲骨文告 Google 什麼?甲骨文控告 Google 開發 Android 時,抄襲了 Java 語言裡的 37 個 API package。(註:當初寫 Java 的是 Sun Micro,後被甲骨文併購。以下都以甲骨文討論。)

API 是一種程式與程式間的接口,用來簡化串接程式的困難。例如火車的售票櫃檯可以想成一種 API。顧客付錢給櫃檯的小姐,說要一張去台東的車票,小姐就敲敲鍵盤,印出一張去台東的車票。顧客不用管小姐怎麼印出車票的,小姐也不用管顧客的錢是哪來的。只要雙方吐出的資訊符合設定,就可以正確接口。

如果顧客說:『給我一籠小籠包吧』,小姐是不會理他的,因為這個輸入參數不符合接口的設定。(感謝 Odin 提供的比喻)

eva_air_ticketing

圖片來源:kuei.chen

OK 這樣我們懂 API 的功用了。那為何甲骨文說 Google 抄襲它的 API 呢?這牽涉到 API 內部長什麼樣子。API 是一個程式的結構,由很多指令集結而成。用圖書館來比喻:

想像有一個圖書館,專門放各種如何動手做(how to)的書。圖書館裡有很多書架,每一個書架上集合了類似領域的書。例如「教你怎麼賺錢喔!」的書架上放了很多個人理財的書,「廚藝天王你來做」的書架上放很多有關廚藝的書。

每一本書裡則集合了類似題材的章節。例如「廚藝天王你來做」的書架上有一本書叫做「快速牛肉料理大全」,然後其中一章是「如何做蔥爆牛肉」。

由小往大看,「如何做蔥爆牛肉」這一章就是一個指令(method),「快速牛肉料理大全」這本書是一個 class,而「廚藝天王你來做」這個書架就是 API Package。這些書架集合起來就是 Java 圖書館。

每一章裡還會分兩部分:「前提說明」與「實際操作」。例如「如何做蔥爆牛肉」這一章,會先有一個前提說明「準備綠蔥,可以在家樂福買。準備牛肉,指澳洲牛,可以在 Costco 買。準備醬油,可以用任何品牌。」然後實際操作的部份,則描述如何運作:「先爆香蔥,再下牛肉跟調味料」。

在程式語言裡,每一章的「前提說明」叫做 declaration code。而實際操作這一段叫做 implementation code。

那麼 Google 做了什麼?Google 當初在蓋 Android 圖書館時,為了吸引原本習慣去 Java 圖書館的眾多工程師,因此逐字的抄了 Java 的 37 個書架的命名,以及這 37 個書架內,共 7,000 行的「前提說明」。如此一來,當工程師們來蓋 Android 圖書館時,因為很熟悉架構,可以輕鬆上手。

結果 Google 成功了。大把的工程師來幫 Google 蓋 Android 圖書館。反而 Java 自己的圖書館,特別是專攻手機系統的圖書館(Java ME),都沒人來蓋了。

不過 Federal Circuit 認為 Google 此舉侵犯了甲骨文的著作權。很好懂吧?其實上面的比喻就是本案裡 Google、甲骨文以及法官共同採用的比喻。

 

 

菜單有著作權?

Google 承認它照抄了這 37 個書架的命名結構,以及這 7,000 多條的「前提說明」碼。「抄」這點沒有爭議,我在另一篇「Android 的成功:落後時抄襲,領先時霸凌?」已經介紹過 Google 明知故犯的證據。Google 也承認如果 Java API 受著作權保護的話,Google 的使用方式(非 GPL 使用)不符合甲骨文的免費授權條件。

有爭議的是,API 有沒有著作權?

要知道著作權保護的是表現(expression),不是概念(idea)。著作權重視的是創意(creativity)與原創性(originality)。例如「采菊東籬下,悠然見南山」這句話每個字都是舊的概念,但像這樣組織起來有不同的表現,就受著作權保護。

API 不像「采菊東籬下,悠然見南山」那麼詩意,它主要是在描述程式語言的順序、結構、組織(sequence, structure, organization)。書架的命名架構,或是「前提說明」比較像菜單或是書的目錄,難道也受著作權保護?

Federal Circuit 說當然受著作權保護。任何軟體工程師都知道,一個好的 API 需要非常高的創意與原創性才寫得好。甲骨文集眾多工程師,花費許多時間合寫出的 Java API,所需的心力恐怕不輸給寫出「采菊東籬下,悠然見南山」所需要的才華。因此當然有著作權保護。

就像如果有一家餐廳從零寫出自己的菜單,並且獲得眾多顧客光臨。假如有另一家餐廳也要寫菜單,它可以自己寫 -- 畢竟寫菜單的方式有千百種。但它不可以照抄前一家的菜單,當然更不應該為了吸引前一家的客人而照抄。

 

Google 的論點,以及為何全部被駁回 

Google 主張 Java API 不該受著作權保護。而且它的主張部分被地方法院接受,卻被 Federal Circuit 全數駁回。我簡介一下為何這些主張被駁回。

  1. API 是一種概念(idea)

Google (以及地方法院)主張 API 是一種概念,而不是表達,因此不該受著作權保護。類似如果有一本書叫做「五月逃稅的 10 種方法」,那 Google 主張這 10 種逃稅方法是一種概念,任何人都有權利照樣操作,因此不能夠擁有著作權。

但 Federal Circuit 說文字常常同時兼具功能性與表達性。當兩者皆有時,表達性的部份仍然受著作權保護。例如上述的會計書,它的文字兼具功能性與表達性。其他人的確可以照書中寫的這 10 種方法逃稅,但不可以翻印書的內容。

除非,描述該概念的文字只可能有一種。例如假設上述會計書的寫法,是唯一一個描述這 10 種逃稅方法的寫法。那麼它會失去著作權保護。例如「1+1 =2」這句話基本上不可能有別的寫法,因此也不能有著作權。

但甲骨文當初設計 Java 圖書館時,有無限多種命名選擇。甲骨文選擇了這 37 個名字本身是一種創意表現,應該受著作權保護。

2. API 的文字很短

Google(以及地方法院)認為 API 是一連串的短字組織而成,因此不能受著作權保護。

Federal Circuit 說的確名字、標語、職稱等短詞一般沒有著作權。但著作權在乎的不是短或長,而是有沒有創意。很多短的字句仍然有可能包含創意。Federal Circuit 引用著名小說家的作品:

 「. . . . 狄更生的小說「雙城記」開頭也只有一連串的短詞。但沒有人會說只因為可以被拆解成更小的部分,狄更生小說的開頭便不值得著作權保護。」

註:沒有法律人不喜歡引經據典跟雙重否決語式(double negative)

dickens_tale_two_cities

圖片來源:peter_curb

3. Java 的 API 結構已經廣被接受,成為業界標準了

Google 的另一個論點是因為工程師都已經普遍接受 Java 的 API 結構了,因此成為業界的標準,應該失去著作權保護。

Federal Circuit 說沒這回事。智慧財產權之中,只有商標可能因為受歡迎而被稀釋(dilute),例如 Sony 的 Walkman 後來就變成人人都可用的名稱。但專利與著作權沒有這種限制。

4. 抄 Java 的 API 是為了可以跟 Java 相容(interoperability)

Google 最後一個論點被 Federal Circuit 狠狠打槍。Google 說它抄 Java 的 API 是為了可以跟 Java 相容。

但 Federal Circuit 說首先,Android 能不能跟 Java 相容根本就不關 Java 的事。Android 是否能跟 Java 相容,與 Java 有沒有著作權一點關係都沒有。

其次,Federal Circuit 說:『Android 跟 Java 相容的證據在哪?有任何 Android 程式可以在 Java 環境裡跑嗎?沒看到啊?』

Google 的律師辯稱:『如果一個 Android App 只用到這 37 個 API Package 的話,就可以在 Java 環境裡跑啊。』Federal Circuit 回嗆:『可是你沒提出有任何一個 Android 程式只用到 37 個 API Package 啊?舉個例子來瞧瞧。』

Federal Circuit 更指出很多證據顯示,Google 當初跟甲骨文談不攏就是因為 Google 堅持 Android 不要跟 Java 相容。它完全不支援 Java 的核心哲學「寫一次,到處都能用」(write once, run anywhere)。

 

媒體上與法庭內的差異 

本案最終結果會如何呢?讓我引用訴訟律師的標準回答:『應該會和解吧。』也就是 Google 付錢給甲骨文。統計上絕大部分的訴訟都會和解。說了等於沒說。

接下來,Google 要回到北加州地方法院重審「合理使用」(fair use)的部分。「合理使用」是一種著作權侵權的避風港。這概念只要你看過「網路共享版」的影片就知道了。片頭會寫:「本片僅供教育或英語教學使用 . . . .」。這就是想躲進「合理使用」的避風港。

從 Federal Circuit 的判決來看,Google 敗部復活的可能性不大,因為抄的事證明確,而且 Google 抄的理由離合理使用太遠。一般合理使用僅限於學術用、新聞用或是教學用;抄競爭對手的東西來吸引對方的工程師,很難被稱為「合理使用」。

Google 如果再輸,可以上訴到最高法院。但成功機會也不大。因為 Federal Circuit 的判決書清楚明瞭、斬釘截鐵,並不是如國外媒體上說的不懂著作權、不懂程式設計。

我比較有興趣的反而是要怎麼計算 Google 的罰金?因為 Google 是免費提供 Android 給手機製造商,獲益絕大部分還是來自 Google Search。要怎麼連結這兩點,計算出 Android 的商業價值,會是法院棘手的問題。

至於美國網路上還是一片哀鴻遍野,疾呼「程式設計完了」,一部分是因為網路上聲音最大的「開放社群」的網民,比較傾向 Google,看不起甲骨文。另一部分是因為美國的網路媒體跟台灣類似,也喜歡塑造聳動的對立來拉抬收視率。就像我這篇的標題。

那麼,對台灣的軟體工程師,這個案例有何影響?主要是確認 API 的創意價值與商業價值,並且讓著作權的範圍更加明確。這對每一個從業人都有幫助。一個法院把 API 與狄更生的小說相提並論,不是等於完全無法否認程式設計無疑是優美又富創意的工作嗎?(四重否定句)


 

本長文為公開文章。歡迎轉寄給期待優質科技策略分析的朋友,並鼓勵他 / 她訂閱有物

封面圖片: valanzola.t

«

»

科技島讀-你的未來趨勢嚮導

有物推出新產品囉!

由有物報告團隊製作的最新產品-科技島讀

透過閱讀科技島讀,你將能夠掌握科技趨勢,從更高的視角觀察科技將如何改變世界。

現在就前往 >> 科技島讀