Amerikaans gerechtshof: 'Google schond met Android copyright van Oracle'

Een Amerikaans gerechtshof heeft vrijdag in hoger beroep bepaald dat Google met zijn Android-besturingssysteem het copyright van Oracle heeft geschonden. Daarmee draait de raadsheer het besluit van een rechter twee jaar geleden terug.

Google gebruikte in Android weliswaar deels dezelfde naamgeving voor methoden en classes als in Java, maar heeft de implementaties van die methoden vervolgens zelf geschreven. De Android-maker nam van 37 van de in totaal 166 api-packages van Java de methodenamen over om Android zo veel mogelijk compatibel te houden met bestaande Java-code.

De overgenomen delen vormden in 2012 slechts drie procent van alle regels code in de 37 api-packages, terwijl de rest door Google zelf was geschreven. Toch oordeelde het gerechtshof vrijdag dat Google de fout was ingegaan, omdat 'de aangeboden code en de structuur, volgorde en organisatie van de api-packages het copyright schenden'.

Het gerechtshof heeft het arrest vrijdag teruggestuurd naar de rechter, die de zaak opnieuw moet bekijken. Die moet uitzoeken of Google gebruik heeft gemaakt van fair use, wat inhoudt dat onder bepaalde voorwaarden auteursrechtelijk materiaal mag worden gebruikt. Volgens het gerechtshof is namelijk niet duidelijk vast te stellen wanneer iets fair use is.

Het conflict tussen Oracle en Google over de 37 api-packages speelt al jaren. De eerste zaak was in 2012, toen de Amerikaanse rechter niet Oracle, maar Google gelijk gaf. De rechter verwierp destijds dat er copyright van Oracle rust op de structuur van de programmeertaal Java. Oracle moest Google 1,1 miljoen dollar proceskosten betalen. Het bedrijf liet toen weten in beroep te gaan.

Oracle liet vrijdag weten dat het oordeel van het gerechtshof 'een overwinning is voor de complete software-industrie die afhankelijk is van het auteursrecht om innovatie te bevorderen', zo schrijft Ars Technica. Google en andere oppositiepartijen vinden daarentegen dat er moet worden gekeken naar de functionaliteit van de code, en niet naar de creativiteit. Bovendien dient een api volgens de tegenpartijen om software met elkaar te verbinden en zou het copyright dat niet in de weg mogen staan.

Reacties (147)

Beide partijen hebben hun eigen agenda. Google weet precies wat ze gedaan hebben en dat ze een beetje stout zijn geweest. En Oracle heeft een redelijk actieve juridische afdeling, én moet eigenlijk wel dit soort zaken aanpakken omdat ze anders zeggen dat je rustig hun spullen mag namaken.
Google en Oracle hebben een iets ander businessmodel en als Google van commerciele software zou leven, hadden ze een heel ander standpunt gehad.
Zo gaat Google weer de strijd aan met lieden die kloten met addclicks en proberen hun zoekmachine te fucken om bovenaan te komen. Ieder zijn business...

Google heeft met Android inderdaad iets gedaan wat niet zo netjes is: ze hebben de Java community als hefboom gebruikt, zonder officieel Java te implementeren. Dat is niet alleen de schuld van Google: Sun (en Oracle nog steeds) had de ME en SE editie van Java, die zeer grote verschillen bevatten. Google wilde graag SE op de telefoon, maar in de clausule van Java staat dat je het daar niet voor mag gebruiken. Daar kwamen ze toen met Sun niet uit: Sun had met Nokia en Blackberry al licentiedeals met de ME editie. Daarnaast bevat de volledige SE editie van Java code die alleen op een desktop past: je zou dus een gestripte versie moeten maken.

Google heeft uiteindelijk doorgezet en zelf maar een VM gebouwd die een subset van Java API's implementeert. Dat Oracle dit niet leuk vindt snap ik. Maar is het illegaal? Veel van de Java API's zijn zelf ook kopieën van API's die in andere libraries te vinden zijn. Kunnen de ontwikkelaars van C nu Java gaan aanklagen, wegens het overnemen van de curly brace? Het wordt op een gegeven moment wel heel triviaal.

Het andere bijzondere aan deze rechtzaak is de "sequence and organization" motivatie, bedacht door Oracle advocaten en eigenlijk helemaal niet als criterium aanwezig in de wet. Als ik een artikel schrijf en "Inleiding" en "Conclusie" schrijf, in die volgorde, dan krijgt dat dus meer betekenis. Wanneer is die structuur genoeg? De vorige rechter vergeleek dit met het overnemen van een hoofdstukindeling uit een boek: iets wat op zich zelf ook niet als een copyright overtreding wordt beschouwd.

Het is niet voor niets dat veel vooraanstaande mensen zich fel uitspreken tegen Oracle en de manier waarop de API copyright claim wordt opgerekt. Als wat Google heeft gedaan niet meer mag, dan wordt ineens veel meer vervolgbaar. En dan hebben we, naast eindeloze patent-discussies, nu ook eindeloze copyright-discussies in de software industry.

De wet is de wet, wellicht heeft Oracle gewoon gelijk, hoe vervelend dat ook is voor de talloze andere bedrijen die andermans tech klonen. Als je dat een slechte zaak vindt, dan moeten die vooraanstaande mensen gaan lobbyen voor een revisie van de copyright wet, het heeft weinig zin om Oracle daarop aan te kijken, die proberen hun recht te halen. Of het is niet hun recht, dat kan ook. Dat is aan de rechters om te bepalen.

[Reactie gewijzigd door Dreamvoid op 11 mei 2014 01:51]

