Is sjoemelsoftware in je Volkswagen reden om hem te retourneren?

| AE 8057 | Informatiemaatschappij | 38 reacties

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?

| AE 8023 | Intellectuele rechten, Security | 31 reacties

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

| AE 7806 | Intellectuele rechten, Security | 22 reacties

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’?

| AE 7693 | Innovatie, Intellectuele rechten | 38 reacties

Voertuigfabrikanten 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… Lees verder

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

| AE 7673 | Intellectuele rechten | 15 reacties

Een 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… Lees verder

Tweedehands software mag worden doorverkocht, en de licentie gaat mee

| AE 7557 | Intellectuele rechten | 14 reacties

Een 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… Lees verder

Mag je Metasploit-modules publiceren voor kwetsbaarheden in software?

| AE 7448 | Intellectuele rechten, Security | 17 reacties

Een 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… Lees verder

Hoe lang moet een telefoonverkoper Android ondersteunen?

| AE 7398 | Intellectuele rechten, Ondernemingsvrijheid | 41 reacties

Een 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… Lees verder

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Intellectuele rechten | 40 reacties

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… Lees verder

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

| AE 7167 | Intellectuele rechten, Ondernemingsvrijheid | 15 reacties

Een 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… Lees verder