Supreme Court neemt beroep Google in ruzie met Oracle niet in behandeling

Het Hooggerechtshof van de Verenigde Staten, de US Supreme Court, wil het beroep van Google in de copyrightzaak met Oracle niet in behandeling nemen. Een jaar geleden bepaalde een Amerikaanse rechter dat Google met Android het copyright van Oracle schond.

Dat meldde Bloomberg maandag. Door het besluit blijft de uitspraak van de rechter van vrijdag 9 mei 2014 overeind, waardoor Oracle een vergoeding in rekening mag brengen voor het gebruik van sommige delen van de Java-programmeertaal in Android. Google vond op zijn beurt dat het dat niet hoefde te doen, iets waarvoor het bedrijf in 2012 in het gelijk werd gesteld, waarna Oracle weer in hoger beroep ging en dat laatste dus won in 2014.

De zaak gaat over hoeveel copyrightbescherming er geboden moet worden met betrekking tot Java. Android heeft deels dezelfde naamgeving als Java voor methoden en classes, maar heeft de implementaties zelf geschreven. In Android zijn de methodenamen van 37 van de 166 api-packages van Java overgenomen, om het besturingssysteem zoveel mogelijk compatibel te houden met de bestaande Java-code.

Google stelde dat als Oracle zou winnen er een 'enorme hoeveelheid innovatie' verloren zou gaan, omdat ontwikkelaars dan niet meer vrij op elkaars werk kunnen bouwen. Aan de andere kant vond Oracle dat copyrightbescherming juist weer van belang is bij software-innovatie.

Oracle sleepte Google in 2010 voor de rechter en eist ongeveer een miljard dollar voor de copyrightschendingen. De regering Obama was eerder al gevraagd om zijn licht te laten schijnen over de zaak en vroeg het Hooggerechtshof de zaak niet in behandeling te nemen. Het proces wordt hiermee weer verplaatst naar een federaal gerechtshof in San Francisco.

Reacties (161)

[CAPSLOCK2000]

Wat een ramp, deze zaak is veel groter dan Oracle vs Google.

Het gaat om de vraag of een API onder copyright valt. Je mag nu dus geen alternatieve implementaties meer maken zonder (te betalen voor) toestemming.

Een API is de interface waarmee programma's met elkaar praten. Een API vertelt precies welke functies een programma heeft en hoe je die moet gebruiken. Als een programmeur een nieuw stuk code schrijft dat moet samenwerken met een ander stuk code dan leest hij in de API hoe dat moet.

Als een auto een API zou hebben dan zouden daar dingen in staan als:
Stuurwiel ( X richting, Y hoek): Draai aan het stuurwiel om de voorwielen Y graden te draaien in richting X.
Ruitenwisser (aan/uit): Gebruik de knop "ruitenwisser" om de ruitenwisser aan of uit te zetten. Als de knop op "aan" staat gaat de ruitenwisser bewegen.

Als je een bestaand stuk software wil vervangen door iets nieuws dan zorg je dat de nieuwe software dezelfde API heeft als de oude software. Zo kun je onderdelen vervangen zonder dat de rest van het systeem dat merkt.

Een voorbeeld is dat je meerdere webbrowser op je computer kan installeren en met een simpel knopje kan kiezen welke browser er standaard gebruikt moet worden. Omdat alle programma's die de standaard browser willen starten dat via dezelfde API doen hoeven de programma's niet te weten welke browser jij hebt.

Je mag nu dus niet meer zomaar een stuk software maken dat als drop-in replacement voor een ander stuk software kan dienen omdat het dezelfde API gebruikt. Fabrikanten gaan daar natuurlijk niet aan meewerken om het hun concurrenten zo moeilijk mogelijk te maken, zoals Oracle hier laat zien.

De volgende vraag is of je als programmeur wel gebruik mag maken van een API zonder explicite toestemming.

[Verwijderd]

De volgende vraag is of je als programmeur wel gebruik mag maken van een API zonder explicite toestemming.

Er is een groot verschil tussen programmeurs die een API gebruiken van een aanbieder om code te schrijven en een aanbieder die API's jat van een andere aanbieder. Android ontwikkelaars valt niets te verwijten voor het gebruik van Android API's die eigenlijk gejat zijn van Oracle.

[Superstoned]

Ze hebben de api niet gejat, dat impliceert namenlijk dat Oracle de API nu niet meer heeft. Dat is nogal een verschil tussen digitaal en real world.

Het enige wat Google gedaan heeft is een compatibiliteit met een bestaande api mogelijk maken. Zoals bijvoorbeeld wine een her implementatie van de ME Windows API maakt zodat je Windows programmas op Linux of Mac kunt draaien. Daar is niets illegaals aan, je geeft een applicatie wat het verwacht - je hoeft zelfs de originele API en de documentatie daarvan nooit gezien te hebben.

Het is alsof je een schroefgat ziet en besluit een schroef te maken die past. Je kopieert niets!

[Reactie gewijzigd door Superstoned op 23 juli 2024 00:30]

[roy-t]

Het is alsof iemand tien jaar heeft nagedacht over assortiment schroeven en schroefgaten die dankzij hun ontwerp ook zonder vulling geen water toe laten en nooit vast komen te zitten en dat iemand anders daar dan een cheap knock off van maakt die wel werkt met jouw systeem maar waarmee jouw systeem niet werkt.

Is het dan nog steeds zo vanzelfsprekend, eerlijk dat dit mag?

Het design van hoe alle onderdelen van een library met elkaar interacteren is bij verre weg het moeilijkste van programmeren. Een enkele methode implementeren is makkelijk. Google heeft de complete architectuur van een hoop Java libraries gejat en heeft er tegelijkertijd voor gezorgd dat hun versie niet compatible is met die van Oracle. Hadden ze dat niet gedaan dan was er niets aan de hand volgende de licentie die Orcal gebruikt..

Dus ja Google mag hier flink voor op de vingers getikt worden. Ik snap echt niet wat ze bezielde om dit te doen.

[Superstoned]

Stel dat jij gelijk hebt, en google heeft dit gedaan om werk te besparen. Dan zou je zeggen, ja, daar is copyright wetgeving voor: iemand kopieert iets in plaats van het harde werk zelf te doen, en dat mag niet. Helemaal mee eens.

Maar heeft Google dit om die reden gedaan?

Als dat de reden was geweest, waarom hebben ze de API dan exact overgenomen? Je zou zeggen - die API bestond al jaren, voortschrijdent inzicht enzo - ze hadden hem zeker aangepast en verbeterd! Leer mij een engineer kennen - als management had gezegd 'maak een goede JAVA API voor Android' dan zouden ze zeker naar de Oracle API gekeken hebben, maar 0,0% kans dat ze precies de API van Oracle over zouden nemen! Er is altijd wel iets te verbeteren, al is het maar om reden van smaak of verschil van mening.

En als ze de API hadden verbeterd had Oracle echt geen zaak gehad - er was tenslotte geen kopie gemaakt, dus Google is niet schuldig. (Grappig, he? Als Google iets 'slechts' had gedaan, dat is, werk bespaard door naar de concurrent te kijken, waren ze niet schuldig geweest. Natuurlijk doet iedereen dit in IT, en zo hoort het ook, en dit geeft ook gelijk aan dat er iets mis is met traditioneel copyright, patenten etcetera in de IT business).

Het is duidelijk dat hier een ander scenario speelt: ze hebben het niet gedaan om werk te besparen, maar om interoperabel te zijn. Dat KAN niet onder copyright vallen, daar is copyright gewoon niet voor. Als ik de afstand tussen twee boutjes in een machiene door middel van copyright kon beschermen tegen andere bedrijven die een vervangend onderdeel willen maken was het hek van de dam. Dat zou enorme economische schade veroorzaken en onze maatschappij echt op zijn kop zetten - we hebben al advocaten zat, dankuwel.

Kortom, Google kan niet schuldig zijn aan het breken van copyright. Als ze dit gedaan hadden om werk te besparen hadden ze het niet gekopieert!

Hoe moeilijk het bouwen van de API ook is (en ik spreek dat heus niet tegen) - je KUNT dat niet copyrightable maken want dat heeft echt idiote gevolgen, en dus MOET Google dit winnen.

[roy-t]

Als Google graag compatibility wilde met Java, en dat hun doel was, dan hadden ze zich aan de license van deze packages gehouden. Op dit moment is Google's Java implementatie in Android juist niet compatible. Je kunt niet iets wat je voor android heb gemaakt op een gewone JVM draaien. Dat is een van de grote problemen in deze rechtzaak.

Het is ook zo dat dit niet technisch mogelijk was. Lang voordat er Android was waren er al telefoons die java ondersteunden. Zoals bijvoorbeeld de Siemens SL45 uit 2001! https://en.wikipedia.org/wiki/Siemens_SL45

Compatibility was dus niet het argument van Google om deze APIs kopieren. De API is toch exact het zelfde. Dan kan ik toch echt alleen maar concluderen dat het gedaan is om tijd en geld te besparen.

Nu worden er ook software patenten bij gehaald. Software pantenten zijn vaak er slecht. Bijvoorbeeld een pantent op' de metafoor van een winkelwagentje in webshops'. Een super vaag idee uit de echte wereld waar een patent op zit in de software wereld. Stom!

Een patent/copyright op een API is heel iets anders. Het is een bescherming van de woord-voor-woord letterlijke kopie. Ik vind het heel erg gewoon dat daar bescherming voor is.

Laten we het trekken naar boeken: een software patent is als zeggen 'je mag geen boeken schrijven over tovenaars met een blauwe punt muts'. Copyright op de API is als zeggen: je mag niet alle namen van alle hoofdpersonen uit Harry Potter overnemen in een boek over een Britse tovernaarsleerling. Deze bescherming verbied niemand om een boek te schrijven over een Britse tovenaarsleerling.

[Superstoned]

De licentie van Java is alleen relevant als je iets van de code gebruikt (copyright) en die is NIET gekopieert - dus die licentie is niet van belang.

Ze wilden duidelijk niet het complete Java platform ondersteunen, maar een deel ervan, en dat is best. Als ik een onderdeel van een wasmachiene na wil maken kun jij mij niet dwingen een hele wasmachiene te maken...

Je zou Android code best in een Java VM kunnen draaien als daar aanpassingen in werden gemaakt om de Android API's te ondersteunen - en dat zou totaal legaal zijn.

Serieus, als jij echt gelooft dat een team programmeurs de API exact heeft overgenomen omdat ze niets beters konden verzinnen moet je toch eens diep in jezelf kijken of met een programmeur praten. Dat is zo ongelofelijk onwaarschijnlijk dat het onzin is om het te beweren. Tijdsdruk zou hoogstens een extra reden zijn niet compattible te zijn want dat kost eerder meer dan minder moeite. Je zou bijvoorbeeld heel veel dingen overslaan, niet precies 37 van de 166 api packages implementeren maar stukjes 'all over'.

Het is gewoon onmogelijk dat dit gedaan is om tijd te besparen.

[roy-t]

...... ik ben zelf programmeur

En ja ik geloof heel erg goed dat programmeurs heel vaak geen tijd hebben om iets beters te verzinnen. Exact overnemen scheelt ontzettend veel tijd.

We snappen elkaar blijkbaar totaal niet? Ik snap echt niet hoe je het onwaarschijnlijk vindt dat iemand tijd wil besparen door niet het wiel opnieuw uit te vinden maar een bestaan idee exact te kopieren.

Je kunt ook niet makkelijk 1 dingetje veranderen. Stel je wilt graag net op een iets andere manier met streams werken. Dan moet je ook de API van alle libraries die iets met streams aanpassen.

Je stukjes all over argument snap ik ook niet. Ze hebben toch slechts een subset van alle libraries geimplementeerd. Precies wat ze nodig hebben, om tijd te besparen. Toch?

[Superstoned]

90% van het werk zit uiteindelijk toch in het implementeren van de functionaliteit, niet in het design van de API. En als je bezig bent met de implementatie, zeker als je wat ervaring hebt met de API (zelf Java programmeur bent of bent geweest) kan ik me niet voorstellen dat er niet ergens in al die functionaliteit iets zit wat je anders zou doen. Misschien hebben alle programmeurs om mij heen toevallig erg sterke meningen of grote ego's maar - ik vind het echt moeilijk voor te stellen.

