Gepubliceerd op 23 september 2026
Een onderneming laat software ontwikkelen, betaalt de facturen en gebruikt het systeem dagelijks. Toch betekent dat niet automatisch dat zij ook rechthebbende is op de broncode. Dat kan problemen opleveren wanneer de samenwerking met de ontwikkelaar eindigt, de software moet worden doorontwikkeld of de leverancier failliet gaat.
Wie is dan wél auteursrechthebbende? En hoe voorkomt u discussie over het gebruik, de aanpassing en de overdracht van uw maatwerksoftware? Let op de terminologie: eigendom en auteursrecht zijn juridisch niet hetzelfde. U kunt eigenaar zijn van de gegevensdrager en toch geen auteursrecht hebben op de code.
Inhoudsopgave
De hoofdregel: de maker heeft het auteursrecht
Volgens de hoofdregel van de Auteurswet komt het auteursrecht toe aan de maker van het werk. Voor software betekent dit in beginsel de programmeur of ontwikkelaar die de code heeft geschreven.
Computerprogramma's en het voorbereidend materiaal daarvoor, zoals ontwerpdocumenten, functionele specificaties en broncode in ontwikkeling, kunnen auteursrechtelijk beschermd zijn. Daarvoor moet wel sprake zijn van een eigen intellectuele schepping van de maker.
De partij die de softwareontwikkeling betaalt, verkrijgt dus niet automatisch het auteursrecht. Zonder aanvullende afspraken blijft de feitelijke maker rechthebbende.
Werknemers: het werkgeversauteursrecht
Voor werknemers geldt een belangrijke uitzondering. Wanneer een werknemer software ontwikkelt tijdens zijn dienstverband, kan de werkgever op grond van artikel 7 Aw als maker en dus als auteursrechthebbende worden aangemerkt.
Daarbij zijn met name de volgende omstandigheden van belang:
- er is sprake van een dienstbetrekking;
- softwareontwikkeling behoort tot de werkzaamheden van de werknemer;
- partijen hebben niet uitdrukkelijk anders afgesproken.
Een softwareontwikkelaar die in dienst is genomen om programmatuur te bouwen, valt eerder onder deze regeling dan een systeembeheerder die incidenteel een script schrijft. Het is daarom verstandig om in de arbeidsovereenkomst en de functieomschrijving duidelijk vast te leggen dat softwareontwikkeling tot de werkzaamheden behoort.
Freelancers en externe IT-leveranciers
Het werkgeversauteursrecht geldt niet automatisch voor freelancers, zzp'ers en externe IT-leveranciers. Zij werken doorgaans op basis van een overeenkomst van opdracht en niet op basis van een arbeidsovereenkomst. Het auteursrecht blijft dan in beginsel bij de externe ontwikkelaar of leverancier, tenzij het rechtsgeldig aan de opdrachtgever wordt overgedragen.
Dat kan problemen geven wanneer:
- de opdrachtgever een andere partij de software wil laten aanpassen;
- de leverancier geen broncode meer verstrekt;
- de software onderdeel wordt van een bedrijfsovername;
- de leverancier failliet gaat;
- de opdrachtgever de software aan derden wil licentiëren.
Betaling van de ontwikkelkosten is daarvoor op zichzelf onvoldoende. De overeenkomst moet duidelijk regelen welke rechten de opdrachtgever verkrijgt.
Overdracht of licentie?
Een opdrachtgever moet onderscheid maken tussen overdracht van auteursrecht en een licentie.
Een licentie kan volstaan wanneer de opdrachtgever de software alleen intern wil gebruiken. Wie de software wil kunnen aanpassen, doorontwikkelen, verkopen of aan derden ter beschikking wil stellen, doet er verstandig aan die rechten uitdrukkelijk te laten opnemen.
Nieuw sinds 1 januari 2026: schriftelijkheidsvereiste
Op 1 januari 2026 is de Wet versterking auteurscontractenrecht in werking getreden (Stb. 2025, 352). Daarmee is artikel 2 Aw gewijzigd. Voor zowel de overdracht van auteursrecht als de verlening van een exclusieve licentie geldt nu een schriftelijkheidsvereiste: de overeenkomst moet schriftelijk worden aangegaan. Een overdrachtsbeding dat alleen in algemene voorwaarden staat of dat mondeling is afgesproken, biedt dus geen zekerheid.
Over de precieze verhouding tussen dit schriftelijkheidsvereiste en het oude aktevereiste, en daarmee tot de levering op grond van artikel 3:95 BW, wordt in de literatuur verschillend gedacht. Praktisch is dat goed op te lossen: leg de overdracht vast in een afzonderlijke, door beide partijen ondertekende schriftelijke overeenkomst waarin staat welke rechten worden overgedragen en op welk moment, bijvoorbeeld bij oplevering of na volledige betaling. Daarmee voldoet u onder elke lezing.
Van belang is verder dat de wet onmiddellijke werking heeft: zij geldt vanaf 1 januari 2026 ook voor bestaande contracten, voor zover het gaat om handelingen ná die datum. Lopende ontwikkel- en onderhoudsovereenkomsten verdienen daarom een hertoetsing, zeker wanneer de software bedrijfskritisch is.
Niet-exclusieve licenties blijven vormvrij en kunnen dus nog steeds mondeling of stilzwijgend ontstaan. Dat is precies het risico voor opdrachtgevers: zonder schriftelijke regeling houdt u vaak niet meer over dan een impliciete, beperkte gebruikslicentie.
Denk ook aan onderhoud, updates en bugfixes
Een veelvoorkomend aandachtspunt is de juridische positie van onderhoud, updates en bugfixes. Leg daarom niet alleen de rechten op de oorspronkelijke software vast, maar ook op bugfixes, updates, nieuwe releases, documentatie, doorontwikkeling en aanvullende modules en koppelingen.
In het kort geding dat leidde tot het vonnis van de voorzieningenrechter van de Rechtbank Rotterdam van 31 mei 2024 (ECLI:NL:RBROT:2024:5183) kwam de vraag aan de orde of bugfixes zelfstandige auteursrechtelijke bescherming opleverden. Na een bedrijfsoverdracht, waarbij alle activa en de daaruit voortvloeiende intellectuele-eigendomsrechten waren overgegaan, weigerde de andere partij de broncode van nadien uitgevoerde bugfixes af te geven. De voorzieningenrechter oordeelde dat het toevoegen van deze bugfixes niet voldeed aan het oorspronkelijkheidsvereiste, omdat daarin geen creatieve keuzes van de maker tot uitdrukking kwamen, en gebood afgifte van de broncode.
Die uitkomst is niet zonder meer een algemene regel. Het ging om een voorlopig oordeel in kort geding en om de concrete kenmerken van die fixes. Een omvangrijke herbouw van een module of een substantiële uitbreiding kan wel degelijk een eigen intellectuele schepping vormen. De les is dus niet dat onderhoudswerk nooit beschermd is, maar dat u daar niet op moet vertrouwen: regel de rechten op onderhoud en doorontwikkeling contractueel.
Los daarvan geeft de wet de rechtmatige gebruiker van software enige ruimte. Artikel 45j Aw staat verveelvoudiging toe die noodzakelijk is voor het beoogde gebruik, waaronder het verbeteren van fouten, tenzij bij overeenkomst anders is bepaald. Omdat IT-contracten juist vaak iets anders bepalen, blijft de contractuele regeling doorslaggevend.
Broncode-escrow als continuïteitsmaatregel
Bij bedrijfskritische software kan broncode-escrow een aanvullende waarborg bieden. De broncode, documentatie en bijbehorende gegevens worden opgeslagen bij een onafhankelijke escrowagent en worden vrijgegeven wanneer een vooraf afgesproken gebeurtenis plaatsvindt, bijvoorbeeld:
- faillissement van de leverancier;
- langdurige beëindiging van de dienstverlening;
- het niet langer kunnen of willen onderhouden van de software;
- een andere contractueel vastgelegde release-trigger.
Escrow is geen vervanging van afspraken over auteursrecht, maar een aanvulling daarop. Een depot heeft alleen waarde als ook is geregeld hoe vaak de broncode wordt geactualiseerd, hoe de vrijgave wordt vastgesteld, en welke gebruiks- en bewerkingsrechten u ná vrijgave krijgt. Zonder dat laatste heeft u wel de code, maar niet het recht om er iets mee te doen.
Praktische checklist voor ondernemingen
- Wie is de maker van de software?
- Is de ontwikkelaar werknemer, freelancer of externe leverancier?
- Wordt het auteursrecht overgedragen of krijgt u alleen een licentie?
- Is die afspraak schriftelijk en voldoende specifiek vastgelegd?
- Op welk moment vindt de overdracht plaats?
- Omvat de regeling ook bugfixes, updates en doorontwikkeling?
- Mag een derde de software onderhouden of aanpassen?
- Wordt broncode-escrow overeengekomen?
- Zijn de release-triggers en de rechten na vrijgave duidelijk omschreven?
- Zijn open source-componenten en hun licentievoorwaarden afzonderlijk in kaart gebracht?
- Is aandacht besteed aan de persoonlijkheidsrechten van de maker (artikel 25 Aw)?
- Zijn de IE-bepalingen gecontroleerd bij een overname of fusie?
Onduidelijke afspraken kunnen ertoe leiden dat u de software wel mag gebruiken, maar deze niet zonder toestemming kunt aanpassen, overdragen of doorontwikkelen.
Conclusie
De partij die maatwerksoftware betaalt, is niet automatisch de auteursrechthebbende. Bij werknemers kan het werkgeversauteursrecht uitkomst bieden. Bij freelancers en externe IT-leveranciers moeten de gewenste rechten daarentegen uitdrukkelijk en schriftelijk worden geregeld, en sinds 1 januari 2026 stelt de wet daaraan strengere eisen.
Law & More beoordeelt uw ontwikkel-, onderhouds- en escrowovereenkomsten, stelt IE-clausules op die ook onderhoud en doorontwikkeling dekken, en toetst bestaande contracten aan het nieuwe auteurscontractenrecht. Staat er een overname op stapel of is uw software bedrijfskritisch, laat de IE-positie dan tijdig controleren. Leg uw situatie aan ons voor. Wij laten u binnen één werkdag weten wat uw opties zijn.
Veelgestelde vragen
Hieronder beantwoorden wij de vragen die ons over dit onderwerp het vaakst worden gesteld.
Ben ik eigenaar van de software waarvoor ik heb betaald?
Niet automatisch. Het auteursrecht komt in beginsel toe aan de maker van de code, niet aan de partij die de ontwikkeling betaalt. Let ook op de terminologie: eigendom en auteursrecht zijn juridisch niet hetzelfde.
Wie is auteursrechthebbende als mijn eigen werknemer de software schrijft?
Dan kan de werkgever op grond van artikel 7 Aw als maker worden aangemerkt. Daarvoor is van belang dat sprake is van een dienstbetrekking, dat softwareontwikkeling tot de werkzaamheden behoort en dat partijen niet uitdrukkelijk anders zijn overeengekomen. Leg dat daarom vast in de arbeidsovereenkomst en de functieomschrijving.
Geldt dat ook voor zzp'ers en externe IT-leveranciers?
Nee. Zij werken doorgaans op basis van een overeenkomst van opdracht, zodat het werkgeversauteursrecht niet geldt. Het auteursrecht blijft dan bij de externe ontwikkelaar, tenzij het rechtsgeldig aan u is overgedragen.
Wat is het verschil tussen overdracht en een licentie?
Bij overdracht gaat het auteursrecht zelf over naar u. Bij een licentie blijft de maker rechthebbende en krijgt u alleen de afgesproken gebruiksrechten. Wilt u de software kunnen aanpassen, doorontwikkelen of doorleveren, dan moeten die bevoegdheden uitdrukkelijk worden geregeld.
Wat is er per 1 januari 2026 veranderd?
Op die datum is de Wet versterking auteurscontractenrecht in werking getreden, waarmee artikel 2 Aw is gewijzigd. Voor zowel overdracht als een exclusieve licentie geldt nu een schriftelijkheidsvereiste. De wet werkt bovendien onmiddellijk, dus ook op bestaande contracten voor zover het handelingen na die datum betreft.
Kan een overdracht in mijn algemene voorwaarden worden geregeld?
Dat is onvoldoende zeker. Leg de overdracht vast in een afzonderlijke, door beide partijen ondertekende schriftelijke overeenkomst waarin staat welke rechten overgaan en op welk moment, bijvoorbeeld bij oplevering of na volledige betaling.
Kan een licentie mondeling ontstaan?
Een niet-exclusieve licentie is vormvrij en kan mondeling of zelfs stilzwijgend ontstaan. Een exclusieve licentie moet sinds 1 januari 2026 schriftelijk worden verleend. Voor opdrachtgevers is de vormvrije variant juist het risico: zonder schriftelijke regeling houdt u vaak niet meer over dan een beperkt gebruiksrecht.
Ontstaat er nieuw auteursrecht op bugfixes?
Vaak niet, maar het hangt af van de omstandigheden. In een kort geding van de Rechtbank Rotterdam van 31 mei 2024 (ECLI:NL:RBROT:2024:5183) oordeelde de voorzieningenrechter dat de betrokken bugfixes niet aan het oorspronkelijkheidsvereiste voldeden, omdat daarin geen creatieve keuzes tot uitdrukking kwamen. Een omvangrijke herbouw of substantiële uitbreiding kan wél een eigen intellectuele schepping zijn, dus vertrouw hier niet op en regel het contractueel.
Mag ik zelf fouten in de software herstellen?
Artikel 45j Aw staat de rechtmatige gebruiker toe de software te verveelvoudigen voor zover dat noodzakelijk is voor het beoogde gebruik, waaronder verbetering van fouten, tenzij bij overeenkomst anders is bepaald. Omdat IT-contracten vaak juist anders bepalen, is de contractuele regeling in de praktijk doorslaggevend.
Wat is broncode-escrow en wanneer is het zinvol?
De broncode, documentatie en bijbehorende gegevens worden gedeponeerd bij een onafhankelijke escrowagent en vrijgegeven bij een vooraf afgesproken gebeurtenis, zoals faillissement van de leverancier. Het is vooral relevant bij bedrijfskritische software. Regel daarbij ook de actualisering van het depot en de gebruiks- en bewerkingsrechten na vrijgave.
Waar moet ik op letten bij een overname?
Controleer of het auteursrecht op de software daadwerkelijk is overgedragen en of die overdracht aan de vormvereisten voldoet, en of ook onderhoud, updates en doorontwikkeling onder de regeling vallen. Breng daarnaast open source-componenten en hun licentievoorwaarden in kaart, en besteed aandacht aan de persoonlijkheidsrechten van artikel 25 Aw.
Heeft u een geschil met een IT-leverancier of wilt u een IT-contract laten toetsen? Onze advocaten IT-recht denken graag met u mee.
