Is sjoemelsoftware in je Volkswagen reden om hem te retourneren?

volkswagen-defeat-sjoemelsoftwareVolkswagen gaat de elf miljoen dieselauto’s die zijn uitgerust met software die de uitstoot kan manipuleren van nieuwe software voorzien, las ik bij Nu.nl. De sjoemelsoftware was ontworpen om de auto’s door emissietests te laten komen, maar de daadwerkelijke prestaties op de weg vielen heel anders uit. De software-update zal deze software verwijderen, maar wat het betekent voor de prestaties van de auto, is nog maar de vraag. En als die tegen blijken te vallen, wat dan?

Wat de softwarepatch precies gaat doen, kan ik nog niet ontdekken. Wat ik lees bij Vox is dat

the NOx emission controls likely degraded the cars’ performance when they were switched on — the engines ran hotter, wore out more quickly, and got poorer mileage. Some experts have suggested that the emission controls may have affected the cars’ torque and acceleration, making them less fun to drive. (Indeed, some individual car owners have been known to disable their cars’ emission controls to boost performance, though this is against the law.)

Dan kun je natuurlijk wel met een update die emissiecontrole permanent aanzetten, maar dan krijg je dus permanent een verslechterde performance. Wellicht dat Volkswagen dat kan oplossen, maar als ze dat konden, dan was er helemaal geen patch nodig lijkt me?

Goed, laten we even aannemen dat Volkswagen een patch uitbrengt die enkel de compliance met wetgeving verzorgt. De auto voldoet aan de emissie-eisen, alleen rijdt hij nu een significant stuk minder prettig. Wat kun je dan?

Je kunt dit juridisch dan over twee banden spelen. Allereerst kun je zeggen: deze auto voldoet niet aan de gewekte verwachtingen (conformiteit), hij doet niet (meer) wat mij is beloofd. De Volkswagen-verkoper moet dat dan herstellen of je een vervangende auto geven. Een lastig punt is dan, kun je hardmaken dat die verwachtingen gewekt zijn? Is er gesproken over de emissie, was dat een relevante factor?

Als VW erin slaagt het gebrek te herstellen (voortschrijdend inzicht, slimme nieuwe algoritmes) dan gaat de conformiteits-route niet meer op. De auto is dan immers hersteld tot wat je mocht verwachten.

Een andere band is dat je zegt: ik ben onjuist voorgelicht en/of Volkswagen heeft dit ten onrechte verzwegen. Je beroept je dan op dwaling, en dat is een grond om de overeenkomst te vernietigen oftewel ongedaan te maken. Het lijkt me iets makkelijker te bewijzen, want het is vrij duidelijk dat VW dit wist én dat je als wederpartij dit had willen weten. Wel zit je ook hier met de vraag hoe belangrijk die emissie is. Het moet namelijk gaan om een ‘wezenlijk kenmerk’, je kunt niet bij een irrelevant dingetje dwaling claimen.

Verder, als je je op dwaling beroept dan maak je de aanschaf ongedaan. Je kunt geen herstel of vervanging eisen, je kunt alleen je geld terug vragen. Bij een lease-auto is dat nog relatief complex te bepalen, want in die prijs zit meer dan alleen een vergoeding voor de auto.

Ongetwijfeld gaat iemand hier een zaak van maken en ik zou zeer benieuwd zijn wat daar uit komt.

Arnoud

Mag je software reverse engineeren om fouten te vinden?

Een lezer vroeg me:

Is reverse engineering legaal als het doel is om beveiligingslekken te vinden? Jij zei ooit van wel, maar in de wet staat volgens mij dat je alleen mag reverse engineeren om compatibiliteit te realiseren.

Oef, dat is lang geleden, maar inderdaad:

Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt bewerkstelligen, of waarmee je alleen de achterliggende ideeën, concepten en principes achterhaalt zijn legaal. Met name is het niet legaal om de informatie te gebruiken om een kloon van de software te maken.