En wat de subset betreft - ik kan me voorstellen dat je een subset van functies doet, alleen wat je nodig acht. Maar precies alle functies van een subset van de libraries, dat vind ik dan weer helemaal niet wijzen op 'we wilden tijd besparen' maar meer op 'we wilden compattible zijn'.

Wederom - stel je voor, je wilt het makkelijk maken om te migreren. Dan zeg je: deze 37 libraries hebben we volledig API compattible gemaakt. Niet: "sommige functies zijn er wel, andere niet". Dat laatste zou de uitkomst zijn als je het zo snel en simpel mogelijk zou doen.

Nogmaals - mijn argument is: als Android/Google de API had overgenomen om tijd en kosten te besparen dan kan ik me gewoon niet voorstellen dat dit de uitkomst zou zijn: 37 libraries precies zo geimplementeerd. Dan zou het zijn dat een subset van functionaliteit in een subset van libraries geimplementeerd is, met regelmatige afwijkingen en verbeteringen.

Deze uitkomst lijkt veel meer op "laten we het platform compattible maken".

En dat kun je niet illegaal maken, zoals ik al aangaf - dan is het hek van de dam.

[roy-t]

Ik vrees dat we het oneens blijven over wat het meeste werk is. Ik zou toch echt zeggen dat 75% architectuur is en hoe alles in elkaar hangt en 25% gewoon code kloppen om functies te implementeren. Maar het lijkt er op dat we een radicaal andere mening hierover hebben en het punt 'mag er copyright opzitten' hangt toch een beetje af van de moeite die ergens voor nodig is (of het triviaal is of niet).

En ja tuurlijk zou ik veel willen aanpassen aan Java, maar dan zou ik die veranderingen moeten ontwerpen, ik zou nieuwe documentatie moeten schrijven, de hele tutorial, cursus en vraag & antwoord molen zou ik een zetje moeten geven, etc... Dat kost ontzettend veel geld en tijd.

[coolmos]

Je snapt 't inderdaad niet.

De rechter die dit in eerste instantie toeliet was zelf programmeur. Hij snapte precies waarom dit niet verboden zou moeten worden.

Het enige dat Google heeft gedaan was alle functies van Java zelf herschrijven, en ze vervolgens hetzelfde noemen. En jij zegt dat de naamgeving het moeilijkste is aan programmeren?

[roy-t]

Nee ik zeg dat de naamgeving niet het moeilijkste is. Ik zeg dat de API deels de architectuur dicteert. Het geeft immers aan hoe verschillende onderdelen samen werken en wat er verwacht wordt van een functie. Het is een soort van raamwerk waar aan alles opgehangen is.

Ik vind dat dit een niet triviaal iets is.

[Superstoned]

Ik zal ook niet zeggen dat het triviaal is, maar meer dan 2% van het werk is het niet. Hou er hier ook rekening mee dat het gaat om de 37 meest basic libraries, het equivalent van wat andere talen ook in hun standaard bibliotheken hebben. Als Google niet van Java had afgekeken hadden ze in 100 andere plaatsen kunnen kijken - nogmaals, dit is gedaan wegens interoparabiliteit, niet om werk te besparen. En dus is het geen copyright zaak.

[roy-t]

Tsja,

Ik zou zeggen dat ik in het dagelijks leven meer bezig ben met de API ontwerpen van een programma dan al die simpele functies implementeren. Maar zoals aan de reacties op dit nieuwsbericht te zien zijn daar erg verschillende meningen over.

[Zezura]

Hoe jij het stelt is compleet fout.

Een API is heel iets anders.
Het is bijvoorbeeld een kabel in de echte wereld.
En het wordt dus verboden om een kabel te maken.

[roy-t]

@Zezura,

Ik weet jouw achtergrond niet, maar als programmeur weet ik toch vrij zeker dat ik weet wat een API is. Een API zijn alle ingangen naar een library. Indirect dicteert de API de structuur van de library en deze vloeit voort uit de ontworpen architectuur.

Het is absoluut niet zoiets simpels of vanzelfspreken als een kabel in de echte wereld.

[Reactie gewijzigd door roy-t op 23 juli 2024 00:30]

[Zezura]

Ik ben ook programmeur, hallo fellow industriegenoot.

Een api is een interface inderdaad, het zou niet copyrighted moeten kunnen worden.. Dat betekend dat zoiets als fprint of fopen in C niet meer gebruikt zou mogen worden in andere libs / talen.

En dat is toch gewoon waanzin.

[roy-t]

Het zou niet copyrighted moeten kunnen worden is natuurlijk een mening.

Fopen niet kunnen gebruiken snap ik niet. Dat is iets anders dan zelf een library maken met alle FOpen achtige functies die exact het zeflde doen en exact dezelfde documentatie hebben.

[Zezura]

Klopt dat is een mening..

[fraggie]

Ik kan mij toch herinneren dat ik vroegah van een windows cd bestanden naar de wine dir moest kopieren om het geheel werkend te krijgen (directx?)

[Superstoned]

Off-topic, maar:
Sommige bestanden waren nog niet of nog niet helemaal geschreven. Die moest je kopieren en dan kon je per DLL aangeven of de 'wine' versie gebruikt moest worden, of de Microsoft versie.

Als je de originele CD had kun je beweren dat je het recht had dit te doen - of niet, nogal een grijs gebied. Tegenwoordig zijn de meeste DLL's wel af en is dit niet echt meer nodig. Of je kunt de 1 of 2 DLL's die je nodig hebt wel ergens downloaden (kun je je weer afvragen of het legaal is...)

[Sissors]

Aan de andere kant kan je je afvragen of je een API kan jatten. Hoewel ik wel tot op zekere hoogte me erin kan vinden dat een API ook binnen intellectual property valt, lijkt me een verbod om een compatible API Te maken me vooral lijken leiden naar vendor lock-in.

[Verwijderd]

Je bent gewoon vrij om een eigen API te maken te precies hetzelfde kan. Alleen niet met letterlijk precies dezelfde functienamen en parameters.
Dat had Google best kunnen doen maar dan hadden ze in Android niet meteen kunnen profiteren van bestaande tools en software libraries voor Java.
Het letterlijk kopiëren van de Java API definities bespaarde Google honderden miljoenen doordat er gigantisch veel Java code hergebruikt kon worden in Android en android apps en scheelde ook heel veel tijd in het creëren van de vulling van de apps store.
Anders had Android misschien een jaar extra vertraging opgelopen tov iOS

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[Zezura]

Dit is dus eerder een doodsteek voor Oracle.

Web applets wordt niet meer gemaakt.

Mensen willen Java steeds minder geïnstalleerd hebben.

En hier wordt je niet populair van als bedrijf. Ik als programmeur wil niks meer te maken hebben met Oracle en Java. Wil niet zeggen dat ik helemaal geen Java meer programmeer alleen, niet als ik andere oplossing kan gebruiken.

[Verwijderd]

Android heeft al jaren geleden java ondermijnd door een groot deel van de Java ontwikkelaars weg te trekken. Java ME voor mobiele apparaten is toen al effectief vermoord door Google's hybride java/android framework.
Gebrek aan licentie inkomsten voor Java droeg bij aan de ondergang van Sun.

[Verwijderd]

Grappig als je ziet dat Android slechts enkele maanden bestond op het moment dat Sun werd overgenomen door Oracle. Waar je het dan vandaan haalt dat Sun last heeft gehad van Android .

[littlewolvie]

Ik denk dat Oracle ook gerust zonder Java nog een tijdje door zou kunnen, hoor. Over die doodsteek hoeven ze zich volgens mij nog niet zo meteen zorgen te maken.

