Decompileren voor foutverbetering is gewoon toegestaan

Helemaal vergeten: het Europese Hof van Justitie had begin oktober het decompileren van software legaal verklaard, als dat nodig is om fouten (bugs) te verbeteren. Het is een vrij technisch arrest maar met een welkome verduidelijking voor de praktijk. Kort gezegd: als je niet aan decompileren ontkomt om een fout te halen uit software die je onder licentie hebt, dan mag dat. Ongeacht wat de licentieovereenkomst zegt.

Het arrest gaat over de wat technische vraag hoe de grenzen van decompilatie liggen in het Europees auteursrecht. Hierbij zijn twee artikelen uit de Europese Richtlijn 91/250 relevant. Allereerst is er artikel 5 (bij ons 45j Auteurswet) over het mogen herstellen van fouten. En dan heb je ook artikel 6 (bij ons artikel 45m Auteurswet) dat bepaalt dat je software mag decompileren om de onderliggende werking te achterhalen ten behoeve van interoperabiliteit met andere software. Denk aan het uitvogelen van een bestandsformaat of een niet-publieke API die je nodig hebt om te interfacen met die software.

In België had de overheidsdienst Selor (het selectiebureau van de overheid) software afgenomen van het bedrijf Top Systems. Selor had daar eigen software naast gebouwd die samenwerkte met de Top software. En zoals dat gaat, er ontstond ruzie over de leveringen door Top, waarna die terugsloeg met de aanklacht dat Selor in strijd met de wet de software had gereverse-engineered.

Bij de Belgische rechter bleek het te gaan om het uitzetten van een functie uit de Top software, die de goede werking van de rest van de software verstoorde. (Ik denk niet dat het om een copyprotectiefunctie gaat, maar kan verder niet vinden wat die functie dan wel zou doen.) Om dit te kunnen doen, moest Selor de software reverse engineeren.

En dan is dus de vraag: je mag fouten verbeteren en je mag reverse engineeren voor interoperabiliteit, maar mag je ook reverse engineeren voor het verbeteren van fouten? Eentje voor het Hof van Justitie, zo dacht de Belgische rechter heel wijs.

Het HvJ begint met uitleggen, zoals juristen dat altijd plachten te doen, dat software bestaat in broncode en objectcode, en dat reverse engineeren neerkomt op die laatste vorm terugzetten in soort-van de eerste. Je hebt altijd enig kwaliteitsverlies (net zoals wanneer je een PDF weer opent in Word) maar het is goed genoeg om dingen aan te kunnen passen als dat nodig is.

Om dit te kunnen doen, moet je de objectcode laden in een decompiler, waarna een kopie in broncodevorm gemaakt wordt. Dit is juridisch rechttoe rechtaan een kopie van de software, net zoals wanneer je broncode in objectcode omzet (of wanneer je een boek verfilmt, hetzelfde wetsartikel).

Voor het maken van een kopie is in beginsel toestemming van de rechthebbende nodig, tenzij er uitzonderingen in de wet staan. Nu hebben we het hier over decompilatie, en dat mag van de wet dus alleen voor interoperabiliteitsdoeleinden (artikel 6/45m), terwijl wat Selor deed ging om foutverbetering. En probleem is dan dat in de overwegingen van de Richtlijn staat:

Overwegende dat alleen in deze zeldzame gevallen de uitvoering van de handelingen van reproduktie en vertaling door of voor een persoon die het recht heeft een kopie van het programma te gebruiken als rechtmatig moet worden beschouwd en in overeenstemming met normale praktijken, en daarom moet worden geacht geen toestemming van de rechthebbende te vereisen;
Het Hof zegt nu echter: dat “alleen in deze zeldzame gevallen” moet je lezen als de zeldzame gevallen waarin decompilatie ten behoeve van interoperabiliteit gerechtvaardigd is. Er staat geen algemeen verbod op decompilatie gevolgd door “behalve heel soms voor interoperabiliteit” (zoals menig juridisch handboek het overigens brengt) maar een serie strenge regels over interoperabiliteit tot stand brengen met decompilatie.

En dan kom je natuurlijk terug bij artikel 5, dat je toestaat de software te verveelvoudigen als dat nodig is voor foutherstel. Decompilatie is verveelvoudigen, maar dat mag dus als dat nodig is. Daarmee is een breder recht van decompileren dus legaal verklaard. Achteraf gezien helemaal niet zo gek: er zijn weinig manieren voor derden om fouten te herstellen zonder decompileren.

Arnoud

 

2 reacties

  1. Enkele dagen terug was er ook nieuws over decompileren: https://tweakers.net/nieuws/190040/fans-zijn-vrijwel-klaar-met-decompileren-binaries-zelda-ocarina-of-time.html.

    Dit wordt niet gedaan voor interoperabiliteit met een ander onafhankelijk vervaardigd computerprogramma en het lijkt dus niet onder de artikel 6 uitzondering te vallen. In dit artikel wordt gezegd:

    Het enige wat ze doen is de broncode met de hand nabootsen in C, wat betekent dat ze geen inbreuk maken op het auteursrecht van Nintendo.
    Waar halen ze deze uitzondering vandaan?

    In een ander project,https://tweakers.net/nieuws/189734/leden-reverse-engineerprojecten-gta-iii-en-vc-vechten-rechtszaak-take-two-aan.html, claimen de programmeurs een uitzondering omdat ze niet de assets (modellen, plaatjes, geluid, verhaal, etc) kopiëren. Ze maken alleen de nieuwe engine waarmee iemand die de assets al heeft, omdat hij een (legale) kopie van het spel heeft, het spel kan spelen met de nieuwe engine zonder bugs en met extra features (e.g. hogere framerate). Ook deze uitzondering haal ik niet expliciet uit artikel 5 en 6, de aangepaste versie (zonder assets) worden immers verspreid en de versie heeft ook nieuwe features naast bugfixes.

    Zijn dit onderwerpen voor de comment sectie, of zou het antwoord hierop zo ingewikkeld zijn, dat het een complete blogpost zou zijn?

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.