Redelijk actieve juridische afdeling is een understatement. Het zijn een stel honden daar. De manier waarop Oracle zaken doet... de manier van geld verdienen is: iets aansmeren en je daarna aanklagen als je er over klaagt (dit heeft in de tijd dat ze nog PC's maakten in de user agreement gestaan; er mocht niet over de performance gesproken worden).

Mijn werkgever heeft er ook last mee: je betaalt niet voor het aantal gebruikers, maar voor het aantal potentiële gebruikers (dus is de server niet helemaal dichtgetimmerd, dan moet je voor iedereen betalen). Nog leuker in de cloud: mag je voor alle servers een licentie gaan kopen.

Ik ben niet snel voor Google, maar wel als ze het tegen Oracle op nemen.

Wellicht een goed argument voor Google (geen ervaring met Android): onze user interface is intuïtief, dus we kunnen het niet van Oracle hebben (die hebben talent om slechte user interfaces te maken / over te nemen).

Java is geen commerciële software dat door Oracle wordt verkocht, maar een hulpmiddel.
Oracle heeft tijdens de aankoop van Sun met $$ in de ogen hiervan gehoord. Want zou Google moeten betalen, dan zou dat belachelijk veel zijn. En dat is heel erg des Oracle.

Daarom gaat Oracle hier ook vol op in. Ookal is Java open en gratis beschikbaar. Ze verliezen er t.o.v. nu dus niets. Enkel die mogelijke potentie van miljarden...
Vele ontwikkelaars zien liever dat hun een samenwerking aangaan en in Android de echte Java stoppen. Maar totdat de laatste rechtszaak hierover is afgelopen, ben ik bang dat dat niet zal gaan gebeuren.

Ik hoop maar dat Google niet verliest. Want dan zal er een oorlog ontketenen. Oracle doet aan software producten, Google aan software services. En door de prijzen van Oracle kunnen ze makkelijk alternatieven maken. Naast dat andere bedrijven ook alternatieve api zullen gaan (proberen te) verbieden.

Vele ontwikkelaars zien liever dat hun een samenwerking aangaan en in Android de echte Java stoppen.

Je moet het wat ruimer zien. Het enige wat Google overgenomen heeft zijn de namen van methodes. De code in die methodes hebben ze zelf geschreven en toegespitst op Android.

Als ze nu ineens overstappen op 'nativa Java' dan word het een ramp omdat je API dan breekt, iets waar geen enkele applicatieontwikkelaar op zit te wachten.

Dat is nou juist het punt van een api: een vaste set functies waar je tegenaan programmeert, zodat de specifieke implementatie kan verschillen, zonder dat het invloed heeft.

Als ze die namen nu veranderen en die nieuwe namen aanroepen is er toch niets aan de hand?! De werkende code is immers door Google zelf geschreven. Je zou ook in de nieuwe hoofdstukken kunnen zetten dat ze naar de oude benaming wijzen, heb je het ook omzeild...

[Reactie gewijzigd door Tourmaline op 11 mei 2014 13:48]

En alle 3rd party applicaties dan? Die zijn dan mooi genaaid...

Java is geen commerciële software dat door Oracle wordt verkocht, maar een hulpmiddel.

Dat is ook de reden dat Oracle de boedel van Sun kocht - Java is essentieel voor hun software, en de leverancier dreigde failliet te gaan.

Los van de juridische details, is het ook randje (en heel slim) wat Google gedaan heeft. Ze hadden gewoon net als bv Blackberry en Nokia een Java licensie van Sun/Oracle kunnen nemen, maar ze hebben de Sun licensie goed bekeken en hebben een net genoeg afwijkende kloon gemaakt met hopelijk genoeg wijzigingen om legaal te zijn. Een shortcut waarmee ze zich vele miljoenen bespaarden, en hun development een paar jaar versneld hebben (een eigen Java-achtige technologie ontwikkelen zoals C#/.NET kost veel tijd), net zoals hun keuze om de Linux kernel te gebruiken ipv een eigen ontwerp. In het geval van Linux was dit juridisch prima mogelijk, in het geval van Java komen er nu wat beren op de weg, in dit geval een copyright schending.

Ik word altijd een beetje moe van die Google vs Oracle fanboy argumenten, het zijn geen voetbalclubs. Wat Google met Java heeft uitgespookt is een juridisch grijs gebied, beide tech giganten zijn zeer afhankelijk van Java dus gaan heel ver om hun gelijk te halen. Uiteindelijk zal er een uitspraak komen, er wordt evt een nieuwe licensie afgesproken en er vloeien wat miljoenen/miljarden van de ene groep aandeelhouders naar de andere. De advocaten schrijven hun uurtjes en lopen binnen. Oracle blijft Java volop doorontwikkelen en Google blijft het voorlopig gebruiken, dus het is "here to stay".

[Reactie gewijzigd door Dreamvoid op 10 mei 2014 00:00]

Maakt toch niet uit of het gratis is? Copyright is copyright. En het maakt uiteindelijk ook niet uit dat Oracle het verkregen heeft door Sun te kopen (of liever gezegd: van de ondergang te redden, dat vergeten veel mensen).
Oracle is een bedrijf dat met commerciële software geld verdient, en dan bedoel ik niet persé Java, maar gewoon de bedrijfsactiviteit/businessmodel als geheel. Dan moet je dus wel die belangen verdedigen. Vanuit het oogpunt van Oracle is dat heel logisch. Als je dat niet doet, zet je de deur open voor andere bedrijven die dan ook maar van alles gaan overnemen/namaken.
Apple klaagt ook iedereen aan met verkregen patenten, want zelf hebben ze niets uitgevonden. Multi-touch? Ook gekocht. Maar zodra je een patent op iets hebt, moet je het wel verdedigen.

En hoe sympatiek ik Google ook vindt, ook dát is een bedrijf dat graag centjes verdient en liefst niet geld uitdeelt. Ze voeren dan wel die spreak 'don't be evil', maar je bereikt niet wat zij hebben bereikt door mensen alleen maar blij te maken. Laat je niet een rad voor ogen draaien. Oracle heeft zijn reputatie als keihard bedrijf zelf verdient, maar 75% van de shit die (vooral hier) uitgekraamd wordt, spoel ik dagelijks 2x door omdat het gewoon overdreven napraterij is. En het is dan heel makkelijk dat Oracle een groot bedrijf is, dan ben je bij voorbaar al evil natuurlijk. Maar voorlopig realiseert niemand zich dat Sun stervende was en er zonder die overname helemaal niets meer over was. Niet dat Larry uit de goedheid van zijn hart zijn vriend heeft geholpen (Scott McNeilly en Larry zijn goede vrienden), maar het was geen conspiracy om Java in handen te krijgen. En FYI: Oracle heeft wel degelijk mee ontwikkeld aan Java. Oracle is een van de grootste vrienden van Java en zijn hele middleware & apps strategie drijft op Java. Ze zijn al jaren bezig om java verder te ontwikkelen en hadden zelfs een eigen Java VM zodat ze hun eigen applications sneller en beter konden draaien. Die Jinitiator liep altijd wat voor op de java release. Helaas zorgde dat ding ook voor een hoop ellende, maar dat is weer een ander verhaal.

Het is altijd weer triest om het gebral van onwetenden aan te horen. Niet dat ik alle ins en out ken, maar de meesten die steeds wat te zeggen hebben, praten na wat ze ergens gelezen hebben, zonder zich er echt in te verdiepen. En propoganda over een evil corporation is makkelijker te vertreren dan rare verhalen over een vriendelijk bedrijf dat allemaal dingen gratis weggeeft...

Lekker kort door de bocht.

Het is en blijft een software patent. En deze onzin moet eens stoppen. Ze schrijven de implementatie opnieuw (lekker handig want als Java het het beste deed krijg je dus altijd een slap aftreksel). Verder kiezen ze een goede structuur. En als ze met een tool ff de namen hadden veranderd naar iets slechts dan was het wel goed geweest?

Als ik cout<< "Hello world"; ben ik dan fout bezig?

Sofware patenten moeten per direct en absoluut verboden worden.

Dit gaat over iets anders dan "1 click to buy" knop patenten.
Dit gaat over copyright. Dat is nog iets anders.

Als ik een boek schrijf en de hoofdstukken zus en zo noem, dan heb jij het recht niet om de namen van mijn hoofdstukken duidelijk over te nemen en de inhoud van de hoofdstukken te veranderen.

De vraag is natuurlijk wanneer iets stelen van copyright is. Als één hoofdstuk hetzelfde noemt, mag dat. Als er 20 op een rij hetzelfde noemen? Waarschijnlijk niet. Ook niet als er nog 500 andere hoofdstukken zijn, maar die 20 toch "toevallig" overgenomen zijn.

En laten we niet vergeten dat Google vlug met Android moest komen omdat het anders te laat in de smartphone wereld ging zijn. Google heeft enorm veel geld (indirect) verdiend met Android. Nu mogen ze dokken.

Van alle voor-de-uitspraak betogers ben je de enige die het probeert te argumenteren, en je stelt de juiste vraag: wanneer wordt het stelen?
Dat is afhankelijk van hoeveel er over genomen word (fair use), hoeveel creativiteit eraan te pas gekomen is aan de ontwikkeling (fair use, niet copirighttable), en voor techische objecten, of het noodzakelijk is voor samenwerking (interoperabiliteit, niet copirightable), en of je het opelijk aan anderen hebt aangeboden. Alle 4 deze aspecten zijn hier van toepassing.
1 het gaat slachts om een fractie van de code; alleen de 'hoofdstukken' zoals ze het bij Oracle vergeleken
2 er is weinig fantasie aan te pas gekomen; het zijn slechts logische uitdrukkingen waaraan de ' echte uitvinding', de werkende code wordt gekoppeld, die door Google opnieuw zelf geschreven is
3 de code moet samen kunnen werkn, anders zou geen enkele JAVA-implementatie kunnen samenwerken
4 Het is inherent aan software dat je de functienamen publiceert, anders kan niemand ermee werken. Bovendien Sun heeft zelf geroepen dat iedereen de taal kon gebruiken en heeft handleidingen en kennis vrij gegeven, waardoor er openbare opleidingen voor Java konden komen (Anders had het nog onder bedreifsgeheid kunnen vallen)

5 Je zou zelfs de conclusie kunnen trekken dat de kennis 'eigendom' is geworden van iedereen die ooit JAva heeft geleerd, en er daarvoor tijd en moite heeft ' betaald'

PS:
6 Google wou eerst in samenwerking met Sun een telefoon ontwikkelen, maar Sun was niet geinterresseert

7 Het is pas Oracle geweest die, mogelijk met dit doel, Sun heeft overgenomen. En volgens hun advocaten aan dit deel (Java) iets van 80% van de waarde van Sun hebben toegekent.

Zie voor een meer technische uitleg Golodh's uitleg

De mensheid zou nu nog in het stenen tijdperk leven als die eerste holbewoner die ontdekte hoe je van een bepaalde steensoort een mes kon maken had gezegd "Mag niet".
Het is juist door het overnemen van bepaalde ideeën van een ander en daar op voort te borduren dat de mensheid zulke grote sprongen heeft kunnen maken.
Neem het begin van de auto- en vliegtuigbouwindustrie. Uitvinders waren toen constant bezig om de ideeën van anderen over te nemen of verder te verbeteren. Hierdoor is dit in het begin zo snel gegaan. Pas toen patenten om de hoek kwamen kijken werd dit tempo een halt toegeroepen. Mensen verdienden destijds hun geld door het produceren van een product dat het gevolg was van al die uitvindingen.
We zouden nu nog met een fietsstuur in de auto zitten als de eerste persoon die een rond stuur gebruikte dit voor anderen had geblokkeerd. Sterker nog, als de scheepvaart dit had geblokkeerd.

Stel je voor dat bedrijf Sun de trein had bedacht. Het bedrijf is heel trots op zijn uitvinding en nodigt zo veel mogelijk mensen uit om er gebruik van te maken.
Vervolgens komt bedrijf Oracle die Sun opkoopt en verbiedt dat je woorden als "trein", "spoor" of "rails" nog mag gebruiken. Ook mag je dezelfde spoorbreedte niet zomaar gebruiken.
Bedrijf Google die ook een trein heeft moet deze dus anders noemen en ook de spoorbreedte aanpassen. Hierdoor kunnen de treinen van Google niet op de sporen van Oracle.
Reizigers moeten dus overstappen als ze van de Google trein op de Oracle trein willen of v.v. en zijn vervolgens boos op Google en niet op Oracle.

Hoewel auteursrecht en patenten met idealistische gedachten zijn ingevoerd, worden ze momenteel alleen nog maar gebruikt voor financieel gewin en om innovatie te blokkeren.
Dit hele systeem zou dan ook grondig op de schop moeten.

[Reactie gewijzigd door benieuwd op 11 mei 2014 06:40]

Als ik de hoofdstukken "Hoofdstuk 1", "Hoofdstuk 2" noem, dan valt dit toch niet onder het copyright?

Vergelijk deze uitspraak met: Dunlop was de eerste met rubberbanden dus moeten andere bandenfabrikanten een ander materiaal gebruiken.

Microsoft deed precies het zelfde met Java onder Windows namelijk een eigen versie schrijven die jaren achter liep met de officiële versie, toen vond iedereen het heerlijk dat de desktopmonopolist eens goed aangepakt werd. En nu de zoekmonopolist het zelfde doet is het ineens prima?

Er is een wereld van verschil tussen de zaak van Sun en MS en Oracle en Google. Google heeft 2 dingen gedaan:
1) API signatuur overgenomen
2) Meer dan 99% van de API geherimplementeerd.

Als de rechter punt 1 toekent hebben we een groot probleem: je mag nooit meer een functie maken die "toString()" heet want die zit al in Java. Ook "getClass()" is verboden. Los van de implementatie zou de naam dan een onderdeel zijn van het copyright.

Punt 2 is gewoon dom: je moet geen implementaties van "toString()" of "getClass" rippen (is ook maar heel beperkt gedaan).

Oh ja, getClass() en toString() zijn slechts voorbeelden om het verschil tussen patent/copyright op een API signatuur en de code achter de functie helder te maken.

Er zit een dunne scheidslijn tussen 'toevallig' een paar functies hetzelfde noemen, of zorgen dat de hele core API hetzelfde werkt.

Dus om bij jouw voorbeeld te blijven: een functie die toString() heet mag wel (al was het maar omdat er vast al eerder iemand een functie zo heeft genoemd), maar de complete API voor alle datastructuren overnemen mag niet. Een kind zal dat begrijpen, maar juristen kunnen er jaren mee bezig zijn, omdat daar geen duidelijke grens voor is aan te geven.

Dan ben ik een jurist want ik begrijp het niet.

Ik vraag je dan ook: Wanneer is iets een kopie?

