這幾天有一則消息,是關於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設計著作權觀念的重要里程碑。

作者簡介


Advertisement

更多 iThome相關內容