Rechter: Android schendt geen Java-copyright van Oracle

Een Amerikaanse rechter heeft geoordeeld dat Google met zijn Android-besturingssysteem geen copyright van Oracle schendt. Laatstgenoemde vond van wel, omdat Android voor veel methoden dezelfde namen gebruikt als Oracles Java.

Rechter William Alsup verwerpt daarmee Oracles claim dat er copyright rust op de structuur van de programmeertaal Java. Google gebruikt in Android weliswaar deels dezelfde naamgeving voor methoden en classes als in Java, maar heeft de implementaties van die methoden vervolgens zelf geschreven.

Google heeft van 37 van de in totaal 166 api-packages van Java de methodenamen overgenomen om Android zo veel mogelijk compatibel te houden met bestaande Java-code. De overgenomen delen vormen slechts 3 procent van alle regels code in de 37 api-packages. De overige 97 procent bestaat uit de implementaties die Google zelf heeft geschreven.

Alsup specificeerde dat zijn uitspraak enkel betrekking heeft op deze specifieke rechtszaak en de regels code die ter discussie stonden. Het moet volgens de rechter niet gezien worden als bevestiging dat de structuur van alle computertalen vrij overgenomen mag worden.

Oracle laat via een woordvoerder weten dat het zeker in beroep gaat tegen Alsups uitspraak. "Als deze uitspraak standhoudt, zou dat de bescherming van innovatie in de Verenigde Staten ondermijnen", aldus het bedrijf.

Reacties (44)

[Terracotta]

Was de uitspraak van de jury niet dat google wel de api-copyright schendt, Waardoor de rechter moest bepalen ofdat API's überhaupt wel onder copyright vallen, wat nu een dikke vette nee in het gezicht van oracle geworden is?

[CrazyJoe]

Nee, de rechter had de jury opdracht gegeven om als basis assumptie te gebruiken dat API's copyrightable waren en zij moesten bepalen of Google in dat geval inderdaad dit copyright schenden met hun implementatie.

Alsup zou zich zelf, na deze uitspraak door de jury, buigen over het punt of API's uberhaupt copyrightable zijn.

Dat heeft hij dus met deze uitspraak gedaan en zijn uitspraak is dat API's niet copyrightable zijn, dus de jury uitspraak op dit punt heeft dus geen waarde in deze zaak.

[awenmaek]

Nee

De jury
- Heeft vastgesteld dat er gekopiëerd is
- Heeft geen uitspraak kunnen maken of de kopie "fair use" was.

Nu heeft de rechter beslist dat het gedeelte niet eens copyrightable was. Dit is ook de enige mogelijke oplossing.
Had de rechter het "copyrightable" geacht, dan was er een re-trial over de zogenaamde "fair use", die de jury niet heeft kunnen oplossen.

[Verwijderd]

Uit de uitspraak

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. It does not matter that the declaration or method header lines are identical.

Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression

Dit vind ik wel een vreemde deel van de uitspraak.
Het was namelijk best mogelijk om vrijwel alle methodes en functionaliteit uit de API's in andere door Google zelf bedacht API definities ook te doen. Er is eigenlijk nooit een 'only way' in software.
Dan was de code natuurlijk niet compatibel met het java framework maar dat is optioneel en geen noodzaak.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[Antipater]

Dan was de code natuurlijk niet compatibel met het java framework maar dat is optioneel en geen noodzaak.

Dat is wel een noodzaak, juist hierom heeft google voor Java gekozen. Er is gigantisch veel code in Java geschreven dat vrij gemakkelijk hergebruikt kan worden voor Android. Realistisch gezien is dat alleen mogelijk als de veelgebruikte standaard api's geport worden. Het gaat niet om het java framework zelf, maar om de interface ervan.

[Verwijderd]

Dat is wel een noodzaak

Nee dat hergebruikt was wat Google wilde bereiken met hun gekopieerde API's. Maar Het is echter niet een noodzaak voor het maken van een software framework voor een mobieltje.
Als Google een eigen framework had gebouwd in plaat van het java framework gekopieerd dan had dat hen veel meer tijd gekost en had het veel moeilijker geweest om ontwikkelaars over te halen.

