Amerikaanse rechtbank: Gebruik van Java API in Android is fair use

aapje-api.pngNa twee weken was de jury er snel uit: wat Google deed met de Java API in Android is een “fair use” onder het Amerikaans auteursrecht, derhalve worden geen rechten van Java-eigenaar Oracle geschonden. Dat las ik bij Ars Technica. Google en Oracle liggen al een paar jaar in de clinch over de vraag of (kort gezegd) Google een herimplementatie van Java-functionaliteit mag doen als ze daarbij de API-definities overtypt uit de specificaties van Oracle. Oracle vond van niet en eiste diverse miljarden schadevergoeding.

In 2014 werd nog bepaald dat Android wél inbreuk maakte op de rechten van Oracle. De aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn creatieve keuzes die de resulterende api een auteursrechtelijk beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Althans, in principe. Dit is immers recht: er is altijd een uitzondering mogelijk. Omdat Google ongelijk had gekregen op het punt van de auteursrechten (zij hadden gezegd dat er geen auteursrecht zit op een API) was de rechtbank niet toegekomen aan de vervolgvraag of een wettelijke uitzondering op het auteursrecht zou gelden. Dat moest dus alsnog worden bepaald, en bij deze: fair use.

Fair use is een open norm in het Amerikaans auteursrecht. Alles kan fair zijn als je maar kunt uitleggen waarom. Er zijn dan vier factoren:

  1. Het doel en karakter van het gebruik, inclusief de vraag of het gebruik commercieel is of educatief en non-profit;
  2. De aard van het beschermde werk;
  3. De omvang en de scope van het overgenomen deel in verhouding tot het beschermde werk als geheel; en
  4. Het effect van het gebruik op de potentiële markt voor of waarde van het beschermde werk.

Helaas komt dat in dit vonnis niet heel goed uit de verf. Het was een jury-oordeel en die komen niet verder dan “inderdaad, dit is fair.” De jury-instructies geven mij de indruk dat het vooral zal zijn gegaan om de aard van het werk: als Google een eigen herimplementatie mocht doen van de functies, dan móet ze wel de API overtypen anders is haar werk volslagen onbruikbaar. Maar het is nog even afwachten hoe een en ander in vonnis wordt gegoten. En natuurlijk gaat Oracle in hoger beroep.

In Europa ligt het anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt.

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

We hebben nu dus twee systemen: in Amerika zit er auteursrecht op een API máár is hergebruik daarvan fair use, en bij ons zit er geen auteursrecht op een API dus leef je uit, qua hergebruik.

Is Java op Android eigenlijk nog wel belangrijk? Ik zie nooit meer Java-applicaties op dat platform.

Arnoud

