Hoe lang moet een telefoonverkoper Android ondersteunen?

| AE 7398 | Intellectuele rechten, Ondernemingsvrijheid | 41 reacties

google-browser-androidEen lezer vroeg me:

Ik las dat Google het dichten van lekken in browser van oude Android versies niet haalbaar acht. Maar kunnen ze dat zomaar beslissen? Ik heb toch recht op een product conform de verwachtingen, en ik mag toch verwachten dat een telefoon een paar jaar goed functioneert?

Dat klopt, een telefoon moet voldoen aan de redelijke verwachtingen die bij jou als koper gewekt zijn. Dat het product perfect veilig is, is geen redelijke verwachting, maar dat (ernstige) fouten worden hersteld mag je vandaag de dag wel verwachten.

De vraag is dan hoe lang je die verwachting mag hebben. Bij een browser uit 1996 lijkt me dat niet redelijk meer, maar Android 4.3 (waar het over gaat) is uit juli 2013, dat is nog geen twee jaar geleden dus. En dat een telefoon inclusief browser zo’n twee jaar gewoon moet werken, dat lijkt

Nu kun je natuurlijk zeggen, ja maar dit is software, dat krijg je toch altijd zonder garantie? Nou, niet helemaal. In 2012 bepaalde de Hoge Raad dat software onder de kooptitel valt, met als motivatie kort gezegd dat dat handig is omdat dan de regels over conformiteit en zo daarop van toepassing zijn. En op producten die je koopt zit “wettelijke garantie”, dat is die eis van redelijke verwachtingen.

Er wordt gewerkt aan een wetsvoorstel om dit te formaliseren. Er komt dan expliciet in de definitie van consumentenkoop uit art. 7:5 BW te staan dat de koopregels ook gelden voor

digitale inhoud die niet op een materiële drager is geleverd, ongeacht of de digitale inhoud individualiseerbaar is en of er feitelijke macht over kan worden uitgeoefend.

Daarmee zijn dus kopersrechten in te roepen ook wanneer het gaat om software (of spellen of video’s).

Maar inderdaad, Google lacht je keihard in je gezicht uit als je dit tegen ze gaat zeggen. Juridisch hebben ze daar nog een grond voor ook, want zij zijn geen partij bij die koopovereenkomst. Die telefoon koop je bij je mobieletelefonieprovider, niet bij Google. Tenzij het gaat om software die je wél rechtstreeks van Google krijgt, zoals de door Google zelf gemaakte en verspreide browser. Alleen krijg je die gratis, dus of je dan van een ‘koop’ kunt spreken is nog maar de vraag. (Op schenkingen, art. 7:175 BW gelden niet de regels van koop, een cadeau krijg je zonder garantie.)

Daar staat tegenover dat ie deel is van een product, en geen duidelijk losse download is. Dus ik denk dat je wel mag zeggen dat de browser deel is van de gekochte telefoon.

Alleen, nu twijfel ik. Want ís het wel redelijk dat je nog twee jaar security updates kunt verlangen op een browser?

Arnoud

Overgrote deel apps overdrijft met toestemming vragen

| AE 6971 | Intellectuele rechten, Privacy | 24 reacties

apps-permission-toestemming-vragenMeer dan 85% van alle apps geven niet eens de meest basale privacyrelevante informatie, zo las ik bij The Register. En een op de drie apps vraagt excessief meer toestemmingen dan ze eigenlijk nodig zouden hebben. Schokkend, maar eigenlijk niet verbazingwekkend. Het onderzoek is van de Global Privacy Enforcement Network (GPEN) waar onder meer de Engelse en Nederlandse privacyautoriteiten deel aan nemen.

Omdat apps best veel kunnen qua privacy, hebben zowel Apple als Google ingebouwde beveiligingen. Je mag als app bepaalde dingen niet doen als die aan de privacy van de gebruiker raken, tenzij je daar toestemming voor hebt gevraagd. Dit gaat dan op de typische techneutenmanier: we mogen iets niet zomaar van Legal, dan vragen we de gebruiker om toestemming en dan kunnen we verder. Een stuk eenvoudiger immers dan je app herbouwen zodat de vraag overbodig is.