[Antipater]

Inderdaad niet noodzakelijk maar wel wenselijk. Noodzakelijk enkel in de zin dat het vereist is om tot een niveau van interoperabiliteit te komen. Maargoed, het gaat niet om waarvoor google het doet, maar of het copyrightable is. De quote in kwestie mist iets van context, hier is de volledige summary waar het duidelijk gesteld wordt:

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. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.
It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.
But the names are more than just names — they are symbols in a command structure wherein the commands take the form java.package.Class.method()

Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability.

[i-chat]

en dus kom je niet op copyright maar op ideeën en uitwerkingen, (met andere woorden: patenten), en laat nu net al eerder uitgezocht zijn, of deze geldig waren of niet..

het onomstotelijk vastgestelde feit is alsvolgt...

sun heeft grote delen van java opensource gemaakt, onder een flink vrije licentie.
dat betekend dat je delen ervan of het hele ding mag hergebruiken. ik zie niet in waarom de syntax en methode-defenities daar geen onderdeel van uitmaken.

vanaf dat moment wek je bepaalde verwachtingen die in bepaalde gevallen bindend kunnen blijken, ook nadat het eigendom is overgegeven aan een andere partij (eentje die er een stuk verwrongener ideeën op na houdt)...

[Belgar]

Volgens mij zegt de rechter het volgende:

Er is maar 1 manier om een functie te declareren. Google is vrij om een functie te bedenken die dezelfde naam heeft en dan op dezelfde manier te declareren als oracle dat doet.

De implementatie moet wel zelf geschreven zijn. Een aantal functies zijn ook logisch. "find", "sort", "print" zijn gewoon 'normaal' en het zou vreemd zijn als Google voor dit soort functies een andere naam zou moeten verzinnen.

[Reactie gewijzigd door Belgar op 24 juli 2024 15:26]

[PL JNS]

Het is niet zo heel gek dat de rechter dat gezegd heeft, hij legt namelijk de wet uit. De copyright van Java berust zich op het gebruiken van dezelfde methodenaam en uitvoering daarvan. Als dat de enige manier zou zijn om software te maken dan kan je er geen copyright op hebben. Daarnaast is Java Java door de methodenamen en de manier waarop die worden uitgevoerd. Als je een van de twee veranderd dan is het geen Java meer en dus heb je er geen copyright op.

Dat is tenminste hoe ik het begrijp.

[_Thanatos_]

Het zou ook raar zijn als ieder softwarepakket een andere benaming moet verzinnen voor iets dat iedereen herkent: "Save As".

Een menu is met een beetje fantasie ook een API, zeker als het gaat om het menu van een programmeerpakket

[Reactie gewijzigd door _Thanatos_ op 24 juli 2024 15:26]

[eejjay]

Mooi, ook weer afgerond. Blij dat de rechter het hier gewoon met Google eens is. Het zou namelijk wel een groot probleem kunnen worden op het moment dat Oracle had gewonnen.
Een groot Oracle-logo bij het opstarten van Android zit ik nu ook niet echt op te wachten.

[LollieStick]

Niet afgerond want Oracle gaat in beroep. En de uitkomst van dat beroep kan nog jaren op zich laten wachten. Dus... To be continued....

[wph]

Waar Oracle waarschijnlijk op hoopt, is dat ze bij het hoger beroep een rechter treffen die minder verstand heeft van programmeren en code dan rechter Alsup. Alhoewel natuurlijk de jury uitspraak doet, is het wel degeljk van belang dat een rechter begrijpt waar het om gaat. Het nadeel voor Google is dat als Oracle tot aan het Supreme Court gaat, de rechters daar waarschijnlijk wat conservatiever zijn en er zitten een paar behoorlijke fossielen bij van dik 70+, wat naar mijn idee wel eens nadelig kan uitpakken voor Google.

Het is te hopen dat dit gezeik eindelijk eens ophoudt, maar ja het zal nog wel jaren duren. Oracle heeft centen genoeg om tot in de lengte der dagen door te procederen en dat zal Larry Ellison dan ook zeker doen.

[Kevinp]

