本週美國的最高法院深得我心。先是判決了州政府禁止同性婚姻的立法違憲，昨天又拒絕重審 Google 主張 API 不受著作權保護的上訴。
Oracle v. Google 這案子我在有物上面一路分析過幾次（分析上訴法院判決、Oracle 的訴狀）。如今又往前邁進了一個里程碑。
Google 明知需要 Java 授權
前情提要。
當年 Google 為了抗衡蘋果的 iPhone，由 Andy Rubin 領軍開發 Android 系統。Andy Rubin 自 2005 年就領導 Android，後來公司被 Google 併購。
Andy Rubin 內部研議後，決定採用 Java 語言為核心來開發 Android。他在 2005 年寫給 Larry Page 的信中，清楚表示 Java 是 Android 的核心：
Android 正在建造一個 Java 的作業系統。我們以 Java 為解決方案的核心因為 a）Java . . . 是行動裝置開發的第一選擇，b） 已有文件與工具，c）電信商要求可掌握的程式碼，4）Java 有安全的架構。
但是，Google 沒有取得 Java 當時擁有者昇陽（Sunmicro Systems）的授權。Java 雖然是開源碼，但開源的前提是必須與 Java 相容。而 Google 並不希望 Android 與 Java 相容，因此依照 Java 的條件還是需要獲得授權。所以在 2005 年另一封 Google 的內部信件中，Andy Rubin 暗示如果昇陽不願授權，就得「硬幹」：
如果 Sun 不想跟我們合作，我們有兩個選項：（1）放棄並改用微軟的 CLR VM 與 C# 語言，或（2）硬作 Java 然後捍衛我們的決定，一路上豎立許多敵人。
“If Sun doesn’t want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language – or – 2) Do Java anyway and defend our decision, perhaps making enemies along the way”
在另一封 2010 年的 Google 內部信中，Android 資深工程師 Tim Lindholm 對創辦人 Larry Page 更承認 Android 需要 Java 的授權 ：
我們被（Google 創辦人）指派調查是否有 Java 以外的選項適合 Android 與 Chrome。我們查了不少，但發現其他的都很爛。我們的結論是我們需要根據我們的條件談判獲得 Java 的授權。
Google 未獲授權硬推 Android
最終 Google 沒有獲得昇陽的授權，決定硬推。為了吸引當時主流的 Java 工程師投入 Android，Google 設計 Android 的方式十分巧妙 — 不是照抄 Java 的程式碼，而只抄襲了 Java API（Application Programming Interface，應用程式接口）的結構。本案的癥結就在於 API 的「結構」是不是受到著作權（copyright）的保護？
我用圖書館來解釋。想像有一個圖書館，專門蒐集各種工具書。圖書館裡有 37 個書架，每一個書架上放了同個領域的書。例如個人理財書架上放了很多個人理財的書，廚藝書架上放很多廚藝的工具書。
每一本工具書裡有不同章節。例如廚藝書架上其中一本是《快速牛肉料理大全》。書的其中一章是「蔥爆牛肉」。
每一章裡還分兩部分，「材料準備」與「實際製作」。例如「蔥爆牛肉」這一章，會先有一個材料準備：「綠蔥至家樂福買。牛肉需澳洲牛，可以在 Costco 買。另外準備醬油。」實際操作的部份，則描述做菜流程：「蔥爆香，再下牛肉跟調味料」。
Google 的巧妙之處，便是在蓋 Android 圖書館時，照抄了 Java 圖書館的 37 個書架名，以及這 37 個書架內，共 7,000 行的「材料準備」。Google 沒有抄實際操作的章節。Google 承認這樣做是為了吸引原本去 Java 圖書館的工程師，讓他們能很快上手 Android。
那麼，這 37 個書架名稱，以及「材料準備」的架構是否受著作權保護？或者依照 Oracle 的舉例，如果有人照抄《哈利波特 — 火盃的考驗》的「目錄」，以及其中每一章第一段的第一行，但是其他部分寫的是另一本小說；而且這樣抄的目的是吸引原本哈利波特的讀者，算不算侵權？
最高法院駁回上訴
去年大約此時，聯邦上訴法院（Federal Circuit）說 Google 的抄襲算侵權。上訴法院說編排目錄、命名章節的方式有千百種，是一種需要創意表達的設計。就像情歌唱法也有千百種。如今 Android 抄襲 Java 的編排方式，就像某小歌星抄襲 Taylor Swift 的情歌，是抄襲了她的創意表達。
最高法院昨天駁回 Google 上訴，意思是「這問題我們沒興趣重審。聯邦上訴法院說了算。」
要注意這裡爭的不是抽象的 API 概念；而是很實際的、Java 這 7,000 多行程式碼的表達方式的著作權。API 受著作權保護，也不代表使用 API 或是設計有同樣效果的 API 就侵權。就像每個人都還是可以做蔥爆牛肉，或是寫出自己的蔥爆牛肉食譜；只要不要照樣抄襲別人食譜的寫法就是了。iCook 愛料理上就有 30 種蔥爆牛肉食譜。
回到地方法院重審「合理使用」
接下來本案將回到地方法院，針對合理使用（fair use）的部份重審。這個順序是因為如果 Java API 不受著作權保護（現在確定受保護），或是 Google 沒有侵權（Google 原本就承認侵權），就沒有審理合理使用的必要。
合理使用的概念是，有時候基於一些公益理由，侵犯著作權是可以接受的。比如說某夜店 DJ 擷取（sample）了 Taylor Swift 情歌的片段，放在舞曲組曲中。這時雖然他用到了 Taylor Swift 的情歌，但是是有限的使用，並且有轉換其意義（transformative），不會讓人誤解 DJ 是原唱，也不會傷害到 Taylor Swift 的情歌市場。那麼基於鼓勵創作的公益性，這樣的侵權沒有關係。
所以接下來，Google 將會主張 Android 雖然確定侵犯了 Java 的著作權，但其侵權有公益理由。Google 首要主張的公益理由，是它侵權是為了促進軟體之間的互用性（interoperability）。 但這理由一般認為站不住腳，聯邦上訴法院也暗示 Google 的論點自相矛盾：
「證據顯示 Google 特意設計 Android 讓它不與 Java 平台或是 JVM 相容，所以我們覺得 Google 的互用性主張令人困惑 . . . Google 不是想要與 Oracle 的 Java 平台與其核心的 JVM 相容。其實 Google 想要的是利用軟體工程師已經有 Java API 的經驗及訓練。」
“given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing. […] The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue.”
一般認為 Google 的侵權不是片段的、有限的轉換使用，而是一個系統性的爭取 Java 工程師的計畫，顯然直接傷害了 Java 的利益。因此很難稱為合理使用。
要等到地方法院裁定是否有合理使用，才能確定到底 Google 與 Oracle 這一場多年戰爭誰輸誰贏。
Google 從 Android 獲得的價值，是否該分給 Java 的開發者？
由於 Google 的情勢相當不利，接下來 Google 可能一手與 Java 和解，簽下一個長期協議；另一手開始推動與 Java 架構完全獨立的語言，如 Go 或是 Dart。但那是大工程。
而大家最愛爭辯的是，軟體該不該受著作權保護？例如 Vox 的標題是「最高法院拒絕重審傷害軟體著作權的案子」（該篇作者的兄弟是 Google 的高管）。在 The Verge 的另一篇討論之下，倒是支持最高法院判決的佔多數。
由於這樣問非常抽象模糊，因此可以吵很久。有些人說如果 API 有著作權，會扼殺其他軟體開發的創新。[註 1] 比如說如果當初 Android 必須付 Java 授權金，恐怕就沒有完全免費的 Android 開放給一般軟體工程師使用。
另外一些人則會反駁說，如果當初不是相信著作權的效力、相信開源碼契約的效力，昇陽也不會投資開發開源的 Java [註 2]。當初也不會累積那麼多 Java 工程師，Android 也不會有東西可抄了。
從企業策略來看，事實上 Google「借鏡」Java 現有的架構來吸引工程師投入 Android，並把 Android 開源，擴大生態圈，與當初昇陽「借鏡」C/C++ 架構來吸引工程師投入 Java，並把 Java 開源，擴大生態圈，策略幾乎如出一轍。下一個這樣做的科技公司是誰？（小米或三星？）會不會又再次讓前一家公司覺得被利用了，出面追討？著作權鼓勵創新的原意沒有變，精彩的是不同企業輪番在政策法規的框架下各出奇招。
註 1：事實上著作權的保護範圍比專利小，只保護表達方式（食譜的寫法）而不是方法（實際做菜步驟）。而且另外還有合理使用與反壟斷法的限制。
註 2：開源的回授權（grant back）前提是有著作權保護，這一點很多人忽略。如果軟體沒有著作權，回授權是沒有強制力的。
本文感謝蔡孟達審閱草稿。