Verder is het allemaal vrij subjectief. Ik als database ontwikkelaar (de ene programmeur is duidelijk de andere niet) en integrator verkies bij voorkeur Oracle als ik de keuze voor de database krijg! De meeste Java ontwikkelaars lopen sowieso al niet zo hoog op met Oracle. Voor mensen zoals mezelf die wel nogal Oracle minded zijn, heeft het dan weer bijzonder weinig met Java te zien (Java, C#, C++, PHP... vanuit mij database perspectief doet er dat voor mij bijzonder weinig toe). Zo hebben ze o.a. ook nog database producten en server hardware die relatief populair zijn.

En Java is net iets meer dan applets. Je frontend is misschien geen Java en als gebruiker hoef je dan ook vaak geen Java meer te installeren, maar dat betekent niet dat de achterliggende backend geen Java kan zijn. En daar is op zich ook niks mis mee.

[Zezura]

True, backend kan Java relevant zijn, maar is C# net zo interessant.

nog een redelijke jonge backend tech is NodeJS,

[littlewolvie]

Tuurlijk! En zo bedoelde ik het ook, hoor. Wat ik wou aangeven is dat die Java meestal op de backend draait en de gebruiker er doorgaans weinig van merkt. Maar uiteraard kan het evengoed iets anders zijn. Bij mij huidig bedrijf is het al Java wat de klok slaagt. Bij mijn vorige werkgever waren ze eerder Microsoft minded en kozen ze voor C#. De database was dan weer in beide gevallen Oracle, wat aantoont dat het vanuit mijn database perspectief dan weer weinig uitmaakt.

[Sissors]

Dan moeten dus derden al hun code aanpassen, wat uiteindelijk vervolgens neerkomt op vooral vendor lockin helpen. Daarnaast lijkt het mij zelf dat de IP juist zit op de opbouw van de API, en niet op de exacte functienamen: Ik vraag me dus ten zeerste af of enkel en alleen de namen veranderen als voldoende gezien zal worden.

[Verwijderd]

Dan moeten dus derden al hun code aanpassen, wat uiteindelijk vervolgens neerkomt op vooral vendor lockin helpen

Er was juist echter geen sprake van een lockin.
Google had op Android geen API en dus was er ook geen lockin. Ze konden prima een eigen API voor hun nieuwe eigen platform aanbieden.
Apple gebruikte Cocoa en Microsoft gebruikte .NET.
Het was gewoon lekker goedkoop en makkkelijk voor Google om de bestaande API van Sun (nu Oracle) te kopieren en daar geen licentie voor te betalen.

[DCK]

Wat een onzin.

Google heeft Java gebruikt als taal en inderdaad wat APIs daar uit overgenomen ter compatibility. Het gaat hier om standaardfunctionaliteit als datastructuren, bestanden, netwerken, en dergelijke. Daarnaast is er nog een hele waslijst aan Android-libraries uniek voor het systeem. Aangezien je met de Java standaardlibraries geen fatsoenlijke mobiele apps kunt bouwen moet dat wel.

Ter vergelijking: Apple gebruikt de libc api voor een heel groot gedeelte van iOS. libc is benaderbaar vanuit Objective-C voor low level dingen en je kunt hele iOS apps schrijven die bijna alleen C en libc zijn. Verwacht je nu ook dat Apple copyrightrechten moet afstaan aan AT&T, waar libc vandaan komt? Immers gebruikt Apple een nagemaakte api afgeleid van hun oorspronkelijke libc.

En Microsoft? Die schavuiten implementeren een geheel eigen nagemaakte versie van de OpenGL-api. En dat terwijl ze al een eigen graphics api hebben!

En Linux? Die implementeren allemaal low level api's die door andere Unixen worden gebruikt, terwijl ze helemaal geen Unix zijn. Ze zijn zo maar compatible met andere Unixen, die 'profiteurs'. Wordt tijd dat ze eens aangeklaagd worden.

Zo kan ik nog wel even verder gaan met het opnoemen van hergeimplementeerde api's. Hoe lang moet het lijstje worden voordat je ziet dat dit ten koste zou gaan van innovatie en/of de consument?

[Reactie gewijzigd door DCK op 23 juli 2024 00:30]

[Verwijderd]

Het is helemaal geen onzin.
Het is duidelijk dat Google de code gekopieerd heeft om te profiteren van een grote hopeveelheid bestaande Java software die beschikbaar was. Dat ze ze daarnaast ook specifieke android API's hebben gecreerd geeft alleen maart aandat ze prima in staat zouden zijn gewesst om ook een API te bouwen voor die zaken die ze nu uit de Java API's gekopieerd hebben.
Dat anderen ook API's kopieren kan best maar dan zijn dan wel vaak API die door de aanbieder als open beschikbaar gesteld zijn.
Zelfs de Java API's zijn open als je maar een Java implementatie bouwt die voldoet aan de voorwaarden die bedoeld zijn om Java wijder te verspreiden.
De android implementatie doet dat niet.

Het blijkt ook dat android nu een blok aan het been is van Java en juist de overgang van ontwikkelaars naar Java 7 afremt. Precies wat Oracle niet wil.

[DCK]

Het is duidelijk dat Google de code gekopieerd...

Dit is zo' n bizarre verdraaiing van de werkelijkheid dat ik dit in het bijzonder even wil uitlichten. Ten eerste is het herimplementeren van publieke api's niet equivalent aan het kopieren van code. Ten tweede is Google specifiek vrijgesproken van het kopieren van code (op een enkel triviaal algoritme dat in beide codebases op dezelfde triviale manier is geimplementeerd). Ten derde heeft niet Google deze herimplementatie ingezet, maar heeft Google de code gebruikt van het Apache Harmony-project, een van de vele projecten die een alternatieve implementatie bevatte van (delen van) de Java class library.

Het is duidelijk dat Google de code gekopieerd heeft om te profiteren van een grote hopeveelheid bestaande Java software die beschikbaar was.

Net zoals Apple libc heeft 'gekopieerd' om te profiteren van de grote hoeveelheid bestaande C-software. Net zoals Microsoft OpenGL heeft 'gekopieerd' om te profiteren van het grote hoeveelheid software die beschikbaar was. Net zoals Linux de Unix-api's heeft 'gekopieerd op te profiteren van de grote hoeveelheid software die voor Unix beschikbaar was. Je doet net alsof het een slecht iets is, en dat vind ik erg belachelijk.

Dat anderen ook API's kopieren kan best maar dan zijn dan wel vaak API die door de aanbieder als open beschikbaar gesteld zijn.

En de Java-API was dat niet? Java, inclusief alle classpaths wordt sinds 2007 als vrije software weggegeven. Je kunt op de website van Oracle de broncode downloaden! Apache Harmony, de Java-implementatie die letterlijk door Google werd gebruikt, bestond sinds 2005. GNU Classpath, de eerste vrije alternatieve implementatie, bestond sinds 1998. Er bestaan zoveel alternatieve Java-implementaties dat je oren er van gaan klapperen. In wat voor opzicht was Java hier in minder open dan libc?

Oracle had zelf een alternatieve API-implementatie van de Java-libraries voordat het Sun kocht. De hypocrisie spuit hier aan alle kanten van af.

Je weergave van de feiten in deze kwestie is bijzonder verdraaid.

[Reactie gewijzigd door DCK op 23 juli 2024 00:30]

[Vizzie]

de Java API's zijn open als je maar een Java implementatie bouwt die voldoet aan de voorwaarden die bedoeld zijn om Java wijder te verspreiden

Leuk dat je alleen op die stukjes reageert waar je een weerwoord op hebt (leuk, maar wel een beetje laf), maar volgens mij zit hier de crux.

Het mag onder voorwaarden.

Geldt waarschijnlijk ook voor lidbc en OpenGL. Drie keer raden welke partijen in jouw rant zich wel en welke zich niet aan de voorwaarden hebben gehouden (hint: Google dus niet)

[Superstoned]

Nee, de code zit onder voorwaarden. De API niet. Zie mijn commentaar in een paar andere draadjes hier, ik copieer ff mijn argument:

Doe eens een stapje terug en denk aan waar copyright voor is.

Jij stopt veel werk in het schrijven van een boek of maken van muziek en iemand kopieert dat schaamteloos. Dat scheelt die ander werk, ten koste van jouw bloed, zweet en tranen. We hebben copyright om jouw te 'betalen' voor je inspanning. Correct?

Maar copyright zou interoperabiliteit niet mogen beperken. Als ik copyright kon gebruiken om de afstand tussen wat boutjes en moertjes te beschermen zodat jij geen onderdeel kon maken wat je in mijn wasmachiene kunt stoppen als vervanging van mijn origineel - dan is het hek van de dam. Nog even en elke mogelijke afstand tussen boutjes en moertjes is gecopyrighted en - nu ja, ik hoef dit niet uit te leggen, toch? Daar is copyright niet voor. Eens?

Nu is de vraag: heeft Google de API overgenomen om werk te besparen (dus is copyright geldig en zijn ze fout) of hebben ze het gedaan wegens interoperabiliteit?

Dit is niet moeilijk te beantwoorden. Vraag jezelf af: de engineers van Google die de API moesten bouwen, was hun requirement: "bouw de beste Android API" of was hun requirement "maak iets compattible met Java"? Kun je je voorstellen dat de engineers de Java API bekeken en dachten: "Goh, dit is absoluut de BESTE API in de hele wereld, ik kan hier niet 1 functie aan verbeteren. Ik moet de BESTE API voor JAVA maken en - dit is hem, helemaal!". Nooit natuurlijk! Als ze de beste API hadden willen maken (en dus de JAVA API zouden bekijken) hadden ze wel wijzigingen aangebracht. En dan zou Oracle ze niet aan kunnen klagen, ook al hadden ze dan daadwerkelijk naar de JAVA API gekeken, en, om werk en moeite te besparen, dingen overgenomen (!!). Maar dat is niet gebeurt: ze hebben de API overgenomen ONDANKS dat dat extra werk is (alle fouten en sub-optimale API dingetjes ook overnemen!) om interoperabiliteit te garanderen.

En dat kun je niet illegaal maken want dan is het hek van de dam.

Google moet dit dus winnen, of we kunnen 100x meer gaan betalen voor al onze vervangbare onderdelen...

[DCK]

Dat wat je quote is een ad-hoc verzonnen argument. Er is totaal geen precedent of ethische verantwoording dat de vorm van een api (en dus niet de daadwerkelijke implementatie) onderhevig is aan de voorwaarden die de rechthebbende er voor verzint. Oracle zou helemaal niet mogen kiezen tussen api-implementaties die het kan waarderen of niet. Mag de Khronos Group kiezen tussen leuke en niet-leuke implementaties van OpenGL? Nee. Mag the Open Group kiezen tussen leuke en niet-leuke implementaties van Unix? Nee. Mag Oracle kiezen tussen leuke en niet leuke implementaties van de Java API? Blijkbaar wel, onder de Amerikaanse wet. En toch zou het antwoord op allemaal hetzelfde moeten zijn.

[Verwijderd]

De Java API mag je van Sun/Oracle (deels) hergebruiken als je maar een JAVA implementatie maakt.
Maar naar nu blijkt dus niet als je een fors deel van Java ME gebruikt om je eigen android VM aan te vullen zodat veel Java code herbruikbaar is op jouw platform terwijl omgekeerd android code meestal niet herbruikbaar is op java platforms.

Sun had in 2007 een licentieprogramma voor Java ME voor mobile toepassingen en Google liet dat links liggen.
http://blogs.broughturner.com/2007/11/google-bypasses.html
http://www.betaversion.org/~stefano/linotype/news/110/

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[DCK]

Wat is dat voor een arbitraire regel die je erbij haalt? Wat maakt een Java-implementatie dan 'Java'?

Bovendien, waarom is het prima dat GCJ al bijna twee decennia bestaat? Dat gebruikt Java, de taal en de APIs, maar gebruikt niet eens een VM. Hetzelfde geldt voor Excelsior JET en RoboVM. Of wat dacht je van de subset van de Java APIs in scala.js?

Hou eens op met de feiten te verdraaien om je punt te maken. Er is niks anders aan de Java API dan aan alle duizenden andere API's die al decennia ongestoord worden hergebruikt, gedeeld en waarmee vendor lockins worden voorkomen.

[Verwijderd]

Wat maakt een Java-implementatie dan 'Java'?

De exacte voorwaarden zullen wel vastgelegd geweest zijn in het Sun licentie programma voor Java maar dat heeft Google vermeden.
Ik vermoed dat Google dan een volledige compatibele JVM had moeten maken

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[edwinjm]

Nou nou, niet gelijk anderen beschuldigen van het verdraaien van de feiten als je ze zelf ook niet op een rijtje hebt.

Het gaat hier om de licentievoorwaarden. En die zijn bij glibc, Win32, OpenGL en Java allemaal anders. Daardoor kunnen deze projecten *niet* met elkaar worden vergeleken.

[DCK]

Is dat zo? Kun je mij vertellen dan 1) hoe die licentievoorwaarden van toepassing zijn op een api? 2) onder welke licentie een api zou vallen? Waarom is het verschil in licenties uberhaupt relevant voor mijn punt?

Bovendien is de broncode van glibc, Java, en de meeste Unix api's allemaal onder een open source licentie te krijgen. Niet dat dat iets met de api te maken heeft, maar het is software die voor de rest ook al open is.

[enver63]

@DCK: "Je praat echt een hoop feitelijke onjuistheden en bizarre weer aan elkaar."
En wie daar goed in is, is expert op gebieden als 'recht' of 'politiek'.

Alleen de eerste rechter, Alsup, in het proces tussen Oracle en Google wist waar hij het over had, maar die had dan ook speciaal hiervoor een paar lessen programmeren gevolgd.

[coolmos]

Het is duidelijk dat Google de code gekopieerd heeft om te profiteren van een grote hoeveelheid bestaande Java software die beschikbaar was.

De hoeveelheid code die Google gekopieerd heeft is marginaal. Ze hebben zowat alles zelf geschreven, maar de functies hebben dezelfde naam gekregen om compatibiliteit te waarborgen.

[MSalters]

WVerwacht je nu ook dat Apple copyrightrechten moet afstaan aan AT&T, waar libc vandaan komt? Immers gebruikt Apple een nagemaakte api afgeleid van hun oorspronkelijke libc.

Nee. C is eind jaren 80 al door AT&T overgedragen aan eerst ANSI (de Amerikaanse standaardisatie organisatie) en in 1990 ging het naar ISO.

Daarnaast gaan de UNIX wortels van iOS terug naar de BSD tak van UNIX, niet de AT&T tak.

[jiriw]

Daar heeft Sissors het helemaal niet over! Het gaat er om dat ik mijn eigen geschreven Java broncode niet kan gebruiken in alternatieve Java-achtige implementaties (zoals Dalvik) omdat Oracle het derde partijen (zoals Google) kan verbieden zulke API compatible implementaties te maken. Google heeft hier niet het grootste probleem, maar iedereen die software schrijft! Tenzij je natuurlijk direct je binaries in binaire opcodes schrijft (Assembly is al een API) of zelf je compiler en taal hebt geschreven (iets wat een programmeur op niveau wel moet kunnen maar de meesten niet zullen doen omdat ze hun tijd wel beter kunnen gebruiken).
Stel je voor dat Bjarne Stroustrup zo'n akkefietje met C++ zou uithalen. Je kan de vooruitgang in de ICT industrie in z'n geheel 30 jaar terugdraaien.

Copyright voor een API, okee. Maar alleen met een impliciete royaltyvrije licentie met onbeperkt gebruik, uitgezonderd het claimen van copyright, voor iedereen op het moment dat je een API als zodanig publiceert.

[Verwijderd]

Het is wel Sun/Oracle die in 20 jaar honderden miljoenen, zo niet miljarden heeft geinvesteerd in Java.
Niet Google.
Jij bent mede Java gaan bouwen vanwege die hoge investeringen door Sun/Oracle.
De Google java-achtige Dalvik implementatie is helemaal niet gunstig voor Oracles Java. Er wordt/werd wel basis Java code naar Android gekopieerd maar omgekeerd komt er weinig terug omdat Dalvik om de java API's heen vol zit met noncompatiblele android API's die niet in Java beschikbaar zijn.
Ook worden door Sun/Oracle jarenlang gesupporte Java ontwikkelaars ontrokken aan het Java eco-systeem die door Google getrokken worden naar Android eco-systeem waar ze hun java code makkelijk kunnen hergebruiken.

[coolmos]

Omgekeerde wereld hier? Sun heeft Java gekocht voor miljarden in de hoop er op binnen te lopen. Ze hebben er zelf nauwelijks wat aan gedaan.

Ze zien nu hun investering verdampen, en dat mag natuurlijk niet. Ook al staat Google volledig in z'n recht, er moet nu iets veranderen zodat Sun/Oracle toch maar vooral enige ROI heeft.

De enige profiteurs in dit verhaal is Sun/Oracle.

[Verwijderd]

Ook al staat Google volledig in z'n recht,

