In principe verplicht de Auteurswet de auteursrechthebbende op software niet om de broncode van de programmatuur aan de gebruiker van de software te verstrekken. Ook niet als onderhoud is vereist of indien er fouten in de programmatuur zijn ontstaan die moeten worden opgelost, waarvoor deze broncode nodig is. Uit de rechtspraak blijkt echter dat de auteursrechthebbende toch in een aantal gevallen wordt veroordeeld tot afgifte van de broncode van de programmatuur aan de gebruiker.
In deze blog zullen de gezichtspunten die bepalend zijn voor een eventuele verplichte afgifte van de broncode kort worden samengevat. Het doel van deze blog is om ervoor te zorgen dat niet alleen juristen van deze gezichtspunten op de hoogte zijn, maar ook de leveranciers en gebruikers van software.
Allereerst zal ik beginnen met een korte uitleg van het begrip “broncode”. De broncode van software is de leesbare code die een programmeur in een programmeertaal heeft geschreven, waarin instructies staan voor de computer. De broncode wordt uiteindelijk vertaald naar een code die door de computer direct is uit te voeren. Dit wordt de uitvoerbare (executable) code genoemd.
Onder afgifte van de broncode in juridische zin wordt verstaan de afgifte van de broncode en van alle technische ontwikkeldocumentatie.
In zowel de Auteurswet als in de Softwarerichtlijn is zoals gezegd geen verplichting opgelegd aan de auteursrechthebbende om ten aanzien van software onderhoud of foutherstel de broncode (of andere benodigde materialen) aan de gebruiker van de software af te staan. Ook wordt geen verplichting aan de auteursrechthebbende opgelegd om tegen een redelijke vergoedingen aanpassingen in de programmatuur aan te brengen. Voor de gebruiker van de software kan dit in sommige gevallen grote problemen opleveren. Daarom blijkt het in sommige gevallen toch mogelijk om als gebruiker afgifte van de broncode te vorderen.
Omdat de Auteurswet en de Softwarerichtlijn niets vermelden over een verplichting tot afgifte van de broncode, hangt de vraag of een vordering tot afgifte van de broncode kan worden toegewezen volledig af van de inhoud van de overeenkomst, de redelijke uitleg hiervan en het soort software waarop de overeenkomst betrekking heeft. In sommige gevallen zegt de overeenkomst uitdrukkelijk iets over een eventuele afgifte van de broncode, maar in veel gevallen zwijgt de overeenkomst hierover en zal het aankomen op een uitleg van de overeenkomst naar maatstaven van redelijkheid en billijkheid. Hierbij wordt onder meer naar de volgende tien vereisten gekeken.
Allereerst wordt gekeken naar de gebruiken die gelden in de desbetreffende softwarebranche. Is het gebruikelijk om de broncode af te staan voor onderhoud, of is dit juist ongebruikelijk?
Daarnaast wordt gekeken naar de nijpendheid van het onderhoudsprobleem. Met andere woorden: hoe ernstig is het probleem? Is het een relatief klein onderhoudsprobleem, dan zal afgifte van de broncode minder snel zijn gerechtvaardigd dan wanneer sprake is van een grote fout in de software.
Indien de gebruiker volledig afhankelijk is van de software, zal eerder worden geoordeeld dat afgifte van de broncode is vereist.
In veel overeenkomsten wordt aan de gebruiker het recht toegekend om de software te “gebruiken”, maar wordt niet aangegeven wat hieronder dient te worden verstaan. De prijsstelling van dit gebruiksrecht zou hier een eventuele aanwijzing bij kunnen zijn. Daaruit zou dan kunnen worden afgeleid dat de gebruiker in sommige gevallen recht zou hebben op de broncode, of juist niet.
Tussen partijen kan zijn overeengekomen dat de leverancier onderhoudsproblemen zal oplossen en fouten zal herstellen. Indien ten tijde van de problemen blijkt dat de leverancier niet over het juiste onderhoudspersoneel beschikt, kan worden besloten dat de broncode dient te worden afgegeven. Op deze manier kan de gebruiker zelf (of een derde partij) de desbetreffende problemen oplossen.
Met een escrow overeenkomst spreken partijen een regeling af voor de continuïteit van de geleverde software. De overeenkomst garandeert dat de gebruiker in bepaalde gevallen kan beschikken over de broncode van de software. Is zo’n escrow overeenkomst gesloten, dan is het aannemelijker dat de gebruiker een recht heeft op de afgifte van de broncode.
In sommige gevallen kunnen de ontwikkelingskosten van de software een aanwijzing zijn voor het wel/niet verplicht zijn tot afgifte van de broncode. Als de leverancier veel geld heeft gestoken in het ontwikkelen van de software, dan ligt het minder voor de hand om de broncode af te staan dan wanneer weinig kosten voor de software zijn gemaakt.
De laatste drie punten hangen enigszins met elkaar samen. De eerste is de inzetbaarheid van de software. Indien de software breed inzetbaar is, is het voor de leverancier commercieel gezien een slecht idee om de broncode zomaar af te geven. Indien de software alleen voor de gebruiker kan worden ingezet, dan heeft het afgeven van de broncode voor de leverancier minder grote gevolgen. Dit kan worden meegewogen bij de vordering tot afgifte van de broncode.
Als de software breed inzetbaar is, kan de commerciële waarde van de broncode aanzienlijk zijn. De broncode kan dan (met enige aanpassing) voor andere klanten worden ingezet. De leverancier kan de broncode dan verder exploiteren. Het belang dat de broncode bij de leverancier blijft, is dan groter dan wanneer de broncode geen (of een lage) commerciële waarde heeft.
Wanneer sprake is van software die speciaal voor de gebruiker is gemaakt (maatwerksoftware) is het aannemelijker om de broncode aan gebruiker af te staan, dan wanneer het gaat om standaardsoftware. Maatwerksoftware is vaak niet breed inzetbaar en de commerciële waarde van de broncode is daarom laag. Bij standaardsoftware geldt het tegenovergestelde: deze is breed inzetbaar en de commerciële waarde van de broncode is vaak hoog.
Naast deze tien feitelijke omstandigheden, wordt ook gekeken naar de bewoordingen van de overeenkomst en de bedoelingen die partijen hadden bij het sluiten van de overeenkomst. Niet alleen dient te worden gekeken naar de letterlijke tekst van de overeenkomst, maar ook moet worden gekeken welke betekenis partijen aan de tekst gaven en wat ze over en weer van elkaar mochten verwachten.
Tot slot wil ik afsluiten met enkele tips, waarmee bovenstaand probleem (zoveel mogelijk) kan worden voorkomen.
Dit artikel is eerder gepubliceerd op lawfox.nl
Geschreven door: Nick Vrugt, IT-jurist LAWFOX
LAWFOX Advocatuur is een procespraktijk voor internetondernemingen en is een partnerkantoor van ICTRecht. Het hoofdkantoor is gevestigd te Tilburg en is opgericht door internetadvocaat Wouter Dammers. Wouter Dammers heeft voor de start van zijn eigen advocatenkantoor LAWFOX ook als juridisch adviseur bij ICTRecht gewerkt.
Meld je nu aan voor één van de nieuwsbrieven van ICTRecht en blijf op de hoogte van onderwerpen zoals AI, contracteren, informatiebeveiliging, e-commerce, privacy, zorg & ICT en overheid.