Hooggerechtshof VS: Googles gebruik van Java-code voor Android was fair use

Het Amerikaanse Hooggerechtshof heeft Google gelijk gegeven in een ruim tien jaar durende rechtszaak die was aangespannen door Oracle. Dit laatste bedrijf claimde dat Google onrechtmatig Java-code had gekopieerd voor Android, maar hier gingen de rechters niet in mee.

De rechters zeggen in hun oordeel dat Googles gebruik van de code rechtmatig was, vanwege vier redenen. De belangrijkste reden is dat de overgenomen Java SE-code voornamelijk draaide rondom method calls, waarmee ontwikkelaars andere, eerder geschreven code kunnen oproepen. Die method calls worden dus niet gebruikt om de computer zelf nieuwe berekeningen te laten uitvoeren. De code heeft daardoor weinig waarde voor de consument die Android zou gebruiken. In plaats daarvan heeft de code volgens de rechters vooral waarde voor de ontwikkelaar die tijd heeft geïnvesteerd om die method calls te leren. Mede daardoor valt de overgenomen code onder het gebruik van fair use, stellen de rechters.

Daarnaast gebruikte Google de Java-code om nieuwe producten te kunnen ontwikkelen, wat volgens de rechters een creatief proces is. Het doel van copyrightrecht is volgens de rechters immers niet om de makers van iets waar copyright op rust te belonen, maar juist om creativiteit te voeden.

Het derde punt is dat Google slechts een beperkt deel van de Java-code gebruikte. De 11.500 regels aan overgenomen code waren onderdeel van 2,86 miljoen regels aan code; Google gebruikte dus 'maar' 0,4 procent van Java SE. Daarbij was het volgens het oordeel moeilijk geweest om Java-ontwikkelaars aan te trekken zonder die code over te nemen, vanwege de praktische functionaliteit van de code.

Tot slot heeft de overname van de code voor Oracle niet geleid tot verlies van omzet of verlies van potentiële markten. Noch Oracle of Sun hadden volgens de rechters grote kans op succes gehad als ze de smartphonemarkt hadden betreden. Daardoor concurreerde de Android-software niet met Java SE en heeft Oracle dus geen financiële schade geleden door Googles gebruik van de code.

Met het oordeel van het Hooggerechtshof is een eerder oordeel van een lagere rechtbank teruggedraaid. In 2018 oordeelde een rechter in hoger beroep dat Googles gebruik van de Java-code geen fair use was. Deze rechter vond dat het gebruik van Google niet niet-commercieel was en oordeelde dat Google hier 42 miljard omzet mee had verdiend. Oracle zei eerder recht te hebben op een schadevergoeding van 8,8 miljard dollar. De rechtszaak begon in 2010, kort nadat Oracle Java-maker Sun Microsystems overnam.

Google wilde aanvankelijk van Sun Microsystems een licentie voor het Java SE-platform kopen, maar deze gesprekken liepen stuk door eisen die Sun stelde aan Java-applicaties. Suns beleid was namelijk dat programma's die met het Java SE-platform ontwikkeld waren op meerdere apparaten moesten kunnen werken. Niet alleen op Android-smartphones dus, maar bijvoorbeeld ook op computers en laptops. Google wilde echter dat Android een opensource-platform zou zijn met weinig beperkingen op het gebied van wat ontwikkelaars en gebruikers met Android kunnen doen. Dit interoperabele, multiplatformbeleid van Oracle zou hier tegen ingaan.

Daarom stopten de gesprekken tussen Google en Sun, en besloot Google zelfstandig de Android-platformsoftware te ontwikkelen. Google wilde hierbij dat ontwikkelaars die bekend waren met Java ook met Android konden werken en gebruikte daarom de 11.500 regels code van een Java SE-api.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (101)

Eindelijk is die rechtszaak klaar, en wat mij betreft gelukkig dat Google heeft gewonnen. Dit had namelijk verstrekkende gevolgen kunnen hebben in software-ontwikkelingsland als Oracle had gewonnen.

