Másfél éve indított az Oracle a Google ellen egy pert, a keresetben felsorakoztattak szabadalmakat, illetve szerzői jogra is hivatkoztak, amelyeket a Google megsértett az Android kapcsán. A per főbb állomásai:
- 2010 január – az Oracle felvásárolja a Sun egészét, ezzel Java szabadalmakat és szerzői jogokat szerez
- 2010 augusztus – az Oracle beadja a Google ellen a keresetét hét szabadalom és a szerzői jogok megsértése kapcsán
- 2011 február – a Google az amerikai szabadalmi hivatalnál kezdeményezi az Oracle szabadalmak felülvizsgálatát, így a hét szabadalomból kettő marad per tárgya
- 2011 július – a bíróság szerint az Oracle 1,4-6,1 milliárd dollár közötti becsült kár nincs alátámasztva
- 2011 szeptember – a két Larry (Page és Ellison) nem tud megegyezni peren kívül
A mai napon az esküdtszék döntött a szerzői jogi kérdések egy részében, a döntés eredményeképp:
- a Google megsértette a perben szereplő 37 csomag Java API felhasználásával az Oracle szerzői jogait (Google has infringed the overall structure, sequence and organization)
- a Google nem sértett szerzői jogot a 37 Java API csomag dokumentációját tekintve
- a Google megsértette az Oracle szerzői jogait a perben szereplő rangeCheck metódussal (lásd lentebb)
- a Sun és/vagy az Oracle abban a tudatban tartott a Google vezetőit, hogy a Java API használatához nem szükséges licenc, viszont a Google nem győződött meg erről megfelelően (Has Google proven that it in fact reasonably relied on such conduct ...?)

private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) { if (fromIndex > toIndex) throw new IllegalArgumentException("fromIndex(" + fromIndex + ") > toIndex(" + toIndex+")"); if (fromIndex < 0) throw new ArrayIndexOutOfBoundsException(fromIndex); if (toIndex > arrayLen) throw new ArrayIndexOutOfBoundsException(toIndex); }
Az említett döntések érdekesek lehetnek annak fényében, hogy az Európai Bíróság a múlt héten az amerikai bírósággal ellentétes döntést hozott:
mivel [azon] szerzői jogi alapelvnek az értelmében, [mely szerint a számítógépi programnak csak a kifejezési formája részesül védelemben], ezek az ötletek és elvek, amennyiben a logika, az algoritmusok és a programnyelv alapjául szolgálnak, ezen irányelv értelmében nem állnak védelem alatt;
Hová vezet az út?
A Java egyik nagy előnye pont a nyíltság, az, hogy az API-ra építve bárki képes implementációt építeni. A jelen döntés azért lehet érdekes, mert ettől a ponttól kezdve kérdéses, hogy például a JSR-286 API-ra építve van-e lehetősége bárkinek portált implementálnia, vagy ehhez először a licenceléssel és szerzői jogokkal kell törődnie. Ezzel a bírósági döntéssel az Oracle jól is tud járni, illetve akár el is veszítheti a Java API feletti ellenőrzését, emlékezzünk a Microsoft és a Sun közötti csörtére, amely eredményeképp a Java alapjain létrejött a C# és a .NET. Az Oracle már "fényesen" bizonyította, hogy nem igazán tudja kezelni a közösségeket, több olyan szoftvert vesztettek el, amely értékes lett volna:
- OpenSSO, amely helyett a OpenAM használható
- OpenSolaris, amely helyett az Illumos létezik
- OpenOffice, amely helyett viharos gyorsasággal a LibreOffice terjedt el
- Hudson, amely egy átnevezéssel Jenkins lett
És a sort lehetne folytatni apróbb dolgokkal, ha a Java API egésze szerzői jog által védett lesz, annak messzemenő következményei lesznek a Java világát tekintve, a Java platformra építkező cégek (IBM, Red Hat, Apache Software Foundation és sok egyéb kisebb-nagyobb cég vagy alapítvány) könnyen arra a döntésre tud jutni, hogy az Oracle kihagyható a Java platformot érintő döntésekből és más néven, más logóval készítenek egy új ágat, amely mögé hamar be tud tagozódni a világ, az Oracle pedig úgy járhat, mint ahogy a fentebb felsorolt technológiákkal járt: a kezében maradt az immár értéktelen trademark.
Ha az Oracle az API nyíltságát feszegeti, akkor nem a Google az ellenség, hanem bárki, aki a publikus JSR specifikációk és a referencia implementációk alapján saját megoldást fejlesztene, és ez könnyen a Java – mint trademark – halála lehet, mivel pillanatok alatt készíthető egy fork és a nagyobb iparági szereplők már néhányszor kiálltak az Oracle viselkedése okán egy-egy technológia mögött (lásd a felsorolást).
6 Comments
Anonymous
ForgeAM helyett nem OpenAM ?
Auth Gábor AUTHOR
Ööö... izé... de igen... a cég ForgeRock, a cucc pedig az OpenAM... javítottam.
Anonymous
"a Google megsértette az Oracle szerzÅi jogait a perben szereplÅ rangeCheck metódussal"
ezt hogy kell erteni? nem olyan sokfelekeppen lehet egy ilyen fuggvenyt megirni... ha en veletlenul nagyon hasonlo modon implementaltam a sajat uzleti alkalmazasomban, akkor en is bajba kerulhetek? ha mondjuk mas lenne a parameterek sorrendje, az elegendo lenne ahhoz hogy ne legyen jogsertes?
Auth Gábor AUTHOR
Ennyit írtak a cikk elején hivatkozott doksiban, nyilván egy Base64 enkódolást/dekódolást se lehet túlságosan sokféleképpen elvégezni, ha valaki szerzői joggal véd egy Base64 modult, akkor a fél világot perelheti utána...
Anonymous
amugy nekem az a velemenyem, hogy az a baj, hogy az informatikaban az algoritmusok szerzoi jogvedesevel penzt lehet keresni. eppen ezert ezt eltorolnem. szerzoi jogvedett algoritmus felhasznalasakor kotelezo lenne feltuntetni, hogy ki volt az eredeti szerzo - nev, email cim, meg amit a szerzo megadott - de ennyi. igy talan felgyorsulnanak a fejlesztesek is, hiszen minden szabadon felhasznalhato lenne.
azzal termeszetesen egyetertek, hogy a kesz termekekert lehessen penzt kerni.
persze ez is tobb sebbol verzik:
Auth Gábor AUTHOR
Az algoritmust lehessen védeni, de tegyék mellé a kifejlesztéséhez szükséges erőforrást és azzal arányos védelme legyen. Tehát egy MPEG4 és egy Base64 algoritmus ne kaphasson azonos ideig védettséget, mert nyilván más a kifejlesztéséhez szükséges idő, pedig mindkettő csak egy codec. Szerintem a fő probléma ott van, hogy nem jelenik meg az arányosság és a tisztesség elve a szerzői jognál és a szabadalmi védelmeknél.