Van wie is je maatwerk software eigenlijk?

Je hebt maatwerk software laten bouwen. Facturen betaald, applicatie draait, iedereen tevreden. Dus die software is van jou. Toch?

Meestal niet. Althans, niet automatisch. In Nederland ligt het auteursrecht op software bij degene die de code schrijft, niet bij degene die ervoor betaalt. Zonder schriftelijke afspraken heb je dus betaald voor iets dat juridisch nog steeds van je leverancier is. Jij hebt dan een gebruiksrecht, een licentie. Meer niet.

Dat klinkt als een detail voor juristen. Dat is het niet. Ik kom het in de praktijk regelmatig tegen, en bijna altijd op het slechtst denkbare moment.

Betaald hebben is niet hetzelfde als eigenaar zijn

Het misverstand is begrijpelijk. Als je een machine koopt, is die machine van jou. Bij software werkt dat anders: de wet zegt dat auteursrecht alleen schriftelijk kan worden overgedragen. Staat er niets over in je contract of offerte, dan is er niets overgedragen.

Wat heb je dan wel? Een gebruiksrecht. Je mag de software gebruiken zoals bedoeld. Maar mag je de broncode opvragen? Mag een andere partij eraan verder bouwen? Mag je de applicatie verhuizen naar een andere hostingpartij? Dat hangt allemaal af van wat er op papier staat. En vaak staat er niets.

Voor de duidelijkheid: dit betekent niet dat leveranciers die het eigendom houden je willen oplichten. Sommige bouwers werken met een eigen platform of herbruikbare componenten, en dat model kan prima werken. Maar je moet wél weten dat het zo geregeld is. Vóórdat je tekent, niet vijf jaar later.

Waarom je dit pas merkt als het misgaat

Zolang de samenwerking goed loopt, merk je niets van deze vraag. De software draait, de bouwer onderhoudt, klaar.

Het gaat knellen op drie momenten. Je wilt overstappen naar een andere partij, omdat de samenwerking stroef loopt of de prijzen stijgen. Je leverancier stopt ermee, gaat failliet of wordt overgenomen. Of er ontstaat een conflict, en ineens is de vraag wie wat mag heel concreet.

Ik heb ondernemers gesproken die jarenlang in een applicatie hadden geïnvesteerd en er bij een conflict achter kwamen dat ze niet eens recht hadden op de broncode. Dan sta je met lege handen. Opnieuw laten bouwen is dan vaak de enige uitweg, en dat kost een veelvoud van wat een goed contract had gekost. Hoe zo'n situatie eruitziet als je developer er ineens mee ophoudt, beschreef ik eerder in wat te doen als je Laravel developer stopt.

De broncode hebben is niet genoeg

Stel, het eigendom is netjes geregeld en je krijgt de broncode. Ben je er dan? Nog niet helemaal.

Een applicatie is meer dan een map met code. Je hebt ook toegang nodig tot de plek waar die code wordt bijgehouden, meestal een systeem als GitHub. Tot de database. Tot de hosting en de domeinnamen. Tot de configuratie met wachtwoorden en koppelingen naar andere diensten. Mist er één schakel, dan kan een nieuwe partij alsnog weken bezig zijn met puzzelen.

Wanneer ik een bestaand Laravel project overneem, is dit steevast het eerste wat ik controleer. Niet de kwaliteit van de code, maar of alle toegangen er zijn. Vaker dan je zou denken blijkt het versiebeheer op het persoonlijke account van een vertrokken developer te staan.

Voor wie het extra zeker wil regelen bestaat er escrow: een onafhankelijke partij bewaart een kopie van de broncode en geeft die vrij als de leverancier failliet gaat. Voor de meeste MKB-applicaties vind ik dat overdreven. Een simpelere afspraak, namelijk dat jij altijd zelf toegang hebt tot het versiebeheer, lost in de praktijk hetzelfde op en kost niets.

Hoe zit dat met open source?

Een nuance die vragen oproept. Veel maatwerk wordt gebouwd op een open source framework zoals Laravel. Dat framework is van niemand en van iedereen; daar kun je geen eigendom van claimen en dat hoeft ook niet.

Waar het om gaat is de laag daarbovenop: het maatwerk dat specifiek voor jouw bedrijf is geschreven. Jouw offertemodule, jouw koppeling met de boekhouding, jouw planning. Dát is het deel waar je afspraken over maakt. Een redelijke tussenvorm die ik zelf ook hanteer: het klantspecifieke werk wordt eigendom van de klant, terwijl de bouwer generieke bouwstenen mag hergebruiken. Daar heeft niemand last van, en het houdt de prijs redelijk.

Wat je concreet vastlegt

Dit hoeft geen contract van veertig pagina's te zijn. Een paar heldere afspraken volstaan:

• Het auteursrecht op het maatwerk wordt schriftelijk aan jou overgedragen, of je krijgt een licentie die overdraagbaar en eeuwigdurend is.
• Jij hebt altijd eigen toegang tot het versiebeheer waar de broncode staat.
• Hosting, domeinnamen en externe diensten staan op naam van jouw bedrijf, niet op naam van de bouwer.
• Bij einde samenwerking werkt de leverancier mee aan een nette overdracht, tegen een vooraf bekend tarief.
• Documentatie van koppelingen en wachtwoordbeheer is onderdeel van de oplevering.

Heb je al een lopende applicatie en is dit nooit geregeld? Dan is het gesprek nu aangaan verstandiger dan wachten. Zolang de relatie goed is, wil vrijwel elke leverancier dit alsnog vastleggen. Bij een conflict ligt dat anders.

Mijn advies

Vraag het gewoon, vóór je een opdracht geeft. "Van wie is de broncode straks, en waar staat dat?" Een goede bouwer heeft daar een helder antwoord op en vindt de vraag niet vervelend. Wie eromheen draait, geeft je eigenlijk ook een antwoord.

Zelf regel ik het simpel: wie mij maatwerk software laat bouwen, wordt eigenaar van dat maatwerk en heeft vanaf dag één toegang tot de code. Niet omdat het moet, maar omdat ik vind dat je nooit klant moet blijven omdat je niet weg kúnt. Klanten die blijven omdat het werk goed is, daar heb je allebei meer aan.

Ik ben overigens geen jurist, en dit artikel is geen juridisch advies. Gaat het om een grote investering of een lopend conflict, leg je contract dan voor aan iemand die daarin gespecialiseerd is. Maar de kern kun je zelf al regelen: zet het op papier, nu het nog makkelijk is.