Daarom moet er net als bij copyright toch ook hier iets veranderen. Dergelijke technieken zijn zo vluchtig dat het geheel gewoon binnen maximaal 2 jaar afgerond moet zijn. Anders kan je namelijk absuurt hoge bedragen vragen die zelfs terecht zijn (je bent immers schuldig)

Zo'n hoger beroep moet gewoon binnen een paar maanden afgerond worden.

[awenmaek]

Waarschijnlijk, maar de rechten heeft het vrij "appeal" proof kunnen maken.

je kan enkel in beroep voor "error in law", en niet voor "facts", dus moet eerst Oracle een fout kunnen vinden van de rechter, om vervolgens nog eens te kunnen strijden met de bevindingen van de jury.

[SacreBleu]

Wat maakt dat logo nou uit? Je draait de software toch? Dat is hetzelfde zeggen dat je geen MS logo wilt zien als je Windows opstart

[bwerg]

Eerder dat je geen apple-logo wilt zien als je windows opstart. De code voor android is namelijk helemaal niet door oracle geschreven.

Hoewel ik mezelf wel afvraag hoe het precies zit met het hergebruik van code: ik heb de source-code voor android nooit bekeken maar heeft google echt alles, tot en met de "standaardklasses" als lists zelf geschreven?

[Mellow Jack]

Ik vraag me ook af hoe je het hergebruik van bepaalde code kan voorkomen. Bijv een API call naar een locatie service. Het is en blijft het versturen van een data pakket wat iets opvraagt en het lijkt me dus vrijwel onmogelijk om zoiets te schrijven zonder dat iemand ooit hetzelfde heeft geschreven. (ik ben dan alleen geen programmeur)

[Rmg]

Sowieso is copyrighten van software lastig. Het gaat om de vraag wanneer iets triviaal is en wanneer iets Creatief/innovatief is.

[BeosBeing]

Net als wij in onze taal hebben afgesproken wat we bedoelen met een appel en een peer is een API een afspraak over hoe je iets aanroept. Als jij bij de groentenboer om een peer vraagt en je krijgt een appel ben je ook niet blij. Als jij bij die groenteboer die peer in het Pools zou vragen zou hij je niet begrijpen.

Een verbod zou in principe betekenen dat je verbied om een java API-call te begrijpen, dat lijkt me een beetje onzinnig, de app die de API-call maakt moet immers ook begrijpen wat hij opvraagt, dan zou dat ook verboden zijn. In dat geval verliest JAVA zijn bestaansrecht.

[CrazyJoe]

Zover ik het begrijp heeft Google een aantal dingen zelf geschreven en voor andere onderdelen wordt geleund op Apache's Harmony project (http://en.wikipedia.org/wiki/Apache_Harmony).

[_Thanatos_]

Nou, je draait de software dus niet. Er zit geen Java in Android. Dat lijkt wel zo door de syntax van de programmeertaal, maar het framework en de runtime is geen Java, maar Dalvik.

[XanderDrake]

Alles behalve afgerond. Dit is nogal een belangrijk concept dat waarschijnlijk tot de Hoge raad zal gaan. Oracle zegt dan ook:

Oracle laat via een woordvoerder weten dat het zeker in beroep gaat tegen Alsups uitspraak. "Als deze uitspraak standhoudt, zou dat de bescherming van innovatie in de Verenigde Staten ondermijnen", aldus het bedrijf.

[David Mulder]

Ach jah, het probleem is dat Oracle niet kan begrijpen dat sun zo (al dan niet) stom was om al hun software vrij weg te geven met het risico dat bijv. google er op deze manier van door mee kon gaan. Hetzelfde met amazon die er met android tot in zekere mate van door probeert te gaan Maja, niet dat dat exact is waar deze rechtzaak om draaide, maar m'n punt is meer dat daarom Oracle's claim dat het een probleem voor innovatie zou zijn tenminste in dit geval niet echt klopt .

[Makkelijk]

Maakt in principe niet uit. Juist de naamgeving van de publieke methoden van de Java library heeft Google overgenomen. De API dus.

Het woord public in API is wel een beetje een give-away

[Bartjeh]

Er zit geen public in API Alhoewel een API wel per definitie public is.

[OddesE]

API = Application Programmers Interface