De scheidslijn is zeker dun als de wetgever vanuit interoperabiliteit wel toestaat dat je mag reverse engineeren. M.a.w. als Oracle morgen stopt met Java dan zou het wel mogen (inclusief het clonen van de complete API) Om je eigen code werkend te houden. En idd. Is de grens voor kopiëren 3 functies of 20%.

Dat is niet waar. Sun claimde dat Microsoft met opzet een incompatibel Java versie maakte, en daarmee zich niet hield aan de afspraken die ze gemaakt hadden.
Microsoft is niet veroordeeld voor het maken van een foute Java versie, Sun en Microsoft zijn buiten de rechtbank tot een overeenkomst gekomen.
http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machin

En waar is de Google versie wel compatibel dan? Zo gauw Java niet meer een standaard is is Java geen standaard meer en dat is zeer vervelend voor een programmeertaal die bedoeld is als universele taal voor alle mogelijke apparaten.

Google maakt geen Java versie, verkoopt geen Java versie. Dalvik is geen Java.
Dat je de taal java gebruikt om voor Dalvik/Android te programeren maakt het nog geen Java. Verder is de Java API die Google gebruikt een fork van Apache Harmony. Google

[Reactie gewijzigd door elmuerte op 10 mei 2014 07:46]

Dat hebben ze in tegenstelling tot MS dan ook niet geprobeert en al helemaal niet als dusdanig aangeboden...

Overigens de grootste fout die Sun kon maken...
Door deze rechtzaak heeft Microsoft hun JVM uit Windows XP gehaald.
Ineens had meer dan 90% van de PCs op het internet geen Java-ondersteuning meer out-of-the-box, en moesten gebruikers zelf een JVM downloaden en installeren.
Dit heeft de populariteit van Java-applets de das om gedaan.

De vraag is of dat zo goed was geweest. Microsoft had een incompatibele versie en je had dus een vergelijkbare situatie gekregen als met HTML en IE5 t/m IE6: stagnatie en iedereen die schrijft enkel en alleen voor één microsoft product versie. Het heeft bijna een decennium geduurt voordat de effecten van dat monopolie enigszins verdwenen waren (en ze zijn er nog steeds)

Tegenwoordig heeft niet elke desktop meer een JVM, maar de JVM is wel zeer populair in het bedrijfsleven. Daarnaast zie je momenteel ook meer nieuwe software voor de JVM verschijnen, deels gedreven doordat veel niet-Java talen voor de JVM (Scala, Clojure, JRuby etc.) in populariteit winnen.

All in all is het dus best goed gegaan voor Java.

Microsoft had een incompatibele versie

Dat is niet waar. De Microsoft JVM was compatible met de Sun JVM.
Het probleem was de andere kant op: als men code voor de MS JVM extensies zou schrijven, zou dit niet compatible zijn met andere JVMs.

All in all is het dus best goed gegaan voor Java.

Daar ben ik het niet echt mee eens. Java-software, vooral applets, waren toch een stuk populairder toen er nog Windows support out-of-the-box was. Het heeft ook een tijd geduurd voordat oa Flash en JavaScript een beetje het gat opvulden dat achterbleef.

en beide zijn nu achterhaald, ook flash en javascript. Het is jammer dat het bedrijfsleven er nog op grote schaal gebruik van maakt.

Waarom zou JavaScript achterhaald zijn? Er wordt volop gebruik gemaakt van JavaScript, niet alleen in het bedrijfsleven, maar ook met social media en dergelijke. Er is ook niet echt een alternatief voor.

Microsoft had wel netjes een licentie op Java afgenomen bij Sun.
Het probleem dan Sun met MS had was dat MS extensies in hun JVM bouwde.

Als het allemaal zo helder en duidelijk was wat Google fout heeft gedaan, hoe kan het dan dat deze twee rechters het klaarblijkelijk niet eens zijn over deze zaak? De een stelt Google in het gelijk, de volgende Oracle. Het wordt op deze manier meer gokken wie je als rechter treft dan dat je werkelijk kunt vertrouwen dat een patent of copyright je beschermt.

De vorige rechter had enige technische en wiskundige kennis, en heeft veel moeite gedaan om dat uit de bewijstlast verder te doorgronden.
Zo wees hij geloof ik o.a. ook 1 van de (overige) copyright claims van Oracle af omdat hij het zelf ook in een uur zou kunnen programmeren, en dus geen xxxx miljoen dollar kon kostten.

Het hoger beroep is bij een rechter die uit alfa-juridische hoek komt en zich dus niet kan voorstellen dat er in de coprghtwetgeving uitzonderingen bestaan voor interoperablity, want dat komt in de literatuurniet voor dus waarom wel in software.
Of de rechter komt uit een jurisdictie dat zijn geld verdient met patentclaims, en is dus van belang dat ' lage' verdedigingen als 'un-copyrightable content' zo veel mogelijk vertroebeld worden zodat allen met veel bewijs, en dus veel dure advocaat-uren ' opgelost' moet worden.

Er zit een verschil in, Google claimt niet dat het Java is,voor Microsoft was het "Embrace, extend, and extinguish"

Het gaat over copyright schending, niet over patenten. Dat is fundamenteel andere materie.

en de enige reden waarom het over copyright schending gaat is omdat oracle een van de eerste zaken (over die patenten) verloor... en dus op deze achterbakse manier voortborduurt op patenttrolling van zaken die ze niet eens zelf hebben ontwikkeld, en waarvan de maker, er in eerste instantie NIETS tegen deed. en het bijna letterlijk aanmoedigde,

Copyright schending waar je spreekt over de implementatie van software. Dat klinkt me eerder als een vieze truck om iemand voor software patenten voor de rechter te krijgen.

Overigens zijn software patenten in de US toe gestaan. In de EU niet, maar via deze indirecte acties kan het toch.

Dus als jij een prachtig stukje software ontwikkeld dan vind je het niet erg als een groot bedrijf er mee aan de haal gaat en het vervolgens 1 op 1 kopieerd?

Voorbeeld: apple steekt 500 miljoen in de ontwikkeling van de iphone/ios. Ze zijn ze 5 jaar bezig om alles softwarematig naatloos op elkaar aan te sluiten. Vervolgens komt google en kopieert eigenlijk ios 1op1 zonder er veel ontwikkelingskosten in te stoppen aangezien die al zijn gedaan.

Dit maakt het voor sommige bedrijven wel erg makkelijk, gewoon de concurrentie kopieren met een goedkoop model aangezien je niet de kosten hebt van diegene die het bedacht heeft. Als we die kant op gaan dan stopt de innovatie erg snel.

@Tothabone

Sorry, maar jij bent hier bezig appels met peren te vergelijken. Van het ontwikkelen van een "prachtig stukje software" waarmee "een groot bedrijf aan de haal gaat" zoals jij beweert is natuurlijk totaal geen sprake. Jammer dat je de discussie hier zo vertroebeld met je onwetendheid, maar ook daar is wel wat aan te doen.

