Skip to end of metadata
Go to start of metadata

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).

      
      
Page viewed times

6 Comments

  1. Anonymous

    ForgeAM helyett nem OpenAM ?

  2. Auth Gábor AUTHOR

    Ööö... izé... de igen... a cég ForgeRock, a cucc pedig az OpenAM... javítottam. (smile)

  3. 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?

    1. 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...

  4. 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:

    • mi szamit algoritmusnak, es mikortol szamit kesztermeknek?
    • mi szamit bele az informatika fogalmaba?
    • egy tenylegesen nagy koltsegu algoritmus kifejlesztesere vallalkozni fog-e valaki (pl 3D rendering engine)?
    • milyen szankcioval lehet kikenyszeriteni a szerzoi jog felhasznalaskor a szerzo feltunteteset?
    • mi van ha valamit tenylegesen tobben kifejlesztettek, anelkul hogy tudtak volna egymasrol?
    1. 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.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))