Dus een interface naar het systeem / platform / os voor de 'simpele zielen' die applicaties ervoor moeten schrijven.

Wat ik me wel afvraag:

Google heeft van 37 van de in totaal 166 api-packages van Java de methodenamen overgenomen om Android zo veel mogelijk compatibel te houden met bestaande Java-code.

Kan iemand die wel verstand van Java heeft dit voor mij vertalen? Wat wordt hier in hemelsnaam bedoeld? De methode namen van een package?

In een package zitten classes en in een class zitten methods. Er zijn dus package namen, class namen en method namen? Welke heeft Google overgenomen? De package namen van 37 packages (bijvoorbeeld 'java.util') ?

[Makkelijk]

Ze hebben de methodenamen overgenomen, er zit inderdaad geen public in API, my bet.
Maar de API van een library is wel de collectie van publieke methodes in het geval van een OO library, dus still counts.

Maar volgens mij hebben ze niet de package namen overgenomen maar juist de class en method names. Packages wil je per definitie niet kopiëren met een andere implementatie, al is het maar omdat je IDE het dan niet meer snapt. Een Java package verwijst immers naar een bepaalde directory structuur en 'java' is gewoon de JDK library, dus dat wil je echt niet in je package naam gebruiken.

Dat betekent dus dat de code hetzelfde blijft maar dat je je imports zult moeten wijzigen Dat is in principe een find en replace als Google zo slim is geweest (ongetwijfeld) om alleen 'java' te vervangen voor iets als 'android' oid.

[Reactie gewijzigd door Makkelijk op 24 juli 2024 15:26]

[Verwijderd]

Er zijn dus package namen, class namen en method namen? Welke heeft Google overgenomen?

Allemaal.
En ook parameternamen en volgordes en propertynamen en ook de resultwaardes van methodes

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[servies]

In theorie is het niet afgerond, daar heb je gelijk in.
Praktisch gezien wel. Alsup heeft blijkbaar zo goed z'n best gedaan op z'n uitspraak over dit punt dat er geen speld tussen te krijgen is en dat een appeal waarschijnlijk geen kans maakt...
Voor een uitleg van de uitspraak kun je terecht op Groklaw

[jpfx]

Andersom is het gebruiken van dezelfde benaming niet veel anders dan het gebruiken van verwijzingen naar hoofdstukken met een paragraaf indeling.

Een aanroep is in dat opzicht niet veel anders als: zie hoofdstuk 12, paragraaf 25.

En op hoofdstukken en paragrafen zit gelukkig ook geen copyright.

[Verwijderd]

Andersom is het gebruiken van dezelfde benaming niet veel anders dan het gebruiken van verwijzingen naar hoofdstukken met een paragraaf indeling

Tja maar al ik een API definieer:
StoreTweakerElement(TweakerElement, result) en de layout van het TweakerElement is een zelf gedefinieerd object type en alle mogelijk resultswaardes zijn in een resulttype gedefinieerd is al veel van de werking van de API vastgelegd in die definitie.

Je kunt dezelfde data misschien ook wel opslaan maar in een compleet andere API, met andere types en andere concepten daarachter. Het is bepaald niet evident dat iemand een identiek zelfde API zou gebruiken. Door 37 libraries met API definites 1-op-1 te kopieren kopieren je in essentie het complete framework ontwerp van een framework bouwer.

[humbug]

Als je dan zo nodig met een boek vergelijking komt moet je het wel goed doen.
Het is meer Hoofdstuk 12 Het Lichaam, paragraaf 25: De hiel.

Natuurlijk zit er geen copyright op het gebruik van hoofdstukken en paragrafen, maar als je elk hoofdstuk en elke paragraaf hetzelfde noemt als dat in een ander boek het geval is kan dat best wel eens een schending van het copyright zijn.

Terug naar java. Er is geen programmeur die een api met functies als 12.25(String var1,int var2, Object2352 var3) gaat gebruiken. Naamgeving is dus belangrijk en wel degelijk een ontwerp keuze. Dat Google deze APIs zo maar heeft gekopieerd kan best legaal zijn, het getuigd in ieder geval niet van originaliteit.

[coolmos]