Waar de vraagsteller naar refereert, is het wetsartikel dat het eerste deel van die zin onderbouwt:

Als inbreuk op het auteursrecht op [software], worden niet beschouwd het vervaardigen van een kopie van dat werk en het vertalen van de codevorm daarvan, indien deze handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd computerprogramma met andere computerprogramma’s tot stand te brengen, mits: (bla)

Dit is inderdaad beperkt tot reverse engineeren met als doel het maken van een interoperabel eigen programma. Soms is het daarvoor nodig dat je de broncode van andere software achterhaalt, omdat je anders onvoldoende informatie hebt over hoe je eigen software moet gaan werken. Het vinden van een fout in software is natuurlijk niet hetzelfde als “interoperabiliteit tot stand brengen”, tenzij je zegt “ik moet weten hoe die fout werkt want ook daarin moet ik compatibel zijn”.

Er is echter nog een ander artikel dat specifieker op fouten ziet:

De verveelvoudiging, als bedoeld in de eerste zin, die geschiedt in het kader van het laden, het in beeld brengen of het verbeteren van fouten, kan niet bij overeenkomst worden verboden.

Reverse engineeren is een vorm van verveelvoudigen. Dat is waarom deze actie in principe inbreuk op het auteursrecht maakt. Echter, dit artikel verklaart het verveelvoudigen ter herstel van fouten legaal (zelfs als in de EULA staat dat dat niet toegestaan is). Daarom zou dit volgens mij toch gewoon toegestaan zijn.

Dus ik geloof dat ik toch gelijk had, hoewel om een andere reden dan ik zei 🙂

Arnoud

Het Wassenaar Arrangement versus de security-onderzoeker

bug-fout.pngEen Britse student mag zijn scriptie niet publiceren omdat hij daarin exploits uitlegt, wat verboden is door het Wassenaar Arrangement. Dat meldde Ars Technica afgelopen vrijdag. De bachelorscriptie bevat nu enkele zwartgemaakte pagina’s, en details daaruit worden alleen aan bona fide securityonderzoekers beschikbaar gesteld. Wacht even, is het nu ook al verboden om wetenschappelijke publicaties over securitygaten te doen?

Het Akkoord van Wassenaar (niet te verwarren met het Akkoord van Wassenaar) is een verdrag dat exportrestricties stelt op wapens en dual-use technologie. In 2014 werd de scope van dit Akkoord uitgebreid: ook intrusion software is nu een ‘wapen’ en daarmee onderworpen aan exportrestricties.

Meer specifiek gaat het om

Software ‘specially designed’ or modified to avoid detection by ‘monitoring tools,’ or to defeat ‘protective countermeasures,’ of a computer or network-capable device, and performing any of the following: (a) The extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or (b) The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

Het is item (b) waardoor ook zero days en andere exploitsoftware hieronder zou kunnen vallen: vrijwel alle exploits zijn uiteindelijk gericht op het uitvoeren van andere instructies, het hele punt immers is de controle overnemen van het systeem dat je aanvalt.

Op zich valt ook een exploit in een paper onder deze definitie. Het gaat immers niet om het medium waarin de software is verschenen of de bedoelingen van de auteur. Echter, elders in het Akkoord staat:

Controls do not apply to “technology” “in the public domain”, to “basic scientific research” or to the minimum necessary information for patent applications.

Hierbij betekent “public domain”

“technology” or “software” which has been made available without restrictions upon its further dissemination. Copyright restrictions do not remove “technology” or “software” from being “in the public domain”.

Oftewel, wie publiceert zonder restrictie, valt buiten het verdrag. Vreemd is het wel, want als je dus je software voor een beperkt publiek aanbiedt dan krijg je exportrestricties om je oren, maar zet je het met broncode en al op internet onder een opensourcelicentie dan heb je nergens wat mee te maken.