Ergerlijk. Maar goed, er komt dus een popup die vraagt “Deze app wil je gps coördinaten” uitlezen en daar kun je ja op zeggen anders mag je de app niet installeren of de update niet gebruiken. Lekker dan. Wie gaat er in die situatie nee zeggen? Ik negeer het ook, hoe vaak ik ook denk “waaróm wil je dat, je bent een zaklamp/spelletje/bankierapp”.

De GPEN pleit zoals toezichthouders wel vaker doen voor meer informatie: mensen uitleggen hoe het werkt, zodat ze daarna met een gerust hart ja of nee kunnen zeggen. Dat gaat ‘m niet worden maar het idee van een gelaagde privacyverklaring is niet verkeerd. Het idee is dat je per permissie kort uitlegt wat en hoe, en wie wil kan doorklikken naar een extra tab.

Maar waarom moeten appbouwers hier het wiel in uitvinden? Laten we de appstores verplichten om dit model te hanteren. Eis dat ze bij een toestemmingsvraag een toelichting laten opnemen. Niet in een privacyverklaring, niet in de app-informatietekst en niet in een “Over ons/Privacy” menu in je app. Nee, gewoon bij de vraag. “Deze app wil je gps coördinaten uitlezen omdat het een navigatie-app is, duh” of “Deze app wil je gps coördinaten uitlezen om lokatiegebonden advertenties te vertonen”.

Natuurlijk is dit lastiger te handhaven dan het technische model dat appstores nu hanteren. Je kunt als beheerder alleen vaststellen of er toestemming is voor functionaliteit, nagaan waaróm die toestemming is verleend (en met welke gedachte bij de gebruiker) is niet echt te programmeren. Maar daar is menselijke controle denk ik een prima alternatief, zeker omdat mensen vrij snel door zullen hebben wanneer toestemming op grond A wordt gevraagd en voor grond B wordt ingezet.

Bij voorkeur zouden mensen dan ook nog eens per toestemmingsvraag ja of nee moeten kunnen zeggen, en als ze nee zeggen dan mag de app best crippled raken maar installatie mag dan niet worden geweigerd. Maar dat lijkt me een brug te ver voor app-ontwikkelaars.

Arnoud

Oracle’s Java API auteursrechtelijk beschermd in VS, Android maakt inbreuk

| AE 6637 | Intellectuele rechten | 21 reacties

aapje-api.pngEen Amerikaans gerechtshof heeft vrijdag in hoger beroep bepaald dat Google met zijn Android-besturingssysteem het copyright van Oracle heeft geschonden, las ik bij Tweakers. Nadat eerder nog was bepaald dat er geen auteursrecht zat op de API’s van Oracle’s Java, beslist het Hof van Beroep nu anders: de aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn wel degelijk creatieve keuzes die de resulterende api een beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Het geschil speelt al sinds 2012. Google had in Android een aantal elementen overgenomen uit de Java API en Oracle startte daarop een rechtszaak wegens auteursrechtinbreuk. In eerste instantie won Google: een API en functiedeclaraties zijn vergelijkbaar met een inhoudsopgave, en bovendien kun je in software vaak dingen maar op één manier uitdrukken. Daarmee is er geen sprake meer van het overnemen van creatieve elementen.

In hoger beroep wordt anders beslist. Allereerst wordt vastgesteld dat het máken van een API best creatief werk kan zijn. Nadenken welke functies je gaat aanbieden, hoe je die noemt, welke argumenten ze moeten krijgen en wat voor soort resultaat er komt, vereist creatieve arbeid. En die arbeid wordt beschermd door het auteursrecht. Een ander mag dan niet zomaar de integrale resultaten van die arbeid overnemen.

