API是否應被視為「著作」？

這幾天有一則消息，是關於IT產業的兩大巨頭Oracle及Google，這兩間公司有一場纏訟多年的訴訟。

美國最高法院駁回了Google所提出的侵權案上訴聽證會申請，而訴訟的戰場，將重新回到舊金山地方法院，就Google的侵權程度，審理其應賠償的金額。

Oracle與Google為Java打官司，爭執是否侵害專利與版權

這個訴訟，其實經歷了好幾年。事情必須追溯至2010年的8月，那時，由Oracle先挑起戰火，出面控告Google侵權。

雙方在什麼項目上侵權呢？很容易可以猜到，那就是Java。

Java一直是Google中極為關鍵的程式語言之一，Google甚至招聘了多位原先在Sun及Java社群裡的Java要角，跳槽至Google（之後甚至招攬了Java語言之父James Gosling）。

其原因，不外乎Google想要更掌握Java的技術，甚至，透過其公司的資源，更進一步改良Java，使得Java更能充份的為Google所運用。

或許，Google真的會後悔當初沒有收購Sun，而讓Oracle買走。

另一方面，Google在行動裝置上推出了Android作業系統，想要奠定在行動裝置上的連網江山。即使Android採用了不同於JVM的Dalvik虛擬機器，但是，在應用程式開發端，仍然還是以Java做為主要的開發語言，並使其可編譯後的結果，可運行於Dalvik之上。

這種作法的好處是，Java已經是普遍廣為程式設計者所愛用的程式語言，這能讓大量的程式設計者毋需經過新語言的學習曲線，即可在很短的時間內投入Android應用程式的開發。

另一方面，許多現存的Java原始碼，都有機會獲得在Android上被重覆使用的機會。對Google來說，在Android上使用Java來開發應用程式，似乎是相當明智的決定。

不過，大多數的Java應用程式都倚靠Java的核心程式庫，Java應用程式開發的高生產力，有一部份必須歸功於這套核心程式庫的設計得宜。正如許多人檢討C++早期，正是缺乏一個標準化的程式庫，致使其開發生產力受到影響。

而Android當然無法直接將Java核心程式庫納入，這是因為，核心程式庫內程式碼的授權問題。

不過，這並非難事，只要照著Java核心程式庫的介面（interface），重新再刻出一份，實作出來即可。

拜利用介面隔離實作設計方法的威力之賜，重刻後的實作（即位在Android的libcore中），基本上，依然運作如在原有Java平臺。

這為Android吸引了眾多Java開發者，讓他們在踏入Android開發領域時，產生了很大的助益。

而Oracle控告Google的部份，包括了兩項侵權項目，即專利侵權與Java的版權侵權。在 2012 年，法院宣布判決，認定Google並未在專利上侵權，但是在版權上侵權。

接著，地方法院又推翻版權侵權的判決，認為Google僅是使用Java的API，因而沒有侵權。Oracle自然對此不服，於是，繼續向聯邦巡迴上訴法院，提起上訴。

API開發者有著作權嗎？法院、廠商端的認定上，均有爭議

而在2014年，聯邦巡迴上訴法院判決：認定API有版權。之後，Google申請舉行上訴聽證會，而到了今年，此聽證會的申請會被拒絕。

結果，兩造現在必須重新回到舊金山地方法院，審理賠償的事宜。

這纏訟的過程，果然是高低起伏。一度法院認定API不具著作權，致使Google逃過一劫；沒想到，該公司高興沒太久，又被判定API具有著作權，看起來，Google最後可能真的免不了賠償收場。

當然，此案的核心關鍵在於，API的設計結果，是否具有著作權。

因為，在此案中，Google被指控侵犯了37個Java的API packages，以及其中七千多行的程式宣告。

但Google主張API只是概念而非表達的方式，而且API的文字很短，因此，不應該被視為有著作權保護的產物。

如果我們從程式設計行業的角度，來看API是否具備著作權的爭議事件，我們又將會得出什麼樣的結果呢？

從設計API的過程，來探討是否有著作權，答案是？

從我的觀點來看，API本身就是一種表述的方式。對程式設計而言，API的設計根本可以視為是一個專門的設計工作了。在我們實際寫下真正的程式碼之前，我們可能會先設計出API。

在之前，我曾寫過一篇名為〈開發應用，API先行〉的文章，其主旨即在談現行開發軟體應用，可以試著先將應用中的核心部份，抽離出來成為API，即使這些API只在此應用中使用，而無供第三方使用之可能，也能藉此將核心與外殼分離，因而在外殼（例如前端的視覺呈現）變更時，仍可維持核心API之不變，由此可見API設計之重要性。

而在現今，API的設計者，甚至是一個專門的角色了。

在一個開發團隊裡，可能就是會有一些人，他們專門職司於API的設計，在API設計完成後，再由其他的程式設計者接手，完成程式碼的撰寫。

在這種分工底下，我們可以說，API是一種高階的設計，而相對而言，程式碼的具體撰寫及實作，則是較於低階的設計。

在那個UML還流行的年代（沒想到，現在已經是一個UML不流行的年代），我們在完成API的設計後，即可據以完成類別圖、循序圖，透過類別圖中的類別及函式設計，以及循序圖中各類別間如何透過叫用彼此的函式，即可描繪實現所有使用者案例的高階樣貌，所剩餘的工作，不過是實作每個函式的細節內容罷了。

因此，API的表述方式，絕對是程式設計中相當重要的一環，其重要性絕不在程式碼的實際撰寫之下，甚至影響更為深遠。

也因此，若是你要在你的團隊中挑選一位成員，來擔任API的設計工作，你肯定會挑一個設計能力較為卓越的成員來擔任。

很容易可以想像，我們把API設計的產出，視為某種智慧的結晶，而且也將它視為軟體設計工作中重要的產出。

API設計的良窳與否，將會對基於此API的開發者而言，產生很大的影響。

一套設計良好的API，可以幫助應用程式在撰寫程式碼時更輕易的表達、寫出可讀性更高的程式碼，不僅可以提高開發的生產力，同時也能避免程式設計者犯錯，或是寫出難以除錯的程式碼。

相反的，設計不良的API，就有機會帶來對應的負面特質。這無關API的程式碼是如何實作，純粹與API的介面是如何設計安排有關。而在這場訴訟裡，兩造所爭執的，正是介面設計本身是否應具備著作權。

上述的說明，正是我想API本身應當被視為著作的原因。如果著作權保護及於程式碼，那麼其實沒有道理不及於API的設計才是，因為API設計需要高度的技巧，對之後應用程式的開發，也會發揮深遠的影響。所以，這一場訴訟，將會是日後API設計著作權觀念的重要里程碑。