Tíz éve tart az Oracle és a Google pereskedése a Java API miatt. A bíróság a gigantikussá terebélyesedő perfolyamban az első döntést öt éve hozta, ami az Oracle győzelmével zárult. 2015 nyarán ugyanis a bíróság eldöntötte: az API (Application Programming Interfaces) szerzői jog által védett szellemi tulajdon. Ráadásul nem csak a kód, hanem az általa megvalósított funkció is. Így akár egy azonos funkciót megvalósító, de egyedi fejlesztésű API-val is meg lehet sérteni más szellemi tulajdonát.

Ezzel azonban még nem záródott le a jogászkodás. Az Oracle ugyanis kártérítésre tart igényt: mintegy 9 milliárd dollárra.

Az Oracle is járt hasonló cipőben

Az Ars Technica az újabb bírósági forduló kapcsán arra jutott, hogy az Oracle-nek sem lesz jó, ha győz. A relációs adatbázisa kifejlesztésekor ugyanis épp azt a gyakorlatot követte, amit a Google esetében most kifogásol. Az adatbázist ugyanis egy az IBM által kidolgozott és white paperként nyilvánosságra hozott koncepció alapján építette fel.

Az IBM kutatói a 70-es években dolgozták ki az adatbázis-szervezés relációs modelljét, amely összetett lekérdezéseket tett lehetővé az adatbázisokban. Ehhez létrehoztak egy új nyelvet is, az SQL-t (Structured Query Language), amivel a lekérdezéseket könnyen meg lehet fogalmazni. Az SQL előnye, hogy szintaxisa nagyon hasonlít a természetes nyelvre (pl. select customer_name, ship_date from orders where product_id=17 and state='CA'), másrészt deklaratív, azaz a felhasználó meghatározza, hogy milyen információkat keres, az adatbázis pedig eldönti, hogyan keressi meg azokat.

Az IBM belefogott a megvalósításba, de közben kutatói – az akkori szokásnak megfelelően – részletekbe menően publikálták az eredményeiket, köztük az SQL nyelv teljes specifikációját. A publikáció 1977-ben keltette fel Larry Ellisonék érdeklődését. A kutatók olyan részletesen ismertették a relációs modellt és az SQL specifikációját, hogy az alapján Ellisonék fel tudták építeni saját relációs adatbázisukat, az Oracle-t, amit úgy is reklámoztak, hogy teljes mértékben kompatibilis az IBM SQL szabványával. Még az SQL egyik vezető tervezőjét, Donald Chamberlint is meghívták tapasztalatcserére, illetve annak ellenőrzésére, hogy termékük valóban teljes mértékben kompatibilis-e az IBM akkor még csak prototípusként létező termékével. Ekkor Chamberlin főnökei észbe kaptak, és bizonyos információk átadását megtiltották.

De Ellisonék már eleget tudtak a továbblépéshez, így 1979-ben megjelenhetett az Oracle első verziója. Az IBM csak két évvel később készült el a saját rendszerével, így az Oracle komoly előnyre tehetett szert ezen a piacon.

És hogy jön mindez ide?

A Google 2000-es évek közepén kezdett el dolgozni a Javával – az Android fejlesztéséhez volt rá szüksége –, és 2005-ben fizetett is 28 millió dollárt a Javához kötődő szabadalmak és a védjegy használatáért a Sunnak. De mivel nem tudtak minden vitás kérdésben megállapodni, a Google úgy döntött, hogy készít egy saját Java-implementációt. A Java funkcionális specifikációja alapján lényegében újraírta a kódot, de felhasználta az eredeti szintaxikai szabályokat, meghagyta a standard függvények neveit, az argumentumtípusokat stb. Azaz ugyanazt csinálta, mint az Oracle az SQL-lel. Miután azonban Oracle 2010-ben felvásárolta a Sunt, szinte azonnal pert indított emiatt a Google ellen.

Persze van egy nagy különbség az SQL és a Java között. Előbbi csak egy koncepció volt, ami mögött akkor még nem volt termék, a Google pedig egy piacon lévő terméket másolt. A Cornell Egyetem szerzői jogi professzora, James Grimmelmann szerint azonban ez lényegtelen eltérés a szerzői jog szempontjából: egy szoftver dokumentációja alapján létrehozni valamint ugyanaz, mint egy API funkcionalitását megvalósítani újraírással. Ha egyik a szerzői jogok megsértése, akkor a másik is.

És hogy ne legyen olyan egyszerű a már amúgy is bonyolult helyzet. Azt is meg kell nézni, hogy egy programozási nyelv másolása különbözik-e az API-k másolásától.

A Java problémája

A Java két részből tevődik össze. Egyrészt van a nyelvi specifikáció, amely meghatározza az utasítások szintaxisát és jelentését. Másrészt van a Java API, amely az objektumosztályok és funkciók könyvtára – ezt együtt szállítják minden modern Java rendszerrel. Ez utóbbiban a Google követte az eredeti Javát, abból vette át a funkciók nevét, az argumentumtípusokat stb. De a fejlesztők minden funkciót nulláról újraírtak. Ennek ellenére lehetnek az Oracle (Sun) és a Google implementációjában azonosságok – figyelmeztet az Ars Technica. Vannak ugyanis olyan funkciók, amiket minden tapasztalt programozó ugyanúgy old meg. Példaként többek között a Google API-jának a java.lang.Math nevű csomagjában használt max funkciót hozzák, ami vesz két egész számot, összehasonlítja, majd a nagyobb értékűt adja vissza ("int max (int a, int b);").

Az Oracle azonban nem az ehhez hasonló azonosságokért perelt, hanem mert a Google egy az egyben használt az API-funkciók neveit és argumentumait. A Java nyelvnek a másolásába nem kötött bele. Az Oracle álláspontja szerint az API és a nyelv két különálló dolog.

Grimmelmann szerint azonban jogilag nem különíthető el a kettő. Az SQL alapvetően egy univerzális adatbázis API, ahogy a Java is. Miért kellene például levédeni egy n= "a + b" összeadást csak azért, mert mondjuk a Java API-ban ezt a funkciót "n = sum (a, b);" formában kell megvalósítani. Ha az egyiket levédhetem, akkor a másikat is.

Az API lényegében egy olyan nyelv, amivel programok kommunikálhatnak egymással, azaz az SQL és a Java API ugyanazt a funkciót tölti be. És ha az API-ban szerzői jog védi a kulcsszavakat, az argumentumtípusok, a szintaxisszabályokat stb., valószínűleg bármely programozási nyelvvel és az SQL-lel is hasonló a helyzet.

Precedens teremthet

Ha ebben a küzdelemben az Oracle-é lesz a végső győzelem, annak a következményei beláthatatlanok lesznek – véli a lap. Hol húzódik a határa az API-kra vonatkozó szerzői jogoknak? Elképzelhető, hogy a bíróságok a jövőben az API-kra vonatkozó szabályokat kiterjesztik a programozási nyelvek alapvető jellemzőire is. Félő, hogy a kérdés csak újabb évekig tartó peres eljárások után tisztázódik, addig viszont megakasztja az innovációt és az interoperabilitási törekvéseket. A legtöbb szoftvergyártó cégnek ugyanis nincsenek akkora erőforrásai, mint a Google-nek, hogy megkockáztasson egy olyan pert, mint ami a keresőóriás és az Oracle között folyik.