Het lijkt er bij deze student op dat er nog wat anders meespeelt: hij noemt naast het Akkoord ook het ethisch beleid van zijn universiteit als factor die in de weg zit. Ik kan dat beleid zo niet vinden, maar het is ergens voorstelbaar dat een stel alfa’s uit het bestuur meende dat exploits publiceren onethisch is ongeacht de wetenschappelijke waarde daarvan. Daar doe je dan verder juridisch niets aan.

Arnoud

Is embedded software het einde van het concept ‘eigendom’?

copyright-symbol-printed.pngVoertuigfabrikanten John Deere en General Motors willen het concept eigendom afschaffen, gilde Wired onlangs. In de VS staat de DMCA ter discussie: welke uitzonderingen op het auteursrecht moeten er in de wet blijven staan, en met name wat gaan we doen met de regels over het omzeilen van technische kopieerbeveiligingsmaatregelen in software. En de reden voor het gillen is de positie van Deere: je koopt weliswaar een tractor, maar de software krijg je slechts in licentie dus daar moet je van afblijven.

Het is decennialang het mantra geweest in software-auteursrechtland: je koopt geen software, je krijgt slechts een gebruiksrecht waarvan de scope niet verder reikt dan het de licentiehouder goeddunkt. Wie wil afwijken van dat contractueel gegunde recht, is eigenlijk maar een piraat.

Steeds vaker grepen softwareleveranciers ook naar technische maatregelen om kopiëren of aanpassen van hun software tegen te gaan. En om het hacken dáárvan weer tegen te gaan, staat sinds alweer heel wat jaartjes in de wet dat het verboden (‘onrechtmatig’) is om effectieve kopieerbeveiligingen te omzeilen of uit te schakelen.

Maar in de wet staat er niet bij dat dat alléén geldt wanneer je de software illegaal wilt kopiëren. Ook het uitschakelen van een beveiliging met een legitiem doel – zeg, omdat je een citaat uit het beschermde werk wilt kopiëren, of omdat je je tractor wil opvoeren met een softwarehack – is strikt gesproken verboden. En Deere en General Motors betogen nu dus dat dit niet alleen maar een ongelukkige lezing van de wet is. In prachtig ronkend auteursrechtenpropaganda heet het dan dat:

[Circumventing the protection may] make it possible for pirates, third-party developers, and less innovative competitors to free-ride off the creativity, unique expression and ingenuity of vehicle software.

Dat het in veel gevallen niet gaat om “minder innovatieve concurrenten” maar om mensen die hun legaal gekochte auto willen aanpassen, zeggen ze er dan niet bij. Die mensen hebben de auto wel gekocht, maar de software slechts in licentie gekregen.

In Europa koop je je software wél, zeker als hij embedded zit in een apparaat. Alleen: daarbij is het zeker niet gezegd dat je de software mag aanpassen. Het auteursrecht op dat exemplaar is uitgeput, maar dat betreft eigenlijk alleen het recht om dat ene exemplaar van de software opnieuw op de markt te brengen.

Het aanpassen van die software valt buiten de uitputting. Net zoals het strikt gesproken niet toegestaan is om in een boek correcties te maken of pagina’s eruit te scheuren en in te lijsten. Alleen dát vinden we doodnormaal. Waarom dan met aanpassen van software niet?

Natuurlijk, het aanpassen van embedded software in een apparaat zoals een auto kan gevaarlijk zijn. Maar dat reguleer je door in de Wegenverkeerswet op te nemen wat er wel en niet mag, zodat de overheid daar toezicht op kan houden. Niet door een auteursrechthebbende te laten bepalen óf je de software in je auto mag aanpassen.

Arnoud

Moet je bij een notice/takedown je hele GitHub repository verwijderen?

notice-takedownEen lezer vroeg me:

Als ik in mijn GitHub repository een pull-request binnenhaal waar ik later een notice and takedown over krijg, voldoet het dan om met een nieuwe commit de omstreden code te verwijderen (de omstreden code blijft dan in in de git historie beschikbaar) of moet ik dan de hele repository verwijderen?