Oracle is nu niet bepaald een bedrijf wat vriendelijk is voor open source software, en hun wijziging van het licentiemodel van Java van een tijd terug (waarbij je moet betalen als je Oracle's implementatie wil gebruiken voor commerciële doeleinden) is gewoon niet goed voor Java. Het is jammer dat Sun destijds niet is overgenomen door een meer open source vriendelijk bedrijf...

Klopt, het is voor mij de driver geweest om alle nieuwe ontwikkelingen die mijn teams doen niet in Java te doen. En bestaande Java software te laten herschrijven, alle Oracle afhankelijkheden hebben we er uit gehaald. En als dat niet kon, is dat stuk in een andere taal herschreven.

Dit was ook de driver voor mij om te besluiten om alle databases van het Oracle platform af te halen, etc.

Het gedrag van Oracle is een te groot risico om nog te rechtvaardigen dat ze essentiële onderdelen van de IT infrastructuur of software stack leveren of beheren.

[Reactie gewijzigd door djwice op 6 april 2021 09:25]

Volgens mij is het kiezen van een andere Java Runtime/Development Kit voldoende. Je had kunnen kiezen uit:

• Adopt OpenJDK
• Amazon Corretto
• Azul Zulu
• Bellsoft Liberica
• SAP SapMachine
• RedHat OpenJDK
• OJDKBuild

Niet alle bovengenoemde JDK/JRE's zullen voor jou geschikt zijn, maar het is niet zo dat er naast Oracle's JDK/JRE helemaal niks meer is. Er zijn genoeg vendors in dat gat gesprongen om een oplossing te kunnen vinden.

Bedoel je serieus dat je al je software in een andere taal hebt gebouwd omdat het gedrag van Oracle je niet bevalt? Hoe doe je dat dan wanneer je 100 manjaren in een applicatie hebt zitten?
Of bedoel je dat je naar OpenJDK bent gemigreerd?

Volgens mij is Oracle zich er al jaren van bewust dat ze hun lock-in al jaren kwijtraken. Daarom zetten ze nu vol in op cloud. (door bijvoorbeeld de gebruiksvoorwaarden voor een 'on premise' database aan te passen waardoor je of enorm in de buidel moet tasten of naar de cloud moet als migreren geen optie is)

Letterlijk al het nieuwe niet meer in Java en alle Oracle dependances er uit, van applicatie servers, database clusters tot aan inderdaad Java libraries.

We kwamen er ook achter dat die miljoenen regels code niet altijd geschreven waren om gebruik te maken van multi threat en streaming verwerking.
Gevolg was dat we met de oude code veel meer cpu's nodig hadden en veel meer geheugen.

Het bespaard ons letterlijk miljoenen per jaar. Al vanaf het eerste jaar dat we begonnen.

Zorg dus dat al je applicaties data als stream verwerken, niet alles eerst inladen tot een groot Java object in het geheugen etc. en gebruik kan maken van parallel executie binnen dezelfde functie. Zorg dat je code niet in een loop wacht of stalt tot de return etc.

Nu start een nieuwe server instance in 5 tot 25ms cold start, dat heb ik Java (spring boot etc) niet vaak zien doen. Langste clean boot die ik gezien heb is 420ms voor een extreem grote applicatie op de kleinste instance type. Dat is incl. hardware provisioning.

[Reactie gewijzigd door djwice op 6 april 2021 19:08]

Als die Java code gewoon suboptimaal in elkaar zat had je het ook in Java kunnen refactoren. Eventueel geleidelijk, dus geen grote migratie. OpenJDK er onder en geen Oracle die je lastig komt vallen.

Nu klinkt het een beetje alsof Java niet zou voldoen, terwijl de taal en runtime behoorlijk wat aan boord hebben om parallelle uitvoer en streaming data op een nette manier af te handelen.

Hoewel ik die cold-boot tijd wel netjes vind vraag ik me wel of dat nou een serieuze metric is om applicatie performance mee te meten. Heb nog maar weinig scenario's gezien waarin dat een serieuze bottleneck is (tenzij je echt 'serverless' wil, maar ook dan kan je instances gewoon warm houden)

tenzij je echt 'serverless' wil, ... instances gewoon warm houden

Niet vloeken in de kerk hè!

Tegenwoordig schalen we op tot zo'n 3.000 tot 8.000 instances en binnen een minuut zijn ze allemaal al lang weer uit en staat het resultaat netjes geconsolideerd op s3 (andere toepassing dan die de Java apps verving).

Waarom zou je die warm willen houden?
Je kunt inderdaad bij AWS Lambda capaciteit reserveren voor een paar euro per maand, maar waarom zou je je ontwikkelaars lui willen maken? Ik heb liever efficiënte code, met zo min mogelijk onnodige libs in de package.

We draaien hele 'mijn' omgevingen voor miljoenen klanten voor een paar tientjes per maand. Met extreem snelle responstijd (nano seconden aan de static server kant, enkele tientallen milliseconden aan de API kant).

[Reactie gewijzigd door djwice op 6 april 2021 22:59]

Je hebt je code laten omschrijven van Java, maar wat ik nog niet heb kunnen opmaken naar welke taal de sources zijn geschreven met de onderbouwing waarom je hebt gekozen voor die taal.

We hebben meerdere stappen in 1x gedaan. We gebruikte Spring op interne servers voor API's en web applicaties en Oracle clusters voor data.

Deze architectuur zijn we vanaf 2015 gaan vervangen door een vertaling van de MEAN-stack naar de AWS cloud native LADA-stack: DynamoDB (mongoDB), AWS API Gateway (ExpressJS), AngularJS, Lambda (NodeJS).

We schrijven OpenAPI (Swagger) plus fakerJS en dat definieert de API en testdata automatisch.

Het was vloeken in de kerk voor veel java-ontwikkelaars. Script taal, etc. en ze waren gewend om de API definitie met de code te genereren i.p.v. andersom.

Nu hebben we per type request een aparte lambda functie. Dus weinig code, dus makkelijk te testen en geen onderlinge afhankelijkheden.

En door de OpenAPI & faker first approach is er al heel vroeg in de ontwikkel fase goed te testen. En heel snel duidelijk of de API past bij het gewenste gebruik.

We hebben automatische tests op de OpenAPI files, m.b.t. input en output validatie, zodat API's well defined zijn en de Edge locatie al op basis daarvan een request kan afwijzen of door laten.

We zijn van een maanden doorlooptijd naar enkele uren gegaan. De data klaarzetten is nu de bottleneck, i.p.v. het ontwerpen, ontwikkelen, testen en deployen van de API.
De data wordt vóór verlading naar DynamoDB getoetst aan de OpenAPI output definitie, zodat we zeker weten dat de data in productie overeen komt met de verwachtte data structuur.

FakerJS zorgt er voor dat we test data hebben in DynamoDB voordat we in productie zijn.

Daarom is een nieuwe API nu heel simpel en ook functioneel goed visualiseer en dus makkelijk met verschillende stakeholders, usability en data experts te ontwikkelen, waar dat voorheen een complexe en zeer technische aangelegenheid was, is dat nu een soort feestje met verschillende expertises samen in een paar uur iets moois maken waar gebruikers blij mee zijn. En de zelfde dag gaat het live.

Dat blijft een kik geven zelfs nu het een paar jaar zo werkt.

Voor veel standaard functies op de website (formulier, data visualisatie, etc) gebruiken we de OpenAPI definitie en een configuratie bestand om de code automatisch te genereren.
Een nieuwe visualisatie wordt dan ook generiek ontworpen, zodat we hem kunnen hergebruiken.

Ik weet het, dit is voor veel mensen nu normaal en inmiddels heel gewoon om het zo te doen. Toen we er mee startte in 2016 om OpenAPI en de in- en output validatie daarvan en de fakerJS data typen de driver te laten zijn voor je interface, database, API en verladingen was dat heel vernieuwend


Voor een aantal dingen gebruiken we inmiddels liever Python, Go-lang of Rust.
En we hebben inmiddels implemtaties die algoritmes kunnen distribueren over duizenden nodes en het resultaat consolideren. Volledig event driven en streaming verwerking van een data. Zo'n run kost vaak slechts enkele centen en verwerkt meerdere terabytes aan data per minuut.

De OpenAPI aanpak zorgt er voor dat de logica niet meer aan de runtime is gekoppeld. We hebben daardoor geen lock-in meer. Niet op taal en niet op platform.
Wat we nu draaien kan op elke cloud provider met een Functions of Container runtime en een NoSQL database.
Een ontwikkelaar wilde dat zeker weten en die heeft in een weekend onze stack draaiende gekregen op IBM cloud (in docker met mongoDB).
Dat geeft mij het vertrouwen dat we de goede keuze hebben gemaakt.
We draaien nu cloud native en serverless omdat het ons veel beheer scheelt (geen os, apps server software etc die we moeten updaten en patchen). Door scheiden per request type is elke api klein met weinig afhankelijkheden, daardoor kunnen we die automatisch updaten en testen als een onderliggende lib update.

[Reactie gewijzigd door djwice op 7 april 2021 09:33]

Samengevat: je bent overgestapt van on-premise monoliths naar een public-cloud serverless architectuur.
Nu geloof ik best dat je hiermee miljoenen bespaart, maar dit heeft toch niets te maken met welke taal je gebruikt(e)? Trouwens, AWS Lambda ondersteunt ook gewoon Java.
En ja, in een serverless architectuur is startup time uiteraard belangrijk, maar tegenwoordig kun je een Java microservice ook starten in minder dan 40ms: https://www.graalvm.org/w...-microservices-frameworks

Hoe moet ik de link die je geeft plaatsen t.o.v. AWS Lambda? Is het code die je in de Java versie van AWS Lambda gooit, of is het een AWS Custom runtime? Hoe zijn die 40ms gemeten? Is dat in een AWS Lamba Java container? En welke memory size is dan gebruikt? Wij gebruiken de kleinste die er is en dat geeft voldoende performance (bij AWS Lambda: hoe meer geheugen, hoe meer vCPU tijd je krijgt).
Of is GraalVM het geen dat AWS gebruikt under hun Lamdba's?

De javanen bij ons hebben een voorkeur voor spring-boot, dat start niet snel in een lambda-container, daarom willen ze hem ook warm houden. Er zijn ook javanen die niet goed om gaan met variabelen, waardoor ze dingen global definiëren, dat is al slechts (cross session data leak), maar het warm houden maakt het niet beter. "vroeger" (2016) hield AWS een Java Lambda 6 uur actief, tegenwoordig zie ik voor NodeJS dat je binnen een paar seconden al een schone container krijgt, ik neem aan dat dit bij Java nu ook zo zal zijn.

En een voorbeeld: onze Edge Lambda's hebben een typische start-up tijd van 5ms en zijn daarna binnen 1 to 5ms klaar met hun taak, dan is een start-up tijd van 40ms nog steeds veel.

Welk java-framework kan een API genereren aan de hand van een OpenAPI definitie? Dan kunnen we de perfomance van de NodeJS lambda en de Java versie vergelijken. Belangrijk voor mij was ook dat de front-end in dezelfde taal geschreven kon worden als de backend, zo kunnen front end en backend ontwikkelaars elkaars code en code style beter waarderen. En is er minder wij-zij en jij doet dit, ik doe dat in het team. En is het niet erg als het ene geautomatiseerd wordt, want dan kunnen ze het andere nog. Mensen maken vreemde bokkesprongen als hun werk grotendeels wordt geautomatiseerd. Dit blijft perspectief bieden, waardoor het hele team achter alles automatiseren blijft staan. En dat leverd enorme kwaliteitsslagen.

[Reactie gewijzigd door djwice op 7 april 2021 18:07]

Tja, Spring Boot starten in een lambda-container slaat dan ook nergens op, als je 't mij vraagt.

En die link was er gewoon om aan te tonen dat Java tegenwoordig ook enorm snel kan starten als dat nodig is. Maar ook hier: dat zijn allemaal microservice frameworks, die veel meer doen dan je in een serverless architectuur nodig hebt.

Ik heb er zelf geen ervaring mee, maar ik kan me moeilijk inbeelden dat, mocht je de standaard AWS Lambda Java APIs (https://docs.aws.amazon.c...atest/dg/lambda-java.html) gebruiken, je een merkbaar verschil zou zien met dezelfde functies in Node.js.

Mijn punt is vooral: je bespaart die miljoenen door de radicale switch in architectuur, niet doordat je van Java naar Node.js bent geswitcht.

De miljoenen besparen we door Oracle uit te faseren, niet door de taal switch.

We hebben voorbeelden waarbij we één Oracle rack konden vervangen door één RedShift node en S3 én daarbij 50% snellere query tijden halen (en de besparing in out-of-pocket loopt in de miljoenen).

Nu ook nog Apache parquet ondersteunt wordt, begrijp je dat Oracle nergens meer een valide business case kan maken.

Kijk dat is dus mede een reden van mijn taal switch, de javanen bleven frameworks kiezen die niet paste bij stop 1 microservice request in 1 container.

We zien het elders ook, daar doen ze het niet in Lambda maar in Docker; een volledige application server van een grote leverancier in een docker container en daar dan 1 java microservice in deployen. Volgens mij zijn er heel goede hele kleine java-servers die die microservice prima kunnen serveren.

Maar goed, java is niet mijn specialisme, dus ik zal wel iets over het hoofd zien.

GraalVM laat o.a. toe om AOT te compilen naar een native executable. En Quarkus (Red Hat) en Helidon (Oracle) zijn 2 microservice frameworks die er ondersteuning voor hebben (Spring is er ook mee bezig, maar ik ben persoonlijk geen Spring fan). Dus je zou bij wijze van experiment eens kunnen vergelijken met Quarkus ( https://quarkus.io/guides/amazon-lambda ) waarbij je o.a. ook een AWS Lambda Custom Runtime kan gebruiken ( https://quarkus.io/guides...bda-custom-native-runtime ). Om een API te genereren is https://github.com/OpenAPITools/openapi-generator voor zover ik weet de gangbare tool (zelf heb ik er geen ervaring mee).
Maar in het typische geval worden Java microservices dus gedeployed in een PaaS/Kubernetes i.p.v. FaaS omgeving.
In ieder geval, voor mij hoef je niet terug te gaan naar Java hoor. Ik was vooral getriggerd door bepaalde uistpraken zoals:

We kwamen er ook achter dat die miljoenen regels code niet altijd geschreven waren om gebruik te maken van multi threat en streaming verwerking.

Aangezien Java sinds dag 1 (1995) multi-threading ondersteunt, en software zoals Apache Kafka/Storm/Flink/Hadoop/... allemaal op de JVM draait.

[...]
Aangezien Java sinds dag 1 (1995) multi-threading ondersteunt, en software zoals Apache Kafka/Storm/Flink/Hadoop/... allemaal op de JVM draait.

Ja, daarom verbaasde het mij zo erg, en daarom moest die code op de schop. Ik heb nog een paar voorbeelden gegeven van XSLT met apply-templates i.p.v. call-template, en laten zien wat het verschil was.
Maar er waren te weinig lichtjes.

Jaren er voor had ik al in java een streaming reader laten maken op en Oracle XML database (lezen als een relational table, niet de hele XML er uit willen hebben!!) die de data al gaf terwijl hij nog aan het lezen was, dat scheelt heel erg veel in response tijd én geheugen gebruik én je hebt veel minder idle resourcs en in BEA een webservice geparalleliseerd, zo danig dat de beheerders ineens zagen dat alle 8 theaths gebruikt werden in plaats van 1 te gelijk (hij kon veel breder schalen 200 kon makkelijk, maar dat hadden de servers toen nog niet). Ze hadden hun systeem nog nooit zo snel berichten uit zien sturen
Tot dan toe zei iedereen altijd dat het BEA cluster traag was en er meer ijzer nodig was... vanaf toen was de focus anders

Dus toen ik hier zag (ander bedrijf) dat data eerst gelezen werd in het geheugen als file, dan naar een object omgezet werd, en dat weer 6x naar andere objecten en dan een kopie gemaakt en daar dan bewerking voor bewerking sequentieel op het hele object, tja...

Java is een mooie taal, maar je moet het wel slim gebruiken. Ik ben geen held in java, er zijn veel mensen veel beter dan ik, maar ik heb wacht liever niet te lang op een machine om iets te verwerken

Heel herkenbaar allemaal. Met dat verschil dat ik er in tegenstelling tot jou erg slecht in ben om mensen te overtuigen dat het ook anders en beter kan

Nieuw ergens komen helpt. Sommige vernieuwingen kosten ook mij 3,5 jaar om eindelijk ingevoerd en doorgevoerd te krijgen.

Maar daarna zijn we nog steeds de eerste ter wereld, raar maar waar.

Sommige dingen duren te lang, de serverless virusscanner had ik in 2017 draaien maar wordt nu pas geaccepteerd voor company wide uitrol. Echter is er vorig jaar ook een bedrijf opgestaan die het als pakket biedt. Dus soms is het gewoon lastig om iets goeds (snel, schaalbaar en goedkoop) tijdig te verkopen.

[Reactie gewijzigd door djwice op 9 april 2021 17:54]

Nu start een nieuwe server instance in 5 tot 25ms cold start, dat heb ik Java (spring boot etc) niet vaak zien doen. Langste clean boot die ik gezien heb is 420ms voor een extreem grote applicatie op de kleinste instance type.

Dat is ms van "minutes" of ... ? 7 uur voor die laatste tot hij klaar was om te serveren ?

Miliseconden lijkt mij

ms = milliseconden

De 420ms is voor een Linux container die binnen een Linux container wordt gedraaid. Meestal doen we dat niet, dat scheelt dus ~400ms.

[Reactie gewijzigd door djwice op 7 april 2021 09:36]

Hoe doe je dat dan wanneer je 100 manjaren in een applicatie hebt zitten?

100 manjaren is bij herbouw enkele miljoenen (het gedrag van de applicatie weet je immers al). Als Oracle geld wil zien, dan ben je al snel meer kwijt.
nieuws: 'Nederland dreigde naar de rechter te gaan wegens miljardeneis van Or...
En dan mag je ook jaarlijks blijven betalen en het liefst nog met terugwerkende kracht.

Het gaat me niet over het specifieke aantal jaren, maar meer dat het veel kan zijn. En gegeven dat een beetje ICT-er toch wel een ton kost (meer als het inhuur is) ben je dan al 10 miljoen verder. Voordat je zo'n bedrag uitgeeft neem ik aan dat de kosten/baten wel goed bekeken zijn.
Ook met Microsoft kan je een slepend licentieconflict krijgen en een boete moeten betalen...

Dat hebben wij bij een klant ook gedaan, en de reden was het belachelijk agressief gedrag van Oracle. Het risico om nog Oracle in het applicatie landschap te hebben was simpelweg te groot.

De boel is “simpelweg” van weblogic naar .net gemigreerd

[Reactie gewijzigd door Yalopa op 6 april 2021 11:33]

Oracle; commerciële ratten. Na een achterlijke ervaring met hun heb ik vol ingezet op niet-Oracle gebonden software. En dat heeft de organisatie geen windeieren gelegd.
Ik kan me voorstellen dat dat voor grote platforms lastig en duur kan zijn, maar als je de keuze hebt kies dan voor platformonafhankelijkheid!

Ik ben geen fan van allebei de bedrijven, maar Oracle - en met name Larry Ellison - vind ik erger. Larry kan (naar mijn mening) gewoon niet hebben dat er iemand anders is die rijker is dan hij. Hij was (naar mijn mening) heel lang zo jaloers op Bill Gates, en heeft met Oracle op allerlei fronten Microsoft geprobeerd te frustreren. Zijn modus operandi is o.a. om opensource sofware op te kopen om het voor concurrenten moeilijk te maken... MySQL is ook een voorbeeld hiervan. Het zou mij niet verbazen als het kopen van Sun eigenlijk alleen maar ging om het hebben van Java.

Het ging ook alleen maar om het hebben van Java.
De ontwikkeling werd praktisch stilgelegd en de focus kwam volledig te liggen op het exploiteren van een licentiemodel.

Destijds runde ik met een paar andere devs een eigen bedrijf. We hebben nog contact gehad met Oracle over bepaalde exploits in de runtime. Hun antwoord was dat ze het op de planning hadden staan om over 3 jaar gefixed te hebben.

Dat was voor ons genoeg om Java nooit meer te gebruiken.

Ik moedig initiatieven zoals Kotlin dan ook ten zeerste aan.

Kotlin compileert toch naar Java bytecode en wordt uitgevoerd op een Java runtime? Als er kwetsbaarheden in de runtime zitten, dan moet de runtime gefixed worden of een andere runtime gebruikt worden. Switchen van Java naar Kotlin (of andere taal die naar Java bytecode compileert) gaat dat probleem niet oplossen.

Kotlin kan ook compileren naar JavaScript of native via LLVM.

De shout-out naar Kotlin was echter niet bedoeld als oplossing voor de problemen in de JRE, meer om de stap in de goeie richting om los te breken.

We hebben nog contact gehad met Oracle over bepaalde exploits in de runtime. Hun antwoord was dat ze het op de planning hadden staan om over 3 jaar gefixed te hebben.

Als je zware beschuldigingen uit, verwacht ik dat je ook harde bewijzen hebt, dus: wat zijn de CVE referenties van die "bepaalde exploits" waar je het over hebt? Dan kan ik meteen ook eens nagaan hoe lang het effectief geduurd heeft om ze op te lossen.

En dat ze expliciet "over 3 jaar" gezegd hebben, kan ik trouwens ook niet geloven. Als dit net na de Java 8 release was, en ze geantwoord hebben "we zullen het oplossen in Java 9", dan is je statement in zekere zin nog aannemelijk, maar dan is het duidelijk dat die "bepaalde exploits" helemaal geen exploits waren.

Oracle is nu niet bepaald een bedrijf wat vriendelijk is voor open source software

Ik denk ook niet dat Oracle het meest vriendelijke bedrijf t.o.v. open source is. Maar in dit is het wel een beetje vreemd dit te zeggen. Ze hebben net alles van Java of zelf open source hebben gemaakt (in de vorm van de openjdk (sources), inclusief de commerciële functionaliteit) of de sources hebben gedoneerd (denk hier bijvoorbeeld aan de EE sources aan Jakarta EE)

waarbij je moet betalen als je Oracle's implementatie wil gebruiken voor commerciële doeleinden

Ik vraag mij af waar je hier op doelt, er is eigenlijk geen Oracle implementatie er zijn sources die o.a. Oracle compilen tot binaries en als je de binaries van Oracle gebruikt willen ze hier geld voor zien en krijg je hier support voor terug.

Eindelijk is die rechtszaak klaar, en wat mij betreft gelukkig dat Google heeft gewonnen. Dit had namelijk verstrekkende gevolgen kunnen hebben in software-ontwikkelingsland als Oracle had gewonnen.

Het is jammer dat Sun destijds niet is overgenomen door een meer open source vriendelijk bedrijf...

Met beide stellingen ben ik het 100% eens.

Jammer om te horen dat Oracle met hun verdienmodel Java (deels) ondermijnt.
Ik had namelijk een positiever beeld van Oracle, doordat ze in het verleden hebben geopenbaard hoeveel winst Google maakte met Android. Dat was namelijk tot 2016 zo'n 22 miljard dollar (op 31 miljard omzet, dus >70% winst). Weet je gelijk wat er met onder andere onze privacy betaald wordt: niet alleen de ontwikkeling van apps .

Ik snap deze uitsrpaak niet volledig:

... Het doel van copyrightrecht is volgens de rechters immers niet om de makers van iets waar copyright op rust te belonen, maar juist om creativiteit te voeden. ...

Maar de creativiteit wordt juist gevoed doordat wat gecreëerd wordt, beloond wordt omdat het beschermd is?

Het oorspronkelijke doel van copyright is inderdaad het bevorderen van creativiteit. Het beschermen/belonen van makers is daar weliswaar een essentieel onderdeel van, maar is niet het doel op zich. Als maximaal belonen van makers het enige doel zou zijn, zou dat in veel gevallen verdere creatieve ontwikkeling in de weg staan. Daarom bevat copyright-wetgeving ook zaken als 'fair use' en beperkingen in de looptijd van copyright. Het gaat erom een balans te vinden tussen de belangen van eerdere makers enerzijds, en de mogelijkheden voor nieuwe makers anderzijds.
De achterliggende gedachte is dat geen enkel idee en geen enkele creatieve uiting volledig op zichzelf staat. Iedereen bouwt voor op hetgene dat andere mensen hebben bedacht. Zoals Isaac Newton al zei "If I have seen further it is by standing on the shoulders of Giants."

Een voorbeeld van hoe copyright creativiteit ook kan frustreren, kun je vinden bij de geschiedenis van de stoommachine. James Watt had (terecht) patenten op een essentiële onderdelen daarvan. Maar iedere volgende uitvinder die daarop wilde voortbouwen en de machine verder wilde verbeteren, kon geen slimmere stoommachine verkopen zonder eerst langs het tolpoortje van James Watt te gaan. Die rekende exorbitante prijzen, en dus kwamen verbeteringen niet van de grond. James Watt zelf had geen enkele prikkel om verder te innoveren, want hij werd toch wel rijk van zijn bestaande patenten.
Pas na het aflopen van het patent van James Watt, raakte de ontwikkeling van de stoommachine weer in een st(r)oomversnelling.

Oracle is helaas een enorme patent trol.

Toen Sun werd opgekocht door Oracle (2010) zaten we vol in de ontwikkeling van Java 8.

De high security vulnerabilities die naar buiten kwamen besloot Oracle pas over 3 jaar te fixen. Dat was ook de doodsteek voor Java in browsers.

Ik ben blij met de uitspraak. Het zou slecht zijn als een patent trol een (gratis) taal kan kopen en kan gaan exploiteren. Oracle is het slechtste wat Java is overkomen. Maar het was nog veel erger geweest als dit nu een enorm lucratieve businessmodel was geworden.

De high security vulnerabilities die naar buiten kwamen besloot Oracle pas over 3 jaar te fixen. Dat was ook de doodsteek voor Java in browsers.

Ik ben niet echt een fan van de remote execution omgeving die de browser van vandaag geworden is maar liever dat dan in de knoet gehouden te worden door de plugins van Adobe en Sun/Oracle.

Oracle is nu niet bepaald een bedrijf wat vriendelijk is voor open source software, en hun wijziging van het licentiemodel van Java van een tijd terug (waarbij je moet betalen als je Oracle's implementatie wil gebruiken voor commerciële doeleinden) is gewoon niet goed voor Java. Het is jammer dat Sun destijds niet is overgenomen door een meer open source vriendelijk bedrijf...

Onwaar: Oracle biedt ook gewoon gratis production-grade JDKs aan op https://jdk.java.net.

Quote van https://jdk.java.net/16/:

This page provides production-ready open-source builds of [...] under the GNU General Public License, version 2, with the Classpath Exception.

Commercial builds of JDK 16 from Oracle, under a non-open-source license, can be found at the Oracle Technology Network.

Om te beginnen gaat het niet om wel of niet "production-grade" (technisch wel of niet geschikt voor productie), maar om de licentie.

Ik heb het nog eens nagekeken. Info is te vinden in de Oracle Java SE Licensing FAQ en deze blogpost geeft ook een goed overzicht.

Oracle biedt nu twee versies aan, hun oude Oracle JDK, en een door Oracle gebouwde versie van OpenJDK.

Vroeger was de Oracle JDK gratis (onder hun "BCL" - Binary Code License). Wat er is veranderd, is dat die Oracle JDK nu alleen nog maar gratis is voor personal use, development etc. en niet meer voor productiedoeleinden. Als je de Oracle JDK wilt gebruiken voor productie dan moet je een Java SE Subscription hebben, waarvoor je moet betalen.

De Oracle OpenJDK build was en blijft gratis en open source, ook voor productiedoeleinden. Volgens Oracle zitten er alleen maar kleine cosmetische verschillen tussen Oracle JDK en OpenJDK.

Dus als bedrijf, als je de Oracle JDK gebruikte, kun je het beste overstappen naar OpenJDK (gebouwd door Oracle, of door één van de andere aanbieders zoals AdoptOpenJDK), of als je support van Oracle wilt, dan kun je Oracle JDK blijven gebruiken maar moet je voor een subscription gaan betalen.

Helemaal akkoord. Alleen begrijp ik niet waarom je dan het volgende zegt:

Dat zeg ik niet. Maar er zijn andere manieren, en naar mijn mening betere manieren, om geld te verdienen met open source. Bijvoorbeeld: Laat het gebruik van Java gratis, en verkoop commerciële support voor bedrijven die dat willen / nodig hebben. Dat is bijvoorbeeld hoe Red Hat het doet met Red Hat Enterprise Linux. Ook Microsoft doet het op die manier met het .NET platform.

Dit is toch precies wat Oracle ook doet? Ze bieden gratis JDKs aan, en verkopen commerciële support voor bedrijven die dat willen/nodig hebben? En juist omdat Oracle zo hard inzet op OpenJDK, is het tegenwoordig triviaal voor elk bedrijf om hun eigen "OpenJDK distributie" te maken. Bovendien heeft Oracle voor alles wat redelijkerwijze kan geopensourced worden, dit ook gedaan, inclusief features zoals JMC/JFR waar je vroeger wel voor moest betalen.

Ja, dat klopt, en wat ik eerder schreef klopt dus niet helemaal... weer wat geleerd

Want al die duizenden manuren die in onderhoud en verbetering van Java gaan zitten (incl. alle vervelende securitytests en tests op obscure platforms waar weinig Open Source contributor trek in heeft, of laat staan de middelen voor heeft) die moeten maar gewoon gratis als een soort gift aan de mensheid worden gedaan?

Dat zeg ik niet. Maar er zijn andere manieren, en naar mijn mening betere manieren, om geld te verdienen met open source. Bijvoorbeeld: Laat het gebruik van Java gratis, en verkoop commerciële support voor bedrijven die dat willen / nodig hebben. Dat is bijvoorbeeld hoe Red Hat het doet met Red Hat Enterprise Linux. Ook Microsoft doet het op die manier met het .NET platform.

Met hoe Oracle het doet, werpen ze een obstakel op de weg waardoor bedrijven minder snel geneigd zullen zijn om voor Java te kiezen.

Het feit dat de OpenJDK en andere alternatieve runtimes bestaan is toch voldoende? Heb je als bedrijf geld over voor die van Oracle ivm support, security patches en wellicht wat extra features prima, en anders draai je toch voor nop op een alternatief? De Java community is springlevend in elk geval dankzij en ondanks Oracle.

Gelukkig zijn er naast Oracle's implementatie ook nog andere aanbieders van Java. En ja, het is goed dat er een bedrijf met geld achter Java zit wat ervoor zorgt dat het zich nog ontwikkelt enz., maar het zou nog beter zijn geweest als dat ook een open source vriendelijk bedrijf was geweest.

Hoewel ik het helemaal eens ben met de conclusie vind ik het argument "Google gebruikte dus 'maar' 0,4 procent van Java SE" wel een vreemde. Het gaat er toch niet om hoeveel andere code ik zelf schrijf in relatieve zin? Dat maakt de "diefstal" (bij gebrek aan een beter woord) niet kleiner denk ik dan.

Het verschil is dat het deel dat is overgenomen een beschrijving van de API is en niet de implementatie.

Zie het als de index van een boek.

Hoofdstuk 1 - file bewerkingen
1.1 openen
1.2 sluiten
etc.etc.

Google heeft een boek uitgebracht met EXACT dezelfde indeling van het originele boek en exact dezelfde paragrafen, maar alle tekst erin is verschillend.

Oracle claimt dat een boek uitbrengen met exact dezelfde indeling een copyright probleem is. Het maken van de indeling van het boek is volgens hen creatief en valt onder copyright. Het hooggerechtshof heeft bepaalt dat het het makkelijk maakt voor mensen om het boek te lezen die bekend zijn met het originele boek en dat de originele makers daar in principe niet onder lijden.

Google zelf vergeleek de rechtzaak met een patent aanvragen op het QWERTY toetsenbord. Chief Justice Roberts vergeleek het met een menu in een restaurant (je mag een menu hebben, maar niet hetzelfde menu als de buurman). Oracle vergeleek het met het maken van een 'short story into a movie' (het tweede kan niet zonder het eerste bestaan).

Die vergelijkingen zijn dus hoogst verdacht, want dienen allemaal een doel en voor mij als leek is het vrijwel onmogelijk om hier de juiste vergelijking aan te houden zonder geweld te doen aan de realiteit.

Bron: het mondeling verweer bij de Supreme Court

[Reactie gewijzigd door Risce op 6 april 2021 09:53]

De kern van het probleem is dat je niet een compatibele API kunt ontwikkelen, zonder dat je quasi identiek bent aan het origineel. De namen van je functies/endpoints, de volgorde/namen en types van de argumenten, en het gedrag zoals beschreven in de documentatie, het type van het resultaat, etc moeten exact hetzelfde zijn. Zoniet, dan kan je even goed je eigen API ontwikkelen.

Dit is de kern van deze rechtzaak. Mag je een API 1:1 nabouwen? Vandaar dat dit zo'n belangrijke rechtzaak is. Het gaat niet over een paar duizend regels code die Google mogelijk onterecht heeft overgenomen. Het gaat over het precedent van bedrijven die monopolie kunnen claimen over APIs die ze ontwikkeld hebben. Dit lijkt vrij niche, maar die soort officieuze API implementaties komen enorm veel voor en werden de laatste tientallen jaren als acceptabel gezien in de industrie.

Als voorbeeld: Amazon heeft voor hun AWS S3 object storage service een API die developers en applicaties kunnen gebruiken. Voor zo ver ik weet hebben letterlijk alle concurrenten buiten Microsoft Azure die API overgenomen om compatibel te zijn. Amazon heeft hier nooit problemen rond gemaakt, want ze vonden het blijkbaar wel oké om de controle te hebben over de standaard API. Moest Oracle deze rechtzaak hebben gewonnen, dan zou Amazon plots de optie hebben om quasi al hun concurrentie meteen buitenspel te zetten. En ook al had de concurrentie nooit die S3 API gebruikt, dan zou het altijd een gigantische effort zijn om weg te migreren van AWS S3 want niemand anders mag software schrijven die hiermee compatibel is. Is dit een situatie die we willen? En dit is maar één voorbeeld waar ik van weet. Er zijn echt eindeloze gevallen te vinden.

Als industrie hadden we besloten dat het overnemen van APIs acceptabel was, omdat het het leven voor iedereen makkelijker maakt. Het heeft geen zin van het wiel constant opnieuw uit te vinden. Net zoals de rechters hier hebben bevonden: door APIs buiten copyright te houden bevorder je juist creativiteit door een hele hoop snelheidsdrempels weg te nemen voor zowel ontwikkelaars als platform bouwers. En voor de originele ontwikkelaar van de API: een API is geen product. Het is alleen maar de "taal" waarmee software met je product interageert. De manier waarop je uitlegt wat je gedaan wilt krijgen. In die zin vind ik de analogie van Justice Roberts nog het beste: de API is niet het menu zelf, maar de interactie van het bestellen via een menu die een voorspelbare indeling heeft. Eisen dat iedereen hun eigen menu structuur en/of bestel interactie gaat verzinnen is gewoon ongewenst en niet productief.

Het blijft natuurlijk een grijze zone van tot welk niveau een idee of zelfs uitwerking van een idee eigendom kunnen zijn. Maar in dit geval was de consensus in de industrie vrij duidelijk, en gelukkig zijn de rechters daarin mee gegaan.

[Reactie gewijzigd door Niosus op 6 april 2021 12:00]

Dat komt omdat dit soort dingen eigenlijk niet onder copyright zou moeten vallen, dus iedere rechter vind een argument uit om een gebrekkige wet op iets toe te passen dat daar niet geschikt voor is. Maar wat wil je ook met dit stel a-technische bejaarden.

In programmeren is een van de doelen als je iets maakt jou product laten samenwerken met andere producten. Daarvoor definieer je interfaces. Die bevatten geen code, het is alleen een "index" bij gebrek aan een beter woord, een definitie wellicht. Als je die definitie niet kunt gebruiken zonder copyright te schenden is samenwerking tussen software van verschillende partijen gewoon niet meer mogelijk.

Tegelijk is het verzinnen van die definitie een origineel werk. Dus oracle probeert via die achterdeur geld los peuteren door de technisch wereld proberen te slopen.

Waarom moet je die rechters zo aanvallen? Zij moeten de wet kennen en interpreteren. Zij moeten niet technisch zijn. Het is aan beide partijen om hun argumenten te geven van hoe zij hun gedrag binnen de wetgeving zien om dan te gaan toetsen wie er gelijk heeft.

Aangezien Oracle het zelf heeft over het schenden van hun auteursrecht moet jij mij trouwens eens zeggen waarom dit niet onder het auteursrecht zou vallen. Alle broncode is beschermd door het auteursrecht en daarop zijn alle argumenten gebasseerd.

En gelukkig is de wetgeving rondom auteursrechten in de VS zo geschreven dat er dus ruimte is voor fair use.

Hoe kun je toetsen wie er gelijk heeft als je de materie niet begrijpt. Je kunt de wet niet toepassen zonder dat. Dat zijn alsof je oordeelt over moord zonder te begrijpen wat dood en geweld inhoud. Zonder de gevolgen van je beslissing te begrijpen is recht niet mogelijk. Dan kun je allen maar kijken welk advocaat je het aardigst en meest overtuigend vind of een pipo neus heeft....

Aangezien Oracle het zelf heeft over het schenden van hun auteursrecht moet jij mij trouwens eens zeggen waarom dit niet onder het auteursrecht zou vallen.

Wat jij daar zegt is dat als Oracle een olifant een muis noemt het een muis moet zijn? Oracle noemt het auteursrechtschending, maar het is aan de rechter (volgens jou nb) om te bepalen of dat terecht is, niet aan oracle.

Ik heb ook de uitleg al gegeven die ik denk dat je vraagt, maar blijkbaar begrijp ook jij die niet. Nogmaals: Oracle noemt het code, maar we hebben het hier over API's. Die I staat voor interfaces. Een interface is geen code, is geen implementatie, het is een definitie. Oracle probeert copyright te claimen op een definitie. En zelfs als dat kan, dan nog zitten ze fout want de API definities van java zijn gebaseerd op de van C en die weer op wat ervoor kwam.

Google heeft nooit (in dit geval) ook maar 1 regel programmacode gekopieerd van Java. Ze hebben hun code alleen dezelfde interface gegeven. Ziet het als dat jij een schoonmaakster hebt. Jij hebt een slot op de deur en jou schoonmaakster heeft een sleutel daarvan. Nu komt ze ook bij mij werken. In plaatst van haar een tweede sleutel te geven maak pas ik mijn slot aan zodat de sleutel die ze al heeft ook er op past. Mijn slot is niet gelijk aan het jouwe, andere materialen, andere technieken, meer en andere sleutel mogelijkheden enz. Maar omdat jou sleutel ook op mijn slot past, claim jij copyright op mijn slot, wat ik zelf aangepast heb op basis van een gedeelde definitie, namelijk de sleutel, die je ook nog eens zelf in handen van een derde partij hebt gegeven. Oracle probeert copyright te claimen op de sleutel en alle sloten waar deze op past. of ze die sloten nou gemaakt hebben of niet, of die sloten nou onafhankelijk zijn ontworpen of niet. Dat gaat gewoon veel te ver. Als dit voorbeeld nog niets duidelijk maar dat weet ik het ook niet meer.

Dat klopt, maar je moet dan ook bedenken dat het hebben van een API niet uniek is. Bovendien is de API van JAVA ook geen volledig origineel werk.

Een groot deel van de namen van functies gebruikt in JAVA zijn exact hetzelfde als in de C++ frameworks. Dat is ook niet toevallig, want dat is gedaan om dezelfde reden dat Google de functieomschrijvingen van JAVA heeft gebruikt: makkelijk maken voor mensen om over te stappen van C++ naar JAVA.

Hetzelfde geldt voor C# van Microsoft dat in principe in dezelfde situatie zit.

Je verwacht dat als een functie "LoadFile" heet, dat je er een file mee kunt laden. Er zijn maar een paar manieren hoe je dat kunt beschrijven. Claimen dat "LoadFile" een unieke uitvinding van jouw is en dat geen enkele andere ontwikkelaar op het idee was gekomen om een functie die een file inlaad "LoadFile" te noemen is maar beperkt verdedigbaar. Copyright is ook niet absoluut. Er zijn "fair use" clausules en er is (denk ik terecht) besloten dat namen van functies die doen wat ze omschrijven in het voordeel is van de gebruiker, zonder veel schade aan de uitvinders.

Dit is een slechte parafrase van het arrest. Er zijn regels broncode overgenomen, maar wel allemaal regels die API definities bevatten. Geen echte functionele code, zeg maar.

De discussie over 0,4 procent is volledig irrelevant, want het gaat niet om omvang maar om creativiteit. Is dit feitjes overtypen, want die functie héét nou eenmaal java.system.out.println(). Of is het jatten van een creatieve uitwerking van Sun destijds dat je een system class hebt met subclass out(put) met daarin een printmethode die we net zo noemen als in C? Als je iets creatiefs overneemt dan schend je auteursrecht, ook al is het maar één regel uit een boek van 40.000.

Het vervelende aan deze uitspraak is dat het Hof zegt dat het fair use is, en niet dat je op een API geen auteursrecht kunt claimen. Want bij fair use zijn er altijd tienduizend argumenten links en tienduizend rechts, dus daar heb je als precedent helemaal niets aan.

Zo werkt de industrie nou eenmaal. Ik denk niet dat de rechters zich eraan werken branden om (mogelijk) auteursrecht te ondergraven. Ze hebben liever dat het per zaak bekeken wordt.
Belangen zijn te groot.

Het vervelende aan deze uitspraak is dat het Hof zegt dat het fair use is, en niet dat je op een API geen auteursrecht kunt claimen.

Inderdaad, ze zeggen hierover zelfs expliciet:

To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

Kortom, "we gaan nu even niet onze handen branden aan dit veel lastigere onderwerp, en doen alleen een uitspraak over dit ene specifieke geval".

Stel, jij hebt een 'open' programmeertaal+libs ontwikkeld, met de API-functies DoeDit000() t/m DoeDit999(), maar jij weigert die te laten porten naar mijn devices, omdat je mijn bedrijf wilt frustreren.

Ik ga vervolgens een eigen programmeertaal+libs ontwikkelen, en gebruik dezelfde API-functienamen DoeDit000() t/m DoeDit999() om het porten van applicaties voor ontwikkelaars makkelijker te maken.

Heb ik 1000 regels van jouw code gestolen?

Deze rechtszaak ging niet over een volledig eigen ontwikkelde API. Google heeft daadwerkelijk 11500 regels code van Oracle gebruikt. Als zij zelf de API volledig hadden geschreven met dezelfde functionele uitwerking (service call doedit000 t/m doedit999) dan was er niks aan de hand.

Wat Google destijds heeft overgenomen is de namen van de functies en hoe ze aangeroepen worden.
Oftewel letterlijk de API.
Daar bestaat die 11500 regels code uit.
En dat was ook waar de rechtszaak uiteindelijk om ging, als Oracle had gewonnen dan was dat de 'doodsteek' voor software ontwikkeling geweest...

En toen google dit deed was Oracle nog geen eens de eigenaar van de code. Die hebben Sun Microsystems overgenomen om er een slaatje uit te slaan.
Sun Microsystems was er niet op tegen wat Google deed.

Google heeft daadwerkelijk 11500 regels code van Oracle gebruikt

Welke regels code zijn dit dan? Ik kan het nergens vinden, alleen maar de melding dat het 11.500 regels zouden moeten zijn.

Dat komt omdat het niet over iets gaat wat een normale programmeur code zou noemen. Het gaat over definities/interfaces. Die dingen die een C programmeur normaal in header files vind.

in principe heeft oracle een functie definitie in java als sum(a, b) voor een functie die a en b bij elkaar optelt. Elke normale programmeer taal heeft zo een definitie en ze heten allemaal sum. Oracle claimed dat sum als naam hun unieke creatieve product is.

Side note, in c kan een header file implementatie bevatten, maar is strik genomen niet de bedoeling en verwaterd deze discussie. Google heeft geen implementatie overgenomen.

Heel veel van de genoemde argumenten klinken inderdaad wat vaag. Als ik een film van Warner Brothers download is dat ook maar een heel klein percentage van hun totale collectie. Als ik er ondertiteling voor schrijf is dat creatief werk.

Een betere vergelijking zou zijn dat je één scène downloadt van de film. (Een stukje van een van de producten van het bedrijf)

Jouw vergelijking zou meer duiden op Oracle DBMS downloaden en daar vervolgens een plug-in voor schrijf, wat ook maar één van de vele stukken software van Oracle is.

Hangt er van af hoe je de ondertitel schrijft. Er zijn voldoende ondertitels die automatisch gegenereerd en vertaald worden.

De creativiteit zit dan in de bouw van de automatiserinslogica niet in de vertaling of de ondertitels zelf.

De vraag kan zelfs gesteld worden of een werk dat ook met automatisering gemaakt kan worden, maar door een mens gemaakt is, nog als creatief gezien kan worden.
Wellicht kan het worden gezien als een werk dat die persoon gemaakt heeft met gebruik van automatismen (aangeleerd gedrag waarvan de verwerking nauwelijks nog kortetermijngeheugen nodig heeft) i.p.v. via een creatief proces (waarbij informatie continu in het kortetermijngeheugen wordt geladen en daar wordt geassocieerd en verbonden).

[Reactie gewijzigd door djwice op 6 april 2021 09:08]

Echter jouw scenario is redelijk gebruikelijk en er zijn op youtube miljoenen filmpjes te vinden met daarin korte clips van films allemaal onder fair use policy.

Die vergelijking gaat niet op. De film zelf is de implementatie achter de API. In dit geval gaat het eerder over de "story beats" als je dat concept kent. Je steelt de film zelf niet, je neemt alleen maar de grote lijnen van het verhaal over. De eerste pitch, als het ware.

Nu je moet echt wel oppassen met het verzinnen van een vergelijkingen hier. APIs zijn echt een vrij uniek concept dat je niet echt ergens anders in de copyright wereld tegenkomt. Het komt nog het meeste overeen met fysieke interfaces tussen objecten in de echte wereld, die soms wel onder patentrecht kunnen vallen. Maar dat moet je dan weer nuanceren omdat APIs een heel stuk abstracter zijn waardoor er soms gewoon maar één zinnige manier van werken is. Hoe zou je bijvoorbeeld een vierkantswortel functie anders gaan definiëren dan een functie die één getal binnen neemt, en een ander getal terug geeft? Je kan eventueel de naam veranderen van "sqrt" naar "squareroot", maar is dat noemenswaardig anders? Dit klinkt natuurlijk als een super onnozel voorbeeld, maar "sqrt" is deel van de "java.lang.Math" module en dus deel van de APIs waarover deze rechtzaak ging.

In het meest absurde geval zou iedereen dus een andere variant van de sqrt functie gaan moeten uitvinden zolang dat er nog copyright rust op de eerste implementatie (wat tegenwoordig dood van de auteur + 70jaar is). Vergeet niet dat het niet om het algoritme voor de berekening van de vierkantswortel zelf gaat, maar puur de beschrijving van hoe je de functie moet oproepen. Natuurlijk in dit geval heeft Oracle de vierkantswortel functie niet uitgevonden en er zijn veel complexere functies waar je wel zinnige alternatieven voor kan verzinnen. Maar waar trek je de lijn?

Zelf een ondertiteling maken voor zo'n film mag ook niet zonder toestemming.

[Reactie gewijzigd door MeMoRy op 6 april 2021 12:37]

Nee, het is meer alsof jij de matrix kijkt en dan ook een film maakt over een virtuele wereld in een computer. Een unieke film met een uniek script. Oracle claimed dat het idee van een virtuele wereld in een computer van hen is. In essentie claimen ze concepten die zo basis zijn dat je nooit meer iets nieuw kunt verbeteren.

Zelf als je het terecht zou vinden, dan geeft je oracle de macht om films over een virtuele wereld in een computer allemaal te verbieden terwijl ze ook niet verplicht zijn hun film te verbeteren of nieuwe te maken. De innovatie zou stil komen te staan.

Het heeft echter betrekking tot de fair use kant van het verhaal.
Google gebruikt dus letterlijk een fractie van en dan is het belangrijk of het om .4% of om 40% gaat bijvoorbeeld.

Ik heb bij het langslopen, één braam geplukt van uw braamstruik, niet de hele struik leeggeplukt en er jam van gemaakt. Meneer de rechter, is het niet wat disproportioneel dat ik hier sta?

Nja het verschil met bramen is dat ik daadwerkelijk minder bramen heb als jij er een pakt, toch? Dat is hier niet echt aan de orde.

Jullie vergelijken allebei appels met peren. Copyright/auteursrechten hebben eigen regels.
Overigens is plukken uit andermans tuin inderdaad niet toegestaan. Wildplukken vaak zelfs niet, of maar heel beperkt

Het doel van copyrightrecht is volgens de rechters immers niet om de makers van iets waar copyright op rust te belonen, maar juist om creativiteit te voeden.

Heeft het Hooggerechtshof hier even en passant alle IP- en patenttrollen in de VS buitenspel gezet?

Dat zal nog niet zo hard lopen, een van de redenen dat de creativiteit gevoed wordt is natuurlijk omdat copyright hebben beloond wordt.
Daarnaast zijn octrooien en copyright twee verschillende zaken.

Zeg dat wel, een octrooi geldt 20 jaar terwijl copyright tot 70 jaar na openbaarmaking (zakelijk) geldt.
Daarom is voor software het copyright ook veel belangrijker.

Enorm ingewikkelde zaak, ik zet hieronder even de spin die Google en Oracle aan deze uitspraak geven:

Google:
The Supreme Court’s clear ruling is a victory for consumers, interoperability, and computer science. The decision gives legal certainty to the next generation of developers whose new products and services will benefit consumers.

Oracle:
The Google platform just got bigger and market power greater — the barriers to entry higher and the ability to compete lower. They stole Java and spent a decade litigating as only a monopolist can.

Zeg het maar...

Suns beleid was namelijk dat programma's die met het Java SE-platform ontwikkeld waren op meerdere apparaten moesten kunnen werken. Niet alleen op Android-smartphones dus, maar bijvoorbeeld ook op computers en laptops.

Dit klopt niet: Sun had juist field-of-use restricties op Java SE zitten zodat het niet op mobiele apparaten (zoals smartphones) gebruikt mocht worden. Daar is een hele rel over geweest met bijv Apache Harmony (een open source ASL2 implementatie van Java). Sun wilde namelijk heel erg graag mobiele Java verkopen (Java ME) en die markt beschermen.

Sun's Java Micro Edition was met name geënt om "apps" te maken voor Nokia telefoons en in één klap verouderd in 2007 door de introductie van de iPhone.

TL;DR. Sun verhinderde alternatieve mobiele Java varianten door deze niet te certificeren op basis van field of use restricties op de certificeringstesten. Hierdoor kon bijv. Apache niet een eigen Java implementatie distribueren, en heeft Oracle een weg gevonden om Google aan te klagen.

De auteur is denk ik in de war met de rechtszaak tussen Sun en Microsoft toen MS een eigen implementatie van Java maakte die niet cross platform was, en die MS geschikt heeft. Dat was een gevalletje "Embrace, Extend and Extinguish" dat door Sun voorkomen is.

[Reactie gewijzigd door dashorst248 op 6 april 2021 10:07]

Logisch dat ze Java ME wilden, daarvoor moesten royalties betaald worden. Voor Java SE niet, dus was Sun er alles aan gelegen dat 'field of use' te blokkeren.

Kleine opmerking: de iPhone had geen enkele mogelijkheid om apps van derden te draaien. Het was de utidrukkelijke wens van Steve Jobs om de telefoon volledig in beheer van Apple te houden. Het was pas in 2008, met iPhone OS 2 dat er een SDK werd vrijgegeven nadat er zowel intern als door externe partijen bij Jobs gelobbyed werd.

Niet dat ik een mening over de uitspraak wil geven, maar dat 2e punt is natuurlijk nogal onzin. Ja, natuurlijk is het idee achter copyright om creativiteit te bevorderen: door ervoor te zorgen dat als je een hoop werk ergens in steekt iemand anders dit niet zomaar mag gebruiken zonder dat jij er iets voor terugziet.

Overduidelijk betekend dit 1 op 1 kopiëren, maar zoals het in het artikel omschreven staat is iets kopiëren en daarop voortbouwen wel ok. Dat is natuurlijk helemaal niet de bedoeling, dan laat je iemand anders het moeilijke werk doen om met versie 1 op de markt te komen, en maak jij doodleuk versie 2 waarbij al het moeilijke werk al gedaan is en je je kunt richten op verfijning. Het lijkt me duidelijk dat het nog steeds de bedoeling is dat de originele ontwikkelaar iets terugziet voor het ontwikkelen van jouw basis.

Voor context, het Europese Hof kwam al tot deze conclusie in 2012:
https://arstechnica.com/t...d-would-monopolise-ideas/

Is dit hetzelfde?
De rechtszaak ging over de code waarin de API is geschreven. Niet de functionaliteit van de API.

Hoe ik die uitspraak van de Europese rechter lees in deze context, is dat Oracle niets kan doen tegen een andere partij die functioneel dezelfde API schrijft.

Dus stel ik heb een API met een service call met een bepaalde naam om een foto te uploaden, dan kan ik niet tegen jou een rechtszaak aanspannen omdat jij ook een API hebt ontwikkeld die een foto uploadt met een service call met diezelfde naam.

Deze rechtszaak ging er over dat jij mijn code hebt gebruikt, waarin ik die service call heb ontwikkeld.

De 11.500 regels code die hier werden hergebruikt zijn waarschijnlijk de beschrijving van de API zelf, niet de implementatie.

Als ik System.out.println("Hello world!") wil kunnen aanroepen heb ik ongeacht welke versie van Java ik heb een klasse System met een object out met een methode println met een String argument. Dat zijn sowieso regels code in Java, zelfs al horen ze bij de API. Die zijn misschien gehaald uit javadoc en vervolgens geschreven door andere mensen, maar zelfs definities zijn code.

Als we code volledig beschermen met auteursrecht valt de API hier ook onder.

Natuurlijk is het op deze manier onmogelijk om een API te gebruiken zonder een klein beetje code te hergebruiken. Wine (windows compatibiliteit) zou hier ook illegaal van worden. Daarom is waarschijnlijk het eerdere vonnis verworpen.

[Reactie gewijzigd door rjberg op 6 april 2021 09:14]

Precies, dat is het verschil waar Oracle over viel

Voor de context, dat nieuws is ook beschikbaar op een niet Amerikaanse bron, namelijk Tweakers.net : nieuws: Hof EU: geen copyright op functionaliteit software en programmeertalen

incl. link naar de uitspraak (404)

[Reactie gewijzigd door djwice op 6 april 2021 08:50]

Dan had Hayte dat er ook best zelf bij mogen zetten. Ik wist al van de Eurpese rechtzaak dus voor een betrouwbare bron heb ik gewoon even snel 'eu api lawsuit' ingetypt en Tweakers stond niet bovenaan. Ik draag graag bij aan een discussie met een stukje kennisdeling, maar ik ben er niet voor om extra reclameomzet voor DPG-Media te genereren.

[Reactie gewijzigd door Eonfge op 6 april 2021 08:50]

Ik denk dat een Europese bron over een Europese rechtelijke uitspraak relevanter is, zeker als de uitspraak zelf ook in de bron wordt gerefereerd.

De webpagina waar jij naar verwijst geeft geen referentie naar de rechtelijke uitspraak, dus is de correctheid van de interpretatie van de journalist lastiger te valideren.

[Reactie gewijzigd door djwice op 6 april 2021 08:55]

11 jaar over die uitspraak doen, wat een juridisch systeem daar in de VS.
En dan ook nog door 9 digibeten van de Supreme Court, waar een paar echt geen flauw benul hebben van hoe de vork in de steel zit.
Uitspraak is wel goed voor de softwarewereld, dit soort juridische steekspellen waren anders alleen maar toegenomen. Lijkt erop dat “fair use” nu van toepassing is en je dus best af en toe wat code mag overnemen zonder toestemming van de eigenaar.

[Reactie gewijzigd door CyBeRSPiN op 6 april 2021 09:09]

Hoe lang denk je dat het in Europa duurt voor een complexe zaak met enorme belangen van de laagste rechter naar het CJEU komt en er een uitspraak ligt?

En wat voor mensen wil jij dan als hoogste rechters? Een stel wereldvreemde techneuten die deze zaak misschien snappen maar over alle andere onderwerpen niets zinnigs te melden hebben (om maar eens lekker in stereotypen te vervallen)?

Ik ben het met het laatste stuk van je post wel eens, en die uitkomst, en de argumentatie van de rechters, laat naar mijn mening zien dat die "digibeten" van de SC eigenlijk best prima begrepen hebben hoe de vork in de steel zit.

En dan ook nog door 9 digibeten van de Supreme Court, waar een paar echt geen flauw benul hebben van hoe de vork in de steel zit.

Een rechter hoeft ook geen technisch verstand te hebben. Een rechter hoeft alleen maar te toetsen op de wet. Allerlei adviseurs/specialisten/enz. vertalen de technische context naar een juridische/functionele/wat ook van toepassing is.

‘Een rechter heeft geen mening’ (op papier dan)

Het kan ook niet anders, anders kan een rechter nooit een uitspraak doen. Een rechter kan niet bijzonder veel kennis hebben van alles waar rechtszaken over gaan (moord, copyright, bouwkunde, agricultuur, meubelbouwen, opvoedkunde, enz enz enz)

Naar mijn mening zitten allebei de bedrijven fout. De ene gebruikt haar macht om te stelenlenen zonder toestemming, de andere maakt hun voorheen 'open' platform niet beschikbaar om concurrentie tegen te gaan. Strijd der monopolisten.

[Reactie gewijzigd door sowen op 6 april 2021 08:39]

Naar mijn mening zitten allebei de bedrijven fout.

Jouw oordeel gaat meer om wat moreel fout is, de rechter gaat over wat juridisch fout is. Ik denk dat jullie alle twee gelijk hebben.

Ik denk dat je Google kan verwijten niet opnieuw te willen beginnen met een compleet nieuwe taal, maar dat is ook erg kort door de bocht in het hele verhaal.

De andere kant is dat de "originele JAVA API" ook niet zo origineel is. Een groot deel van de JAVA API berust ook op "prior art" in de C/C++, PERL en andere communities.

SUN's bijdrage is om best practices van andere talen samen te voegen in hun API. Google heeft die best practices volledig overgenomen zonder veel eigen creatieve input van hun kant. Dat is misschien niet netjes. Oracle neemt SUN over en gaat vervolgens copyright claimen over de API, terwijl het grootste deel van de API ook "gestolen" is van open source communities. Dat is natuurlijk een extreem glijdende schaal.

Sorry, maar als Oracle die stelen mag noemen, wie gaat dan oracle aanklagen voor het stelen van de C/c++ API? Want daar komt de java api vandaan.... en die hebben het weer van .... enz enz...

precies. en het stelen van het concept van relationele DB's.

Niet alleen het concept, maar ook de door IBM verzonnen query syntax ervoor.

Als Oracle gewonnen had konden ze hun eigen software niet meer verkopen. Niet alleen Oracle Database is gemaakt op basis van kopiëren van APIs, maar Oracle maakt ook nieuwe software/diensten die APIs kopieert (zoals bijvoorbeeld hun S3 compatible API).