Heb je auteursrecht op bugfixes op andermans software?

“Het herstellen van een bug is in het algemeen geen grote bewerking”. Aldus de rechtbank Rotterdam in een recent geschil over broncodes. Voordat iedereen boos wordt: het ging hier over auteursrechtelijk grote bewerkingen, en dat is wat anders dan hoe moeilijk het is om voor elkaar te krijgen.

De zaak komt erop neer dat de koper van een stuk software de oude eigenaar (en ik vermoed, maker) daarvan inhuurde als zzp’er om hier bepaalde bug fixes in uit te voeren. Die leverde dat aan in de vorm van gecompileerde binaries, maar wilde geen broncode verstrekken en beriep zich op auteursrecht op de fixes.

Je kunt op zich ook op een klein werk (als in: weinig regels of woorden) auteursrecht hebben. Waar het om gaat, is of je een eigen intellectuele schepping dan wel eigen oorspronkelijk karakter/persoonlijk stempel daar in hebt zitten. Wat de rechter hier “banale of triviale elementen” noemt, valt buiten het auteursrecht. Die interrupt héét nou eenmaal 13h, dus dat getal zul je moeten noemen en daar is auteursrechtelijk niets intellectueels aan.

Intrigerender wordt het door de vervolgzin:

[D]e keuzes van de maker mogen niet louter een technisch effect dienen of te zeer het resultaat zijn van een door technische uitgangspunten beperkte keuze.
Dat je bij programmeren creatief bezig bent, erkent iedereen. Maar er zijn randgevallen waarin daar geen (of weinig) sprake van is. Het herstellen van fouten is zo’n randgeval: je bent dan niet iets nieuws en eigens aan het toevoegen, je herstelt andermans fouten (of denkt dat te doen), en dat is haast per definitie niet een eigen inbreng.

Natuurlijk, het hangt af van het soort fout. Als je een naiëve eenregelige aanroep van een functie vervangt door een pagina vol met checks en balances inclusief security best practices, dan is die pagina vast auteursrechtelijk creatief. Deze zaak lijkt te zijn gegaan om het meer standaardwerk, het corrigeren van kleine misstappen in het origineel.

Een punt is nog wel dat een bug best moeilijk kan zijn om op te sporen (ik heb veel bewondering voor deze) maar niet perse moeilijk om op te lossen áls je het probleem gevonden hebt. Iedereen kent het verschijnsel van een hele middag bezig zijn om een ongewenste puntkomma te lokaliseren. Het frustrerende is dan dat die activiteit niet auteursrechtelijk relevant is – het gaat alleen om creativiteit die in het resultaat te herkennen is.

Als laatste bleek de bugfixer/programmeur niet inhoudelijk diep te zijn ingegaan op wáár dan de creativiteit zat. Als je je op auteursrecht beroept, moet je (desgevraagd) wel kunnen aantonen waarom het jouw intellectuele schepping was.

Arnoud

3 reacties

  1. Gebaseerd op mijn eigen ervaringen als Software Engineer denk ik dat er veel meer creativiteit zit in het oplossen van bugs dan dat mensen denken. Even afgezien van simpele typefouten en dergelijke als oorzaak maak je bijna altijd creatieve keuzes in het oplossen van bugs. Je moet namelijk bijna altijd stukken code herschrijven, daarbij maak je keuzes in hoe je dat aanpakt zowel in stijl, flow van de code, gebruik van functionaliteiten etc.

  2. Ooit was er een geschil over een patch die de licentiecode van een bepaald software pakket wist te omzeilen.

    Het kwam er uiteindelijk op neer dat de patch ook auteursrechtelijk beschermd is omdat het een op zichzelf staand software pakket is. De exacte details weet ik niet meer, het is ook al ruim 25 jaar geleden.

    De gewijzigde code in het oorspronkelijke stuk software was niet zo groot maar de weg er naartoe was best bewerkelijk.

    1. Cracks waren 20-25 jaar geleden (en misschien nog steeds) echte kunstwerkjes. Herkenbare gui, ASCII art, leuk deuntje, daar zit zeker auteursrecht op.

      Heeft de maker van de patch auteursrecht op de gepatchte executable? Dat hangt af van de werking van de patch. Op de juiste plek een JE-instructie in JNE veranderen is bijvoorbeeld precies het standaardwerk dat creativiteit ontbeert waar deze blog mee is begonnen. Maar als de patch uitgebreider is of meerdere zaken creatief combineert, bijvoorbeeld de verbinding met de licentieserver op een creatieve manier afhandelt, is de gepatchte executable een afgeleid (waarop zowel de de originele rechthebbende als de maker van de patch auteursrecht hebben).

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.