Als je je ook maar een beetje in de zaak verdiept had, dan had ook jij gesnapt dat het hier gaat om het maken van een interpreter voor Java ("Android included Google's own implementations of some of the APIs from Java SE." : zie https://en.wikipedia.org/wiki/Oracle_v._Google ).

Om zo'n interpreter te laten werken (de specificaties van Java zijn public domain) moet je ook de aanroepen van Java functies naar de Java standaardbibliotheken meenemen. Voor wie niet weet wat die Java bibliotheekroutines zijn, zie https://en.wikipedia.org/wiki/Java_Class_Library. De specificaties voor die bibliotheken zijn ook vrij toegankelijk.

Wat Google gedaan heeft is Java bibliotheken vanaf scratch programmeren, maar ervoor zorgend dat alle *functie-aanroepen* identiek zijn. Die functie aanroepen worden gedefinieerd door: hoe heet de functie, welke argumenten krijgt die mee, en in welke vogorde. Even voor jouw begrip: die API's zijn allemaal gepucliceerd, omdat anders Java programmeurs niet zouden weten hoe ze bepaalde biblioteekroutines moeten aanroepen.

Zonder identieke aanroepen van bibliotheekroutines is het onmogelijk om een interpreter voor Java te schrijven. De aanroepen van de bibliotheek werden niet als beschermd onder het copyright gezien.

Zoals rechter Alsup het destijds formuleerde (https://en.wikipedia.org/wiki/Oracle_v._Google):

"However, on the primary copyright issue of the APIs, the court ruled that "So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical." The ruling found that the structure Oracle was claiming was not copyrightable under section 102(b) of the Copyright Act because it was a "system or method of operation."

Voor iedereen die ooit wel eens geprogrammeerd heeft of een beetje weet hoe Java werkt is het zonneklaar dat er in de verste verte geen sprake is van enige wezenlijke intellectuele inspanning in de organisatie van de Java bibliotheekroutines.

Een voorbeeldje is de functie max:

package java.lang; // Declares package java.lang
public class Math { // Declares class Math
public static int max (int x, int y) { // Declares method max
if (x > y) return x ; // Implementation, returns x or
else return y ; // Implementation, returns y
} // Closes method
} // Closes class

Een volstrekt triviale functie die je voor de compatibiliteit wel moet implementeren in je library.

Wat Oracle nu voor elkaar gekregen heeft is een hoger gerechtshof laten verklaren dat de vorm van functie-aanroepen onder het copyright vallen. Dat wil dus zeggen dat alle Java bibliotheekfuncties met de interface public static int max(int x, int y) nu onder Oracles copyright vallen.

Bezopen, maar dat oordeel ligt er nu. Snap je nu warom jou opmerking over dat "prachtig stuk software waar een groot edrijf mee aan de haal gaat" echt helemaal nergens op slaat?

Dit oordeel is een bizarre en ongeloofelijk schadelijke beslissing die de normale praktijk van ongeveer 50 jaar software ontwikkeling totaal op zijn kop zet.

Persoonlijk denk ik dat alleen een rechter die totaal geen kaas gegeten heeft van wat programmeren nu precies inhoudt tot zo'n oordeel kan komen.

Om zo'n interpreter te laten werken (de specificaties van Java zijn public domain) moet je ook de aanroepen van Java functies naar de Java standaardbibliotheken meenemen.

Dat is niet juist.
De 'interpreter' (een JVM is meestal een JIT-compiler, maargoed) is een virtual machine, en werkt op een laag niveau met een eigen instructieset.
Dit is nou juist het deel dat Google NIET gebruikt: Dalvik heeft een eigen instructieset (sterker nog: de code wordt eerst naar Java gecompileerd, en daarna vertaald naar Dalvik).
Voor het gebruik van die instructieset is overigens helemaal de taal Java niet nodig, laat staan de libraries van Java.
Dat is hetzelfde als zeggen dat je C++ en POSIX libraries moet gebruiken op een x86 CPU. Onzin natuurlijk.

Er is eigenlijk totaal geen technische reden waarom Google per se de Java APIs moest overnemen voor Dalvik/Android.
Het zal vooral zijn gedaan omdat het makkelijker is dan het wiel opnieuw uitvinden, en het is voor ontwikkelaars ook makkelijker, want die zijn al bekend met Java.

Golodh heeft het over sourcecode. Op de een of andere manier tracht jij dat te koppelen aan gegenereerde bytecode. Wat je daarmee beoogd begrijp ik eerlijk gezegd niet.

Overigens, voor zover ik mij herinner wilde Google in eerste instantie de mobiele versie van Java gebruiken, maar omdat Sun daar problemen mee bleef hebben is daar vanaf gestapt. Google beoogde een soort light versie van Java omdat zij beweerden dat een aantal bibliotheken van Java onbruikbaar/overbodig waren op Android. Echter, Sun bleef destijds eisen dat Google een volledige Java Mobile zou implementeren. Ik weet het niet meer zeker, maar het ging daarbij volgens mij om libraries als GlassFish.

Dat is de reden waarom Google er uiteindelijk voor koos om Java te vervangen door Dalvik. Want als het geen Java was, verviel de eis van Sun.

Ze wilden Java gebruiken om de redenen die jij zelf aangeeft. Ze wilden niet opnieuw het wiel uitvinden en het ontwikkelaars gemakkelijk maken. Dus dat Dalvik gelijk is aan Java is vrij logisch. Ik zou ook niet weten hoe je een technische reden moet verzinnen om Java niet te gebruiken. Java is juist ontwikkeld met een gedachte om onafhankelijk te zijn van de techniek.

Met Dalvik hoopte Google toch de Java instructieset te implementeren, zonder Sun voor het hoofd te stoten met het zich niet houden aan hun eisen. En volgens mij werkte dat eerst ook vrij aardig. Alleen begon Oracle er vrij snel een punt van te maken na de overname, naar mijn idee omdat ze op deze manier geld wilden genereren uit Java.

Golodh heeft het over sourcecode. Op de een of andere manier tracht jij dat te koppelen aan gegenereerde bytecode. Wat je daarmee beoogd begrijp ik eerlijk gezegd niet.

Dan moet je beter lezen. Hij komt met een verhaal over de interpreter. Dus leg ik uit dat de interpreter alleen met bytecode werkt, en niet met Java sourcecode.
Zijn verhaal klopt dus niet.

Met Dalvik hoopte Google toch de Java instructieset te implementeren, zonder Sun voor het hoofd te stoten met het zich niet houden aan hun eisen.

Zoals ik al zei, Dalvik maakt gebruik van andere bytecode dan de JVM. Dit klopt dus ook niet.

[Reactie gewijzigd door Scalibq op 12 mei 2014 11:41]

Omdat Java en Dalvik met bytecode werken is er nogal eens verwarring over wat nou precies wat is. Ik heb de indruk dat je je vooral vast bijt in de definitie van interpreter en niet in wat Golodh nu eigenlijk bedoelde. Golodh had het vrij duidelijk niet over bytecode en wel over sourcecode. En daar gaat de rechtzaak ook over.

Ik heb de indruk dat je je vooral vast bijt in de definitie van interpreter en niet in wat Golodh nu eigenlijk bedoelde.

Knap van je, dat was ook precies het doel van mijn reactie: een deel van het verhaal van Golodh klopte niet, en dat stipte ik aan.

Golodh had het vrij duidelijk niet over bytecode en wel over sourcecode. En daar gaat de rechtzaak ook over.

Dat deel klopt wel, dus had ik daar geen aanmerkingen op.
Je bent het er mee eens dat het verhaal over bytecodes en interpreters los staat van de rechtzaak, blijkbaar.

In feite klopte alleen het woord interpreter niet. Door daar zo groot op in te zoomen wek je de indruk alsof het hele verhaal niet klopt.

Note: Opmerkingen als "Beter lezen" en "Knap van je" dragen niet echt bij aan een prettige discussie.

In feite klopte alleen het woord interpreter niet. Door daar zo groot op in te zoomen wek je de indruk alsof het hele verhaal niet klopt.

Nee, er zijn twee alinea's over 'interpreter' in zijn bericht, die beiden vrijwel compeet geschrapt kunnen worden, omdat die gewoon niet kloppen (de link die hij zelf aanhaalt, spreekt ook niet van een 'interpreter').
Het gaat over APIs, functie-aanroepen en libraries (en dat wordt in de volgende alinea's nog eens toegelicht, dus het deel van de alinea's over interpreters dat wel klopt, is overbodig). De rest is onzin.
Als je goed kijkt, zie je dat ik eigenlijk alleen het deel van de tekst aanhaal dat complete onzin is:

Om zo'n interpreter te laten werken (de specificaties van Java zijn public domain) moet je ook de aanroepen van Java functies naar de Java standaardbibliotheken meenemen.

Je kunt hier niet zomaar een ander woord voor interpreter invullen. Het zal hooguit een cirkelredenering worden. Het klopt gewoon niet.

In feite ben jij hier een andere indruk aan het wekken, door steeds maar weer door te gaan hierop.

Note: Opmerkingen als "Beter lezen" en "Knap van je" dragen niet echt bij aan een prettige discussie.

Ach gut... Jij komt eerst met een hele lange reactie op mijn post... en dan nog met dingen als "Op de een of andere manier tracht jij dat te koppelen aan gegenereerde bytecode. Wat je daarmee beoogd begrijp ik eerlijk gezegd niet."
en "Ik heb de indruk dat je je vooral vast bijt in de definitie van interpreter en niet in wat Golodh nu eigenlijk bedoelde."

En dan ga je klagen over "prettige discussie"? Kijk eerst naar jezelf, jij hebt hier de toon gezet.
En nog steeds ben je op uiterst onprettige wijze aan het doorzeuren om je gelijk te halen, nu weer met de claim over "alleen het woord interpreter".

[Reactie gewijzigd door Scalibq op 12 mei 2014 14:03]

Okee, laten we het er maar op houden dat we het niet eens zijn dan.

Da's makkelijker dan je fout toegeven he?

Als jij dat graag wil geloven, dan heb ik daar vrede mee.

@Scalibq

Je haalt e.e.a. (wat juridisch gezien de vraag is versus wat jouw mening is over interpreters en bibliothene) flink door elkaar zie ik. Maar goed, daar gaan we dan...

Om te beginnen, het enige dat hier juridisch gezien aan de orde is, is dat Google om hun eigen Java interpreter (Dalvik) te laten werken ook de bibliotheken heeft moeten her-implementeren. en daarbij alle interfaces gecopieerd heeft (en dat kan ook niet anders), en zelf de implementatie van de bibliotheken heeft geschreven.

Dat heeft absoluut niets te maken met hoe die interpreter werkt. Jouw verhaal over instructiesets en hoe interpreters werken is daarmee meteen voor 100% irrelevant.

Dat copieren van de interfaces van die bibliotheken is door rechter Alsup eerder (zoals door iedereen anders de afgelopen 50 jaar) afgedaan als niet inbreukmakend, maar door de federale rechter nu als wel inbreukmakend bestempeld.

Daar gaat het om, en niet om hoe Dalvik werkt. Dat oordeel van de Federale rechter heeft de al eerder door mij geschetste vergaande consequenties.


Je opmerkingen over hoe Dalvik werkt zijn met veel enthusiasme geschreven en op zich niet verkeerd, maar in dit verband zijn ze ook geheel niet ter zake. Weliswaar was Dalvik een onderdeel van de eerste rechtszaak onder rechter Alsup, maar daar gaat het nu (in het oordeel van de federale rechter) niet over.

Verder: als je dacht dat je een werkende Java interpreter kan maken die je zelf mag verspreiden (en zonder dat kan je Android niet verspreiden) zonder de Java bibliotheken te ondersteunen vergis je je toch echt. Die ondersteuning moet zelfs 100% zijn, want anders kan je geen compatibiliteit garanderen (oftewel Java programma's op Android zullen niet werken).

Ofwel je ondersteunt Java voor 100%, en dan moet je alle bibliotheken voor 100% ondersteunen en dus de complete Java interface specificatie, of Java programma's werken niet onder Android. Er zijn geen tussenwegen.

Je kan ook niet terugvallen op bestaande Java bytecode bibliotheken want die mag je niet verspreiden verspreiden bij je interpreter vanwege auteursrecht van Oracle.

Bovendien zijn jouw opvattingen ten aanzien van de vraag of het nu wel of niet noodzakelijk is om 100% Java compatibiliteit te bieden door de Java API's over te nemen ook irrelevant. Feit is dat Google van oordeel is dat dat wel noodzakelijk is en Android daarop gebouwd heeft. In de eerdere jurisprudentie mocht dat, nu (totdat in hoger beroep anders beslist wordt) niet meer. En daar gaat het om.

Houd s.v.p. de hoofd- en bijzaken (waar de rechtszaak over gaat versus hoe een interpreter werkt) uit elkaar wil je?

En bovendien verwar je jouw mening over wat Google wel en niet zou moeten doen niet met de juridische kwestie of het copieren van een interface-spacificatie van een stel bibliotheken nu wel of geen inbreuk maakt op het auteursrecht. Dat vertroebelt het beeld ook nog weer eens.

Om te beginnen, het enige dat hier juridisch gezien aan de orde is, is dat Google om hun eigen Java interpreter (Dalvik) te laten werken ook de bibliotheken heeft moeten her-implementeren.

Dat is nu juist het punt waar je fout zit: Dalvik danwel de JVM voeren gewoon bytecode instructies uit. Libraries zitten een niveau hoger. Jij lijkt dat niet te begrijpen.
De JVM kan prima werken met gebruik van alternatieve libraries (op een paar basisdingen na dan, die fundamenteel zijn aan Java en de JVM).
Zoals ik dus al zei: er is geen technisch excuus om vrijwel de hele Java API over te nemen.

Dat heeft absoluut niets te maken met hoe die interpreter werkt. Jouw verhaal over instructiesets en hoe interpreters werken is daarmee meteen voor 100% irrelevant.

Nee, omdat jouw post niet klopt, neem ik de moeite om uit te leggen hoe het dan WEL zit, zodat mensen snappen wat er niet klopt, en waarom. Zeer relevant dus, het is namelijk de onderbouwing van mijn stelling dat een deel van jouw post niet klopt.

Weliswaar was Dalvik een onderdeel van de eerste rechtszaak onder rechter Alsup, maar daar gaat het nu (in het oordeel van de federale rechter) niet over.

Ik beweer ook nergens dat het over Dalvik gaat. Jij komt met de stelling dat Google de Java-API wel *moest* kopieren vanwege de Dalvik-interpreter. Ik zeg *juist* dat dat niet zo is, en dus dat Dalvik inderdaad GEEN onderdeel is van deze rechtzaak, ook niet indirect.

Ofwel je ondersteunt Java voor 100%, en dan moet je alle bibliotheken voor 100% ondersteunen en dus de complete Java interface specificatie, of Java programma's werken niet onder Android. Er zijn geen tussenwegen.

Dan ben je kennelijk niet eens op de hoogte van wat Android is. Android ondersteunt geen Java. Google heeft namelijk niet ALLES van de Java APIs overgenomen. Een deel is vervangen door hun eigen APIs (zoals bv alles gerelateerd aan de GUI en graphics... iets simpels als een bitmapje inladen gaat niet via de Image class zoals bij Java, om maar wat te noemen). Java programma's draaien dus ook niet onder Android.
Frappant, dat je met zo'n stelligheid post, en eigenlijk niet eens weet waar je over praat.

Bovendien zijn jouw opvattingen ten aanzien van de vraag of het nu wel of niet noodzakelijk is om 100% Java compatibiliteit te bieden door de Java API's over te nemen ook irrelevant.

Blijkbaar niet, want jij gaat kennelijk van de (onjuiste) aanname uit dat Android 100% Java-compatible is.
Verder is de crux van jouw probleem dat je met termen als 'interpreter' loopt te schermen zonder dat je het verschil begrijpt tussen de Java Virtual Machine, en Java als programmeeromgeving.
Een JVM (wat jij dus interpreter noemt) is 100% Java-compatible als hij het Java class-formaat ondersteunt en alle Java-bytecodes correct uit kan voeren (de Java API libraries zijn ook gewoon class-bestanden, de JVM ziet geen verschil tussen deze code en willekeurige andere Java-code).

Een Java-omgeving is 100% Java-compatible als je een 100% compatible JVM hebt, en daarbij ook alle libraries hebt om de Java APIs compleet te ondersteunen.
IN het geval van Android heb je dus geen van beide:
- Men gebruikt Dalvik, die geen gebruik maakt van Java bytecode of het Java-class formaat, maar een eigen formaat heeft.
- Android implementeert een deel van de Java API, maar niet alles. Het ontbrekende deel is aangevuld door Google-specifieke APIs (zoals bv de Android Bitmap-class ipv Java's Image class).

En bovendien verwar je jouw mening over wat Google wel en niet zou moeten doen niet met de juridische kwestie of het copieren van een interface-spacificatie van een stel bibliotheken nu wel of geen inbreuk maakt op het auteursrecht. Dat vertroebelt het beeld ook nog weer eens.

Mijn mening? Ik heb helemaal nergens een mening gegeven. Waar denk jij een mening te zien dan?
Ik heb alleen gezegd dat er geen *technische* reden is voor Google om de Java API grotendeels over te nemen, dus dat het waarschijnlijk wel een *praktische* reden zal zijn. Maar het eerste deel is een feit, en het tweede deel is niet zozeer een mening als wel iets van een educated guess.

[Reactie gewijzigd door Scalibq op 14 mei 2014 21:03]

@Scalibq

Leuk verhaal, maar nog steeds 100% irrelevant, ondanks je hardnekkige (en bijziende) gelijkhebberij. Laatste poging van mijn kant.

Waar de discussie gaat over een beslissing over copyright op bibliotheek interfaces kom jij met verhalen over bytecode interpreters. Jammer dat je het onderwerp niet scherp kunt krijgen, en erg vervelend dat je de aandacht zo van de hoofdzaak weet af te leiden.

Zoals al eerder aangegeven is het enige dat juridisch van belang is de uitspraak over het al dan niet mogen copieren van library specificaties.

Al het andere is bijzaak, en in het bijzonder al je verhalen over bytecode interpreters en java-als-programmeeromgeving. Dat heeft nergens wat mee te maken. Een eigen bytecode-interpreter maken heeft Google al gedaan, en dat is ongeschonden door de rechtszaak gekomen. Daar gaat het dus niet om, ok?

Wat Google wel parten speelt is meeleveren van een Java interpreter, inclusief bibliotheken. Het interessert niemand of je hier onderscheid gaat zitten maken tussen bytecode interperters en JVM's.

Jij schijnt te denken dat je beter weet dan Google wat wel en niet nodig is voor Android. Moet jij weten, maar dat maakt jouw mening nog niet relevant.

Nog iets wat ik je al eerder getracht heb te verduidelijken: Google mag de bestaande class libraries niet meeleveren. Copyright! Dus moeten ze die dingen zelfstandig her-implementeren, ok?

Ik had verwacht dat je dat zelf ook wel zou snappen. Natuurlijk kan je de hele rotzooi copieren, maar dat is geen optie.

Als je zonder direct te copieren Java bibliotheek-calls will kunnen afhandelen dan moet je (ook "technisch gezien") de classes opnieuw schrijven. Ongeacht irrelevante haarkloverijen over bytecode interpreters versus JVM's. Voor een eindgebruiker is er maar 1 interpreter: de JVM.

Voor de derde maal: dat is allemaal vonstrekt irrelevant ten aanzien van de vraag of ze die classes nu wel of niet zelf moeten her-implementeren.

Waar de discussie gaat over een beslissing over copyright op bibliotheek interfaces kom jij met verhalen over bytecode interpreters.

Nee, *jij* komt met een verhaal over interpreters:

Als je je ook maar een beetje in de zaak verdiept had, dan had ook jij gesnapt dat het hier gaat om het maken van een interpreter voor Java ("Android included Google's own implementations of some of the APIs from Java SE." : zie https://en.wikipedia.org/wiki/Oracle_v._Google ).

Zoals ik elders al zei: de pagina waar je naar linkt, praat helemaal niet over interpreters.
(Let ook op: ze spreken van 'some of the APIs from Java SE', niet alles dus, het is geen 100% kopie van Java, zoals ik al zei).

Jammer dat je het onderwerp niet scherp kunt krijgen, en erg vervelend dat je de aandacht zo van de hoofdzaak weet af te leiden.

Beetje zielig om me zo persoonlijk te gaan aanvallen. Ik reageerde helemaal niet op de hoofdzaak. Dat staat niet ter discussie. Het ging mij erom dat je verwijzing naar de interpreter onjuist is. Daar gaat het hier niet om, alleen om de libraries en APIs.

Een eigen bytecode-interpreter maken heeft Google al gedaan, en dat is ongeschonden door de rechtszaak gekomen. Daar gaat het dus niet om, ok?

Over 'niet scherp krijgen' gesproken... Ik had al eerder gezegd dat het los stond van de rechtzaak.

Wat Google wel parten speelt is meeleveren van een Java interpreter, inclusief bibliotheken.

Voor de zoveelste keer: Google levert helemaal geen Java interpreter mee. Dalvik spreekt een ander taaltje (zie ook https://source.android.co...lvik/dalvik-bytecode.html . Meest in het oog springende verschil is dat Dalvik register-based is, terwijl de JVM stack-based is).
Daarnaast, welke APIs of zelfs welke programmeertaal je erbovenop gebruikt, zal de interpreter worst wezen, ook de JVM zelf.
Jij probeert Google hier te verdedigen, maar dat lukt dus niet op technische gronden.
Er is ten eerste geen reden voor Google om voor Java te kiezen als programmeertaal voor Android. En ten tweede, zelfs al zou men dat kiezen, dan nog is er geen reden om de Java APIs te gaan klonen.
Vanuit ethisch oogpunt is het op z'n minst niet zo netjes van Google om zomaar Java te gaan gebruiken zonder daar ook maar enigszins met Oracle over te onderhandelen en afspraken te maken.

Jij schijnt te denken dat je beter weet dan Google wat wel en niet nodig is voor Android. Moet jij weten, maar dat maakt jouw mening nog niet relevant.

En weer die persoonlijke aanvallen. Sowieso, waar slaat deze opmerking op? Ik beweer helemaal nergens "wat er wel en niet nodig is voor Android".
En nogmaals, waar verkondig ik uberhaupt een mening dan?

Nog iets wat ik je al eerder getracht heb te verduidelijken: Google mag de bestaande class libraries niet meeleveren. Copyright!

Natuurlijk mag Google de bestaande libraries niet meeleveren. Dat doen ze toch ook niet? Waarom begin je hier uberhaupt over? Volgens mij snap je nog niet de helft van waar ik het hier over heb.

Dus moeten ze die dingen zelfstandig her-implementeren, ok?

Okee, blijkbaar had ik je overschat. Ik nam aan dat je zelf ook wel kon verzinnen dat Google best een eigen API had kunnen ontwikkelen voor Android. Ze *moeten* helemaal niks. Sowieso is Dalvik al geen JVM. En zelfs als het dat was, dan nog hadden ze een eigen API erop kunnen bouwen. Het was hun keuze om (delen van) Java te gaan gebruiken, in plaats van zelf iets te ontwikkelen.
Apple en Microsoft hebben toch ook gewoon eigen APIs ontwikkeld voor hun smartphone OSen? Dat is wat Google ook beter had kunnen doen, ipv leentjebuur spelen bij Oracle.

Als je zonder direct te copieren Java bibliotheek-calls will kunnen afhandelen dan moet je (ook "technisch gezien") de classes opnieuw schrijven.

Heb je over de helft van m'n post heengelezen of zo? Het doel van Android is helemaal niet om alle Java library calls te kunnen afhandelen. Ze hebben slechts een deel van de APIs overgenomen, waardoor je sowieso Java-applicaties moet herschrijven.

Ongeacht irrelevante haarkloverijen over bytecode interpreters versus JVM's. Voor een eindgebruiker is er maar 1 interpreter: de JVM.

Uhh wat?
Ten eerste is een JVM een vorm van een bytecode interpreter. Dus met "bytecode interpreter vs JVM" geef je weer de indruk dat je het niet begrijpt.

Ten tweede, er zijn wel degelijk meerdere interpreters, want Android gebruikt dus geen JVM, maar Dalvik. Dalvik spreekt dus GEEN Java bytecode, maar een eigen taaltje. Je kunt wel Java bytecode converteren naar Dalvik. Maarja, dergelijke oplossingen bestaan er ook voor bv .NET, die ook weer een eigen bytecode-taaltje heeft.

Ten derde, het zal de eindgebruiker allemaal worst wezen, de meesten weten niet eens dat Android-apps in de programmeertaal Java geschreven worden... of dat een JVM of Dalvik uberhaupt bestaan. Dat is allemaal transparant voor de eindgebruiker.

Voor de derde maal: dat is allemaal vonstrekt irrelevant ten aanzien van de vraag of ze die classes nu wel of niet zelf moeten her-implementeren.

Lees eens een keer goed: ik heb het helemaal niet over her-implementeren. Eerder over het ontwikkelen van een eigen API.

[Reactie gewijzigd door Scalibq op 15 mei 2014 11:33]

Amen, precies wat ik wilde zeggen. Alleen dit is (heel wat) duidelijker verwoord.

Tja, maar elk stuk software wat je ontwikkeld kan een bedrijf als Microsoft je voor aan klagen. De kans is groot dat je namelijk stukken hetzelfde hebt. Bewust of onbewust.

Verder als je commercieel gaat is het verstandig om de broncode niet vrij te geven. En geheim te houden.

Wanneer een grote organisatie dat dan (bewust) gebruikt zijn ze schuldig aan heling, of direct diefstal.

Hoogstens kunnen ze het her implementeren. Maar ja alle software is een her implementatie van het een of het ander. Een bijeen geraapt zooitje spul

Sofware patenten moeten per direct en absoluut verboden worden.

Onmogelijk. Deze patenten staan voor tientallen miljarden Dollars/Euro's te boek binnen beursgenoteerde bedrijven. Veel van deze bedrijven zouden (met hele bedrijfstakken) zouden ten over gaan en als de wereld economie iets niet gebruiken kan is het een dergelijk ingreep op dit moment.

Dat software patenten geen goede zaak zijn ben ik met je eens. Maar direct en absoluut verbieden in eenvoudig onmogelijk.

De huidige boekhoudregels slaan ook wekelijk waar nergens op. Maar dat is een heel andere discussie.

Daarnaast kunnen ze in Europa nog niet voor veel te boek staan ze zijn immers hier niet mogelijk. (indirect weer wel, maar dat is een andere discussie).

Het is en blijft een software patent.

Het gaat hier niet over patenten, maar over copyright. Dat is niet geheel hetzelfde, of eigenlijk helemaal niet. Bij het schenden van een patent bouw je dezelfde functionaliteit. Dit gaat eigenlijk nog iets verder. Hier hebben ze niet alleen de functionaliteit nagebouwd, maar dan ook vrijwel identiek geimplementeerd.

Sofware patenten moeten per direct en absoluut verboden worden.

Heel deze zaak heeft niks met softwarepatenten te maken maar met auteursrechten...

Het is en blijft een software patent.

Copyright heeft niets, maar dan ook niets met patenten te maken, je hele comment slaat dan ook nergens op.

[...]


Copyright heeft niets, maar dan ook niets met patenten te maken, je hele comment slaat dan ook nergens op.

Gelukkig maar dan dat jij ons hier gelijk van een breed onderbouwd commentaar voorziet dan, bedankt voor je uitmuntende bijdrage aan deze discussie.

maargoed...

Patent is wel degelijk een vorm van copyright. Het verschil is alleen dat copyright een wettelijk recht is, terwijl een patent officieel is goedgekeurd moet worden door een octrooibureau en waar je als rechthebbende voor moet betalen.

Patent is helemaal niet een onderdeel van copyright. Totaal verschillend, is is niet "alleen dat". Patent gaat bv ook helemaal niet over broncode (zoals copyright dat wel over gaat). Patent is iets abstracts.

Je vergelijkt een recht dat rechtswege ontstaat (copyright) met iets waarvoor je moet betalen. De origine is anders, de werking is anders, de betekenis is anders, ze staan in een ander wetboek.

Copyright krijg je vanzelf en hoef je niet te publiceren. Het is er gewoon, punt uit. Een patent moet je kopen.

Dat is bijna letterlijk wat er in mijn post staat, dus wat is je punt?

Sofware patenten moeten per direct en absoluut verboden worden.

Ja dat is handig dan laat je iemand anders een programma schrijven en hoef jij alleen je eigen naam er maar onder te zetten.

Het is toch logisch dat iemand die ergens veel tijd en energie in gestoken heeft, dit ook wil kunnen beschermen.

Een compleet software pakket valt onder copyright.

Wanneer je iets namaakt (en laten we eerlijk zijn dat gebeurd erg vaak). Hoeveel CMS systemen zijn er? In basis allemaal hetzelfde.

Dat laatste is iets heel anders dan een stuk software als van jezelf uitgeven. Google heeft iets na gemaakt, volledig zelf. Zo veel mogelijk compatible met java (omdat dat nu eenmaal handig is).

Een API maken waar de Math.Round niet in math zit of geen round heet als programmeer api is natuurlijk niet makkelijk werken.

"Mathe.Roundi" nou ja dat zou makkelijk werken.

Ik zie het al gebeuren in de toekomst:
je mag alleen nog maar wrappers maken die verwijzen naar je eigen implementatie vb:

Math,Round(){
return lib.MyRound();
}

Want die zin komt ook in mijn boek voor...

Ik zou geen MyRound() gebruiken want dat heeft ACME Corp al gebruikt. Tip: gebruik een GUID als methode naam, kans is extreem klein dat die al eerder is gebruikt.

Ik hoop maar dat Google in beroep gaat tegen dit bezopen oordeel. Is er eigenlijk geen jurisprudentie op dit gebied, dit komt toch bij boeken ook veel voor? Boek met zelfde titel (b.v. Verliefd), zelfde indeling (Hoofdstuk 1, Hoofdstuk 2, ...), zelfde opbouw (inleiding, kern, slot), zelfde thema (verliefdheid), zelfde doel (verhaal vertellen) en zelfde doelgroep (jongeren).

Is dat dan copyright schending als de invulling van het boek zelf totaal anders is? Als er copyright zit op de structuur en opbouw van auteursrechtelijk beschermd werk dan gaat er nog een hele beerput open. Microsoft kan dan dus gerust Wine aan gaan klagen wegens het schenden van copyright op de Windows API.

Mijn mening is dat je wel over een game of een programma een patent mag aanvragen, maar niet op een stukje code of iets dergelijk...

als ik het goed gelezen heb gaat het om bepaalde stukken code (correct me if im wrong)

Dus als je in java een stuk code schrijft voor (ik zeg maar wat) een rekenmachine voor in een game.
als dat dan de beste/efficientste manier is om een rekenmachine te maken dan vind ik dat je dat gewoon in je eigen programma mag gebruiken en dat op dat soort dingen geen copyright mag komen.

Lekker kort door de bocht.

Het is en blijft een software patent.
(...)

Nog maar eens lezen dan. Dit gaat over copyright, een recht dat iedere auteur automatisch toekomt, en heeft helemaal niets met patenten te maken.

Ik vind dat behoorlijk kort door de bocht.

De uitspraak betreft het gebruik van methode namen van 37 API packages welke 3% van de codebasis vormen - Google heeft de overige 97% (overigens beslaat die 97% de daadwerkelijke uitvoerende code!) zelf gerealiseerd. Let op, dit gaat alleen maar over de API packages - niet om de rest van het systeem! De betwiste inbreuk is zeer klein ten opzichten van het gehele systeem.

Het is in zekere mate noodzakelijk om sterk vergelijkbare code te gebruiken om compatibiliteit te waarborgen, dit is ook de overweging die in 2012 heeft geleid tot de uitspraak dat Google geen inbreuk zou maken op rechten van Oracle.

Gezien de redenen (API compatibiliteit), een voorgaande tegengestelde uitspraak en de eigenschap van de betreffende "inbreuk" (methode name) vind ik het belachelijk te stellen dat Google "de zaak bij elkaar heeft geraapt" en dus "terecht zitten op de blaren". Zeker gezien de idiote staat van het patentensysteem!

[Reactie gewijzigd door ThaRabbit op 9 mei 2014 21:32]

Het is in zekere mate noodzakelijk om sterk vergelijkbare code te gebruiken om compatibiliteit te waarborgen, dit is ook de overweging die in 2012 heeft geleid tot de uitspraak dat Google geen inbreuk zou maken op rechten van Oracle.

Het probleem is ook niet dat ze iets gebruiken of hergebruiken, maar dat ze bepaalde auteursrechten van Oracle schenden. Prima als ze die code absoluut willen/moeten gebruiken, en dan is er niets wat hun tegenhoudt om daarvoor een licentie aan te gaan.

Dat het om 3% gaat doet er verder niet toe. Als ik als fotograaf een foto maak, en een krant wil die gebruiken, maakt die nog veel minder dan 3% van het geheel uit, maar moet de krant mij nog steeds voor die foto betalen. En zo gaat het overal met zaken die auteursrechtelijk beschermd zijn.

Ik ben het volledig met je eens dat de mate van inbreuk in wezen niet van belang is op het moment dat inbreuk is vastgesteld, ik heb het dan ook voornamelijk vermeld om de situatie te verduidelijken. Ik had de indruk dat diegene waarop ik reageerde geen volledig plaatje van de situatie had.

Of naamgeving van methods onder te licenseren code valt staat, zover ik de zaak heb gevolgd, nog ter discussie. Maar dat slaat terug op de al jaren lopende discussie over het patenten systeem - allicht hier niet de beste plaats voor.

Om een link te leggen naar je foto analogie: Als jij je foto "hutje op de heide" noemt en ik noem een vergelijkbare (maar toch wezenlijk andere en zelf geproduceerde) foto hetzelfde - ben ik dan fout?

Een API gaat verder dan 'naamgeving', het beslaat een structuur waarover nagedacht is. Door het te vergelijken met de naam van een foto gaat je analogie echt helemaal de mist in.
Door een API (voor een groot deel) over te nemen maak je natuurlijk gebruik van het werk van degene voor jou. De discussie moet er dan ook niet over gaan of het inbreuk is, maar of er een vergoeding aan vast hoort te zitten.
Om bij de belabberde foto-analogie te blijven; het gebruik van die foto in een publicatie zonder vergoeding is duidelijk fout. Het gebruik in een nieuw kunstwerk, bv met snippets van iconische foto's is het afhankelijk van de omstandigheden of je geld moet betalen.

Google heeft duidelijk gebruik gemaakt van de fundering die Sun met Java heeft gemaakt. Was het zoveel dat ze copyright-vergoedingen verschuldigd zijn aan de nieuwe eigenaar? En dat is ook precies wat nu is besloten: het copyright is duidelijk geschonden, dus ga nu kijken of dit onder fair use viel...

[Reactie gewijzigd door curumir op 10 mei 2014 12:27]

Vanzelfsprekend gaat een API verder dan naamgeving, echter:

nieuws: Rechter: Android schendt geen Java-copyright van Oracle

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

Oké, laten we het zo doen.
Op je volgende tentamen schrijf je 97% zelf en de resterende 3% schrijf je over van je degene die naast je zit. Veel plezier met je argumenten.

Of: ja meneer de politie-agent, ik reed hier even 40km/u te snel, maar globaal gezien reed ik gedurende 97% van de tijd onder de snelheidslimiet hoor

Who cares? Het mag niet. Geen 3% geen 1%.

Als je de posting uit 2012 doorleest zie je dat het toch net wat anders ligt:

De functionele code (of de opgaven op je tentamen) schrijf je zelf, het enige wat jij overschrijft van je buurman is de structuur die hij volgt om de opdrachten aan te geven. Dit doe je zodat een externe partij bij zowel jou als je buurman dezelfde opdrachtaanduiding ziet. (compatibiliteit)

Je schrijft dus, net als je buurman, op:
"Tentamen Wiskunde: Opdracht 1a"

De opgave zelf voer je helemaal zelf uit!

Als jij de uitwerking helemaal (of zelfs maar voor een deel) over had gepend was je vanzelfsprekend helemaal fout bezig geweest, maar dat heb je niet gedaan. Je hebt de opdrachtaanduiding overgenomen.

De vraag of dat ook fout is is, gezien de vorige uitspraak, schijnbaar nog niet duidelijk.

Zo heb ik de situatie uit de verschillende artikelen begrepen, shoot me if I'm wrong.

Het gaat er niet om of het nu een tekst, titel, omschrijving, bijschrift, ondertitel of aantekening is. Er zit een copryright op.

Natuurlijk kan je niet een boekje schrijven met de zin. "Jantje ging naar de winkel" en dan een copyright claimen.

Maar als jij veel werk gehad hebt aan de indeling van je boek, kan daar prima een copyright opzitten omdat het een specifieke verzameling van zaken is.
Zo valt wat een telefoonboek ook onder copyright, omdat het geheel van de verzameling een copyright heeft.

Als je wil dat iets "compatibel" is, dan heb je de permissie nodig van de originele uitgever. Je kan bijvoorbeeld niet zomaar een boek gaan vertalen of in PDF zetten zonder toestemming van de schrijver voor winst. Ook niet om het compatibel te maken voor een iPad of weet ik veel.

In dit geval heeft Google zelf opnieuw een foto gemaakt van dat hutje op de hei. Vanuit hetzelfde gezichtspunt zodat de foto er hetzelfde uitziet.
Deze hebben ze dan in de krant gezet.

Dat hangt ervan af of de titel van de foto onder het auteursrecht van die foto valt of niet. Of in jouw concrete voorbeeld, of het om een geheel gaat of niet. Bij een fictief voorbeeld is dat natuurlijk niet te bepalen.

En ik begrijp ook wel dat sommige zaken in deze case nog ter discussie staan. Mijn punt was vooral dat zowel die 3% als het feit (of die noodzakelijkheid) dat google's code complementair moet zijn, eigenlijk niet ter zake doet. Beide zaken spreken niet in het voor of nadeel van Google noch Oracle.

Maar wat als jij een foto maakt en de krant plaatst een andere foto waarvan 3% gelijk is aan jouw foto, moeten ze je dan nog steeds betalen of valt die 3% gelijkenis onder fair-use? Dat is waar het om gaat.

Maar wat als jij een foto maakt en de krant plaatst een andere foto waarvan 3% gelijk is aan jouw foto, moeten ze je dan nog steeds betalen of valt die 3% gelijkenis onder fair-use? Dat is waar het om gaat.

Nee, dit is niet waar het om gaat. Fair use is heel wat anders. Mogelijk bedoel je de minimis gebruik, wat ook in deze zaak aan de orde is gekomen en verworpen is. Wat er aan de orde is is of het mogelijk is copyright the hebben op een API.

Dan heb je het wel over iets heel anders. Dan heb je het mogelijk over plagiaat. 3% van iemands werk overnemen (of het nu om een foto gaat of om tekst of om code) kan in sommige gevallen erom draaien dat je rechtstreeks iemands auteursrechten schendt, maar ook dat het om plagiaat gaat. In dat geval heb je ook wel degelijk toestemming nodig om die foto te mogen gebruiken. Zeker bij softwarecode is er niet enkel sprake van schending van het auteursrecht wanneer je enkel het geheel overneemt (zonder toestemming), maar mogelijk ook wanneer je delen van de code overneemt.

Fair-use kan je eerder vergelijken met het citeren van andermans werk in een publicatie die op zichzelf staat. Zo mag je gerust shakespeare citeren, maar wanneer je in die publicatie onterecht (on zonder toestemming) laat uitschijnen dat het om jouw woorden gaat, overtreedt je weer de auteursrechtwetgeving.

Op hoeveel manieren kun je een triviale functie inprogrammeren en hoeveel namen kun je deze geven?

Als je functie "max(int x, int y)" heet dan betekent dit toch niet dat de volgende programmeertaal verplicht is om "maximum" te kiezen en de derde "higher" en de volgende "noideaeverynameistakenlol"?

Zeker gezien de idiote staat van het patentensysteem!

dat is compleet off topic: het gaat hier niet om softwarepatenten maar om auteursrecht (copyright).

Blaten kan je, maar ken je de feiten ook? Geen idee waarvan jij nu weer fanboy bent of dat je alleen tegen Google bent, maar Android is echt al jaren in ontwikkeling en echt niet zomaar bij elkaar geraapt. Dus praat alsjeblieft niet zulke onzin.

In de VS er is ook zoiets als algemene "looks and feel" van apparaat/merk waar je rechten aan kan ontlenen, zo houd fluke alle multimeters tegen met geel met zwarte behuizing al lijken ze niet op fluke meters, en alles is verder zelf ontworpen aan die multimeters, en is ook niet omdat fluke patent heeft op geel met zwart maar op algemeen merk uiterlijk. Mag niet meeliften op looks and feel van andere merk.

Weet niet zo goed of wij in Nederland ook zoiets kennen, al mag je hier natuurlijk ook niet zomaar huisstijl overnemen van ander merk, maar weet niet of wij ook zover gaan als de VS.

Even voor de volledigheid, het gaat dan over het verhaal SparkFun - Fluke.
Hier de oorzaak: https://www.sparkfun.com/news/1428
Hier de oplossing: https://www.sparkfun.com/news/1430

tl;dr: Die multimeter leek ook wel erg veel op eentje van Fluke, en dat is echt niet per toeval. SparkFun had beter voor rood/zwart kunnen kiezen (al zijn er ook multimeters in die kleurstelling te vinden) daar dat toch ook beter bij hun branding past. Dat er vervolgens nog eens tientallen andere DMMs zijn die wel erg veel op Flukes lijken, en ook gewoon in de V.S. verkocht worden, wil toch wel zeggen dat de import blokkade nogal vaak faalt, en het dan bedenkelijk is om 'm toch maar de blijven handhaven.

Maar goed, dit ging eigenlijk over een heel ander onderwerp, namelijk of de API methode namen tot zoverre ook onder copyright vielen dat een ander bedrijf kan worden aangeklaagd om het gebruik van die methodenamen. De een is copyright, de andere 'trade dress'-achtige zooi.

Nou vind ik wel dat beide zaken stompzinnig zijn, maar da's een tweede.

Enkel de beschermhoes van Fluke is geel,net zoals het geval is bij zovele merken multimeters.
Benning is overwegend rood en Gossen Metrawatt groen

In de VS er is ook zoiets als algemene "looks and feel" van apparaat/merk waar je rechten aan kan ontlenen

dat bestaat hier ook hoor

wij kennen in nederland ook zoiets. Heb geen idee hoever het in de VS gaat en in NL wisselt het ook nogal. Het idee is dat de gebruikers niet in verwarring moeten kunnen raken tussen de twee producten. Wanneer daar sprake van is.... dat hangt er maar net vanaf wie je het vraagt.

Waanzin!

Vraag me geregeld af wat er voor nodig is dat wetgevende en rechtsprekende machten eens wakker worden en dit hele bizarre concept van intellectueel eigendom eens tot op de grond toe afbreken.

Informatie is van nature 'vrij'. Het hele concept van leven is gebaseerd op die vrijheid. Vrije verspreiding van informatie zit letterlijk in ons dna.

Intellectueel eigendom vormt een kunstmatig monopolie waar een samenleving niet bij gebaat is. Het hele concept monopolie maakt dat iets ten goede komt van een enkeling, ten koste van alle anderen. Hoe onethisch wil je het hebben...

[Reactie gewijzigd door kalizec op 10 mei 2014 00:09]

Informatie is van nature 'vrij'. Het hele concept van leven is gebaseerd op die vrijheid. Vrije verspreiding van informatie zit letterlijk in ons dna.

Informatie is geen wezen en kan dus helemaal niet vrij zijn. Dat is een ver gezocht hoogdravend concept waar de mensheid niet mee gediend is. Geheimen moeten er ook zijn (wachtwoorden, pin codes ect). Intellectueel eigendom maakt kennis en artistieke prestaties vermarktbaar, dat maakt dat deze commercieel interessant zijn om te produceren en daar is de maatschappij zeer bij gebaat. Een wereld zonder intellectueel eigendom zou cultureel nagenoeg leeg zijn. Je krijgt dan de grijze slavenwerelden die je in donkere SF films ziet. Met als enige lichtpuntje dat die donkere SF films dan ook niet meer gemaakt worden.

Informatie is geen wezen en kan dus helemaal niet vrij zijn.

Alle wezens zijn informatie. Dat is wat ze tot individu maakt. Niet de materie waar ze uit opgebouwd zijn.

Geheimen moeten er ook zijn (wachtwoorden, pin codes ect).

Geheimen hebben niets met intellectueel eigendom te maken.

Intellectueel eigendom maakt kennis en artistieke prestaties vermarktbaar, dat maakt dat deze commercieel interessant zijn om te produceren en daar is de maatschappij zeer bij gebaat.

Ik stel voor dat je eens gaat lezen waarom Intellectueel eigendom ooit in wetgeving is opgenomen. Het antwoord is censuur (copyright) en macht (patent). En het had niets met vermarktbaarheid te maken; laat staan dat het ten bate kwam van de samenleving van dat land.

Een wereld zonder intellectueel eigendom zou cultureel nagenoeg leeg zijn. Je krijgt dan de grijze slavenwerelden die je in donkere SF films ziet. Met als enige lichtpuntje dat die donkere SF films dan ook niet meer gemaakt worden.

Alsof er nooit cultuur is geweest voor de uitvinding van 'intellectueel eigendom'... Het feit dat er zat cultuur bestond voor de uitvinding van zaken als copyright en patentrecht bewijst je ongelijk. Of heeft volgens jou de renaissance nooit plaatsgevonden?

[Reactie gewijzigd door kalizec op 11 mei 2014 00:31]

Geheimen hebben niets met intellectueel eigendom te maken.

Klopt maar het betrekt zich op je vrije verspreiding van informatie. Zoiets simpels als een paswoord toont al aan die vrije verspreiding van alle informatie een onhaalbaar concept is.

waarom Intellectueel eigendom ooit in wetgeving is opgenomen. Het antwoord is censuur (copyright) en macht (patent).

Censuur is niet altijd slecht (de examen antwoorden krijg je ook pas na het examen) en patenten zijn zo ongeveer de drijfveer van technologische ontwikkeling.

Het feit dat er zat cultuur bestond voor de uitvinding van zaken als copyright en patentrecht bewijst je ongelijk.

Maar intellectueel eigendom bestond al lang voor dat we dat netjes in wetten hadden vastgelegd. Je hebt een professor in de Rembrandtoligie nodig om het verschil te zien tussen een werk van Rembrandt en dat van 1 van zijn leerlingen en toch is het verschil in waarde enorm. Simpelweg omdat de kopie minder waard is dan het origineel.

[Reactie gewijzigd door mashell op 11 mei 2014 11:26]

Waanzin!

Vraag me geregeld af wat er voor nodig is dat wetgevende en rechtsprekende machten eens wakker worden en dit hele bizarre concept van intellectueel eigendom eens tot op de grond toe afbreken.

Het mag wat bij betreft wel een heel eind, maar tot de grond toe gaat me wat ver. Als software developer wil ik in principe ook graag betaald worden. Er zijn open source business modellen, maar heel succesvol zijn die nog niet. Zoals het nu is is het belachelijk, en het moet helemaal anders, maar alle software in principe vrij gaat me ook weer te ver.

True, echter door android is java ook weer populairder geworden.
Het is een wisselwerking.

De look & feel van code is wel een zeer nieuw gevoel voor me :-). Om dat nu met een (tastbare) multi-meter te vergelijken?

Als de implementatie van methoden verschilt, en alleen de naamgeving gelijk is, zie ik veel meer parallellen met een auto. Of fiets. Min of meer noodzakelijkerwijs zitten er altijd een aantal banden en een stuur op. En een leek zou kunnen zeggen dat alle auto's op elkaar lijken. D.w.z. de methoden zijn gelijk, maar de implementatie is verschillend (al valt dat bij auto's soms ook een beetje tegen, want er zijn van bepaalde onderdelen slechts een zeer beperkt aantal fabrikanten). Er zijn genoeg voorwerpen waar de indeling vaak van triviale eenduidigheid is.

Iemand die programmeert zal altijd dingen herkennen van een collega programmeur (bijv. het gevoel dat sommige code 'stinkt'). Zoiets is toch allemaal een soort 'common sense'. Daar valt ook naamgeving van methods en functies onder. Je zult daar bij veel soortgelijke code ook soortgelijke naamgeving aantreffen. Praktisch voorbeeld: van strings zijn een hele rij verschillende implementaties, en een hele rij daarvan heeft een substr(), substrin() of sub() methode. Copyright op implementatie, dat is terecht. Copyright op naamgeving van functies is m.i. onterecht. Naamgeving zegt verder niets over de implementatie, maar wat de method hoort te doen.

Het concept sturen is misschien wel triviaal maar het stuur zoals we dat nu kennen in een auto niet. (zie hiervoor ook de engelse wiki) Destijds was het stuur een echte vinding en patenteerbaar. Het copyright zat vast alleen op de tekeningen van de stuurkolom (als de uitvinder die al maakte )

Helemaal mee eens! Mooie vergelijking ook met een auto. Als je een virtuele auto zou programmeren, zou je ook zeker het abstracte object 'stuur' maken, met functies 'draai rechts' en 'draai links' of iets in die trend. De implementatie van 'stuur' tsjah, die kan verschillen en patenteerbaar zijn. Om terug te gaan naar de concrete wereld: als jij een slim mechaniek hebt bedacht met (ik noem maar wat) stuurbekrachtiging, dan is dat een mooie innovatie die patenteerbaar moet zijn. Idem voor code wat mij betreft. En als ik dan een bepaald stuur gepatenteerd heb, kan ik ook niet anderen aanklagen dat ze óók een (totaal ander) stuur hebben gemaakt dat naar links en naar rechts kan draaien. Dat zou bizar zijn!

Android is een opvername van google geweest uit 2005: Wikipedia. Het is dus niet snel door Google bij elkaar geraapt (ik neem aan dat er in 2005 ook iets was dat over te nemen viel aangezien het bedrijf in 2003 al bestond).

[Reactie gewijzigd door joop99 op 9 mei 2014 21:25]

In 2005 bestond Dalvik (en daar gaat het hier om) nog niet, dat project is pas 2006/2007 gestart (http://uke.livejournal.com/25660.html) en is pas later door Google overgenomen in Android.

"...Oracle liet vrijdag weten dat het oordeel van het gerechtshof 'een overwinning is voor de complete software-industrie die afhankelijk is van het auteursrecht om innovatie te bevorderen..."

Moest ff een halfuurtje over de vloer rollen van het lachen...

Ja, dit statement van Oracle staat wel zo haaks op de werkelijkheid... dit soort zaken houdt innovatie juist tegen. Maar ja, de innovatie die Oracle bedoelt is hún 'innovatie', van anderen opkopen en dan de betreffende producten gaan uitbaten d.m.v. dit soort rechtszaken.

Persoonlijk ben ik van mening dat copyright alleen rust op de documentatie en de implementatie van een API.

Google en andere oppositiepartijen vinden daarentegen dat er moet worden gekeken naar de functionaliteit van de code, en niet naar de creativiteit.

Dus Google vindt dat creativiteit niet onder het auteursrecht zou mogen vallen ...
Da's lekker dan voor iedereen die van creativiteit z'n beroep heeft gemaakt en nu nog enigzins wordt beschermd door het auteursrecht. Alle kunstenaars worden door Google hiermee in een klap vogelvrij verklaard.

Nee, je moet even beter lezen waar t precies om gaat. Als je de uitspraak leest wordt het een stuk duidelijker wat Google precies bedoeld.

Zie het zo... Als jij een schilderij maakt van een brug, dan is dat creatief; doch niet perse functioneel.
Nu maak ik een schilderij van dezelfde brug, maar ik voeg wat details toe en gebruik iets andere kleuren. Iets minder creatief omdat t dezelfde brug e.d. is, maar even functioneel.

... Doch volgens Oracle zou ik jou copyright schenden omdat ik een tekening heb gemaakt van dezelfde brug. (De API bridge )
Het is dus niet Google maar Oracle die kunstenaars vogelvrij verklaard.
Deze hele zaak is belachelijk en Oracle had nooit mogen winnen. Dit is een extreem gevaarlijke uitspraak voor de hele markt, vooral opensource gaat er van ten onder zo.

Die vergelijking slaat nergens op, in dit geval *is* de brug van Oracle.

Als ik een tekening maak van de brug van San Francisco, schend ik dan het copyright van de architect?
Let namelijk wel, Google's code was in vele gevallen zelf herschreven; alleen het *effect* was precies hetzelfde. En daar rust dus, blijkbaar, copyright op. Komt geen patent aan te pas.

[Reactie gewijzigd door WhatsappHack op 11 mei 2014 01:56]

innovatie is het al zeker niet. ook The Economist oordeelt zo, en die kan je bezwaarlijk anti-innovatie noemen. copyright is nu vooral een manier om innovatie tegen te houden. je moet het warm water telkens weer uitvinden. efficiënt is anders...

Copyright betekent dat andere mensen jouw werk niet mogen klonen, maar hun eigen werk moeten schrijven. Als het oorspronkelijke werk zo waardevol is, dan betaal je de maker ervoor. Dat is het toppunt van innovatie.

[Reactie gewijzigd door Dreamvoid op 11 mei 2014 01:43]

En terecht, een bel of achterlichtje van een fiets stelen is misschien ook iets van (0,?) 3 procent, het blijft diefstal.

Alleen heeft Google allang de betreffende 3% van de code die wél inbreuk maakte verwijderd, waardoor de zaak eigenlijk één grote poppenkast is (als het dat niet al was).