Wie maatwerksoftware laat bouwen en de rekening betaalt, is daarmee nog geen eigenaar van de broncode. Het auteursrecht blijft bij de maker, tenzij het schriftelijk is overgedragen. Dat volgt uit de Auteurswet en het wordt bevestigd door meerdere Nederlandse juristen, waaronder Dirkzwager (Ernst-Jan van de Pas, 15-08-2019) en SenS Juristen (mr. Hester Spaans).
Hieronder staat wat dat praktisch betekent: welke drie eigendomsmodellen er in de markt bestaan, welke clausules je contract nodig heeft, wanneer escrow zinvol is, wat open source met je afspraken doet, en welke artefacten je bij een overdracht fysiek moet krijgen om zonder je leverancier verder te kunnen. Wat zo'n project kost, staat in wat kost maatwerksoftware.
Waarom "ik betaal, dus ik ben eigenaar" niet klopt
Software is auteursrechtelijk beschermd werk: de Auteurswet noemt computerprogramma's en het voorbereidend materiaal expliciet (art. 10 lid 1 sub 12). Het recht ontstaat bij de maker, degene die de code schrijft. Dirkzwager (15-08-2019) zet de posities scherp tegenover elkaar — "ik maak, dus ik ben eigenaar" tegenover de misvatting "ik betaal, dus ik ben eigenaar". Een opdracht en een betaalde factuur leveren een gebruiksrecht op, geen auteursrecht.
Wat de Auteurswet hierover zegt
Vier artikelen doen het werk. Art. 4 bevat het vermoeden van makerschap: wie op of bij het werk als maker is aangeduid, geldt als maker. Art. 6 maakt een uitzondering voor werk dat is gemaakt naar het ontwerp van een ander en onder diens leiding en toezicht — dan geldt die ander als maker. Art. 7 regelt het werkgeversauteursrecht: werk dat een werknemer in dienstverband vervaardigt heeft de werkgever als maker, tenzij anders is overeengekomen. En art. 2 stelt de eis die het vaakst wordt vergeten: de overeenkomst waarmee auteursrecht wordt overgedragen moet schriftelijk worden aangegaan, en bij overdracht door de maker gaan alleen de bevoegdheden over die uitdrukkelijk in die akte zijn vermeld. De IT-Jurist (03-01-2024) is van de geraadpleegde bronnen de enige die deze artikelnummers noemt; SenS Juristen stelt in gewone taal hetzelfde: zonder akte geen overdracht.
Die laatste eis wordt vaak onderschat. Alleen uitdrukkelijk vermelde bevoegdheden betekent dat een akte waarin niets meer staat dan "het auteursrecht wordt overgedragen" in een discussie smaller kan uitvallen dan je dacht. Je wilt ze benoemd zien: verveelvoudigen, openbaar maken, wijzigen, doorontwikkelen, verhandelen, sublicentiëren en overdragen aan een rechtsopvolger.
Freelancer, bureau of eigen medewerker: drie verschillende uitkomsten
| Wie bouwde het | Standaard rechthebbende | Wat je moet regelen | Bron |
|---|---|---|---|
| Eigen medewerker in dienstverband | De werkgever | Controleren of softwareontwikkeling binnen de functie valt | Art. 7 Auteurswet; De IT-Jurist (03-01-2024) |
| Freelancer of zzp'er | De freelancer | Akte van overdracht in de opdrachtovereenkomst | SenS Juristen; art. 2 Auteurswet |
| Extern bureau | Het bureau | Akte van overdracht, plus afspraken over hergebruikte eigen modules | Dirkzwager (15-08-2019); Ambrero (14-03-2023) |
| Naar jouw ontwerp, onder jouw leiding en toezicht | Jij kunt als maker gelden | Vastleggen wie ontwierp en aanstuurde; smalle uitzondering | Art. 6 Auteurswet; De IT-Jurist (03-01-2024) |
Wat er gebeurt als meerdere partijen aan dezelfde code werkten
Bij software van enige omvang is dat eerder regel dan uitzondering: een bureau bouwt de kern, een freelancer doet de koppelingen, een derde neemt het onderhoud over. SenS Juristen behandelt dit als gedeeld auteursrecht: elke maker heeft rechten op zijn eigen bijdrage, en zonder akte bij elke schakel houd je een lappendeken over. Spreek dus bij elke nieuwe partij dezelfde overdrachtsclausule af, en vraag bij overname van een bestaand project naar de aktes van de vorige leveranciers. Ontbreken die, dan koop je een risico dat pas zichtbaar wordt als je de software wilt verkopen of laten herschrijven.
Eigendom, exclusieve licentie of gebruiksrecht
In de markt bestaan drie modellen naast elkaar. In een offerte klinken ze vergelijkbaar; in de praktijk verschillen ze sterk. Dat het derde model gewoon voorkomt is geen aanname: CODE14 schrijft op de eigen kennisbankpagina eigenaar te zijn van alle door hem ontwikkelde maatwerksoftware, en dat de klant een licentie krijgt met terugkerende kosten van circa 20% per jaar (volgens CODE14; geen auteur of datum op die pagina).
| Model | Wat je mag | Als de leverancier stopt | Doorontwikkeling door een derde | Kosten op termijn |
|---|---|---|---|---|
| Volledige overdracht | Gebruiken, wijzigen, doorontwikkelen, verkopen — mits opgesomd | Je houdt de rechten; alleen de artefacten heb je nog nodig | Zonder toestemming van de bouwer | Eenmalig in de bouwprijs, daarna alleen onderhoud |
| Exclusieve licentie | Gebruiken en meestal laten wijzigen; exclusief voor jou | De licentie blijft; wie het beheer overneemt is een aparte afspraak | Alleen als het wijzigingsrecht in de licentie staat | Vaak eenmalig, soms met periodieke vergoeding |
| Gewoon gebruiksrecht | Gebruiken binnen afgesproken grenzen; wijzigen meestal niet | Het grootste risico: zonder escrow of depot sta je stil | Niet, tenzij apart overeengekomen | Terugkerend, zolang je de software gebruikt |
De vraag bij een offerte is dus niet alleen "wat kost het", maar "welk model krijg ik en wat kost het verschil". Een lagere bouwprijs met een gebruiksrecht kan over vijf jaar duurder uitpakken dan een hogere bouwprijs met overdracht. Die rekensom staat in wat kost maatwerksoftware; hoe wij prijzen per fase opbouwen staat op onze prijzenpagina.
Wat er in het contract moet staan
| Clausule | Waarom die er staat | Wat er misgaat zonder |
|---|---|---|
| Overdracht bij akte, met opsomming van bevoegdheden | Art. 2 eist schriftelijkheid en draagt alleen vermelde bevoegdheden over | Je hebt betaald en juridisch niets in handen |
| Persoonlijkheidsrechten: afstand of uitdrukkelijke regeling | Gaan niet automatisch mee (Dirkzwager, 15-08-2019) | Discussie bij een ingrijpende herschrijving |
| Vrijwaring bij inbreuk door derden | De leverancier staat in voor code die geen rechten van derden schendt (Dirkzwager) | Een claim van een derde komt bij jou terecht |
| Hergebruikte modules van de leverancier | Eigen basiscomponenten vallen zelden onder de akte (Ambrero, 14-03-2023) | Je bezit de bovenlaag, niet het fundament |
| Lijst van gebruikte open-source-licenties | Copyleft brengt verplichtingen mee die jij overneemt | Je ontdekt de verplichting pas bij doorverkoop |
| Geen retentie op de broncode bij een geschil | Anders blokkeert een factuurdiscussie je eigen systeem | Een betalingsgeschil legt je bedrijfsvoering stil |
| Data-eigendom en dataportabiliteit | Data is iets anders dan code: leg vast van wie, en in welk formaat | Je krijgt de code wel, je klantgegevens niet |
| Exit-procedure met een termijn | Wie levert wat op, binnen welke termijn, tegen welk tarief | De overdracht wordt een onderhandeling op je zwakste moment |
Over persoonlijkheidsrechten nog dit: ze zijn in de Auteurswet apart geregeld en blijven volgens Dirkzwager (15-08-2019) bij de maker, ook na een geldige overdracht. Praktisch raakt dat vooral de situatie waarin je de software jaren later ingrijpend laat herschrijven door een andere partij. Laat een jurist toetsen welke afstand in jouw geval mogelijk is; hier schiet een standaardclausule van internet tekort. Liaise Advocaten (Merel Teunissen, 27-02-2020) wijst er verder op dat een akte digitaal ondertekend kan worden, en dat een licentie een werkbaar alternatief is als een ontwikkelaar niet wil overdragen, mits het wijzigingsrecht erin staat.
Loop je contract of je bestaande software langs deze checklist. Twijfel je of je genoeg in handen hebt om zonder je huidige leverancier verder te kunnen? Leg de vraag voor, dan zeggen we welke onderdelen ontbreken.
Escrow: wanneer het zin heeft
Escrow is de standaardoplossing voor het scenario waarin je een gebruiksrecht hebt en je leverancier stopt. Schenkeveld Advocaten (Annette Mak, 20-10-2021) is van de geraadpleegde juridische bronnen de enige die het expliciet aanraadt bij faillissement van de ontwikkelaar. Het werkt met drie partijen: jij, je leverancier en een onafhankelijke escrow-agent die het depot beheert en pas vrijgeeft als een vooraf beschreven release-conditie zich voordoet.
- Bepaal of je het nodig hebt. Bij volledige overdracht plus de repository in eigen beheer voegt escrow weinig toe. Bij een gebruiksrecht op bedrijfskritische software is het de enige realistische bescherming.
- Leg de release-condities vast. Faillissement of surseance, staking van de bedrijfsactiviteiten, structureel niet nakomen van onderhoudsverplichtingen — per conditie met een objectief vaststelbaar moment.
- Beschrijf de depotinhoud. Volgens Escrow4all gaat het om meer dan broncode: technische documentatie, installatie- en buildscripts en waar nodig testdata.
- Eis verificatie. Een depot dat nooit is gecontroleerd op compleetheid en bouwbaarheid is schijnzekerheid: een archief dat niemand kan compileren op het moment dat het moet.
- Spreek een depotfrequentie af. Code van achttien maanden oud sluit niet meer aan op de draaiende omgeving. Koppel het depot aan releases, niet aan de kalender.
In veel MKB-projecten werkt een eenvoudiger constructie beter: een gedeelde repository waarvan jouw organisatie accounthouder is, met de leverancier als medewerker. Er is dan geen depot dat kan verouderen. Escrow blijft dan alleen relevant als de leverancier principieel geen toegang tot de repository wil geven — en die weigering is zelf al informatie.
Open source in jouw maatwerk
Vrijwel elk maatwerkproject staat op open-source-fundamenten: frameworks, bibliotheken, componenten. Dat is normaal en verstandig, maar het betekent dat "jouw" software een verzameling licenties met zich meedraagt. Het Open Source Initiative publiceert de erkende licentieteksten, en de verschillen daartussen zijn niet cosmetisch.
Permissieve licenties (MIT, Apache 2.0, BSD) stellen weinig eisen buiten naamsvermelding en behoud van de licentietekst. Copyleft-licenties — de GPL-familie is de bekendste — kunnen eisen dat afgeleide werken onder dezelfde licentie beschikbaar komen. Ambrero (Jelle van den Berg, 14-03-2023) waarschuwt daar expliciet voor. Voor interne software die je nooit distribueert is dat zelden een probleem; wil je de applicatie later verkopen of als dienst aanbieden, dan wil je die vraag vooraf beantwoord hebben.
De praktische consequentie is klein: vraag bij oplevering om een licentielijst — alle gebruikte componenten met versie en licentie, in de geest van een SBOM. Moderne pakketbeheerders genereren dat met één commando. Een leverancier die zo'n lijst niet kan produceren, weet zelf niet wat er in het product zit.
De overdrachtschecklist: wat je fysiek moet krijgen
Dit is het onderdeel dat in juridische artikelen ontbreekt. Auteursrecht overdragen zonder de artefacten levert een opdrachtgever op die juridisch eigenaar is en operationeel stilstaat. Zeven items maken het verschil tussen "ik heb de code" en "ik kan verder".
| Artefact | In welke vorm | Hoe je controleert dat het compleet is |
|---|---|---|
| Repository met volledige historie | Git-repository onder jouw account, inclusief branches en tags | De historie loopt door tot dag één; een tag komt overeen met wat live draait |
| CI/CD-pipelines en buildinstructies | Pipeline-definities in de repository, plus een beschrijving van de buildstappen | Een derde bouwt de applicatie zonder de oorspronkelijke bouwer |
| Infrastructure-as-code | Serverconfiguratie als code (Terraform, Ansible, containers), geen handwerk | De omgeving is herbouwbaar vanuit de repository |
| `.env`-template en lijst van benodigde geheimen | Alle variabelenamen met hun betekenis, niet de geheimen zelf | Bij elke variabele staat wie de waarde kan aanmaken |
| Runbook en architectuurdocument | Hoe deploy je, hoe herstel je een back-up, wat bij bekende incidenten | Een nieuwe ontwikkelaar komt er zelfstandig uit |
| Domeinen, DNS en accounts bij derden | Domein, DNS en externe accounts op jouw naam | Je wijzigt zelf een DNS-record en trekt zelf een API-sleutel in |
| Licentielijst en documentatie | Open-source-componenten met versie en licentie, plus betaalde licenties | De lijst is gegenereerd uit de pakketbeheerder, niet met de hand gemaakt |
Draait de software op infrastructuur die de leverancier beheert, dan hoort daar hetzelfde bij: wie is accounthouder, wie kan de omgeving benaderen, hoe verhuis je hem. Op hosting en beheer staat welke rollen en toegangen daarbij horen. Voor koppelingen geldt hetzelfde — sleutels en accounts op jouw naam; zie waarom koppelingen stukgaan. Voor geautomatiseerde workflows werkt de overdracht net zo, zie onze aanpak van automatisering.
Vijf vragen die je vóór ondertekening stelt
- Krijg ik het auteursrecht overgedragen, of een licentie? Vraag het antwoord in één zin, en zoek die zin terug in het contract.
- Welke bevoegdheden staan uitdrukkelijk in de akte? Wijzigen, doorontwikkelen en overdragen aan een rechtsopvolger horen erbij; art. 2 draagt alleen over wat er letterlijk staat.
- Welke onderdelen zijn hergebruikte modules van jullie? Dit is de meest voorkomende uitzondering op een verder nette overdrachtsclausule.
- Wat lever je op bij einde samenwerking, binnen welke termijn? Loop de zeven artefacten hierboven punt voor punt langs.
- Wat gebeurt er met de code bij een factuurgeschil? Het antwoord "dan houden we de code vast" is een reden om niet te tekenen.
Dit zijn geen strikvragen. Een leverancier die overdracht normaal vindt, beantwoordt ze in vijf minuten. Wat wij bij overnames van bestaande projecten vaak zien is ook geen kwade wil maar slordigheid: een repository zonder historie, geheimen die alleen in het hoofd van één ontwikkelaar zitten, een server die met de hand is ingericht. Herstelbaar, maar het kost tijd die niemand heeft begroot.
Tot slot
Eigendom van software is geen kwestie van vertrouwen maar van vastleggen, en het regelen ervan is geen aanval op je leverancier: zo gaat het bij elk ander bedrijfsmiddel ook. Betalen maakt je geen eigenaar, een akte met benoemde bevoegdheden wel — en pas de zeven artefacten maken dat eigendom bruikbaar. Wat een traject kost waarin dit vanaf dag één goed staat, lees je in wat kost maatwerksoftware en wat automatisering kost.
Nogmaals: dit is praktijkuitleg op basis van de Auteurswet en de genoemde juridische bronnen, en geen juridisch advies. Laat het contract dat je gaat tekenen toetsen door een IT-jurist — zeker de bepalingen over persoonlijkheidsrechten en hergebruikte componenten, want daar schieten standaardteksten het vaakst tekort.