Wat dus niet het geval is gebleken.

Er is nog een kleine hoop voor Google dat hun gebruik van de API als fair use kan worden aangemerkt maar zelfs zo'n beslissing laat onverlet dat de API gecopyrighted blijft.

Zou alleen Google veel geld besparen in licenties.

[Superstoned]

Wat dus niet het geval is gebleken.

Verkoop de huid niet voor het beestje geschoten is - het is nog niet klaar.

En - kom op, als dit finaal was, dit zet de IT wereld op zijn kop - als je geld kunt vragen voor API's, als API's copyrightable zijn. Dat is de dood voor honderden, duizenden businesses. Hoe ver gaan we? Scrapen van webpagina's is illegaal? her-implementatie van elke API wordt opeens illegaal... Het openen van elk proprietair documentformaat wordt illegaal. Microsoft, Google, Apple - ze krijgen allemaal enorme rechtzaken aan hun broek voor het MS Word docuement formaat, Adobe formaten, Wordperfect formaten en zo voorts.

Nee, deze uitspraak gaat onderuit, ik voorspel het. Dit is gewoon een rechter geweest die de gevolgen van zijn uitspraak niet overzag - daarom is het naar het hoog gerechtshof gegaan. En die hadden er geen zin in omdat het zo overduidelijk fout is dus het is terug lokaal waar ze gewoon verder gaan.

[Verwijderd]

Verkoop de huid niet voor het beestje geschoten is - het is nog niet klaar.

Het lijkt me wel dat de vraag over het copyright nu klaar is.
Wel kan er nog gestreden worden over of de acties van Google inbreuk betekenen of fair use maar ik zie niet in wie er nog het betroffen gerechtshof kan overrulen tav de beslissing over copyright van de API definities.

Dit is gewoon een rechter geweest die de gevolgen van zijn uitspraak niet overzag - daarom is het naar het hoog gerechtshof gegaan

De initiele rechter besloot toch juist dat er geen sprake was van copyright en is later overruled door een gerechtshof die de API's als wel coprightable beoordeelde.
En nu weigert het supreme court een verdere uitspraak te doen om het gerechtshof te overrulen.

[Verwijderd]

Microsoft, Google, Apple - ze krijgen allemaal enorme rechtzaken aan hun broek voor het MS Word docuement formaat, Adobe formaten, Wordperfect formaten en zo voorts.

De oude Microsoft Office bestandsformaten zijn door Microsoft gratis vrijgegeven voor gebruik door iedereen de nieuwe Microsoft Office formaten zelfs open standaarden die iedereen gratis mag implementeren.
http://www.iso.org/iso/ho...detail.htm?csnumber=61750
En ook de pdf formaten van Adobe zijn open standaarden.
http://www.iso.org/iso/ho...detail.htm?csnumber=51502

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[enver63]

Het hergebruiken van code en het draaien op allerlei platformen was een van de gedachten achter Java (toen Sun nog zelfstandig was): Write Once, Run Anywhere.

Toen Oracle Sun had overgenomen en erachter kwam dat ze daar niet zoveel aan hadden (in termen van aandelhouderswaarde) hebben de advocaten van Oracle zich te pletter gezocht naar iets van Sun waarmee ze toch nog geld konden verdienen, en toen kwam de rechtszaak tegen Google eruit. De organizational chart van Oracle is veelzeggend.

[Verwijderd]

Het hergebruiken van code en het draaien op allerlei platformen was een van de gedachten achter Java (toen Sun nog zelfstandig was): Write Once, Run Anywhere.

Dat is inderdaad de gedachte maar als ze dat echt gewild hadden dan dan had Google het java mobile platform moeten gebruiken en niet alleen maar een flink deel van java in hun android platform moeten gebruiken aangevuld met eigen niet compatible android API's

Sun had in 2007 al een licentieprogramma om Java te monetiseren. Voordat Oracle ook maar in de picture was. Het is dus niet dat Oracle degene was die origineel bedacht dat er geld verdient moest worden aan Java licenties.
In 2007 werd dan ook al opgemerkt dat het maken van een niet standaard Java VM een vreemde actie was tov Sun:
http://archive.oreilly.co...gles_tweaked_nonstan.html
http://www.betaversion.org/~stefano/linotype/news/110/

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[Superstoned]

Je gooit toch weer API en code door elkaar. Code copieren -> copyright. API gebruiken -> interoperabiliteit. Heel verschillende doelen, heel verschillenden dingen.

En het argument dat SUN miljarden in het ecosysteem heeft gepompt - sure. Google heeft dat ook gedaan, meer nog dan SUN nu. Is het dan nu van hen? Een ecosysteem is precies dat - een ecosysteem. Dat is niet echt van 1 bedrijf...

[Verwijderd]

Nee ik haal het niet door elkaar. Jij probeert alleen de uitspraak van de rechter te negeren en te claimen dat er geen copyright op de API definities rust maar alleen op de code. Dat standpunt is echter door een VS hof naar de prullebak verwezen.

[Superstoned]

Als een communicatie protocol (dat is een API) gecopyright kan worden kan dat ook met een bestandsformaat of de afstand tussen boutjes in een machine. Dat zou onze complete maatschappij op zijn kop zetten. Als de rechter tot die conclusie is gekomen - nou ja, dat er rechters zijn die het niet helemaal begrijpen lijkt me wel duidelijk. Het zal William Alsup niet geweest zijn...

[Verwijderd]

kan dat ook met een bestandsformaat of

Dat is ook zo voor een definitie van een bestandsformaat.

Google zelf heeft ooit de VP8 specificatie onder een creative commons licentie (gratis) ter beschikking gesteld.
Dat is ook gewoon een copyright licentie voor een bestandsspecificatie.

[Superstoned]

Slecht voorbeeld.

De tekst van de specificatie is copyrightable, maar de specificatie zelf niet - iedereen mag een VP8 implementatie maken, ook als de specificatie niet onder een CC licentie was.

Op die implementatie kunnen patenten zitten (wat bij MPEG & friends het geval is) maar - copyright heeft er niets mee te maken.

Serieus, no offense - maar je zit er hier mee echt naast.

[MrNOnamE]

Niet alleen qua ontwikkeling scheelde het google geld, zelfs nu verdient google nog geld mede dankzij deze API's. Niet meer dan redelijk dat je daar dan ook een vergoeding voor moet betalen.

[koelpasta]

Niet alleen qua ontwikkeling scheelde het google geld, zelfs nu verdient google nog geld mede dankzij deze API's.

Hoe bedoel je? Google heeft een eigen implementatie gemaakt. 't Is niet dat ze code hebben gejat ofzo.

[MrNOnamE]

De uitspraak van de rechter was dat google delen van de code Oracle had overgenomen. Of dat dan is door het letterlijk overnemen of door een soort gelijk iets te maken doet er dan niet zo veel toe.

Feit blijft dat een (klein) deel van Android mede tot stand is gekomen dankzij Oracle. De grote vraag blijf welk deel en hoeveel moet google hiervoor gaan betalen.

Al denk ik voordat we dat weten we toch zeker een aantal rechtzaken verder zijn

[Superstoned]

Nee, de uitspraak was dat Google 1 stukje code op dezelfde manier had geschreven als Google - en dat stukje was zo triviaal dat de rechter (alstrup) in 1 week zichzelf Java heeft aangeleerd en toen zelf die code nog een keer, onafhankelijk, heeft geschreven. Toen stond de advocaat van Oracle wel goed voor lul, want die bleef maar beweren dat dit zulke unieke code was. Erg leuk om over te lezen, het is al een paar jaar terug, maar een mooie actie.

Nu gaat het erom of je een API met copyright kunt beschermen. En dat kan niet, en dat is maar goed ook - een API is NIET code, het is een set redelijk arbitrare conventies. Zeg de afstand en vorm van een onderdeel van een wasmachiene. Dat kun je niet met copyright beschermen tegen een ander bedrijf wat een vervangend (goedkoper!) onderdeel wil maken, dat zou echt van de gekke zijn. Als het ingewikkeld genoeg is heb je er een patent op, en als het triviaal is kun je het per definitie niet patenteren - dus dat komt hier ook niet ter sprake.

Dan kun je nog jezelf afvragen of Google de API heeft gekopieerd om zichzelf werk te besparen (een API ontwerpen kost wel wat tijd) want dan kun je argumenteren dat het toch een copyright zaak is. Maar geloof je nu echt dat als je een groep brilliante google engineers vraagt om de 'beste' Android API te schrijven, dat ze de Oracle API zouden bekijken en tegen elkaar zeggen: "Oh, my god, these Oracle guys, they were gods! They wrote the BEST API EVER, I wouldn't know what to improve or do different. Perfection has been found, let's copy, class by class, how they did it". Natuurlijk zouden ze dingen kunnen verbeteren, versimpelen, of gewoon anders doen omdat het anders kan. Het zijn engineers.

Nee, ze hebben de API overgenomen omdat ze compatibiliteit wilden garanderen voor een sub-set van de code, zodat porten eenvoudiger was, zodat programmeurs sneller met Android aan de slag konden.

Dat is interoperabiliteit - en, dus, einde verhaal copyright zaak.

[enver63]

Uh oh... Ik heb ook wel eens een programma geschreven in Java...

[roy-t]

Wat je ook niet moet vergeten is dat door de APIs over te nemen Google niet hoefde na te denken over de structuur van het programma. Alleen over de implementatie van individuele methoden.

Wat ze eigenlijk gedaan hebben is de complete architectuur van al die libraries schenden, en juist dat is het ingewikkeldste gedeelte van programmeren!

[koelpasta]

Die 'architectuur' waar je het over hebt is gewoon open hoor. Iedereen mag java helemaal namaken zolang ze blijkbaar maar de naampjes en implementatie veranderen. Dat heeft de rechter nu blijkbaar beslist.
Het kan oracle dus nooit gegaan zijn om de 'architectuur', whatever je daar mee bedoelt.
De naampjes zijn gewoon gestandaariseerde labels, een interface. Heeft verder niks met de eigenlijke archiectuur te maken.

[koelpasta]

Je bent gewoon vrij om een eigen API te maken te precies hetzelfde kan. Alleen niet met letterlijk precies dezelfde functienamen en parameters.

Dat is tegenstrijdig.
Een api die precies hetzelfde kan kan dus ook op dezelfde manier worden aangeroepen.

Dat had Google best kunnen doen maar dan hadden ze in Android niet meteen kunnen profiteren van bestaande tools en software libraries voor Java.

En als jij in c schrijft dan kun je ook gelijk gebruik maken van bestaande c functies. Betekent niet dat je de standaard libraries niet mag nabouwen.
Geen argument dus.

Het letterlijk kopiëren van de Java API definities bespaarde Google honderden miljoenen doordat er gigantisch veel Java code hergebruikt kon worden in Android

Dat geldt voor alle standaarden. Jij zegt dat als een fabrikant een bepaald bandmodel heeft bedacht die alleen maar op hun auto past dat niemand anders een auto mag maken waar dat type banden op passen, ook al is het een heel andere auto. Je zegt ook dat niemand een verloopstuk mag maken waarmee die banden op een willekeurige auto te gebruiken zijn. VInd ik onzin.

Het letterlijk kopiëren van de Java API definities

Een API wordt niet gedefinieerd in de interface. De interface wordt gedefinieerd in de interface. De API zelf is de implementatie en die is volgens mij niet overgenomen.

[Verwijderd]

Dat is tegenstrijdig.
Een api die precies hetzelfde kan kan dus ook op dezelfde manier worden aangeroepen.

Een API die precies hetzelfde kan hoeft niet dezelfde functies of parameters te hebben.
Je kunt bijvoorbeeld een API hebben om afwisselend woorden of spaties/leestekens op een scherm te tonen terwijl je precies hetzelfde ook kan bereiken door een API te maken die 1 voor 1 karakters op het scherm toont.

Dat geldt voor alle standaarden

Een API is echter niet automatisch een standaard tenzij de API gestandaardiseerd wordt zoals Javascript API in Ecmascript standaard of de Canvas API in de W3C HTML5 standaarden.
API's zijn in de basis gewoon software producten. Soms worden deze gestandaardiseerd.

[Alfa1970]

