跳至主要內容

搜尋摘要

目錄
科技島讀 節目封面
00:44:35 ~4 分鐘

Ep.139 Google vs. 甲骨文 — 大法官的妥協|特別來賓 水某教授 與 鄉下教授

美國最高法院歷時十年裁定 Google 複製 Java API 的行為構成合理使用,但刻意迴避了 API 是否受著作權保護的根本問題,判決邏輯遭質疑,也讓軟體業界的競爭優勢從法律壟斷轉向實作與生態建設能力。

在 Apple Podcasts 收聽

本頁摘要由 AI 自動生成,著作權屬原節目創作者;可能存在錯誤或遺漏,建議收聽 原節目《科技島讀》 以獲取完整資訊。

重點摘要

  • Google v. Oracle 案歷時十年終結:美國最高法院以 6 比 2 裁定 Google 複製 Java API 的行為構成合理使用(Fair Use),Android 平台得以維持現狀,軟體業界鬆一口氣
  • 最高法院迴避核心問題:法院刻意不回答「API 能否受著作權保護」,僅假設受保護後再討論合理使用,讓法律上最根本的問題懸而未決
  • 判決邏輯遭批牽強:多數意見由 Justice Breyer 執筆,打破傳統分析順序,被異議法官 Thomas 批評刻意迴避不利論點,論理不清爽
  • 合理使用四要素是判斷關鍵:利用目的、著作性質、利用質量、市場替代效果——其中 Breyer 強調 API 具高度功能性、保護應極薄,並認定 Google 將電腦端技術移植至手機端具「轉化性」
  • 判決範圍極窄,不等於 API 可隨意複製:僅適用於本案具體情形,其他開發者不能直接援引,仍需個案判斷

詳細內容

案件背景:Google 為何複製 Java API

2005 年智慧型手機時代來臨前,Google 收購 Android 公司、決定打造手機作業系統,選擇以 Java 語言為基礎,目的是吸引當時大量已熟悉 Java 的工程師。

Google 複製了 Java 的 37 個套件(package)的 API 宣示碼(Declaring Code),也就是那套讓工程師呼叫功能的「索引系統」——判決書中 Breyer 大法官以「機器人走到正確的櫃子、拉開抽屜、取出食譜交給廚師」比喻:Google 抄的是「櫃子與抽屜的命名規則」,但「廚師怎麼做菜的部分(Implementing Code)」則完全自行重寫,針對手機硬體優化。

原本 Java 的開發商 Sun Microsystems(昇陽) 並不反對,甚至歡迎 Android 加入生態系;但 2010 年 Oracle(甲骨文)收購昇陽後,開始積極追討授權費,才引發這場長達十年的訴訟。

兩個核心法律問題

第一回合:適格性(API 能否受著作權保護?)

電腦程式在 1990 年代被美國國會刻意納入著作權保護,視為「文學著作」。但 API 是否也在保護範圍內,全美 13 個巡迴上訴法院意見分歧,最高法院本應做出定論。

然而,這次最高法院選擇迴避——多數大法官以「假設 API 受保護」為前提,跳過此問題直接討論合理使用,令學界大失所望。

第二回合:合理使用(Google 的行為是否合法?)

著作權法的合理使用有四項判斷標準(台灣著作權法第 65 條、美國著作權法第 107 條):

要素說明本案分析
1. 利用目的與性質是否具「轉化性」(Transformative)?Breyer 認定從電腦平台移植到手機平台具轉化性
2. 著作性質被抄作品的保護強度API 功能導向,保護應極薄
3. 利用的質與量用了多少、用了最重要的部分嗎?僅複製 API 宣示碼,未複製實作碼
4. 市場替代效果是否損害原著作市場?Google 認定沒有實質替代效果

判決邏輯的爭議:多數意見 vs. 異議意見

Justice Breyer(多數意見) 採用非常規分析順序,先從第二要素(著作性質)切入,強調 API 功能性高、表達選擇空間極小,因此就算受保護也保護力極薄。其「轉化性」論述也被批評過於簡略——僅因使用環境從電腦換成手機,就稱之為轉化。

Justice Thomas(異議) 則批評 Breyer 刻意迴避傳統上最重要的第一與第四要素,邏輯順序倒置,是為了達成預設結論的「先射箭再畫靶」。

兩位受訪法學教授(水某教授、鄉下教授)也坦言:Thomas 的論理較清晰,Breyer 的寫法像是「妥協的產物」——面對燙手議題,為避免讓業界震撼而做出的結論先行、論理為輔的判決。

判決對軟體業的實際影響

對開發者:謹慎樂觀,非全面開放

  • 本案結論極為狹窄,適用條件苛刻:必須像 Google 一樣只複製 API 宣示碼、自行重寫實作碼、且目的在於將既有技能帶入全新平台
  • API 的著作權保護問題仍未解決,原始碼擁有者仍可對他人主張權利
  • 越接近 Google 的用法越安全,越偏離則需重新個案分析

對產業生態:競爭邏輯轉移

  • API 若不再能成為壁壘,競爭優勢將回歸到後端實作能力、生態系建設、使用者體驗
  • 許多公司可能需要轉向以生態系價值(而非法律壟斷)鞏固競爭力
  • 有觀點認為此判決反而有利於開放競爭:基礎工具共享,各家比拼實力

精選語錄

「今天 API 到底受不受保護,在最高法院從來沒有討論過……而這一次,最高法院還是選擇迴避了。」

「Breyer 他的多數意見為什麼我們很少看到說『我們先假設他的著作權好了,其他先不要談,我們再來談合理使用』——這是很難看到的一點論理的東西。」

「你的案子越接近 Google 那就越安全,你的用法越像……財力要越像 Google,你再去跟他打個十年看看。」


時間軸

本集逐字稿未包含時間戳記,以下為主題進行順序:

  • 開場 — 介紹兩位匿名法學教授(水某教授、鄉下教授),來自 Podcast「法學教授的茶話群組」
  • 案件背景 — 2005 年 Google 收購 Android、選用 Java、談判破裂始末;2010 年 Oracle 收購昇陽後發動訴訟
  • 什麼是 API — Breyer 大法官的「抽屜 / 食譜 / 廚師」比喻解析
  • 為何軟體受著作權保護 — 1990 年代美國國會刻意選擇著作權而非專利保護的歷史脈絡
  • 合理使用四要素逐項分析 — 以「古阿木(GoodMoRe)五分鐘看電影」為具體案例說明
  • 判決爭議 — 多數意見(Breyer)vs. 異議意見(Thomas)的邏輯對比
  • 實務建議 — 對軟體工程師、公司法務、API 創業者的影響評估
  • 結語 — 來賓介紹其 Podcast 節目

相關主題