白癡判決讓 Oracle 可以拿九列程式碼的著作權到處濫收保護費

Oracle vs google 的 Java API 官司， Oracle 勝訴， 於是 Oracle 準備大舉開徵保護費， 各行各業挫著等 [ 科技報橘、 風傳媒]。 身為程式設計師， 我看了快吐血。

讓我做幾個比喻， 你不需要會寫程式， 也能理解何謂 應用程式介面 Application Programming Interface。 牆壁上的電源插座， 就是電力供應的 API。 供電方與用電方同意： 接觸的兩隻腳距離要多遠、 電壓是多少、 頻率是多少。 提款機的提款卡插入口， 就是提款/查詢服務的 API。 提款卡的寬度、 厚度、 晶片的位置、 傳遞的資訊、 ... 這都有固定的數值， 是業界大家共同遵守的共識。 電腦跟電視之間、 跟投影機之間的 VGA 接口或 HDMI 接口， 就是影像傳輸的 API。 API 是一個共通的介面， 是一種微型的語言， 讓參與溝通的多家廠商可以交換資訊。 相較於發電廠、 相較於各種需要吃電的複雜電器設備、 相較於提款機內部電路， API 不過是一個小小個的接口， 它的複雜度幾近於零。 API 不應該受到著作權保護。 它既不屬於臺電、 也不屬於任何一家家電業者、 更不屬於任何一家銀行所獨有； 它是大家溝通時共用的語言。

隨便找一個 C 語言或 C++ 語言所寫的程式， 比較一下 *.h 程式碼 (API) 的份量 vs *.c 或 *.cpp 或 *.c++ 程式碼 (實作， implementation) 的份量， 你就可以具體地粗估我所說的 「趨近於零」 的那個數字。 自由軟體之父 Richard M. Stallman 在設計 GPL 的時候， 還多設計了一個 (約束力較小的) LGPL， 就是要讓專屬軟體可以採用自由軟體的 API 而不需要跟著把自寫的專屬軟體的程式碼釋放出來。 因為他知道支持 GPL 需要理念； 但對於那些想佔自由軟體便宜但又不想付出的廠商來說， LGPL 比較可以接受。 另一方面， 即使是專屬軟體的著作權人之間， 經常也需要靠 API 來溝通。 例如 W3C 引發公憤的 EME 「標準」， 就是一種 DRM 領域的 API， 沒有哪一家白癡公司主張對 EME 擁有著作權。 從自由軟體到瀏覽器 DRM， 光譜上的這兩個極端， 任何稱職的程式設計師都知道： API 是一個溝通用的介面； 它不該是智慧財產權保護的對象。 一旦 API 被列為智慧財產權保護的對象， 開發應用程式就成為處處可能踏到法律地雷的高風險違法行業。 這也是為什麼蘋果共同創辦人 Steve Wozniak、 C++ 之父 Bjarne Stroustrup、 Unix 之父 Ken Thompson、 作業系統大師 Andrew Tanenbaum、 Linux 之父 Linus Torvalds、 ( 感嘆世人看不見的) Smalltalk 之父 Alan Kay、... 還有電腦界其他許多大咖， 他們透過法庭之友機制在本案當中力挺 google， 對法院解說為何 API 不該被著作權保護。 如果有程式設計師竟然還主張著作權可以保護 (用來讓兩隻程式接口的) API， 那我看他不如就乾脆加碼主張他嘴巴碰過的碗以及屁股坐過的馬桶等等任何跟他身上的洞口對接過的東西也通通都侵犯他的著作權吧！ 這位拒聽專家建言的白癡法官一定也會力排眾議跟他站在同一陣線的。

API 不該被著作權保護、 基於 API 的侵權判決是智障判決； 但是 Google 在其他面向有沒有侵權？ 有， 就只有 九列程式碼：

private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
     if (fromIndex > toIndex)
          throw new IllegalArgumentException("fromIndex(" + fromIndex +
               ") > toIndex(" + toIndex+")");
     if (fromIndex < 0) 
          throw new ArrayIndexOutOfBoundsException(fromIndex);
     if (toIndex > arrayLen) 
          throw new ArrayIndexOutOfBoundsException(toIndex);
}

從我們的角度來看， 這就是 Oracle 勉強有立足點可以拿來坑殺顧客的 「智慧」 財產依據。 第一審的法官 William H. Alsup 為了理解大家的說法， 還 認真地自學寫程式， 最後判 Google 勝訴。 但是上訴法庭的白癡法官就沒這麼認真做功課了。 對於這種低能判決， 我沒有力氣再幹譙或解釋更多了。 有興趣了解此案來龍去脈的讀者， 可以從 EFF 的 Oracle vs Google 專頁 找到很多資料。 除了上述電腦專家之外， 還有微軟/紅帽/HP、 App 開發者聯盟、 Mozilla、 智慧財產權教授群、 電腦與通訊工業協會等等團體也都透過法庭之友機制， 在本案中力挺 Google。

雖然這次的事件的受害者主要是 java 用戶； 但資料庫被 Oracle 綁架的公司更多。 而仗著九行侵權程式碼向 Google 敲詐九十億美元的 Oracle 是怎麼樣的一家公司呢？ Oracle 的軟體稽核、 經銷商： Oracle 毀了我們的事業 (2011)、 「我覺得好像被敲詐了」 一位客戶解說如何被 Oracle 逼上雲端 (2015)、 Oracle 殘暴的銷售戰術 (2015)、 ... 特別大推這份報告： 採用 Oracle 應用軟體的隱藏代價。 簡單講， Oracle 的專長不是技術或服務品質而是簽合約； 它採取的手段不是提供誘因， 而是威脅。 就是透過軟體稽核逼用戶越陷越深。 但是客戶們通常因為自己授權不足、 法律上自己理虧， 所以人人心虛、 沒人敢站出來大聲反抗， 也因而無法彼此交流經驗， 共同找出對抗 Oracle 的策略。 和那些被黑道用毒品控制住的受害者有沒有像？ 跟 Oracle 的作風對照之下， 現在回頭再看那些 「只收你一次錢就滿足的勒贖軟體」， 後者根本就是慈悲為懷的大善人。

所以， 如果你們公司用到 Oracle 的任何一種產品， 都應該覺醒了。 最重要的第一步就是理解 Scott McNealy 所說的 barrier of exit。 他是 Sun Microsystems 創辦人， 在 Oracle 買下 Sun 的時候， 就給了這個超級重要， 但卻被主流資訊教育體系及資訊產業所忽略的六分鐘演講。 對， 沒錯， 他雖然是拿 IBM 的 DB2 作例子， 但其實一樣適用於 Oracle 的資料庫， 現在竟也出人意表地適用於被 Oracle 搞爛掉了的 Java。 這不是只有 CIO 需要知道。 不寫程式的老闆也能夠、 也需要理解。 事實上我在通識課裡， 每個學期都會考這個概念， 因為這就像是每一位公民需要知道詐騙集團的手法或毒品的危害一樣重要。 戒毒很痛苦， 但只痛一次； 不戒的話， 就痛一輩子。 「跳下賊船」 不是喊跳就馬上能跳的， 邁向自由， 必須逐步穩健走； 但若不起頭， 就只能永永遠遠地當 Oracle 的奴隸， 直到你們公司或你們國家降旗收攤不再做生意的那一天為止。

* * * * *

（本文也刊載於 關鍵評論）