In dit geval was het jatwerk makkelijk aan te tonen want Google heeft gewoon sommige bestanden letterlijk gekopieerd inclusief de comments van Oracle.
Het jarenlange getouwtrek ging dan ook niet om de schuldvraag, want die was vanaf het begin af aan al vrij duidelijk in het voordeel van Oracle.

[Aham brahmasmi]

In dit geval was het jatwerk makkelijk aan te tonen want Google heeft gewoon sommige bestanden letterlijk gekopieerd inclusief de comments van Oracle.

Zijn dat niet comments van Sun, die het prima vond dat Google Java voor Android gebruikte?

[enver63]

Plus een aantal interfaces, waarin slechts wordt vastgelegd welke properties en methods een class (die de interface implementeert) moet hebben. Foei toch!

[Alfa1970]

In zekere zin zijn het de comments van Sun, maar aangezien Sun is verkocht aan Oracle, zijn ze eigendom van Oracle, iig vandaag de dag.

[CAPSLOCK2000]

Dat voorbeeld was misschien een beetje te extreem maar het gaat mij om het probleem dat hiermee API's onder copyright zijn gekomen en daarhangen allerlei wetten en regels aan vast. Een flink deel daarvan staat nog open voor interpretatie.

Mag je bijvoorbeeld een boek schrijven over Java waarin de API wordt uitgelegd?

Een extremer (en theoretisch) voorbeeld is dus of je een API wel mag gebruiken zonder toestemming. Dat je een API mag lezen staat wel vast, dat is net als een boek. Ik vind het ook vanzelfsprekend dat je tegen zo'n API mag programmeren maar er is vast wel een jurist te vinden die er anders over denkt.

Nog interessanter wordt het als het om een API gaat die niet is gepubliceerd. Veel software bevat API's die nooit publiek zijn gedocumenteerd. Zo'n API valt ook onder copyright en ik zie het nog wel gebeuren dat bedrijven een aanklacht indienen tegen programmeurs die gebruik maken van zo'n (officieel) niet gedocumenteerde API.
Vergelijk het met deeplinks. Een deeplink maken kan verboden zijn als de eigenaar van de content niet de bedoeling had om de content publieke online te zetten. Het is informatie die gewoon online staat maar toch mag je er geen gebruik van maken.

[Blokker_1999]

Om het simpel te zeggen met praktijkvoorbeelden, ReactOS is bij deze ten dode opgeschreven in de VS en ook een project als wine kan in principe niet meer.

[devslashnull]

Hahaha....

Iedereen die ooit in Java een Listener interface uit de Java API heeft geimplementeerd is schuldig aan illegale implementatie van een API en moet centen schuiven....

"Mijn naam is Oracle en Google heeft veel poen en daar willen we wel wat van..."
"Mijn naam is de Europese Commisie en Google heeft veel poen en daar willen we wel (veel) van..."

[koelpasta]

Er is een groot verschil tussen programmeurs die een API gebruiken van een aanbieder om code te schrijven en een aanbieder die API's jat van een andere aanbieder.

Er zijn helemaal geen APIs gejat. Er zijn interfacenamen overgenomen om compatibiliteit te waarborgen.

[roy-t]

Een Application Programmer Interface is een beschrijving/contract van een de publieke methode, en wat ze doen, in een library. Hoe heeft Google dit niet gejat door alle namen van types en methodes en documentatie exact over te nemen?

[T0mBa]

In veel gevallen gaat het over dusdanig eenvoudige API calls dat het compleet belachelijk zou zijn om het te veranderen.
Als ik een functie "Print(string texttoprint)" schrijf die de doorgegeven string afdrukt, schend daarna iedereen die ook zo'n functionaliteit (op een andere manier geimplementeerd) biedt met dezelfde naam, mijn copyright?
Sterker nog, volgens jouw definitie van "jatten", zou Google een string zelfs geen string mogen noemen omdat Java dit al zo doet?

[roy-t]

Natuurlijk is het in dit kleine voorbeeld idioot. Maar Google heeft een significant deel van de Java libraries exact gekopieerd. Ik denk niet dat alles wat daar in zit zo triviaal is.

Google mag natuurlijk wel een string een string noemen. Dat is niet iets van Java maar gewoon iets uit de computerliteratuur. Dat is als zeggen dat een bedrijf niet meer een moertje een moertje mag noemen.

[coolmos]

Dat is als zeggen dat een bedrijf niet meer een moertje een moertje mag noemen.

Ga maar eens echt kijken naar wat Google werkelijk heeft gedaan, want op dat niveau zit het echt.

Oracle zegt in feite dat je niet dezelfde functie mag implementeren als je de functie dezelfde naam geeft. Je mag dus wel een PRINT functie schrijven, maar je mag 'm geen PRINT noemen. Daarmee is dus alle compatibiliteit in één klap naar de prullenbak verwezen.

[roy-t]

Ik discussieer nu met je op verschillende stukken in dit nieuwsbericht. Lastig .

We worden het niet echt eens over de metaforen over wat een API precies is. Laat ik het dan bij mijn standpunt houden dat een API ontwikkelen niet triviaal is en dat het een hoop meer informatie, en architectuur is, dan een stel namen. Waar het misschien in het begin op lijkt. (Om toch weer een metafoor te gebruiken, een naam van een karakter in een boek is ook niet gewoon maar een naam)).

Dus nee ik denk dat de ontwikkeling van een API niet triviaal is en dat er daarom goed over nagedacht moet worden, in hoeverre deze beschermd mag worden. Google heeft iets gekopieerd van een ander bedrijf op zo'n manier dat alleen Google er profijt van heeft. Is dat eerlijk is de grote vraag hier.

[koelpasta]

Een Application Programmer Interface is een beschrijving/contract van een de publieke methode, en wat ze doen,

Maar wat het niet is is hoe de methodes werken. Het is enkel de interfacenaam die overgenomen is.

Jij mag toch ook gewoon een TV maken zolang je maar niet iemand anders zn ontwerp jat?
En zo mag volgens mij iedereen gewoon een willekeurige java method implementeren zolang ze de code zelf maar niet jatten.
Anders krijg je dat mensen gaan claimen dat ze de '+' functie hebben gecopyright enzo en dat is vette onzin. Al jij een eigen optelfunctie wil maken dan kan dat gewoon. En als jij een eigen vervanger voor een willekeurige java methode wilt maken dan kan dat ook gewoon. Althans, volgens deze nazi van een rechter blijkbaar niet meer.
Echt, fu*k Oracle. Heeft niet lang geduurd na de overname van Sun dat ze java verpest hebben met hun grijpgrage corporate vingertjes.

[burgt]

Oracle heeft er sowieso nooit wat aan ontwikkeld, ze hebben Sun overgenomen en zijn daarna op oorlogspad gegaan met Google. Sun heeft het nooit een probleem gevonden.

Oracle is hier de troll die alleen een berg easy money wil hebben.

[Verwijderd]

Sun overnemen was gratis dan? Nee, die overname kostte Oracle 7,4 miljard dollar. Het is de gewoonste zaak in technologie land om bedrijven over te nemen voor technologie en patenten. Een belangrijk punt van die overname was dat Oracle Java in handen kreeg. Op het moment dat Sun nog beschikte over Java bestond Android pas enkele maanden. Al je aannames zijn foutief te noemen.

[majoh]

Is dat zo erg? Op API's kan ook copyright staan. En als dat op deze API's het geval is dan heeft Google zich dan daaraan te houden als de houder van het copyright dat eist...

Op veel API's staat geen copyright of is een geaccepteerde standaard. Dat veranderd door deze uitspraak echt niet.

De browser vergelijking klopt dan ook niet. Dit is een beschreven standaard ipv een API met copyright.

[CAPSLOCK2000]

Is dat zo erg? Op API's kan ook copyright staan. En als dat op deze API's het geval is dan heeft Google zich dan daaraan te houden als de houder van het copyright dat eist...

Op veel API's staat geen copyright of is een geaccepteerde standaard. Dat veranderd door deze uitspraak echt niet.

Álle API's vallen nu onder copyright. Copyright is namelijk automatisch. Je hoeft niet meer zoals vroeger je boek/API/... bij een bureau te registeren. Alles wat copyrightbaar is valt automatisch onder copyright. Als je geen bijzondere toestemming van de uitgever hebt dan moet je je aan de beperkingen uit de wet houden, bijvoorbeeld dat je geen kopietjes mag maken.

De browser vergelijking klopt dan ook niet. Dit is een beschreven standaard ipv een API met copyright.

Het is het allebei. Het is inderdaad een beschreven standaard maar die standaard bevat een API. Alle API's vallen nu onder copyright dus deze ook. Daarmee is nog niet gezegd dat je die API niet mag gebruiken maar hij valt sowieso onder copyright.

[majoh]

Het kan misschien aan mijn kortzichtigheid liggen. Maar waar staat dat het over alle bestaande en toekomstige API's gaat? De artikelen die ik lees gaat het over het herschrijvenen van standaard implementaties van Java API's...

[CAPSLOCK2000]

Het verbieden van het herschrijven van stukken van de implementatie is het doel van Oracle maar het middel dat ze er voor gebruiken is copyright.

In het artikel staat:

De zaak gaat over hoeveel copyrightbescherming er geboden moet worden met betrekking tot Java.

Dat is een beetje vaag maar de vraag waar het over gaat is of een API onder copyright valt of niet. Hier is besloten dat deze API (en daarmee alle andere) inderdaad onder copyright vallen en dat het hergebruiken van (delen van) een API dus niet mag zonder explicite toestemming van de houder.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 00:30]

[majoh]

Heb je hier ook een bron voor. Ik als software ontwikkelaar vind dit namelijk heel interessant...

Wat ik lees gaat het niet over de API, maar over het herschrijven van implementaties, waarbij ik dan gok (sorry, nog niet kunnen vinden) dat het over een deel van de java.lang packages gaat, en wat geen interfaces zijn, maar geïmplementeerde classes... Aangezien als het interfaces waren, hadden ze de implementaties niet hoeven te herschrijven / overschrijven.

En als dat zo is, gaat je stuur / ruitenwisser vergelijking niet op. Om even in de auto termen te blijven. Google heeft dan geen eigen auto gebouwd, maar dan heeft Google gewoon een Audi herbouwd, gebruik makende van eigen technologie, maar het ziet eruit, en rijdt ongeveer hetzelfde als een Audi. En dan kom je dicht bij Chinese kopieer praktijken. Iets waar ik wel op tegen ben...

[rickiii]

Google heeft dan geen eigen auto gebouwd, maar dan heeft Google gewoon een Audi herbouwd, gebruik makende van eigen technologie, maar het ziet eruit, en rijdt ongeveer hetzelfde als een Audi.

Het uiterlijk van een auto heeft een bepaald imago dat een naamsbekendheid heeft en daarmee consumenten op het verkeerde been kan zetten. Als je een Android SDK gebruikt, dan staat er nergens dat je Oracle software gebruikt. Een ontwikkelaar kan dat onderscheid wel maken. Hij of zij kiest specifiek voor een ontwikkelplatform.

[leftright]

Expliciete toestemming is niet per se nodig in geval van fair use. Uit de uitspraak van het Court of Appeals blijkt dat ze daar nog niet over uit zijn in dit geval: "Because there is an insufficient record as to the relevant fair use factors, we remand for further proceedings on Google’s fair use defense. " https://www.eff.org/files...21.opinion.5-7-2014.1.pdf

[Durandal]

Dus als jij je kinderen dezelfde naam geeft als ik de mijne al heb gegeven, doe jij inbreuk op mijn auteursrecht..
Veel anders is het eigenlijk niet.

[Verwijderd]

Dus als jij je kinderen dezelfde naam geeft als ik de mijne al heb gegeven, doe jij inbreuk op mijn auteursrecht..
Veel anders is het eigenlijk niet.

En soms gaan analogieen helemaal fout.... Als jj niet inziet of wil inzien dat dit iets anders is heeft een discussie niet erg veel zin.

[Durandal]

Zeg dan niets of leg het dan toch uit, want ik zie het verschil niet.

[CharlesND]

Wat je voor het gemak even vergeet is dat Android NIET compatibel is met Java. Google maakt dus gebruik van de tijd en geld die Oracle in Java heeft gestoken om een systeem op de markt te brengen dat in veel opzichten een concurrent van Java is. Al was het alleen maar omdat hele volksstammen programmeurs nu moeiteloos voor Android konden programmeren en toepassen en Java dus minder aantrekkelijk werd voor fabrikanten en ontwikkelaars.

