Door Nick Vrugt | Softwarerecht | 27 december 2021 | 7 min. leestijd
Software is nooit helemaal foutloos, maar fouten kunnen meestal wel worden hersteld. Een vraag die daarbij speelt is wat een gebruiker van de software mag doen om dergelijke fouten zelf te (laten) herstellen. Daarover heeft het Hof van Justitie van de Europese Unie (hierna: “HvJEU”) recent een belangrijk arrest gewezen. De centrale vraag luidt: in hoeverre heeft de gebruiker het recht om software te “decompileren” om fouten te herstellen?
Wat is decompileren?
Voordat ik het arrest bespreek, zal ik eerst kort uitleggen wat decompileren is.
Software wordt ontwikkeld doordat een programmeur broncode schrijft (“programmeren”). Deze broncode is niet direct door een computer te lezen. Deze moet eerst worden omgezet in objectcode. Dit omzetten wordt compileren genoemd.
Decompileren is het omgekeerde proces van compileren. Dus het reconstrueren van de broncode op basis van de objectcode. Door de objectcode te decompileren krijg je overigens niet exact de oorspronkelijke broncode, maar wel een code die daarop lijkt. Deze code wordt de quasibroncode genoemd.
De gebruiker van software heeft vaak alleen de objectcode van de software. De broncode blijft meestal in handen van de ontwikkelaar van de software. Dit kan anders zijn als er afspraken zijn gemaakt over de afgifte van de broncode, of als een rechter heeft bevolen dat de ontwikkelaar de broncode moet afgeven.
Om fouten in de software te herstellen is vaak de broncode nodig, maar de gebruiker beschikt daar vaak niet over. De vraag is in hoeverre de gebruiker de objectcode mag decompileren en zo de fouten mag herstellen met de quasibroncode. Dit speelde ook in de zaak waarover het HvJEU heeft geoordeeld.
Top Systems / Selor
De zaak betreft een Belgische zaak tussen Top System en Selor. Top System verleent sinds 1990 IT-gerelateerde diensten aan Selor. Een van deze diensten betreft het ontwikkelen van software om het recruteringsproces van Selor te ondersteunen. Deze software bestaat uit standaardsoftware van Top System (het Top System Framework) met enkele op maat gemaakte aanpassingen voor Selor.
Op een gegeven moment migreert Selor de software naar een nieuwe omgeving. Dit gaat echter niet zonder slag of stoot. Er doen zich enkele foutmeldingen voor. Selor komt met Top System niet tot een oplossing van de fouten en vervolgens – zo lijkt uit het arrest te volgen – besluit Selor om de software zelf (of door een derde) te (laten) decompileren om de fouten zelf te (laten) herstellen.
Top System stelt zich op het standpunt dat dit een auteursrechtinbreuk oplevert en zij start een procedure in België, onder meer om schadevergoeding te krijgen.
De Belgische rechter in eerste aanleg oordeelt dat geen sprake is van inbreuk. In hoger beroep weet het Belgische hof niet zeker of Selor als rechtmatige gebruiker de software mocht decompileren onder de Softwarerichtlijn, zonder de toestemming van Top System. En welke voorwaarden hiervoor eventueel zouden gelden. Het Belgische hof besluit daarom vragen te stellen aan het HvJEU.
Vragen
De vragen luiden, kort en simpel gezegd, als volgt:
- Moet artikel 5 lid 1 van de Softwarerichtlijn zo worden uitgelegd dat het de gebruiker toestaat om een programma te decompileren als dat noodzakelijk is om fouten te kunnen herstellen?
- Zo ja, moet dan ook aan de voorwaarden van artikel 6 van de Softwarerichtlijn of aan andere voorwaarden worden voldaan?
Uitzonderingen in de Softwarerichtlijn
Voordat ik het oordeel van het HvJEU bespreek, eerst kort iets over de relevante bepalingen uit de Softwarerichtlijn.
Artikel 4 van de Softwarerichtlijn bepaalt, kort gezegd, dat voor alle reproductie-, wijzigings- en distributiehandelingen in beginsel de toestemming van de auteursrechthebbende is vereist.
Artikel 5 vormt daarop een uitzondering in die zin dat voor reproductie- en wijzigingshandelingen geen toestemming nodig is als deze handelingen voor de gebruiker noodzakelijk zijn om de software te kunnen gebruiken voor het beoogde doel, onder meer om fouten te verbeteren. In dit artikel wordt niet gesproken over decompileren.
Artikel 6 bevat een andere uitzondering. Dit artikel noemt wel uitdrukkelijk decompileren. Decompileren zonder toestemming van de rechthebbende is onder bepaalde voorwaarden toegestaan om de compatibiliteit met andere software tot stand te brengen. In dit artikel wordt niet gesproken over foutherstel.
De vraag die nu voorligt is of decompileren met als doel het herstel van fouten is toegestaan. En zo ja, welke voorwaarden in dat geval gelden. Die van artikel 5, die van artikel 6, of beide.
Oordeel van het HvJEU
Decompileren is een reproductie- en wijzigingshandeling
Het HvJEU stelt allereerst vast dat decompileren een handeling is waarbij software – in elk geval gedeeltelijk – wordt gereproduceerd en vertaald. Daarom is dit een handeling die onder artikel 4 van de Softwarerichtlijn valt en waarvoor dus in beginsel de toestemming nodig is van de rechthebbende.
De uitzonderingen in artikel 5 en 6
Vervolgens oordeelt het HvJEU dat onder de uitzondering van artikel 5 ook moet worden verstaan het decompileren van de software om fouten te verbeteren. Ook al wordt decompileren niet uitdrukkelijk genoemd in artikel 5 (zoals dat wel gebeurt in artikel 6). Volgens het HvJEU was het niet de bedoeling van de wetgever om de mogelijkheid om te decompileren te beperken tot de compatibiliteitsuitzondering in artikel 6. Ook zou de doeltreffendheid van de uitzondering van artikel 5 ernstig beperkt worden als de software niet gedecompileerd mocht worden om fouten te herstellen. Voor het herstel van fouten is namelijk in veel gevallen de broncode nodig. Of in elk geval de quasibroncode.
Maar welke voorwaarden gelden er dan? Die van artikel 5 en/of die van artikel 6? Het HvJEU oordeelt dat de strikte voorwaarden van artikel 6 in een dergelijk geval niet gelden. Deze voorwaarden zijn namelijk bedoeld voor een andere situatie (namelijk compatibiliteit i.p.v. foutherstel).
Wel gelden de voorwaarden van artikel 5: decompileren moet noodzakelijk zijn om de software te kunnen gebruiken voor het beoogde doel, onder meer om fouten te verbeteren.
Noodzakelijk?
Het HvJEU zegt nog iets over dit noodzakelijkheidsvereiste: de gebruiker mag slechts decompileren als de broncode niet contractueel of wettelijk beschikbaar voor hem is. Is deze wel beschikbaar? Dan is decompileren namelijk niet noodzakelijk.
Decompileren mag alleen voor foutherstel
Ook mag het decompileren alleen met als doel om fouten te herstellen. Een fout is volgens het HvJEU een gebrek in de software waardoor de software niet naar behoren functioneert en dat afbreuk doet aan de mogelijkheid om de software te gebruiken voor het beoogde doel. Het resultaat van het decompileren mag niet worden gebruikt voor andere doeleinden dat voor foutherstel. Deze mag bijvoorbeeld dus niet worden verspreid of worden gebruikt om andere, concurrerende, software mee te ontwikkelen.
“Tenzij bij overeenkomst anders bepaald”?
Wat verder nog interessant is, is dat in de uitzondering van artikel 5 is opgenomen dat toestemming van de rechthebbende niet vereist is “tenzij bij overeenkomst uitdrukkelijk anders bepaald is“. Met andere woorden, partijen kunnen afspreken dat voor decompileren voor foutherstel toch de toestemming van de rechthebbende nodig is. Het HvJEU steekt daar nu een stokje voor. Het HvJEU oordeelt dat niet iedere mogelijkheid van de gebruiker om fouten te herstellen d.m.v. decompileren kan worden uitgesloten. Wel kunnen partijen afspraken maken over hoe deze mogelijkheid kan worden uitgeoefend.
Tot slot
Als in de overeenkomst niets is geregeld, dan mag de gebruiker de software dus decompileren als dit nodig is om fouten te herstellen. Wil je deze mogelijkheid als ontwikkelaar beperken? Dan kan je ervoor kiezen om overeen te komen dat de broncode – onder bepaalde voorwaarden – voor de gebruiker beschikbaar is. Decompileren is dan niet meer noodzakelijk. Een andere optie is om afspraken te maken over / voorwaarden te stellen aan de mogelijkheid tot decompileren.
Interessant is ook dat het HvJEU in deze zaak een definitie geeft voor een “fout”. Tussen partijen bestaat nog wel eens discussie over de vraag of iets wel/geen “fout” is. Mogelijk kan er in zulke gevallen bij de definitie van het HvJEU aansluiting worden gezocht.