28 reacties

    1. Wat ik begrijp is dat de Dalvik VM niet JVM compatible is en dat daarom het hele ontwikkelplatform ook geen (door Sun) erkende Java is. Google vond het niet nodig om 100% van de Java features te implementeren voor Android.

      1. Correct. Maar we hebben tegenwoordig de Android Runtime als vervanging voor Dalvik. Daarnaast verwacht ik ook veel van de Low Level Virtual Machine waar Apple ook een drijvende kracht is maar die misschien ook voor Android gebruikt gaat worden.

        Het verschil tussen Dalvik en ART is dat ART al de bytecode compileert op het moment van installatie en Dalvik pas op het moment van uitvoeren. Vandaar dat apps tegenwoordig iets beter presteren.

        De meeste Android Apps werden gemaakt in Java en gecompileerd naar bytecode. Die bytecode kan door Dalvik en ART weer worden gecompileerd naar machine code. Dalvik leunde daarbij heel sterk op Java voor het genereren van de bytecode. ART ondersteunt dit nog steeds om backwards compatible te blijven. Maar de bedoeling is uiteindelijk dat Apps in het ELF formaat getransformeerd gaan worden. En dat maakt het mogelijk om meer verschillende compilers te ontwikkelen voor Android.

        En vandaar dat ik verwacht dat LLVM steeds populairder gaat worden omdat men zo een generieke ontwikkelomgeving heeft waarmee voor meerdere platforms ontwikkeld kan worden. De enige uitdaging zijn dan de platform-afhankelijke libraries. En een virtuele machine of compiler om de Intermediate Representation naar machine code te vertalen.

        1. De grote verschillen tussen Sun/Oracle en Google zitten in:

          1. De implementatie van de java APIs; deze heeft Google geherimplementeerd.

          2. De Byte code; De google compiler produceert een compleet andere bytecode dan de Sun/Oracle compiler. Dat betekent dus ook een compleet andere VM/JIT die met die andere buytecode om kan gaan.

            1. Elroy heeft volgens mij volledig gelijk. De java afhankelijkheid zit alleen aan de ontwikkelkant. Het kan zelfs zijn dat daar eerst (deels) naar java byte code wordt gecompileerd en dat deze vervolgens naar dalvik byte code wordt omgezet. Dat lijkt me auteursrechtelijk in principe geen enkel probleem (zover google wel eigen implementaties maakt van de java api’s en niet de implementaties van sun naar dalvik compileert).

            2. De Android Studio IDE (gebasseerd op IntelliJ IDEA) is geschreven in Java. Dat heeft natuurlijk nog niets te maken met de taal en compilers die door deze IDE’s gebruikt kunnen worden.

              Microsoft Visual studio kan gebruikt worden om Javascript applicaties te ontwikkelen. Dat wil niet zeggen dat de IDE zelf ook geschreven is in Javascipt. (Omgekeerd voorbeeld maar het punt lijkt me wel duidelijk,)

              1. Nee, IntelliJ IDEA is niet alleen in Java geschreven, want anders was de installatie ervan niet platform-afhankelijk. IntelliJ bestaat uit meerdere executables, waaronder een 32-bit en een 64-bit versie. Dat is bij Java overbodig. In de binaries kom ik daarbij ook nog eens verwijzingen naar de Windows API tegen en naar de java.com website. Oh, de tekst “Microsoft Visual C++ Runtime Library” staat in unicode in de executables dus da’s een redelijke hint betreffende de taal die is gebruikt.

                Android Studio maakt ook nog eens gebruik van ANT en dat is een Java Build tool. En Python wordt ook gebruikt. Verder zijn er erg veel Java libraries die worden gebruikt voor de projecten die je in IntelliJ aanmaakt. Ook wordt gebruik gemaakt van ASM om Java Bytecode te manipuleren.

                De fabrikant van IntelliJ levert sowieso veel ontwikkeltools voor .NET, Java, C++, Python en andere ontwikkel-omgevingen, waarbij ze ook meerdere platforms ondersteunen. Maar ja, daar heb je geen Java voor nodig maar dat kan ook met C of C++. Mits je maar extra libraries hebt met platform-specifieke code.

    1. Ik krijg altijd een glimlach bij dit soort opmerkingen. Je hebt uiteraard formeel gelijk, maar wat is effectief het verschil tussen een bibliotheek met functies en een class met static methods?

  1. De uitkomst van deze zaak (tot dusver) is een hele verademing ten opzichte van de situatie die gecreëerd zou zijn wanneer de jury voor de argumenten van Oracle gekozen zou hebben. Persoonlijk denk ik dat rechtszaken over dit soort fundamentele principes nimmer door een jury beslist zouden moeten worden, maar het moge duidelijk zijn dat de rechters in het hoger beroep vonnis van 2014 net zo goed een verkeerde weg in kunnen slaan. Het is eigenlijk best wel triest dat het een lekenjury is geweest die de industrie nu heeft behoed voor een door rechters gecreëerde juridische nachtmerrie.

    Dat in sommige gevallen een API als een creatief werk gezien zou kunnen worden, kan ik nog wel begrijpen. Dat dit ook voor de Java API’s zou moeten gelden blijf ik echter van den zotte vinden. Het merendeel van deze API’s is een logisch gevolg van een optimale functionele organisatie en hiërarchische onderverdeling en niet zo zeer een creatief werk (in artistieke zin). Evenzogoed, dat Oracle op een gegeven moment besloten heeft om Google te gaan chanteren terwijl het (her)gebruik van Java, en met name het gebruik van de API’s, tot daarvoor juist werd aangemoedigd, mag een duidelijke indicatie zijn, voor dat Oracle nimmer goede bedoelingen heeft gehad en (ongeacht de consequenties) enkel op financieel gewin uit is. Voor wie deze zaak van het begin aan gevolgd heeft, zal dit ook wel duidelijk zijn geworden door de manier waarop Oracle met steeds meer wereldvreemde argumenten aan kwam zetten, toen hun aanvankelijke argumenten één voor één van tafel geveegd werden.

    Een “op-ed” artikel van één van de advocaten van Oracle, Annette Hurst, dat door Ars Technica geplaatst werd (hier) na uitspraak in de laatste rechtszaak, spande wat mij betreft echter de kroon. In dit artikel beweerd deze advocaat dat de uitspraak in feite betekend dat de alle werken die ooit open aangeboden zijn niet langer auteursrechtelijk beschermd zouden kunnen worden en dat dit tevens een gevaar is voor de GPL (alsof Oracle dat ooit iets kon schelen). Het is naar mijn mening een compleet van de pot gerukt artikel, waarin de advocaat ook nog eens totaal geen onderscheid maakt tussen functionele code en API declaraties. Waarschijnlijk opzettelijk, aangezien dit ook tijdens de rechtszaak vrij duidelijk gebruikt werd in een poging om de jury te misleiden. Ik kan mij eerlijk gezegd moeilijk voor stellen wat voor tunnelvisie er bij deze advocaat en bij Oracle moet heersen om hen in hun gelijk te doen blijven geloven. Volkomen geschift. Je zou haast gaan denken dat Larry Allison (CEO van Oracle) een broer of het beste maatje van Darl McBride (voormalige CEO van SCO) moet zijn.

    1. Wow, dat artikel van Oracle is tenenkrommend. Of ze begrijpen er niets van, of ze zijn bewust misleidend. Men zegt “never assume bad intentions when assuming stupidity is enough”, maar in dit geval, waarbij er een duidelijk belang is bij misleiding, en Oracle eigenlijk ook wel beter zou moeten weten, zie ik het als opzettelijke misleiding.

      Het grote missende element in het artikel van Oracle is het verschil tussen een interface en een implementatie. Het is extreem gebruikelijk in de software-wereld om interfaces te zien als niet-copyrightable: niet alleen zijn er tientallen high-profile voorbeelden te noemen van industrie-bepalende ontwikkelingen waarbij een interface (API) werd gekopieerd, maar het is ook logisch dat dit met enige regelmaat nodig is om de stand van de techniek vooruit te helpen, al is het maar door de oorspronkelijke maker van de API een te grote, schadelijke macht te ontnemen.

      Het niet-copyrightable zijn van een interface zegt niets over het copyrightable zijn van een implementatie. Ook in de open source wereld wordt over het algemeen van uit gegaan dat het iedereen vrij staat een her-implementatie te maken van een GPL-bibliotheek, en die her-implementatie onder een incompatible license uit te brengen, zelfs als beide de zelfde API hebben. Het idee is dat de moeite die her-implementeren kost voldoende bescherming biedt om de GPL effectief te laten zijn.

      Dit zegt niet dat er geen creatief werk kan zitten in het ontwerp van een interface. Alleen: het verbieden (via auteursrecht of op andere manier) van het hergebruik van een interface zou zodanig schadelijk zijn dat dit terecht wordt uitgezonderd van het auteursrecht.

  2. Laat het duidelijk zijn, API’s zijn wel degelijk het result van creative activiteit, en het maken van een goede API is zeker niet makkelijk. Als zodanig zouden ze normaal gesproken onder auteursrecht vallen. Vandaar dat er een uitzondering in de EU richtlijn staat voor API’s. Voor concurrentie is het namelijk nodig om API’s te implementeren aangezien klanten “compatibiliteit” verwachten – een klassiek geval van netwerkeffect. Dat die in het Amerikaanse systeem onder fair use valt is in lijn met dezelfde gedachte dat auteursrecht niet bedoeld is om een breder monopolie in stand te houden.

    Het GPL argument is nogal opgeblazen. Er is echter wel een punt, en wel bij het gebruik van GPL software binnen een breder programma. Het probleem daar is dat de GPL licentie nodig is om ook de onderliggende software te gebruiken, en de GPL dus additionele voorwaarden mag stellen. Wat deze uitspraak impliceert is dat je gpl software zou kunnen her-implementeren met een compatible API. Als je dat doet dan zou je niet onder the GPL vallen.

    1. Dat herimplementeren van de API mogelijk is om te voorkomen dat je aan de GPL moet voldoen lijkt mij toch evident aangezien er onder de GPL genoeg API geherimplementeerd zijn om andere commerciele licenties te ontwijken. Het is logisch dat dat twee kanten op werkt.

      Ik heb in een eerdere discussie zelfs wel eens betoogd dat onder de nederlandse definities en uitzonderingen de restrictie op dynamisch linken in de GPL niet houdbaar is. (en waarschijnlijk dan ook europees niet aangezien we ons op europese richtlijnen gebaseerd hebben)

      Overigens is in de VS het laatste woord over Copyrights op APIs waarschijnlijk ook nog niet gezegd. Zo’n beetje de hele amerikaanse academische juridische wereld viel over het vonnis van de court of appeals omdat het lijnrecht ingaat tegen wat er in de Amerikaanse wet staat. De uitspraak is gedaan door een rechtbank die erom bekend staat dat ze vaak gecorrigeerd moeten worden door het hooggerechtshof vanwege hun te ruime bescherming van patenten en auteursrechten.

      Het hooggerechtshof heeft deze zaak geweigerd, maar het is heel goed mogelijk dat een andere court of appeals in een ander cicuit tot een ander oordeel komt, gezien de algemeen heersende opinie onder juristen in de VS over de huidige uitspraak. Dan is er sprake van een circuit split en is de kans groot dat het hooggerechtshof de zaak oppakt.

      Mijn enige angst is dat dit langer kan duren dan nodig is. De Court of appeal die deze zaak behandelt, behandelt alle hoger beroepen waar patenten bij spelen ongeacht het circuit waar de irigineren. Dit zelfs als die patent claims in een later stadium, maar voor het hoger beroep al zijn laten vallen. Je kan dus afdwingen dat je bij deze rechtbank terechtkomt door in je rechtzaak een patent op te nemen, zelfs al ben je nooit van plan om dat door te zetten.

    2. Voor het gebruik van software onder een GPL licentie, of onderdelen daarvan, moet uiteraard aan de licentievoorwaarden worden voldaan. Daarin is de GPL niet bijzonder, aangezien hetzelfde geldt voor iedere andere (software) licentie. De uitspraak impliceert enkel dat wanneer software (GPL of anderzijds) een API bevat, die tevens als publieke interface geadverteerd wordt voor gebruik door derden (hoewel dit naar mijn mening een bijzaak is), dit niet betekend dat derden geen alternatieve implementatie van de onderliggende functionaliteit achter deze API kunnen bouwen omdat deze API auteursrechtelijk beschermd zou zijn.

      Met andere woorden: Het auteursrecht op een API kan niet leiden tot een monopoly op de onderliggende functionaliteit. Tenzij ik het verkeerd begrepen heb, betreft de auteursrechtelijke bescherming op software enkel het creatieve werk/resultaat van een implementatie, niet de functionaliteit zelf. Indien je zelfstandig functionaliteit implementeert in software, zonder daarbij broncode of uitvoerbare (binaire) code van reeds bestaande (GPL) software over te nemen, schend je daarmee geen auteursrecht. Sterker nog, op dat werk rust je eigen auteursrechtelijke bescherming.

      Het argument dat er een probleem zou zijn met de GPL is enkel een (slechte) afleidingsmanoeuvre. Allereerst is de mogelijkheid tot een zelfstandige alternatieve implementatie van software (functionaliteit) onder een ander licentie gewoon toegestaan (althans binnen de context van het auteursrecht), of dit nu software onder een GPL licentie betreft of anderzijds. Anderzijds het hele concept van dit “probleem” is nogal absurd wanneer gekeken wordt naar een van de essentiële doelen van de GPL, namelijk het beschermd openbaren van broncode zodat anderen er lering uit kunnen trekken. Dat laatste betekend niet dat code verbatim overgenomen mag worden, maar wel dat de functionaliteit ervan openbaar moet zijn zodat op basis hiervan, derden een eigen implementatie kunnen ontwikkelen. Hierin is de GPL totaal het tegenovergestelde van de meeste gesloten licenties, waarvoor het argument van Annette Hurst waarschijnlijk veel meer op gaat (als zijnde een potentieel gevaar).

      Dit hele “probleem” rondom API’s komt enkel voort uit het feit dat Oracle, in een laatste wanhopige poging om hun rechtszaak niet vroegtijdig te zien sneuvelen, besloot om opzettelijk verwarring te zaaien onder een jury van ondeskundigen (of althans een poging daartoe). Dit deed Oracle door eerst te stellen dat broncode auteursrechtelijk bescherm is, wat inderdaad correct is. Vervolgens beweerde Oracle dat omdat de declaraties van de interfaces naar hun auteursrechtelijk beschermde code tevens onderdeel uitmaken van diezelfde broncode (nogal wiedes), daarmee ook de die publieke interfaces een gelijke auteursrechtelijke bescherming moeten genieten. Zo ongeveer iedereen met enige ervaring in softwareontwikkeling begreep meteen dat dit een nogal zotte en extremistische redenering was, en de opstand tegen deze gekunstelde redenatie van Oracle was dan ook groot. Zeker niet in de laatste plaats vanwege de implicaties die deze redenatie met zich mee bracht.

      Ik denk echter niet dat dit de primaire reden is geweest waarom Oracle van Google verloren heeft. De reden daarvoor is waarschijnlijk veel meer de overduidelijke kwade intentie en de lange reeks aan gekunstelde beweringen van Oracle (waarvan een groot deel simpelweg misleidend zo niet onwaar zijn gebleken) in de volledige ontwikkeling van deze rechtszaak geweest.

      Totdat Oracle deze kunstgreep nodig had om hun rechtszaak te “redden”, ging eigenlijk niemand in de industrie er vanuit dat een programmeerinterface (API) actief beschermd zou moeten worden tegen het gebruik ervan door derden. Veel van de mensen die nu denken dat dit wel het geval zou moeten zijn, blijken veelal ofwel een meer theoretische dan een praktische achtergrond te hebben wat betreft softwareontwikkeling, dan wel intellectueel eigendom puristen of zelfs fundamentalisten te zijn. Hoewel er zeker een plek voor dergelijke mensen is, zeker waar het om filosofische discussies gaat, denk ik niet dat de praktische wereld van de IT industrie erg gebaat zal zijn bij dergelijke ideeën. En al helemaal niet wanneer de primaire drijfveer achter dergelijke ideeën enkel financieel gewin (b)lijkt te zijn.

  3. En natuurlijk gaat Oracle in hoger beroep.

    Wat ik begrijp is dat de kans dat Oracle daar wel wint niet zo groot is. Kennelijk is het tamelijk not-done om als rechter een jury verdict te overturnen. Tenzij men een fout kan vinden in Alsup’s jury instructies, dan zou dat een argument kunnen zijn om wel de mening van de jury naast zich neer te leggen.

    1. Oracle moet natuurlijk de spierballen laten zien en duidelijk maken tegen kleine partijen dat ze beter kunnen buigen… Het alternatief is failliet te gaan aan de kosten van een paar jaar een rechtszaak voeren in Amerikaanse rechtbanken.

  4. Zover ik weet had de “lagere” rechter in de zaak (alsup) ook besloten dat er geen copyright kon rusten op de api. Om nagenoeg dezelfde redenen als die in Europa. (de transcripts stonden destijds op groklaw en waren zeer humorisch). De ongeïnformeerde rechters van het federal circuit deden vervolgens een duid in het zakje door dat terug te draaien. en toen kon google alleen nog winnen op fair use….. Ik verwacht trouwens dat als oracle dit ooit wint ze worden aangeklaagd door ibm en alle anderen want de java api indeling is gebaseerd op dit van C en andere voorgaande talen.

    Android heeft nooit echte java applicaties gehad. Alleen een API die overeenkomt met die van java zodat java programmeurs eenvoudig konden overstappen zonder iets nieuws te leren. Daarom is het zo gestoord dat Oracle copyright durft te claimen. De implementatie is totaal uniek en API’s overnemen om het gebruikers makkelijk te maken is hoe de ontwikkel industrie werkt.

    1. Daarom is het zo gestoord dat Oracle copyright durft te claimen

      Een (vorm van) Copyright lijkt me in principe wel terecht: Het schrijven van goede interfaces (incl. API’s) kan veel creatief werk zijn en vervolgens kan het ook nog eens een flinke inspanning kosten om een interface in de markt geaccepteerd te krijgen. Voor veel systemen zijn de interfaces misschien zelfs wel het belangrijkste onderdeel.

      Alleen, om (machts)misbruik te voorkomen moet dit recht bij externe interfaces zoals API’s natuurlijk wel drastisch ingeperkt worden. Een fair use benadering lijkt me daarom op eerste gezicht wel redelijk. Een andere mogelijkheid zou misschien een systeem met beperkte vergoedingen kunnen zijn. Aan de andere kun je je afvragen of dat nodig is: als de auteursrechthebbende van een API onredelijke eisen aan het gebruik van zijn API stelt, zal die API tegenwoordig niet snel geacccepteerd raken en zullen er snel alternatieven voor ontstaan.

  5. Dit is al hele oude materie. Zie USL v. BSDI. Zoals ik het begrijp mag je, ten minste in de VS, gewoon headers en vergelijkbare zooi integraal overnemen, zolang het voor de compatibiliteit noodzakelijk is. Je mag zelfs objectcode overnemen, zolang er geen andere redelijke manier is om bepaalde functionaliteit te implementeren (als er maar 1 manier is, is het niet creatief). Geheel in lijn met het /common law/-principe is daar na het tussenvonnis (uiteraard werd de zaak opeens geschikt), voor zover ik weet, weinig meer aan veranderd.

    De enige nieuwswaarde van deze nieuwe zaak lijkt mij dat het om Oracle en Google gaat. Gaap.

    1. Deze lijkt me toch me wel wat anders: Google gebruikt de headers niet om compatibel te kunnen zijn met traditionele java bibliotheken of programma’s (in java byte code), maar gebruikt ze in hun eigen ecosysteem Android waar ze een afgeleide “java” hebben gecreeerd (dalvik VM) en die juist niet met java byte code samenwerkt. De redeneerlijn waarom Google dit mag moet dus anders zijn.

      Men komt uit op fair use, maar hoe het nu precies beredeneert wordt blijft dus nog onduidelijk..

      Wat Google niet zou mogen is me overigens niet helemaal duidelijk meer, want (grootste deel van) java was al open source. Gaat het nu alleen nog om het verder oprekken van die opensource licentie?

      1. Ik zie het verschil niet. Als ik het goed begrijp is jouw argument “het is hier anders, want er kan hier geen noodzaak zijn tot behoud van compatibiliteit, want de bytecode is anders”. Als dat het hele verhaal was, dan had Google natuurlijk nooit deze juridische ongein over zich zelf uit geroepen: dan hadden ze gewoon hun eigen API gemaakt. Zo veel werk is het maken van een API namelijk ook weer niet; Google heeft heel capabele ontwikkelaars in dienst die dit goed kunnen, en het voordeel van een eigen API is dat je die helemaal naar eigen wensen in kunt richten.

        Natuurlijk is dat niet het hele verhaal. Google streeft met de Java API wel degelijk naar compatibiliteit, maar dan niet op byte code niveau, maar op source code niveau. Bestaande Java libraries kunnen nu makkelijk naar Android geport worden, en programmeurs die Java gewend zijn kunnen snel aan de slag in Android. En ja, daarvoor is het wel degelijk noodzakelijk om de Java API over te nemen.

        Het is dus wel degelijk “oude materie”, zoals zeurkous het noemt. Het raarste is nog wel dat die eerdere rechtbank dit wel als auteursrechtenschending zag, maar gelukkig is er nu “fair use” van gemaakt.

        1. Ik snap je punt wel, maar de “noodzaak” voor Java lijkt me toch echt van een andere orde. Het is geen absolute noodzaak, maar vooral handig. Zoals je zelf al aangaf: ze hadden ook hun eigen api kunnen maken en een andere taal kunnen kiezen. Echter: 1. Dat zou een hele hoop werk zijn geweest (ik ben het ook absoluut niet eens met je suggestie dat het ontwikkelen van een (goede) api wel meevalt. Dat kost op zijn minst heel veel doorlooptijd en ik weet ook zeker dat de java ontwikkelaars daar ook heel veel tijd in hebben gestoken) 2. Ik vraag me af of Google dezelfde api kwaliteit zo snel gehaald zou kunnen hebben (ik ben niet zo onder de indruk van de android specifieke api’s) 3. Het zou veel meer inspanning hebben gekost om app-ontwikkelaars naar het google platform te krijgen.

          Verder deel ik overigens wel je opluchting dat hier “fair use” van is gemaakt. Nu alleen nog een heldere motivatie vanuit de rechtspraak!

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.