Dus je hele verhaal van 'bestaande software vervangen door iets nieuws' klopt niet. Google bracht geen verbeteringen maar een concurrerend systeem op de markt zonder daar Oracle een cent voor te betalen. Dat Oracle dat niet leuk vond en een proces aanspande lijkt mij dus niet zo gek.

[CAPSLOCK2000]

Wat je voor het gemak even vergeet is dat Android NIET compatibel is met Java.Google maakt dus gebruik van de tijd en geld die Oracle in Java heeft gestoken om een systeem op de markt te brengen dat in veel opzichten een concurrent van Java is. Al was het alleen maar omdat hele volksstammen programmeurs nu moeiteloos voor Android konden programmeren en toepassen en Java dus minder aantrekkelijk werd voor fabrikanten en ontwikkelaars.

Dus je hele verhaal van 'bestaande software vervangen door iets nieuws' klopt niet. Google bracht geen verbeteringen maar een concurrerend systeem op de markt zonder daar Oracle een cent voor te betalen. Dat Oracle dat niet leuk vond en een proces aanspande lijkt mij dus niet zo gek.

Het is misschen sneu voor Oracle maar ik vind de nadelen van deze uitspraak veel te groot. Copyright is een deal tussen samenleving en houder waar beide partijen voordeel uit moeten halen. Ik zie hier een enorme last voor de samenleving om Oracle een financieel voordeeltje te bieden.

Als het echt alleen over Java vs Android ging dacht ik er misschien anders over maar dit heeft gevolgen voor zo veel meer dat ik die aspecten veel belangrijk vind dan geruzie tussen Oracle en Google.

Overigens vind ik het ook niet vanzelfsprekend dat iedere vorm van gebruik van het werk van een ander automatisch tot een financiele vergoeding moet leiden. Als de overbuurman z'n tuin netjes heeft gesnoeid kan ik daar van genieten maar ik hoef er niet voor te betalen.

Copyright is niet door god gegeven. Het is deal tussen staat en copyrighthouder. Zo'n deal moet voor beide partijen gunstig zijn.
Ik vind dat er goede argumenten zijn om API's niet onder copyright te laten vallen en dat die zwaarder wegen dan de aandelenkoers/belastingafdracht van Oracle.

[CharlesND]

Je slaat de spijker precies op z'n kop! Copyright is bedacht om de samenleving te kunnen laten profiteren van uitvindingen en nieuwe technologieen. Essentieel punt daarbij is dat degene die er tijd en geld in gestopt heeft daar een redelijk bedrag voor terug krijgt als anderen die uitvindingen gebruiken. Dat Google het gratis gebruikt is niet sneu maar de doodsteek voor het hele copyright idee.

Oracle vroeg een redelijk bedrag, ik dacht iets van 70 miljoen om gebruik te maken van Java API's. Google vond dat te veel (niet betalen voor software en patenten van anderen is vanaf het allereerste begin de standaard voor Google...) en liet het daarom op een rechtszaak aankomen.

Het idee dat het niet vanzelfsprekend is dat je voor iedere vorm van gebruik van het werk van een ander zou moeten betalen schijnt helaas alleen te gelden voor creatieve beroepen als musicus, schrijver, filmmaker en software ontwikkelaar enzo. Bij de garage, de tandarts, de tuinman en de schilder moet ik altijd voor ieder gewerkt uur betalen. Heel vreemd.

[CAPSLOCK2000]

Je slaat de spijker precies op z'n kop! Copyright is bedacht om de samenleving te kunnen laten profiteren van uitvindingen en nieuwe technologieen. Essentieel punt daarbij is dat degene die er tijd en geld in gestopt heeft daar een redelijk bedrag voor terug krijgt als anderen die uitvindingen gebruiken. Dat Google het gratis gebruikt is niet sneu maar de doodsteek voor het hele copyright idee.

Je vergeet het andere essentieele punt namelijk dat de maatschappij er ook iets voor terug krijgt. Bijvoorbeeld een boek dat anders niet geschreven zou zijn of een nieuwe uitvinding.
Die twee punten moeten een beetje in verhouding staan. De laatste decennia is de balans flink verstoord. De maatschappij draagt de lasten maar deel nauwelijks in de lasten.
Dit is een stevig voorbeeld. De maatschappij krijgt een zwaar nadeel om Oracle een klein voordeel te bieden. Dat vind ik geen eerlijke ruil.

Het idee dat het niet vanzelfsprekend is dat je voor iedere vorm van gebruik van het werk van een ander zou moeten betalen

Ik vind dat niet zo vanzelfsprekend.
Als ik de sneeuw van mijn stoepje veeg en iemand loopt over de stoep heb ik geen recht op een vergoeding. Als ik bloemen in mijn tuin plant mogen mensen daar naar kijken zonder dat ik recht heb op een vergoeding. Als ik in de bus een liedje zing hoeft niemand daar voor te betalen. Als ik onder de bus kom mag een journalist daar een foto van maken zonder mij of de busmaatschappij te betalen.

Er zijn zat gevallen waarin je gebruik mag maken van het werk van anderen zonder dat daar direct een vergoeding tegenover staat.

[Verwijderd]

Dit is een stevig voorbeeld. De maatschappij krijgt een zwaar nadeel om Oracle een klein voordeel te bieden. Dat vind ik geen eerlijke ruil.

De maatschappij heeft eingelijk nauwelijk nadeel hiervan.
Google moet wat geld in licenties betalen en voortaan weet iedereen waar je aan toe bent met API's.
Dus als je voortaan een API gebruikt die niet open/vrij is dan kies je daar zelf voor omdat het bijvoorbeeld een betere/handigere API is en dan heeft de maker daarvan een mogelijkheid om geld te verdienen aan die betere/handigere API.

API makers zullen ofwel hun nieuwe API's vrijgeven om het gebruik daarvan zo veel mogelijk te stimuleren ofwel de nieuwe API commercieel exploiteren en dat is nu makkelijker met de bescherming van copyright op de API definities.

[servies]

De maatschappij heeft eingelijk nauwelijk nadeel hiervan.
Google moet wat geld in licenties betalen en voortaan weet iedereen waar je aan toe bent met API's.

Euh....
Deze uitspraak (op een API zit copyright) doortrekken betekent grofweg dat de halve IT wereld op z'n gat komt te liggen...
Er is een copyright komen te liggen op de naamgeving van een functie... Niet op de implementatie, maar op de naamgeving...
Zeg maar dag met je handje naar portabiliteit.
Het zou me niets verbazen dat wanneer je in de code van Apple of Microsoft of een willekeurig ander bedrijf dat een taal heeft ontwikkeld, je hetzelfde probleem gaat tegenkomen...

[Verwijderd]

Ik denk dat Apple en Microsoft zich weinig zorgen maken. Beiden hebben veel ervaring met copyright geschillen en gebruiken daarom alleen software met (open) licenties.

Google/android heeft bewust gekozen om geen licentie van Sun te nemen en in hun interne emails werd al gediscussieerd of dat wel verstandig was.

[CAPSLOCK2000]

Ik hoop dat het inderdaad zal leiden tot open API's maar ik ben bang dat het vooral zal worden gebruikt om de concurrentie dwars te zitten.
Neem nu Android zelf. Een hoop mensen zijn niet zo zeer gehecht aan Android als wel aan de apps die er op draaien. Als een concurrent een mobiel OS kan maken waar Android-apps op kunnen draaien (en er zijn er een aantal) dan zal dat flink helpen. Als Google zegt dat niemand anders hun API mag gebruiken dan wordt het haast onmogelijk om van Android af te stappen met behoud van je apps.

Minstens zo vervelend is het als je ook aan andere apparaten denkt, bijvoorbeeld het hele IoT-gebeuren of eigenlijk ieder apparaat dat "geautomatiseerd" is.
Dusver kon iedere programmeur in principe z'n eigen backends schrijven om de software van de leverancier te vervangen als die niet beviel. Nu ben je verplicht om toestemming te krijgen van de fabrikant. Er zijn er vast een hoop die daar niet aan mee gaan werken.

Ik denk dat copyrightlose API's meer innovatie zouden opleveren omdat het dan iedereen vrij staat om willekeurige componenten met elkaar te combineren. Nu ben je veel meer gebonden aan de leveranciers.

Ik vind dus dat dit wel degelijk flinke nadelen zijn voor de samenleving. Verder is er ook nog de tijd en het geld dat er gaat zitten in vervolging en rechtspraak. Dat zijn kosten die de samenleving draagt. Al met al vind ik dus dat er wel flinke nadelen zijn voor de samenleving en dat die niet opwegen tegen de voordelen.

[Verwijderd]

Bij dominante marktpartijen zoals Google kan dat eventueel worden afgedwongen door de overheid zoals dat ook met de server protocollen van MS is gebeurd.
Overigens zijn de meeste api's van android Open source en zijn er redelijke licenties voor de meeste api's van googles clouddiensten die nodig zijn voor android.

[Durandal]

Je slaat de spijker precies op z'n kop! Copyright is bedacht om de samenleving te kunnen laten profiteren van uitvindingen en nieuwe technologieen. Essentieel punt daarbij is dat degene die er tijd en geld in gestopt heeft daar een redelijk bedrag voor terug krijgt als anderen die uitvindingen gebruiken. Dat Google het gratis gebruikt is niet sneu maar de doodsteek voor het hele copyright idee.

Copyright (kopieer recht - letterlijk dus) is bedacht omdat boekdrukkers hun inkomsten veilig wilden stellen door via lobbyen alleenrecht te krijgen voor het drukken van boeken. Let op, drukkers dus, niet de auteurs.
De hele vooronderstelling dat auteursrecht (een restrictief recht) de creatie van werken bevordert is een fals dogma, net zoals dat van ander IP. Omdat niemand een orgineel idee heeft en alles voort bouwt op wat er al was is het beter om dat vrij te hebben.
Copyright is een methode voor de rijkeren (en wederom de drukkers - nu de film/muziekindustrie) om hun belangen veilig te stellen. Je ziet copyright wetten ook pas opkomen als landen hun economie ontwikkelen en er een rijke elite ontstaat met belangen in deze.

[Verwijderd]

Innovatie gaat toch het hardste in landen met goede bescherming van IP rechten. Vooral ook omdat alle investeringen in research en/of aankopen van IP rechten in die landen plaatsvinden.

[Verwijderd]

Hmmm, wie was de eerste met een big data api? die kunnen nu ontzettend binnen lopen (aangezien dat de nieuwe hippe term is op de werkvloer, en "iedereen" het opeens doet)

[Gurd]

Ook erg is dat er voor de niet digitale wereld er al jurisprudentie is op dit vlak wat wel werkt.

Je mag lego-compatibel blokjes maken die samenwerken met bestaande legoblokken zolang het ontwerp van het aansluit-gedeelte niet hetzelfde is als de originele lego blokken.

Maar ja... als je 't zou willen proberen te vertalen naar software. Moet je dan andere interface namen bedenken met een refactoring tool of volstaat het toevoegen van nieuwe optionele parameters?

[Tsenre]

Wat een ramp, deze zaak is veel groter dan Oracle vs Google.

Het gaat om de vraag of een API onder copyright valt. Je mag nu dus geen alternatieve implementaties meer maken zonder (te betalen voor) toestemming.

Een API is de interface waarmee programma's met elkaar praten. Een API vertelt precies welke functies een programma heeft en hoe je die moet gebruiken. Als een programmeur een nieuw stuk code schrijft dat moet samenwerken met een ander stuk code dan leest hij in de API hoe dat moet.

Als een auto een API zou hebben dan zouden daar dingen in staan als:
Stuurwiel ( X richting, Y hoek): Draai aan het stuurwiel om de voorwielen Y graden te draaien in richting X.
Ruitenwisser (aan/uit): Gebruik de knop "ruitenwisser" om de ruitenwisser aan of uit te zetten. Als de knop op "aan" staat gaat de ruitenwisser bewegen.

Als je een bestaand stuk software wil vervangen door iets nieuws dan zorg je dat de nieuwe software dezelfde API heeft als de oude software. Zo kun je onderdelen vervangen zonder dat de rest van het systeem dat merkt.