Voor de niet-programmeurs:

Als ik in de online broncode-opslag van mijn softwareproject code van elders toevoeg, en iemand klaagt dat daardoor zijn auteursrechten door geschonden worden, is het dan genoeg om deze code te wissen uit de meest recente versie van mijn project, of moet ik deze ook uit het archief met oude versies wissen?

Wanneer je een kopie van andermans software publiceert of verspreidt, is het mogelijk dat je daardoor auteursrechten schendt. Dit staat los van de techniek die je gebruikt, via een flitsende GitHub repository of heel ouderwets op een FTP server of website. Krijg je een klacht van de rechthebbende, dan zul je maatregelen moeten nemen en eentje daarvan is het staken van de inbreuk.

Bij zo’n ouderwetsche website is dat eenvoudig: weg is weg. Maar GitHub is een veel moderner en handiger systeem, en heeft onder meer een uitgebreid archief waarin je alle oude versies en varianten van de software kunt opvragen. Dan kun je het dus wel uit de huidige versie van de software halen, maar zit er nog steeds een kopie in dat archief.

En ja, ook die moet weg want ook een kopie in een archief telt als “verveelvoudiging” en als die in strijd is met auteursrechten dan moet er worden ingegrepen. Het argument dat het een historisch document is, of dat het veel werk is om die oude kopie op te ruimen, is niet relevant. Het had er nooit mogen staan, dus bij deze moet het alsnog weg.

Arnoud

Tweedehands software mag worden doorverkocht, en de licentie gaat mee

software-charts-usedsoftEen eeuwige softwarelicentie die tegen een eenmalige vergoeding is verstrekt, mag worden doorverkocht ongeacht wat er in die licentie staat. Wel is de koper vervolgens gebonden aan alle bepalingen uit het licentiecontract. Dat staat in een vonnis (via) van de rechtbank Midden-Nederland van vorige week. Hiermee wordt het UsedSoft-arrest uit 2012 bevestigd.

In deze zaak had het bedrijf CWS software verkocht aan een persoon, die deze vervolgens ingezet had in een later opgerichte BV waar hij bestuurder van was. Na enkele jaren merkte CWS dat op en sprak ze beiden aan wegens licentieovertreding en auteursrechtinbreuk. De persoon vanwege het verbod de licentie over te dragen, en de BV vanwege het gebruik van de software zonder dat daardoor voor was betaald.

De gedaagden beriepen zich op het Usedsoft arrest, dat bepaalt dat een licentie een verkoop is van de software wanneer de licentie voor onbepaalde tijd wordt verstrekt en er een eenmalige vergoeding tegenover staat die een reële vergoeding is (de economische waarde). Deze software was geleverd tegen een betaling van $ 395, en de licentie stelde geen duidelijke, beperkte looptijd. Nergens blijkt uit dat deze prijs onder de economische waarde ligt (altijd een lastige vraag), dus de rechter neemt aan dat de prijs deze waarde vertegenwoordigt. En dan is de usedsoft-uitkomst simpel: deze software is verkocht.

Een discussiepunt bij tweedehandslicentieverkoop was nog altijd in hoeverre de koper van de licentie gebonden in aan de bepalingen daaruit. Immers, het contract staat niet op zijn naam dus hoezo moet hij dan alle bepalingen uit het contract nakomen? Met die redenering zou je dan bijvoorbeeld een goedkope consumentenlicentie kunnen kopen en die als bedrijf gaan toepassen, omdat dan de beperking “alleen voor consumenten” eraf zou zijn gevallen.

De rechtbank gaat daar niet in mee: het verkopen van een licentie wordt simpelweg juridisch geduid als een contractsoverdracht. Dat kan onder Nederlands recht, maar de verkrijger van het contract zit dan uiteraard wel gebonden aan alle licentievoorwaarden:

