Mellékleteink: HUP | Gamekapocs
Keres
Felhőből visszaköltözéstől egészen egy banki malware evolúciójáig. Üzemeltetői és IT-biztonsági meetupokkal érkezünk!

Oracle-Google: nem volt jogszerű a Java API-k használata

Gálffy Csaba, 2018. március 29. 12:08

Komoly vereséget szenvedett a Google, de még mindig nincs vége a sokéves játszmának. Rekord kártérítés néz ki az Oracle-nek, az androidos fejlesztők pedig lassan elkezdhetik tanulni az alternatív keretrendszereket.

hirdetés

Elkaszálta a szövetségi fellebbviteli bíróság a Google utolsó védekezését is az Oracle által indított szerzői jogi perben és úgy ítélte meg, hogy a Google nem jogszerűen használta fel a Java API jelentős részeit az Android operációs rendszerben. A lassan hét éve folyó per ezzel a harmadik fázisába lép, a következő lépcsőben a bíróságok a Google által fizetendő kártérítés mértékét határozzák majd meg.

Fair?

Az Oracle még 2010-ben perelte be a Google-t, azzal vádolva a céget, hogy az megsértette a Javához fűződő szerzői jogait. Ezek a jogok a Sun felvásárlásával kerültek az Oracle-hez, a cég pedig vitatja, hogy a Google Android operációs rendszerének Java implementációja jogszerű lenne. A Google ugyanis készített egy, a Sunétól teljesen független saját implementációt, a kompatibilitás érdekében azonban ennek (értelemszerűen) követnie kellett a Java API struktúráját, tehát a fejlesztők által meghívható képességek neve, struktúrája azonos kellett legyen - annak ellenére, hogy az azt végrehajtó kód már egészében a Google saját fejlesztése volt.

A per innen látványos és sok szereplőt megmozgató hullámvasúttá vált, az ügy ugyanis nagyon fontos, eddig jobbára bíróságon nem vizsgált kérdést tesz fel. Például azt, hogy az API-t védi-e szerzői jog, vagy az szabadon újraimplementálható? Ez nem elvi kérdés, az API-k az informatikai rendszerek legalapvetőbb részei, létezésük rengeteget tett azért, hogy az informatika mai súlyát elnyerje. Az API-k olyan konnektorok, amelyeken keresztül más-más fejlesztőktől származó szoftverek szorosan össze tudnak kapcsolódni, például a windowsos alkalmazások a Windowshoz, a kliens appok a felhős kiszolgálóhoz, stb.

A bíróságok végül jogerősen eldöntötték, hogy az API-kat védi szerzői jog, azokat nem lehet szabadon újraimplementálni, és ez erre a speciális esetre is érvényes, a Google megsértette a Java API-khoz tartozó szerzői jogot. Egy kérdés azonban még eldöntésre várt: a jogsértés az úgynevezett "fair use" doktrína által meghatározott keretek között maradt-e, vagy átlépte azokat. A "fair use" azokat a kivételeket jelenti, amikor más szerző műve felhasználható valamilyen más mű megalkotásához - ide tartozik a kritika, a paródia, a kommentár. Így például rövid idézetek (forrásmegjelőléssel) átvehetőek egy kritizált műből jogszerűen.

Az amerikai jog mára igen részletes keretrendszert dolgozott ki arra vonatkozóan, hogy egy ilyen felhasználás mikor számít fair use-nak, és mikor lépi át a kereteket. A bíróságnak ehhez rengeteg paramétert kell mérlegelnie, például az új mű eredetiségét, az átvett tartalom arányát - a lényeg, hogy az új alkotásnak valahogyan "át kell alakítania" az eredetit. Ha valakit bővebben érdekel a téma, érdemes fellapozni például a Stanford jogi karának kisokosát. Sajnos a legfontosabb kitétel az, hogy a "fair use"-t nem szabályozza kristálytiszta törvény, minden egyes esetet egyenként dönt el a szövetségi bíróság.

A szövetségi bíróság most nyilvánosságra hozott ítélete nagyon világosan lezárja ezt a kiskaput: az API egy-az-egyben átvétele nem fair use, "semmi fair nincs abban, hogy valaki egy jogvédett művet egyben átvesz" - írja az ítélet. A Google veresége azonban nem volt biztosra vehető, korábban, alsóbb szinten az esküdtszék elfogadhatónak találta a cég védekezését és az implementációt fair use-kompatibilisnek ítélte. Ezt fordítja most jogerősen visszájára az új ítélet.

A bíróságokat egyébként a szakértők szerint a C-s fejléc (header) fájlok alaposan összezavarták. Ezek írják le az API-t, deklarálják a függvényeket és a nyelv egyéb elemeit, ezek azonossága így értelemszerű egy újraimplementáció esetében. Az Oracle ezt azonban a per során végig a forráskód durva lemásolásaként állította be - ez annyiban igaz, hogy a .h fájlok tényleg a forráskód részei, vitatható azonban, hogy valódi kreatív munkát tükröznek-e, így a mű részének tekinthetőek-e. Az egyik korábban eljáró bíró, az élő legendának számító William Alsup vette a fáradságot és alap programozási ismereteket szerzett, ennek fényében pedig úgy ítélte meg, hogy ezeket nem védi a szerzői jog - döntését azonban később a felületesebb szövetségi bíróságok felülbírálták.

Menekülés előre

És mi van akkor, ha a bíróság hivatalosan és végleg elmeszeli az androidos Java-implementációt? Ebben az esetben ugyanis nem csak egy jelentős, sok-sok milliárd dollárra tehető egyszeri kártérítést kell fizetnie (az Oracle 9 milliárdot követel), hanem a jövőre nézve licencelni is kényszerül a Javát az Oracle-től, a céget ismerve pedig ez egy jelentős, akár milliárdos nagyságrendű évi summát tenne ki. A legrosszabb forgatókönyv pedig az, ha az Oracle kerek-perec megtagadja a Java licencelését és megtiltja annak használatát a Google számára, nem feltételezzük azonban az Oracle-ről, hogy bosszúból lemondana a licencelés bevételéről.

A Google vészforgatókönyve erre az esetre már készen áll, ez Flutter, a Google következő generációs alkalmazásplatformja. Ez szakít a Javával, a keretrendszer a Google házi nyelvén, Dartban programozható, és egyébként keresztplatformos, az így készült alkalmazások iOS-en és a készülő Fuchsia operációs rendszeren is futtathatóak. A Flutter pedig nagyon aktív fejlesztést kap, február végén kapott béta státuszt, a készítők szerint pedig hamarosan megérkezhet az első stabil kiadás is.

Az Android Java-függősége a Fluttertől függetlenül is sokat lazult az elmúlt években, az olyan projektek, mint a React Native, a Xamarin, a Cordova, a PhoneGap és sok más kezdeményezés más nyelvek felé is megnyitották a platformot, meggyőző sikerrel. Az igazán erőforrásigényes, optimalizációra éhes alkalmazások pedig eddig sem a Javára, hanem az Androidon szintén a kezdetek óta támogatott C++-ra és a Native Development Kitre (NDK) támaszkodtak.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
4-4 klassz téma a HWSW júniusi üzemeltetői és IT-biztonsági meetupjain. Nézz meg a programot!