Deze uitspraak was te verwachten, gezien het feit dat er in Europa al een uitspraak was dat API's niet onder copyright vallen.

Google heeft wel ontzettend gemazzeld met deze rechter (William Haskell Alsup).
Hij had al programmeerervaring, en heeft zich voor deze zaak bijzonder goed verdiept in java.

De uitspraak is een feest om te lezen. Oracle wordt prachtig op z'n nummer gezet, zoals in de zaak zelf ook al gebeurde.

[Verwijderd]

Deze uitspraak was te verwachten, gezien het feit dat er in Europa al een uitspraak was dat API's niet onder copyright vallen

Aangezien de wetten op dat gebied flink verschillen tussen de EU en de VS is dat niet een erg logische conclusie.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[_Thanatos_]

Als het een simpele kwestie van wetten was, was er geen jury nodig, en zou hoger beroep zinloos zijn. Het probleem is juist dat het maar de vraag is (was) of API's onder copyright vallen, en er is niets op tegen dat een US rechter kijkt hoe een EU rechter het gedaan heeft. Dat heeft nml weer niets met wetten te maken, maar met werkwijze van een rechter.

[awenmaek]

Klopt niet volledig. Dit is een "jury trial" geworden omdat Oracle erachter vroeg. Hun bedoeling was dat ze de jury met technisch onbekwame mensen zouden kunnen overtuigen.
De rechter heeft dit toegestaan, maar het maakt wel dat deze zaak beter "appeal proof" is geworden.
Oracle heeft gegokt, en verloren

[_Thanatos_]

Klinkt wel als de US. Zelfs als een kwestie voor een rechter zo klaar als een klontje is, dan de aanklager nog steeds een jury erbij halen

[Makkelijk]

Op een meer programmeertechnisch vlak kunnen we nu dus zeggen dat OO zo in ons beeld van software is vast komen te zitten dat methode niveau kennelijk het niveau van software is waarin we stukjes code als een eenheid beschouwen.

In de uitspraak staat min of meer dat de uniekheid van code zit in de implementatie van methodes.

Dit is heel lang anders geweest, vroeger was deze zaak waarschijnlijk anders afgelopen doordat we modules als eenheden beschouwden en de procedures of functies in die module toch echt als onderdeel van een eenheid.

[Reactie gewijzigd door Makkelijk op 24 juli 2024 15:26]

[Verwijderd]

"Als deze uitspraak standhoudt, zou dat de bescherming van innovatie in de Verenigde Staten ondermijnen"

Hahaha ja vast, de bescherming van domme Amerikaanse patent trollen bedoel je.
Ik denk/hoop dat de rechter de houding van Oracle heeft meegenomen in het oordeel, feit is dat ze allerlei open source initiatieven overkopen, verkloten, en er geld aan proberen te verdienen.

Toen Google met Android begon, was java nog van Sun en was het juist een enorme plus om ze compatibel te houden, ik denk dat dit inderdaad een groot punt zal zijn geweest in de uiteindelijke uitspraak, leuk dat Oracle nu niet amused is, maar Sun was er juist wel heel blij mee, en is en blijft de maker van java, en daarmee (in mijn ogen iig) blijven ze altijd een vorm van recht houden, al helemaal op uitspraken gedaan in het verleden (toen het dus nog Sun was)

Goede uitspraak!

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:26]

[simplicidad]

Als deze uitspraak standhoudt, zou dat de bescherming van innovatie in de Verenigde Staten ondermijnen"

Ja want er zit veel innovatie in het benoemen van functies of namespaces. En dan dat typisch "denk aan de VS" opmerking, zijn er echt mensen die dat geloven ?

Uiteindelijk denk ik - zeker met monde van interoperabiliteit - dat het een vrij logisch iets is dat je op zijn minst een API niet kunt gaan patenteren of een copyright op kunt verkrijgen.

[Reactie gewijzigd door simplicidad op 24 juli 2024 15:26]

[Menesis]

Mooi, nu kunnen mijn Google aandelen eens gaan groeien

[mystic101]

Maar goed ook, anders was Microsoft vast op het lumineuze idee gekomen om WINE aan te klagen vanwege copyright infringement van de Windows API.