Doordat de software en de licentieovereenkomst een onverbrekelijke band hebben (zie r.o. 84 van het UsedSoft-arrest), moeten de uit de licentieovereenkomst voor de licentienemer voortvloeiende rechten (naar Nederlands recht, dat op de overdracht van de software van [gedaagde 1] naar [gedaagde 2] van toepassing is) worden aangemerkt als kwalitatieve rechten als bedoeld in artikel 6:251 lid 1 BW die van rechtswege overgaan bij overdracht van de software aan een derde. Daar staat wel tegenover dat die derde alsdan gebonden is aan de daar tegenover staande verplichtingen (zie lid 2).

Als je dus software tweedehands verkoopt, gaan alle rechten en plichten één op één over naar de kopende partij. Dat is een heel logische uitkomst wat mij betreft. Het betekent natuurlijk wel dat je die consumentenlicentie niet tweedehands kunt kopen en zakelijk inzetten, maar dat kan ik billijken. Het UsedSoft arrest is niet bedoeld om licentiedifferentiatie te verhinderen, het is bedoeld om de markt voor tweedehands software open te breken.

Arnoud

Mag je Metasploit-modules publiceren voor kwetsbaarheden in software?

metasploit-security-scannerEen lezer vroeg me:

Vanuit een research-oogpunt zou ik graag Metasploit modules willen publiceren voor gedichte kwetsbaarheden in veelgebruikte software. Kan dit zomaar of ben je dan strafbaar bezig?

Het is strafbaar om een kwetsbaarheid te exploiteren en zo binnen te dringen in een computersysteem. Dat is de computervredebreuk uit artikel 138ab Strafrecht.

Aanvullend is het strafbaar om exploits te maken, verkopen, verkrijgen, invoeren, verspreiden of anderszins beschikbaar te stellen of voorhanden te hebben (art. 139d Strafrecht). Maar niet elk stukje code dat een kwetsbaarheid gebruikt om toegang te verschaffen is een exploit in de zin van de wet.

Er gelden drie eisen:

  1. het moet gaan om een technisch hulpmiddel, het moet dus iets ‘doen’. Een uitleg in gewoon Nederlands valt hier waarschijnlijk niet onder, hoewel in de context van betaaltelevisie kraken een stappenplan in een tijdschrift wél als ‘voorwerp’ strafbaar was.
  2. met het hulpmiddel moet je computervredebreuk kunnen plegen. Een exploit die alleen maar méldt dat er een kwetsbaarheid is, zonder daadwerkelijk binnendringen te faciliteren, is dus niet strafbaar.
  3. het hulpmiddel moet “hoofdzakelijk geschikt gemaakt of ontworpen” zijn daarvoor. Een tool die toevallig en ondergeschikt ook gebruikt kan worden voor computervredebreuk, is dus niet strafbaar.

De discussie zal vooral gaan over punt 3. Wanneer is iets “hoofdzakelijk geschikt of ontworpen” voor een misdrijf?

Die grens ligt denk ik bij de uitstraling. Sommige tools zijn duidelijk bedoeld als serieuze tools voor security onderzoekers, andere tools zijn duidelijk ‘hacktools’ met de bekende groene letters op zwarte achtergrond en verlokkingen dat je iedereen hiermee kunt h4xoren. De wet is bedoeld voor het laatste.

De grens hiertussen is natuurlijk vaag, maar dat is een juridische feature. Het zal dus afhangen van hoe de tool wordt gepresenteerd en wat de uitgever ervan zegt in zijn aankondiging en reclame voor de tool. “Nu snel iemands MSN/Hotmail kraken” of “Onderzoek of uw bedrijfsdata nog wel veilig is” maakt voor mij veel verschil.

De site van Metasploit ziet er voor mij best serieus uit, en is duidelijk geschreven voor professionals die hun eigen netwerk willen beschermen. Daarom denk ik niet dat een Metasploit-module snel als “hulpmiddel hoofdzakelijk geschikt gemaakt of ontworpen voor computervredebreuk” wordt gezien.

