Gepubliceerd op 23 september 2026 · Laatst bijgewerkt op 13 oktober 2026
Een onderneming die software laat bouwen, wordt niet automatisch auteursrechthebbende op de broncode. Dat recht komt in beginsel toe aan de ontwikkelaar die de code heeft geschreven, niet aan de partij die de facturen betaalt; alleen als die ontwikkelaar uw eigen werknemer is, bent u als werkgever in beginsel zelf rechthebbende (artikel 7 Auteurswet).
Dat kan tot problemen leiden wanneer de samenwerking met de ontwikkelaar stopt, u de software wilt laten doorontwikkelen of de leverancier failliet gaat. Wie dan wél rechthebbende is en hoe u dat vooraf regelt, leest u hieronder. 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
Wie heeft het auteursrecht op software?
Volgens de hoofdregel van de Auteurswet komt het auteursrecht toe aan de maker van het werk. Voor software is dat in beginsel de programmeur die de code heeft geschreven, niet de opdrachtgever die daarvoor betaalt.
Computerprogramma's en het voorbereidend materiaal, zoals ontwerpdocumenten, functionele specificaties en broncode in ontwikkeling, kunnen auteursrechtelijk beschermd zijn. Daarvoor moet sprake zijn van een eigen intellectuele schepping van de maker. Zonder aanvullende afspraken blijft de feitelijke maker dus rechthebbende, ook als u de ontwikkeling volledig heeft gefinancierd.
Geldt dat ook voor uw eigen werknemer?
Niet altijd. Ontwikkelt uw werknemer software tijdens het dienstverband, dan kunt u als werkgever op grond van artikel 7 Auteurswet als maker en dus als auteursrechthebbende gelden.
Daarvoor moet aan drie voorwaarden zijn voldaan: er is een dienstbetrekking, softwareontwikkeling behoort tot de werkzaamheden van de werknemer, en partijen hebben niet uitdrukkelijk iets anders afgesproken. Een ontwikkelaar die is aangenomen om programmatuur te bouwen, valt eerder onder deze regeling dan een systeembeheerder die incidenteel een script schrijft. Leg daarom in de arbeidsovereenkomst en de functieomschrijving vast dat softwareontwikkeling tot de taken behoort. Anders dan bij freelancers en externe leveranciers hoeft u dit niet apart schriftelijk te laten overdragen: het werkgeversauteursrecht ontstaat in dat geval van rechtswege, zodra aan de drie voorwaarden is voldaan.
En bij freelancers of een externe IT-leverancier?
Dan geldt het werkgeversauteursrecht niet. Freelancers, zzp'ers en externe IT-leveranciers werken doorgaans op basis van een overeenkomst van opdracht, niet van een arbeidsovereenkomst.
Het auteursrecht blijft dan in beginsel bij de ontwikkelaar of leverancier zelf, tenzij dat rechtsgeldig aan u is overgedragen. Alleen betaling van de ontwikkelkosten is daarvoor onvoldoende. Dat kan problemen geven wanneer:
- u een andere partij de software wilt laten aanpassen;
- de leverancier geen broncode meer verstrekt;
- de software onderdeel wordt van een bedrijfsovername;
- de leverancier failliet gaat;
- u de software aan derden wilt licentiëren.
De overeenkomst moet daarom duidelijk regelen welke rechten u als opdrachtgever verkrijgt.
Een voorbeeld ter illustratie: een onderneming laat door een externe IT-leverancier een bestelsysteem bouwen en betaalt de volledige ontwikkelkosten. Wil zij later zelf verder bouwen aan het systeem of een andere partij het laten onderhouden, dan blijkt zonder schriftelijke overdracht dat het auteursrecht bij de leverancier ligt. De onderneming mag het systeem dan wel gebruiken, maar niet zonder toestemming laten aanpassen door een derde.
Overdracht of licentie: wat is het verschil?
Bij overdracht gaat het auteursrecht zelf over naar u. Bij een licentie blijft de maker rechthebbende en krijgt u alleen gebruiksrechten.
Wilt u de software alleen intern gebruiken, dan kan een licentie volstaan. Wilt u haar kunnen aanpassen, doorontwikkelen, verkopen of aan derden ter beschikking stellen, laat die rechten dan uitdrukkelijk vastleggen.
Wat is er per 1 januari 2026 veranderd?
Sinds 1 januari 2026 geldt de Wet versterking auteurscontractenrecht (Stb. 2025, 352), die artikel 2 van de Auteurswet wijzigt. Voor zowel de overdracht van auteursrecht als het verlenen van een exclusieve licentie geldt nu een schriftelijkheidsvereiste.
Een overdrachtsbeding dat alleen in algemene voorwaarden staat of mondeling is afgesproken, biedt dus geen zekerheid meer. Over de precieze verhouding tussen dit schriftelijkheidsvereiste en het aktevereiste van artikel 3:95 BW voor de daadwerkelijke levering, wordt in de literatuur verschillend gedacht. Praktisch lost u dat op door de overdracht vast te leggen in een aparte, door beide partijen ondertekende schriftelijke overeenkomst waarin staat welke rechten overgaan en op welk moment, bijvoorbeeld bij oplevering of na volledige betaling.
De wet werkt bovendien onmiddellijk: zij geldt sinds 1 januari 2026 ook voor bestaande contracten, voor zover het gaat om handelingen na die datum. Heeft u lopende ontwikkel- of onderhoudsovereenkomsten, laat die dan opnieuw toetsen, zeker als de software bedrijfskritisch is. Niet-exclusieve licenties blijven overigens vormvrij: die kunnen nog steeds mondeling of stilzwijgend ontstaan. Zonder schriftelijke regeling houdt u dan vaak niet meer over dan een impliciete, beperkte gebruikslicentie.
Wie heeft het auteursrecht op onderhoud, updates en bugfixes?
Vaak ontstaat op een bugfix geen nieuw, zelfstandig auteursrecht. Regel daarom niet alleen de rechten op de oorspronkelijke software, maar ook op updates, nieuwe releases, documentatie en doorontwikkeling.
De voorzieningenrechter van de Rechtbank Rotterdam oordeelde daarover op 31 mei 2024 in kort geding (ECLI:NL:RBROT:2024:5183). Na een bedrijfsoverdracht, waarbij alle activa en de daaruit voortvloeiende intellectuele-eigendomsrechten waren overgegaan, weigerde de partij die nadien bugfixes had uitgevoerd de broncode daarvan af te geven. De voorzieningenrechter oordeelde dat deze bugfixes niet voldeden aan het oorspronkelijkheidsvereiste, omdat daarin geen persoonlijk stempel van de maker tot uitdrukking kwam, en gebood afgifte van de broncode.
Dit was een voorlopig oordeel in kort geding over de concrete kenmerken van die fixes. Een omvangrijke herbouw van een module of een substantiële uitbreiding kan wél een eigen intellectuele schepping vormen. Vertrouw daar echter niet op: regel de rechten op onderhoud en doorontwikkeling contractueel. Artikel 45j Auteurswet geeft de rechtmatige gebruiker overigens al enige ruimte om fouten te herstellen, tenzij bij overeenkomst anders is bepaald. Omdat IT-contracten dat vaak juist wel bepalen, blijft de contractuele regeling in de praktijk doorslaggevend.
Is broncode-escrow zinvol?
Bij bedrijfskritische software kan broncode-escrow een aanvullende waarborg bieden. Uw broncode, documentatie en bijbehorende gegevens worden dan opgeslagen bij een onafhankelijke escrowagent.
De escrowagent geeft de broncode vrij zodra een vooraf afgesproken gebeurtenis zich voordoet, 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 vervangt geen afspraken over auteursrecht, maar vult ze aan. Regel daarbij ook 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. Bespreek dit vooraf met uw escrowagent en neem de afspraken op in de escrowovereenkomst, zodat bij vrijgave geen discussie ontstaat over wat u er wel en niet mee mag.
Waar let u als opdrachtgever op?
- 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?
- Spreekt u broncode-escrow af?
- Zijn de release-triggers en de rechten na vrijgave duidelijk omschreven?
- Zijn open source-componenten en hun licentievoorwaarden apart in kaart gebracht?
- Is er aandacht voor de persoonlijkheidsrechten van de maker (artikel 25 Auteurswet)?
- Zijn de IE-bepalingen gecontroleerd bij een overname of fusie?
Zonder duidelijke afspraken mag u de software vaak wel gebruiken, maar niet zonder toestemming aanpassen, overdragen of doorontwikkelen.
Waar let u als softwareleverancier op?
- Leg vast welke rechten u overdraagt en welke u behoudt, bijvoorbeeld op generieke bibliotheken en eigen tools die u bij meer klanten gebruikt.
- Koppel de overdracht aan volledige betaling, zodat de rechten pas overgaan als de factuur is voldaan.
- Controleer of de licentievoorwaarden van de open source-componenten die u gebruikt de afgesproken overdracht toelaten.
- Leg schriftelijk vast welke rechten uw eigen freelancers aan u hebben overgedragen: u kunt niet meer overdragen dan u zelf heeft.
Wat kunnen wij voor u doen bij auteursrecht op maatwerksoftware?
Onze advocaten IT-recht helpen opdrachtgevers en leveranciers met de volgende stappen:
- Wij stellen de ontwikkelovereenkomst op of toetsen haar, met een schriftelijke overdracht of licentie die aansluit op artikel 2 Auteurswet.
- Wij controleren bestaande ontwikkel- en onderhoudscontracten op de rechten op updates, bugfixes en doorontwikkeling.
- Wij leggen in arbeidsovereenkomsten en functieomschrijvingen vast dat softwareontwikkeling tot de taken behoort (artikel 7 Auteurswet).
- Wij stellen een escrowregeling op met heldere release-triggers en gebruiksrechten na vrijgave.
- Wij vorderen in kort geding afgifte van de broncode als een leverancier die ten onrechte achterhoudt.
Samengevat
- Wie de software betaalt, is niet automatisch auteursrechthebbende: dat is in beginsel de maker.
- Bij werknemers kan het werkgeversauteursrecht van artikel 7 Auteurswet uitkomst bieden, bij freelancers en externe leveranciers niet.
- Regel overdracht en licentie schriftelijk; sinds 1 januari 2026 stelt de wet daaraan strengere eisen.
- Leg ook de rechten op onderhoud, updates en doorontwikkeling vast: op een bugfix alleen ontstaat vaak geen nieuw auteursrecht.
- Overweeg broncode-escrow bij bedrijfskritische software, met heldere afspraken over vrijgave en gebruiksrechten daarna.
Veelgestelde vragen
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. Eigendom en auteursrecht zijn juridisch niet hetzelfde.
Wie is auteursrechthebbende als mijn eigen werknemer de software schrijft?
Dan kunt u als werkgever op grond van artikel 7 Auteurswet als maker gelden, mits sprake is van een dienstbetrekking, softwareontwikkeling tot de werkzaamheden behoort en u niets anders bent overeengekomen. Leg dat 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 dat 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, laat die bevoegdheden dan uitdrukkelijk vastleggen.
Kan een overdracht in mijn algemene voorwaarden worden geregeld?
Dat is onvoldoende zeker. Leg de overdracht vast in een aparte, 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. Zonder schriftelijke regeling houdt u bij een niet-exclusieve licentie vaak niet meer over dan een beperkt gebruiksrecht.
Ontstaat er nieuw auteursrecht op bugfixes?
Vaak niet. De voorzieningenrechter van de Rechtbank Rotterdam oordeelde op 31 mei 2024 in kort geding (ECLI:NL:RBROT:2024:5183) dat de bugfixes in die zaak niet aan het oorspronkelijkheidsvereiste voldeden, omdat daarin geen persoonlijk stempel van de maker tot uitdrukking kwam. Een omvangrijke herbouw of substantiële uitbreiding kan dat wel zijn: vertrouw daar niet op en regel het contractueel.
Mag ik zelf fouten in de software herstellen?
Artikel 45j Auteurswet staat de rechtmatige gebruiker toe de software te verveelvoudigen voor zover dat nodig is voor het beoogde gebruik, waaronder het herstellen van fouten, tenzij bij overeenkomst anders is bepaald. Omdat IT-contracten dat vaak wel doen, is de contractuele regeling in de praktijk doorslaggevend.
Wat is broncode-escrow en wanneer is het zinvol?
Uw broncode, documentatie en bijbehorende gegevens worden dan gedeponeerd bij een onafhankelijke escrowagent, die deze vrijgeeft bij een vooraf afgesproken gebeurtenis, zoals faillissement van de leverancier. Dat is vooral relevant bij bedrijfskritische software. Regel daarbij ook de actualisering van het depot en de rechten 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 let op de persoonlijkheidsrechten van artikel 25 Auteurswet.