Een voorbeeld is dat je meerdere webbrowser op je computer kan installeren en met een simpel knopje kan kiezen welke browser er standaard gebruikt moet worden. Omdat alle programma's die de standaard browser willen starten dat via dezelfde API doen hoeven de programma's niet te weten welke browser jij hebt.

Je mag nu dus niet meer zomaar een stuk software maken dat als drop-in replacement voor een ander stuk software kan dienen omdat het dezelfde API gebruikt. Fabrikanten gaan daar natuurlijk niet aan meewerken om het hun concurrenten zo moeilijk mogelijk te maken, zoals Oracle hier laat zien.

De volgende vraag is of je als programmeur wel gebruik mag maken van een API zonder explicite toestemming.

Maar als ik dit goed lees: is een API enigszins vergelijkbaar met een instructie boekje.

en is (vind ik) het interessant om te weten of JAVA de eerste was met "API's" (patent)
of
zijn de bewuste 37 vervangen/gebruikte API's beschermt (copyright ???)
en zijn ze niet bewust geschreven om te kunnen vervangen?

Ik mag ook andere banden onder mijn auto zetten als de door de fabriek geleverde.

[CAPSLOCK2000]

Een API is inderdaad een instructieboekje. Het wordt ook wel gezien als een contract waarin staat wat er mogelijk is en hoe dat werkt.

Anderen in deze thread hebben al vergelijkingen gemaakt met waar je de ophangpunten voor je motor in een auto maakt of hoe welke maten een schroefje en een moertje moeten hebben zodat ze samen kunnen werken.

JAVA was niet de eerste met een API, alle programmeertalen gebruiken API's. API's zijn niet geschreven om te worden vervangen. Een API is een stel afspraken, die afspraken moeten hetzelfde blijven. De uitwerking van de code achter zo'n API kan wel verschillen. Denk aan de besturing van je auto. In de API staat dat je aan het stuur kan draaien en hoe de pedalen werken. Wat er onder de motorklep gebeurt verschilt van auto tot auto maar je bestuurt ze allemaal op dezelfde manier.

Een API kun je ook zien als een stuk gespecialiseerd gereedschap voor een programmeur. Zo kan er bv een API zijn om foto te maken of om een lokatie op een landkaart te laten zien of om een lijstje telefoonnumers te sorteren.

De ruzie tussen Oracle en Google gaat om dat Google delen van een API heeft gebruikt die voor Java is ontworpen. Alsof de ene autofabrikant stukken van het dashboard van een andere fabrikant heeft overgenomen. Voor de programmeurs is dat makkelijk, die kunnen hun kennis van het ene systeem mee nemen naar het andere systeem.
De vraag was of zo'n ontwerp eigenlijk wel onder copyright valt en of je zo'n API mag hergebruiken. De eerste vraag is nu beantwoord, ja, een API valt onder copyright. Het is wel nog mogelijk dat de rechter nog gaat besluiten dat je ondanks het copyright toch zo'n API mag hergebruiken onder de 'fair use' clausule. (Let op, dat is een Amerikaans concept dat we in Nederland niet hebben).

[Tsenre]

thx, maakt het duidelijker voor me

[Verwijderd]

Lekker dan.

Dus afgaand op de uitkomst van dit hele gebeuren, kan dus (bijvoorbeeld) de maker van C de maker van C++ of C# aanklagen omdat er functie namen overeen zouden komen?

Kom op echt, ga niet de hele tijd een nieuw strijdveld zoeken, en veeg die shit van de tafel zou ik zeggen, dit toont maar weer aan wat voor een ontzettend steenkolen-rechtsbesef ze in Amerika hebben, ga je schamen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:30]

[ronaldmathies]

Nee want de makers van c / c++ hebben de api vrijgegeven voor anderen om te gebruiken. Het is dan ook een standaard. Dat is bij java niet het geval. Je mag een implementatie maken met dezelfde api maar dan moet ht compatible zijn. En dat is Android niet.

[Verwijderd]

Ah, daar had ik even niet bij stil gestaan, dat C open is en Java niet (of een stuk minder)
Maar dan nog blijft m'n punt van functie namen redelijk overeind.

Er word de suggestie gewekt dat omdat die 37 namen overeen komen dat het dus maar een schamteloze kopie van Oracle's techniek is, maar blijft het nog steeds een feit dat
1] Google Android graag op Java wou laten lijken, maar het toch echt zelf heeft geschreven
2] Functie/methode namen zijn over het algemeen nou eenmaal standaard, welke taal dan ook, alles kent wel dingen als arrays, ints, print, for, while, nou ja je snapt het wel, alles komt dus redelijk overeen tussen de verschillende talen.

Als jij of ik nou morgen een taal schrijft, en we hebben een array nodig, gaan we dat toch geen vouwfietsen noemen? snapt niemand dat het arrays zijn. Nou is dit voorbeeld natuurlijk een beetje kort door de bocht en het gaat in het Java <-> Android verhaal wel om wat specifiekere dingen, maar uiteindelijk, blijf ik erbij, veeg die hele zaak van tafel, het is ondertussen al bekend dat Google de code lekker zelf heeft geschreven, dus het is nu gewoon azijnzeiken over functie/methode namen, en daar verdoen we alleen maar iedereen zn tijd mee.

[ronaldmathies]

Het is niet dat 37 namen overeenkomen maar 37 API's. Dat is heel wat meer. Een API package is bijvoorbeeld:

http://docs.oracle.com/ja...a/io/package-summary.html

Een overzicht van packages kan je hier vinden:

http://docs.oracle.com/ja...api/overview-summary.html

Ze hebben dus letterlijk, 22% van deze lijst plat overgenomen. Dat is heel wat meer dan 37 naampjes. je hebt het over duizenden naampjes die ze hebben overgenomen inclusief logische structuur die erbij hoort.

Het gaat niet om simpele dingen als primitives (int, double, boolean etc..) maar ook om de structuren die er gelegd zijn. Waardoor alles een logische samenhang heeft. Dat is veel belangrijker dan wat basis naampjes.

[Niemand_Anders]

Het gaat niet om de taal, maar om de API toolkit (libraries) waarvan Google de naamgeving heeft behouden. Zoals ze zelf zeggen om compatible te blijven met Java.

Ik mag ook niet zomaar een Harry Potter boek schrijven zonder de namen en de locaties te veranderen. Uiteraard probeert Google het hier algemener te trekken, maar juridisch gezien is het gewoon een copyright schending. Het enige wat Google hier verliest is een miljard dollar, want Oracle heeft het gebruikt van de API niet verboden. Het wil alleen een vergoeding voor het gebruik ervan..

[Verwijderd]

Een API is functioneel en de namen moeten ergens op slaan, dat is echt heel wat anders dan verzonnen plaatsen. Jou logica volgend zou het voldoende zijn om alle API calls te prefixen met "google" en dan is er geen schending. En dat verschil zou een miljard vergoeding waard zijn.

Even helder nadenken en ziet dat je argumentatie nergens op slaat.

[beantherio]

Het enige wat Google hier verliest is een miljard dollar, want Oracle heeft het gebruikt van de API niet verboden. Het wil alleen een vergoeding voor het gebruik ervan..

Het gaat niet om het gebruik van een API. Het gaat over de naamgeving in een API.

[GewoonWatSpulle]

Microsoft heeft dit in het verleden ook geprobeerd en toen ook op donder gekregen waarop Microsoft's Java Virtual Machine verleden tijd werd en er verder werd gegaan met .NET C# is eigenlijk wat Microsoft met Java wilde doen.

[elmuerte]

Dat klopt niet wat je zegt. Microsoft's JRE implementeerde een aantal Java dingen niet goed, en dan verschillende non-standaard toevoegingen. Resultaat dat Java programma's niet perse uitwisselbaar waten tussen verschillende JREs. Dit was een schending van het contract tussen Microsoft en Sun, en mocht Microsoft het ook geen Java noemen. Microsoft was het daar niet mee eens, en er volgde een rechtszaak.
.Net is niet wad MS met Java wou doen. .net was all in ontwikkeling. De MS JRE was wel zo opgezet om mensen makkelijker over te laten gaan naar de .net walled garden.

Google noemt Dalvik geen Java. Ook al is de primaire source input Java, de runtime en byte code zijn dat niet.

[ronaldmathies]

Tja, 37 van de 166 api packages qua naamgeving overnemen is ook gewoon stom. Je hebt het over 22% van de klasse / methode namen die in java voorkomen.

Ondertussen is Android volledig niet compatible met java. Je wilt dus over de api naamgeving van een ander ontwikkelaars aan je binden. Je hebt dus een commercieel voordeel hierbij. Vindt het dan ook wel terecht.

[Superstoned]

Onzin, echt. Ik zie een schroefgat en maak een schroef die past. Heb ik iets illegaals gedaan? Nee, maar dat is wat Google doet: functionaliteit aanbieden die applicaties verwachten. Net als je wielen maakt die op een bepaalde fiets passen, banden op een auto... Compatibiliteit kun je niet illegaal maken, dat zou idioot zijn.

[Verwijderd]

Ik kan ook vergelijkingen maken. Ik ontwerp een auto met moter en versnellingsbak en Google bouwt een andere auto maar kopieert wel mijn motor en versnellingsbak.
Letterlijk kopiëren van een API kun je prima illegaal maken want je kunt dan nog altijd een eigen API maken die gewoon dezelfde mogelijkheden biedt.

[Rutix]

Behalve dan dat ze de inside van de motor en versnellingsbak niet kopieren maar alleen de bevestigingspunten zodat tools die op de jou ontworpen motor en versnellingsbak ook passen op de motor en versnellingsbak van Google. Ik vind het sowieso onzin. Functie horen beschrijvend te zijn, op een gegeven moment heb je alle mogelijkheden om bepaalde logica te beschrijven in 1,2 woorden wel gehad en wat dan? Moet je dan alles maar prefixen met je vendor naam ofzo?

[uiltje]

Ja hallo, nou doe je net alsof het alleen om een paar naampjes gaat. Het gaat om de complete packages inclusief alle classes en alle publieke / protected methoden, argumenten, excepties etc.. Dat komt overeen met een complete blue-print van de belangrijkste Java packages uit de API. De meeste business logic die ik schrijf (nou ja, voor Java 6 dan) kan ik zonder te knipperen met mijn ogen voor Android compileren en gebruiken.

Zelf ben ik ook niet altijd zo'n sterk voorstander van Oracle's manier van handelen. De manier waarop Apache is behandeld (de code die nu voor Android wordt gebruikt) lusten de honden ook geen brood van. Maar te suggereren dat er geen andere mogelijkheden zijn is complete lariekoek. Vraag 4 verschillende programmeurs een API ergens voor te schrijven en je krijgt 4 compleet verschillende API's. Zeker als het om de functionaliteit van 37 packages gaat.

Het feit dat Android op Java 6 compatibiliteit is blijven hangen is ook niet goed voor de Java taal.

[Superstoned]

Dan nog. De logica, de implementatie is niet gekopieerd. Er is gewoon geen copyright zaak want er is niets gekopieerd...

[Verwijderd]

De manier waarop de API's gedefinieerd zijn bepaald ook veel van de logica. En dat is wel degelijk volledig gekopieerd.

[Superstoned]

Sure, er zit wat logica in, maar dat betekend niet dat het waardevol is... Je moet het hetzelfde doen wegens interoperability, zelfs als de api dom is of fouten heeft. Een nieuwe api bouwen is zo extreem moeilijk niet dus het gaat hier niet om dat Google iets heeft gekopieert om gebruik te maken van de tijd en energie die Oracle er in heeft gestopt (zoals normaal bij een copyright overtreding het geval is - je kopieert iets om werk te besparen) maar er is iets overgenomen met als doel interoperability. Oracle mag dat niet verbieden - als je interoperability gaat verbieden met copyright krijg je idiote dingen: ik kan een copyright hebben op de afstand tussen twee moertjes waarmee ik iets in een auto verbind zodat jij geen vervangend onderdeel mag maken? Dat zou enorm slecht zijn voor consumenten, de markt economie, alles...

[Rutix]

Er zijn maar 37 van de 166 packages gedaan. En als ik even vergelijk met C# komen heel veel namen gewoon overeen omdat het gewoon logisch is. Je gaat toch niet een exception moeilijker noemen alleen maar omdat het dan iets anders eruit ziet?