Hoe lang moet een telefoonverkoper Android ondersteunen?

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

Maakt linken van een GPL bibliotheek je software automatisch GPL?

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library gebruikt? Het programma wérkt niet zonder de library. Maar Europees auteursrechtelijk waag ik dat toch te betwijfelen.

De term ‘afgeleid werk’ is een tikje ongelukkig. De term komt uit het Amerikaans auteursrecht; in Europa kennen we alleen de ‘verveelvoudiging in gewijzigde vorm’, oftewel een kopie, al dan niet aangepast, van (een deel van) het werk. Dat klinkt inderdaad wat beperkter, en dat is het volgens mij ook.

In de SAS/WPL-uitspraak heeft het Hof van Justitie de grenzen getrokken van het software-auteursrecht. In die zaak beriep SAS zich op een auteursrecht voor haar programmeertaal en functionaliteit daarin, maar gedaagde WPL kreeg gelijk, zo’n auteursrecht bestaat niet.

Auteursrecht op software bestaat volgens de hoogste Europese rechter alleen op de broncode en de daarvan afgeleide uitvoerbare code. Men noemt dit de ‘uitdrukkingswijzen’ en daaronder wordt alleen datgeen verstaan dat tot “reproductie van het computerprogramma of tot het computerprogramma zelf kunnen leiden”. Je moet dus, kort gezegd, met wat er overgenomen of gebruikt is in het andere werk, het originele programma zelf althans gedeeltelijk kunnen terugvinden.

Bij het gebruik van een software library roep je in je eigen programma een functie aan, waarna de implementatie van de library wordt uitgevoerd om de betreffende functionaliteit te realiseren. In het SAS/WPL arrest ging het om functies uit een programmeertaal, maar ik zie het verschil niet met een API van een specifieke bibliotheek. In feite is de implementatie van een programmeertaal ook een library (of set libraries) die je middels een API aanroept. Wil je in C een tekst op het scherm, dan zeg je printf("Hello, world!");, waarna libc de implementatie daarvan uitvoert, en wil je bij GNU readline een regel invoer verkrijgen dan zeg je readline(my_prompt);, waarna readline de implementatie daarvan uitvoert. Dat is technisch volgens mij dus hetzelfde.

Meer algemeen, als het aanroepen van een functie van een bibliotheek zou meebrengen dat je het auteursrecht op die bibliotheek schendt, dan zou het auteursrecht dus in feite de functionaliteit beschermen die achter de functie zit. En dát is nadrukkelijk niet de bedoeling in het Europese auteursrecht.

Gelet op deze overwegingen moet worden geconstateerd dat, wat de elementen van een computerprogramma betreft (…), noch de functionaliteit van een computerprogramma, noch de programmeertaal en de indeling van gegevensbestanden die in het kader van een computerprogramma worden gebruikt teneinde de functies daarvan te benutten, een uitdrukkingswijze van dit programma vormen in de zin van [het auteursrecht].

Het opnemen van een functie-aanroep in je programma (zoals printf("Hello, world!"); of readline(my_prompt);) kan dus niet leiden tot een auteursrechtinbreuk op libc of GNU readline, omdat die functie-aanroep nog geen uitdrukkingswijze van het programma libc dan wel readline vormt. Pas als je code zou overnemen, ook in gedeelten, zou er inbreuk kunnen ontstaan.

Wat de GPL of de FSF zeggen over afgeleide werken, linken of Complete Corresponding Source doet er hierbij volstrekt niet toe: je komt pas aan terminologie uit een licentie toe als er sprake is van inbreuk. Pas dan zou de aanroeper van de software immers hoeven te zeggen “geen inbreuk, ik heb een licentie”.

