Oracle vs. Google: az Oracle Java API-jai nem copyrightolhatók

Címkék

Újabb vereségek az Oracle oldalán a Google ellen indított Java/Android perben. Azután, hogy a múlt héten az esküdtek úgy döntöttek, hogy a Google nem sértett Oracle szabadalmakat, az Oracle arra kérte az ügyben eljáró bírót, hogy az hatálytalanítsa az esküdtek döntését és hozza meg a döntést maga. Az Oracle az ún. "Judgment as a matter of law" indítvánnyal a döntést a bíró kezébe helyezte volna. William Alsup bíró szerdán elutasította az Oracle kérését.
Ha ez nem lenne elég, Alsup - a Groklaw-os Pamela Jones szerint - úgy döntött, hogy az Oracle Java API-jai nem copyrightolhatók.

Therefore, Oracle’s claim based on Google’s copying of the 37 API packages, including their structure, sequence and organization is DISMISSED

PJ szerint ez azt jelenti - az ő olvasatában legalábbis -, hogy nem lesz újabb tárgyalás a copyrightolhatóság témában. Az Oracle számára a bukta elkönyvelése mellett egyetlen opció a fellebbezés, de PJ szerint hülyék lennének, ha ezt az utat választanák.

Részletek a Groklaw oldalán.

Hozzászólások

nagyon nagyon jó hír!

Ezek szerint USA-ban nagyon fontos kérdésekben ugyanaz a szerzői jogi álláspont, mint Európában, és API-k alternatív implementációi szabadon elkészíthetőek.

nagyon nagyon jó hír.

Állítólag az a nagyon nagy mák, hogy Alsup nem hülye a témához és valamennyire ért hozzá:

However more important is the fact that Judge Alsup. who has a mathematics degree, really does understands the technical issues at the heart of this case. He has written code and over the period of his involvement of this case has extended his knowledge of programming languages to include Java.

--
trey @ gépház

A google nem egy java-kompatibilis vm-et csinált, hanem egy ahhoz hasonló megoldást, aminek a tisztaságát vonták kétségbe. A vm-hez a java nyelvet és alap API-jait használta fel, utóbbi miatt ismét csak összevonták a szemöldöküket a porszívóügynökék.
Ezzel szemben a ms egy saját java implementációt készített, ami vállaltan inkompatibilis volt, és problémás piacszerzési taktikai szerepe volt, ami miatt a bíróság elmeszelte őket, és kényszerültek egy alternatív megoldásra.

Ennek akkor hogy látjátok, milyen következménye lesz a java ecosystemre nézve:
- az Oracle újabb jogászi trükköket fog kieszelni a pénze behajtására
- vagy adaptálja az eredeti ötletet, és pénzt tesz a java ecosystembe annak érdekében, hogy megelőzze az MS (és a .NET ecosystem) terjeszkedését
- vagy ugyanaz lesz a sorsa a javának, mint a Sun-nál, hogy ki sem engedik a kezükből, de menedzsment fókusz sem kerül rá és a java ismét mostohagyerek lesz
- vagy az lesz a sorsa mint az openoffice-nak, hogy az oracle elzárja a pénzcsapot vagy megváltoztatja a liszencelést, erre valaki más folytatja az implementációt egy független vonalon és széthullik a java ecosystem, míg végül az oracle bedobja a közösbe a javát ami ezek után nem fog kelleni senkinek
- vagy az egész per csak egy médiahack volt, gyakorlatilag kimondatták a bírósággal és jó nagy ingyensajtóval hogy nem kell félni a javától (helyesebben az oracle-től), ami jóval nagyobb erővel bír, mintha csak úgy simán az oracle sajtósa mondta volna ugyenezt?
.... vagy?

Szia!

Igazából készíthettem volna, de a célom nem az, hogy bármit helyettesítsek a monoval.
Időnként építek beágyazott rendszereket, és szeretek hozzá egy csinos kis webes felületet adni (a designhoz nem értek, azt rendszerint más csinálja). A tesztem mindössze arra irányult, hogy ezt a felületet elkészíthetem-e mono+MVC3-mal, vagy továbbra is a hagyományos partizántechnológiáimat kell használnom (el sem mondom, hogy mit :-)).
A teszt pozitív eredménnyel zárult: konfig felületnek tökéletesen megfelel :-)

Fuszenecker_Róbert

Az ironikus felmosoly az ugye csak lefelejtodott? Vagy ez ilyen demoprojekt volt? Vannak ketelyeim, hogy egy eles oldalt is el tudna-e vinni, mittudomen, egy Sense.Net-et. Mert kb. akkor lesz neki valami haszna is.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nem felejtettem le a mosolyt, pontosan azt írtam, amit akartam. Elég nagy vagyok már ahhoz, hogy meg tudjam ítélni, mit szeretnék írni.