Ik snap het punt maar ik vind dit een heel gevaarlijke uitspraak. Als dit een precendent schept zou je het zelfs kunnen trekken naar kleinere "compatibility" redenen van andere kleinere api's.

[Reactie gewijzigd door Rutix op 23 juli 2024 00:30]

[Durandal]

Google heeft de motor niet gekopieerd, maar slechts de gaatjes van de motorophanging op dezelfde plaats geboord.

[ronaldmathies]

Nee google heeft een deel van de blauwdruk van de motor vekopieerd en daarmee zelf een motor gemaakt. Dat is een logischere vergelijking.

[Superstoned]

Nee, dat zou het geval zijn als Google dit had gedaan om tijd en werk te besparen. Maar dat is niet zo: dit is uitsluitend gedaan om interoperability mogelijk te maken. Net als die afstand tussen de moertjes: het kost zelfs extra tijd het precies hetzelfde te doen! Zeker als je zou kunnen leren van de fouten in de Oracle API en het beter doen - dat hebben ze niet gedaan. Duidelijk dus dat het motief interoperability was en als je dat illegaal zou maken onder kopierecht dan staat echt alles op zijn kop.

[ronaldmathies]

Welke interoperability? Dit zou betekenen dat java op Android draait en Android code op een JVM. Een android applicatie draait niet binnen een JVM. Ze hebben dit puur uit economisch oogpunt gedaan, op deze manier komden mensen makkelijker met de Android SDK aan de gang. De enige die hier baat bij heeft is Google. En dat zal de reden zijn van deze rechtzaak. Je mag prima de API hergebruiken, mits het gecompileerde resultaat binnen een JVM draait. Dit laatste gebeurt al zat, IBM heeft zijn eigen JDK, Weblogic had zijn eigen JDK Apache had er een.

[Reactie gewijzigd door ronaldmathies op 23 juli 2024 00:30]

[Superstoned]

op deze manier komden mensen makkelijker met de Android SDK aan de gang

Dat noem ik dus toch interoperabiliteit, niet 'het besparen van werk voor Google'.

Ik heb het gisteren nog in een ander comment geschreven: doe eens een stapje terug en denk aan waar copyright voor is.

Jij stopt veel werk in het schrijven van een boek of maken van muziek en iemand kopieert dat schaamteloos. Dat scheelt die ander werk, ten koste van jouw bloed, zweet en tranen. We hebben copyright om jouw te 'betalen' voor je inspanning. Correct?

Maar copyright zou interoperabiliteit niet mogen beperken. Als ik copyright kon gebruiken om de afstand tussen wat boutjes en moertjes te beschermen zodat jij geen onderdeel kon maken wat je in mijn wasmachiene kunt stoppen als vervanging van mijn origineel - dan is het hek van de dam. Nog even en elke mogelijke afstand tussen boutjes en moertjes is gecopyrighted en - nu ja, ik hoef dit niet uit te leggen, toch? Daar is copyright niet voor. Eens?

Nu is de vraag: heeft Google de API overgenomen om werk te besparen (dus is copyright geldig en zijn ze fout) of hebben ze het gedaan wegens interoperabiliteit?

Dit is niet moeilijk te beantwoorden. Vraag jezelf af: de engineers van Google die de API moesten bouwen, was hun requirement: "bouw de beste Android API" of was hun requirement "maak iets compattible met Java"? Kun je je voorstellen dat de engineers de Java API bekeken en dachten: "Goh, dit is absoluut de BESTE API in de hele wereld, ik kan hier niet 1 functie aan verbeteren. Ik moet de BESTE API voor JAVA maken en - dit is hem, helemaal!". Nooit natuurlijk! Als ze de beste API hadden willen maken (en dus de JAVA API zouden bekijken) hadden ze wel wijzigingen aangebracht. En dan zou Oracle ze niet aan kunnen klagen, ook al hadden ze dan daadwerkelijk naar de JAVA API gekeken, en, om werk en moeite te besparen, dingen overgenomen (!!). Maar dat is niet gebeurt: ze hebben de API overgenomen ONDANKS dat dat extra werk is (alle fouten en sub-optimale API dingetjes ook overnemen!) om interoperabiliteit te garanderen.

En dat kun je niet illegaal maken want dan is het hek van de dam.

Google moet dit dus winnen, of we kunnen 100x meer gaan betalen voor al onze vervangbare onderdelen...

[scsirob]

Tja, 37 van de 166 api packages qua naamgeving overnemen is ook gewoon stom. Je hebt het over 22% van de klasse / methode namen die in java voorkomen.

So what. Java is een taal. Een geschreven methode om procedures te beschrijven. Het is van de zotte dat je het gebruiksrecht op een taal, op expressie van ideeen in een bepaalde taal tot eigendom kan claimen. Copyright is volslagen doorgeschoten, en dit is er een ultiem bewijs van.

[mashell]

Het is van de zotte dat je het gebruiksrecht op een taal, op expressie van ideeen in een bepaalde taal tot eigendom kan claimen.

Nee. Java is een taal van Sun/Oracle. Beschreven in een "boek". En net als op het nieuwe boek van Dan Brown kan ook het Java boek copyright op gelden. Daar mag je dan geen hele stukken van overnemen.
Het copyright is helemaal niet doorgeschoten, de respectloze omgang er meer van downloaders en multinationals als Google is doorgeschoten.

[thunder7]

Wat is het toch zonde dat Groklaw gestopt is. Daar had ik dit nu graag nagelezen...

[letatcest]

Met enigszins misschien wat bias, is dit ook interessante achtergrondinfo: http://www.fosspatents.co...droid-java-copyright.html

[servies]

Enigszins??????
Ben je betoeterd???
Die gast (ik ga z'n naam niet noemen) staat op de loonlijst van Oracle...

[WhatsappHack]

Dit.
Van FM wil je echt niets aannemen over deze zaak.

Die staat niet enkel op de loonlijst van Oracle wat een belangenverstrengeling is, maar heeft voor eigen software waar ie aan werkt ook een model bedacht waarbij Google's ideetjes enorme roet in 't eten gooien.

Hij zegt wel dat ie objectief is, maar ondertussen...

Erg jammer, want in z'n begindagen toen ie nog neutraal op IP zaken zat te commenten was het echt een onuitputtelijke bron van bizar boeiende informatie; zoals de rechtszaken Nokia v Apple en Apple v HTC, wat je daar allemaal naar boven kreeg: prachtig.

... Nu heeft ie helaas geld geroken en zijn de principes pleite.
Niet perse iets mis mee hoor, principes zijn leuk en aardig; maar een zeer goed gevulde portemonnee in ruil voor wat marketing is erg makkelijk geld verdienen. Can't really blame him.

[terje7601]

Dit is het advies dat de Solicitor General vorige maand aan de Supreme Court gegeven heeft, en dat de Supreme Court nu dus opgevolgd heeft:
http://computemagazine.co...licitor-General-Brief.pdf

Ik raad iedereen, en de plaatselijke "Politiek en recht" experts in het bijzonder, aan om dit eens door te lezen, want de hoeveelheid onzin die ik hier al gelezen heb is echt ongelooflijk.

[letatcest]

Dank. Heb overigens die fosspatents niet gebruikt @WhatsappHack en @servies

[Rafe]

Eens. Ik ben wel benieuwd hoe dit alles te maken heeft met de al lang bestaande OpenJDK (GPL).

[Zenety]

Het proces wordt hiermee weer verplaatst naar een federaal gerechtshof in San Francisco.

Dus het proces zelf loopt nog wel maar dit keer bij een ander gerechtshof? Maakt lijkt mij voor Google niet echt veel uit?

[voske]

Het gerechtshof (Federal Circuit Court of Appeals) heeft beslist dat de zaak op één punt wordt teruggewezen naar de rechtbank (het District Court). Dat betreft het "fair use" argument van Google. Nu het Supreme Court de beslissing van het gerechtshof in stand heeft gelaten, kan dit punt behandeld gaan worden door de rechtbank.

[atillav]

Wat bij mij direct opkwam was onze vrienden van MS die praktisch gehele Xlib API's hebben gejat en ipv van X er MS voorgezet. De vraag rijst natuurlijk of een generiek framework wat een OS (Android), Windowing systeem in feite is, nu bijdraagt aan copyright. In ieder OS en Windowing systeem zal gigantisch veel overlap zitten, ook al zou het van scratch worden opgetekend. Veel mechanismen zijn ontleend aan banale wiskundige, algoritmische vanzelfsprekendheden. Het wordt dan heel moeilijk om een nieuw OS of iets te schrijven, omdat iemand de eerste was. En onze vrienden van Oracle hebben Java ook niet uitgevonden. Dat waren de overgenomen vrienden van Sun. Java was echt bedoeld als Open Source, maar helaas heeft Oracle dat vreemde (commerciële) ideeën over. Het is niet voor niets dat MariaDB is ontstaan, omdat ze hetzelfde met MySQL hebben gedaan.

[Verwijderd]

Als je de namen van API componenten veranderd zodat de libraries niet meer compatibel zijn is het copyrights verhaal al deels de deur uit. (tenzij je verder de code letterlijk kopieert)

[Belgar]

Je moet de hoogte van de schadevergoeding ook met een korreltje zout nemen. De genoemde 1 miljard is toegewezen door leken. Er is na die uitspraak toen al gesteld door een rechter dat de eigenlijke schade zoals die toegewezen zou worden door een federaal hof waarschijnlijk uit zal komen op 20-40 mln.

De stap naar het hooggerechtshof ging over de vraag of je uberhaubt copyright mag eisen op werk wat je zelf publiekelijk aanhoud. Het enige wat er nu is gebeurt is dat het hooggerechtshof geen reden ziet om uitzondering te maken op de geldende wetten.

Het gaat nu gewoon naar een federaal hof en daar zal waarschijnlijk een veel en veel kleiner bedrag uitkomen

[voske]

Die 1 miljard betreft de eis. Er is nog geen schadevergoeding vastgesteld door een jury. Dat zal dus nog moeten gebeuren.
Wel zijn Oracle en Google op een heel klein punt een schadevergoeding van $ 0 overeengekomen. Zie http://www.groklaw.net/pdf3/OraGoogle-1210.pdf

[TheMak]

Ik vind het ook wel terecht dat je niet zomaar een API kan overnemen. Volgens mij is het moeilijkste van programmeren: een set interfaces/objecten definiëren. Als je die hebt, dan volgt de rest vanzelf. De analogie met schroef en schroefgat klopt deels, dit omdat je op schroeven een patent zou kunnen claimen als je de eerste bent.

[Soldaatje]

Ik vind het ook wel een soort van terecht, in het begin hebben ze het zo gespeeld omdat Google geen licentiegelden wou betalen voor Java, daar plukken ze nu mooi de vruchten van.

[mbb]

Ja, da's een goeie ' investering' geweest in Sun door Oracle; altijd roepen dat Java meer open moet worden.
wachten totdat Google afhankelijk genoeg is van java/Dalvik om niet te switchen, dan concurrent Sun opkopen, een groot deel van het bedrijf sluiten/vernietigen, en vervolgens zeggen dat de investering alleen bedoelt was voor de patenten op Java, zodat bijna het hele investeringsbedrag teruggevangen kan worden.
en dan verliezen op alle patenten, maar winnen op de copyright op een fractie (API's voor interoperabiliteit) van de code...
... en dat omdat een politicus een hoger beroep blokkeerd

Dat zijn het soort vruchten waar de wereld beter van wordt...

[Reactie gewijzigd door mbb op 23 juli 2024 00:30]

[maevian]

Dat is gewoon kapitalisme, bedrijven zijn er niet met als doel om de wereld een betere plaats te maken

[nullbyte]

3 billion devices run Java. Dit zouden er vast een hoop minder zijn als google niet zo creatief met andermans werk was geweest

[uiltje]

Nee, die aantallen worden simpelweg gehaald door het aantal smart cards en SIM kaarten met Java Card die in het veld zijn. Elk van die chipjes is een micro Java Card VM. Verder heb je nog de Blue ray spelers en andere consumenten-electronica, de Java enabled phones (zonder Android) en natuurlijk een hoop PC's en servers. Maar die laatste zijn dus flink in de minderheid.

Die 3 miljard staat er overigens al een hele tijd, misschien wel voor dat Android echt populair werd. Android hebben ze echt niet meegeteld, da's volgens Oracle / Sun geen Java.