Het argument uit Oracle/Google dat het maken van de API zélf creatief is, gaat hierbij niet op. In die zaak werd Google’s API-kloon van Java inbreukmakend geacht omdat Oracle creatieve arbeid had gestoken in het definiëren daarvan. Maar dat was natuurlijk ook het geval bij de SAS programmeertaal waarvoor WPL programma’s maakte. De functionaliteit, dus ook hoe de functies heten, wat ze doen en welke parameters en return values daarbij horen, is geen “uitdrukkingswijze” van het programma.

Een complete reproductie van de API zou mogelijk wél inbreuk kunnen zijn. In de SAS/WPL uitspraak stond ook de eigen handleiding van WPL ter discussie, waarin elke functie was opgenomen (maar volgens mij ook stukken tekst uit de documentatie van SAS). Dit is iets dat de rechter per geval moet onderzoeken: hoe veel is er overgenomen en hoe creatief is hetgeen overgenomen is? Mogelijk dat bij een handleiding het citaatrecht nog een verweer kan zijn, maar bij een volledige overname met als doel een interface-compatibele kloon te schrijven twijfel ik zeer of dat opgaat. Maar wellicht biedt dit dan een lichtpuntje:

In deze context moet worden gepreciseerd dat indien een derde een gedeelte van de bron- of doelcode betreffende een voor een computerprogramma gebruikte programmeertaal of indeling van gegevensbestanden zou aanschaffen en hij met behulp van deze code soortgelijke elementen in zijn eigen computerprogramma zou creëren, deze handeling mogelijkerwijs een gedeeltelijke reproductie in de zin van [het auteursrecht] zou opleveren.

Het lijkt dus echt nodig dat er ook broncodes worden overgenomen. En puur de definities van de functies voldoen niet snel aan die eis.

Wat vinden jullie? Is er een wezenlijk verschil tussen een API van een of andere bibliotheek aanroepen versus de functies uit een programmeertaal? Maakt het uit of er maar één implementatie van die API+bibliotheek is? Of zijn er andere redenen om een API-aanroep toch inbreuk op het auteursrecht te noemen?

Arnoud

Mag een bedrijf licenties van software afnemen op naam van een werknemer?

vraagteken-zoeken-weeswerk-orphan-workEen lezer vroeg me:

Ik ben student en werk bij een ICT-bedrijf. Mijn werkgever heeft me gevraagd om bij Surfspot wat software met studentenprijzen aan te schaffen zodat hij goedkoper uit is. Moet ik daaraan meewerken? En ga ik de boete krijgen als er een audit komt?

Als student kun je vaak met flinke korting licenties kopen bij bedrijven als Surfspot. Heel handig, want als student heb je het niet breed. En je bent alvast verslaafd tegen de tijd dat je bij een bedrijf gaat werken.

Deze licenties zijn gewoonlijk niet bestemd voor bedrijfsmatig gebruik, in ieder geval niet door anderen dan de licentienemer zelf. Je mag als startende zzp’er bijvoorbeeld soms wel deze software gebruiken hoewel dat bedrijfsmatig is. Dit is wel iets om per softwarepakket te controleren. Maar in de geschetste situatie lijkt het me evident: dit is niet toegestaan onder die goedkope licenties.

Of je aan het verzoek moet meewerken als studentmedewerker, is een lastige. Ik ben geneigd te zeggen van niet: het is geen redelijke dienstopdracht en de werkgever wéét dat hij iets aan laat schaffen dat hij niet kan gebruiken. Bovendien brengt hij de werknemer in een lastig parket omdat die nu ook willens en wetens wat doet dat niet mag.

Aan de andere kant, dit is het risico van de werkgever en juridisch gezien kan de werknemer niets verweten worden in zo’n situatie. Je zou dus kunnen kiezen voor meewerken om de relatie met de werkgever goed te houden, in de wetenschap dat hij het probleem met BSA of andere partijen krijgt en niet jij. Hoewel niet uit te sluiten is dat zo’n werkgever bij problemen gewoon doorverwijst naar de student en daar zit je ook weer niet op te wachten.

Wat zouden jullie doen? Meewerken of nee zeggen?

Arnoud