Ez tényleg egy demó projekt volt. Nem tudom megítélni, hogy egy nagy látogatottságú oldalt vajon elvinne-e gond nélkül. Valószínűleg ezt nem is próbálnám ki.

Pusztán arra voltam kíváncsi, ha pl. egy beágyazott rendszerhez kellene webes felületet készítenem, akkor a jól bejáratott megoldásom (MVC3) használható lenne-e. Jelenleg úgy látom, hogy ennek nincsen akadálya. Elképzelhető, hogy kell némi kompromisszumot kötnöm, ha élesben akarom használni (nincs pl. EF), de ha ezt az elején tudom, akkor tudok ezzel méretezni.

Fuszenecker_Róbert

Azert en embedded rendszerre valszinuleg nem monot raknek, pont a teljesitmenyigeny miatt.

Egyebkent meg nem csak a teljesitmeny szamit, hanem pl. amint emlitetted, az EF, meg egyeb mas technologiak is, amiknek nincs Mono-s alternativajuk. Persze lehet workaroundolni, meg sajat fw-t irni, de akkor kb. ott vagy, mintha Javaznal.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

"pont a teljesitmenyigeny miatt."
Ezt egy android/dalvik topikban :)

http://hup.hu/cikkek/20120505/xobotos_de_icaza_es_csapata_portolta_az_a…
http://blog.xamarin.com/2012/05/01/android-in-c-sharp/

Igaz, hogy csak egy raklap eroforras hatekonyabb megoldas van webet kiszolgalni,
Es az is igaz, hogy a manapsag "fileres" vas is siman kiszolgalja az egy darab admint, a leglassabb megoldassal 10x :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egy fontos mondat a vegzesbol: "Functional elements essential for interoperability are not copyrightable"

Szerintem meg az Oracle sorra bukja el a bevételi lehetőségeit,és radikálisan szűkülni kezdett jövője.
Egyre inkább azt látom, hogy az ilyen léptékű perek egy utolsó kétségbeesett lépésként születnek, egy adott cég/technológia/érdekcsoport védelmében.

Azt is látni vélem, hogy az ora. egy -a saját sikertermékeiben használt gondolkodással állt hozzá olyasmihez, amely egy másik cég totál más gondolkodása alapján volt működőképes, és erőlködni kezdett vele. Végül belebukott.
Sem a java, sem az openoffice nem olyan szándékkal/szemlélettel/piaci forrással/célcsoporttal készült és lett sikeres, mint amit az oracle a szögletes értékesitési gondolkodása felfog.
--

A tesólapos cikkben az a fontos momentum is benne volt, hogy ez a döntés csak erre a perre vonatkozik, nem általános érvényü. Nem véletlen, hogy a Java API-t kihangsúlyozták az itéletben.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Elnezest, nem a cikket kritizaltam, csak sokan most elkezdtek orulkodni, hogy milyen fasza, mostantol minden API vedett. Vagy minden Java API vedett. Hat nem. Gondoltam, ennek jelzesere kell egy komment is, sokan ugyanis automatikusan nem olvassak a cimeket. De ezt talan pont neked nem kell meselni :-)
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az ítéletben külön ki is hangsúlyozta a bíró, hogy csak erről az esetről van szó.

Szerintem ez azonban messze túlmutat egy egyedi ügyön:
- precedenst teremtett, és az itt leírt érvelést máskor is meg lehet próbálni alkalmazni (ha a kiinduló feltételek nagyon hasonlóak)
- mivel Európa kőkeményen és egyértelműen kiállt az API-k, és programok megfigyelése utáni szabad újraimplementálása mellett, ezért az USA igencsak maga alatt vágná a fát, ha nem ugyanebbe az irányba tolná el a jogértelmezést (szoftver fejlesztő cégek EU-ba költöznének)

Szóval bár papír szerint teljesen igazad van, a valóságban ennél sokkal kedvezőbb a helyzet.

A presedensnek komoly ereje lehet a jövőbeli ügyekben.

Például ez is szerepel az ítéletben:

"So long as the specific code used to implement a method is different,
anyone is free under the Copyright Act to write his or her own code to carry out
exactly the same function or specification of any methods used in the Java
API."

Ebben csak a "Java" szót kell aktualizálni, és máris hivatkozási alap.
IMHO az ítélet komoly hatású a jövőre nézve.

Ez - tulajdonképpen - cirkusz a Javából.