Amerikaans auteursrecht verbiedt auteursrecht op methods of operation. Al in 1995 speelde dit: mocht Borland met spreadsheetprogramma Quattro de menustructuur van concurrent Lotus overnemen? Ja, zo oordeelde men destijds, want een menu is dé manier van het opereren/gebruiken van een stuk software. En in eerste instantie won ook Google het met dit argument, omdat het nabootsen van een menu hetzelfde werd geacht als het aanroepen van een API. Dat wijst het Hof af: het kopiëren van API declaraties is wat anders dan het kopiëren van labels uit een menu.

Bovendien is de Lotus-uitspraak uit een ander circuit en in de VS geldt zo’n uitspraak dan niet als bindende jurisprudentie. Het Hof valt terug op een eigen precedent dat wél bindend is: de manier waaróp je een method of operation vormgeeft, kan wel auteursrechtelijk beschermd zijn. Mits er maar meer dan één manier is om dat te doen. En dat is hier het geval: de Java-ontwikkelaars hadden de vrije keuze om hun API te maken zoals zij wilden.

In Europa ligt het compleet 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.

Hiermee zou een API dus wél vrij bruikbaar zijn omdat het dan enkel gaat om de functionaliteit die in de API ligt. Het ging in de SAS-zaak om het gebruik van een programmeertaal waarop auteursrecht werd geclaimd. Het schrijven in die taal zou dan inbreuk opleveren, omdat een programma in die taal immers de beschermde functionaliteit aanroept. En dát wijst het Hof van Justitie af. Dit lijkt mij 1-op-1 door te trekken naar API’s van een programma. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

Google krijgt nog een kansje in de tweede ronde: de zaak is terugverwezen naar de rechtbank om Googles verweer op grond van fair use te beoordelen. Onder fair use mag je in het Amerikaans auteursrecht iemands werk gebruiken mits dat billijk (fair) is. Daarbij spelen zaken mee als hoe concurrerend je bent, hoe commercieel je bent en hoe transformatief of juist letterlijk je gebruik is. Dat is dus een moeilijker zaak om te bewijzen dan wanneer de Java API niet auteursrechtelijk beschermd zou zijn verklaard.

Dit kan nog wel eens heel hinderlijk worden want heel veel internet-API’s worden beheerd door Amerikaanse bedrijven. En als die nu allemaal auteursrechtelijke voorwaarden gaan koppelen aan gebruik daarvan, dan gaat me dat nog flink wat juridische hoofdpijn opleveren.

Arnoud

“Overal op je tablet” niet van toepassing op alle tablets

| AE 5708 | Ondernemingsvrijheid | 22 reacties

Dit is dus waarom reclame altijd van die kleine lettertjes heeft. De zin “Zo kun je overal in huis tv kijken op je tablet of smartphone” impliceert dat de tvkijkapp met élke tablet werkt, en is daarmee misleidend omdat er bepaalde systeemeisen golden waar niet elke app aan voldoet. Dat bepaalde de Reclame Code Commissie… Lees verder

Mag Track en Protect op een gestolen iPhone als bewijs worden gebruikt?

| AE 2615 | Privacy, Security | 25 reacties

Een lezer vroeg me: Ik wil proberen de gestolen iPhone van een vriend terug te halen. De iPhone is voorzien van het programma Track and Protect. Hiermee kan je je telefoon volgen op internet. Het programmaatje zal kennelijk de aanwezige gps gebruiken of de zendmasten in de omgeving om aan te geven waar de telefoon… Lees verder

Een retourtermijn voor software

| AE 2607 | Intellectuele rechten | 19 reacties

Taiwanese iOS-gebruikers mogen apps 7 dagen testen, las ik bij iPadclub. De Taiwanese wet koop op afstand blijkt ook te gelden voor digitale producten zoals apps voor iPads en Android apparaten. Apple heeft gemeld haar beleid aan te passen, maar Google weigert meer dan 15 minuten retourtermijn te geven en incasseert de boetes vooralsnog. Bij… Lees verder