Overzichtsblog: auteursrecht op software

Je bedrijf heeft maanden aan een softwareproject gewerkt. Duizenden regels code staan er strak in, de functionaliteiten, API's en UI kloppen allemaal en de oplevering is een groot succes. Maar dan ontstaat er discussie: zijn de auteursrechten op de software van de ontwikkelaar, van jouw bedrijf, of van de opdrachtgever die de rekeningen heeft betaald?

Dit soort vraagstukken zijn regelmatig onderwerp van conflict, en de antwoorden zijn niet altijd wat partijen hadden gehoopt of verwacht. Partijen gaan er immers vaak onterecht vanuit dat het wel goed zit. In dit blog zetten wij daarom uiteen wanneer software auteursrechtelijk beschermd is, wie de rechthebbende is en wat je contractueel kunt regelen om verrassingen te voorkomen.

Wanneer is software überhaupt auteursrechtelijk beschermd?

Voordat je kunt spreken over wie de rechten heeft, is het belangrijk te weten óf er überhaupt auteursrechtelijke bescherming is. Het goede nieuws: auteursrecht ontstaat automatisch, zonder registratie of andere formaliteiten. In de praktijk wordt dan ook vaak gesproken over een scheppingsdaad, waarna het auteursrecht wordt geboren.

Het auteursrecht is enkel van toepassing op iets wat wordt aangeduid als een 'werk'. Ten tijde van de Auteurswet 1817, de allereerste nationale wettelijke regeling voor het auteursrecht in het Koninkrijk der Nederlanden, werd met dit begrip hoofdzakelijk gedoeld op letterwerken, kunstwerken en het aanverwante 'regt van kopij'. Met de komst van de Auteurswet 1912, die sindsdien meerdere malen is aangepast aan de moderne tijd, werd de reikwijdte van het werkbegrip geleidelijk verbreed. Het was uiteindelijk de Europese Softwarerichtlijn van 1991 die software expliciet onder de bescherming van het auteursrecht bracht, en die bescherming sindsdien heeft geharmoniseerd binnen de EU. Wél moet de software aan drie eisen voldoen:

• Eigen oorspronkelijk karakter: de software mag niet ontleend zijn aan het werk van iemand anders. Volstrekte nieuwheid is niet vereist en toevallige gelijkenissen mogen, maar bewuste ontlening niet.
• Persoonlijk stempel van de maker: de software moet het resultaat zijn van scheppende menselijke arbeid, waarbij creatieve keuzes worden gemaakt. Banale of puur technische bepaalde werken vallen dus buiten de bescherming.
• Vatbaar voor zintuigelijke waarneming: de software moet op de een of andere manier waarneembaar zijn. Aan dit vereiste wordt bij software vrijwel altijd voldaan.

In de praktijk ligt de creativiteitsdrempel voor software opvallend laag, en dat is gunstig nieuws. Hoewel software van nature technisch en functioneel is, blijkt uit vaste rechtspraak van het Hof van Justitie van de EU dat snel sprake is van bescherming, zolang de ontwikkelaar bij het schrijven van de code enige creatieve vrijheid heeft gehad en daar persoonlijke keuzes heeft gemaakt. Denk aan de structurering van de code, de gekozen architectuur of de manier waarop een probleem is opgelost. Puur mechanisch of dwingend technisch bepaalde code, waarbij de programmeur feitelijk geen keuze had, valt buiten de bescherming. Maar in de meeste gevallen geldt: als er een mens achter de code zit die keuzes heeft gemaakt, is de drempel voor bescherming al snel gehaald.

Wat valt er níet onder de bescherming?

Het auteursrecht beschermt de concrete uitwerking, niet het idee erachter. Een idee voor een handige app of een slim algoritme is op zichzelf niet beschermd; pas de daadwerkelijke code die dat idee uitwerkt geniet bescherming. Bovendien valt niet elk aspect van een stuk software binnen de bescherming. Denk bijvoorbeeld aan:

• De programmeertaal waarin de software is geschreven
• De functionaliteit van de software als zodanig
• Bestandsformaten die bij de software horen
• Functioneel bepaalde UI-elementen: onderdelen van de gebruikersinterface die louter worden bepaald door technische of functionele eisen.

Wél beschermd zijn de broncode en de objectcode als zodanig, voor zover ze voldoen aan de eerder benoemde eisen.

De hoofdregel: de maker is rechthebbende

Als de software auteursrechtelijk beschermd is, rijst de vraag: wie heeft de rechten? De hoofdregel is simpel: het auteursrecht komt toe aan de maker, oftewel degene die de creatieve keuzes heeft gemaakt en daarmee zijn persoonlijk stempel op het werk heeft gedrukt.

In de praktijk is software zelden het werk van één persoon; software-ontwikkelaars werken vaak in teams, waardoor er regelmatig sprake is van meerdere makers. De wet maakt dan onderscheid tussen twee situaties:

• Samengesteld werk: het werk bestaat uit meerdere afzonderlijke, te onderscheiden bijdragen. Iedere maker heeft het auteursrecht op zijn eigen bijdrage, en kan dat ook zelfstandig handhaven.
• Gemeenschappelijk auteursrecht: de bijdragen zijn zo met elkaar verweven dat ze niet meer te onderscheiden zijn. In dat geval hebben alle makers het auteursrecht gezamenlijk. Ze moeten elk afzonderlijk toestemming geven voor exploitatie en maken elk aanspraak op een evenredig deel van de daarmee gemoeide vergoeding.

Het recht zou het recht niet zijn als er geen uitzonderingen bestonden op de hoofdregel. Gelukkig zijn die er volop! En zijn deze te herleiden naar grofweg drie situaties.

Uitzondering 1: werkgeversauteursrecht

De meest voorkomende uitzondering is het werkgeversauteursrecht (artikel 7 Auteurswet). Het werkgeversauteursrecht bepaalt dat wanneer een werknemer in het kader van zijn dienstverband software maakt, de werkgever als maker wordt aangemerkt en dus het auteursrecht verkrijgt.

Om hiervan te kunnen spreken moet er worden voldaan aan twee vereisten:

1. Er is sprake van een arbeidsovereenkomst (dit impliceert dus ook een gezagsverhouding, loon, duurzame relatie en productiviteit).
2. Het maken van de software valt binnen de taakomschrijving van de werknemer.

Ondanks het kader vrij helder geschetst kan worden om te herleiden wie auteursrechthebbende is, komen we in de praktijk vaak grensgevallen tegen die de nodige discussie met zich meebrengen:

• Software buiten werktijd geschreven: ook dan kan het werkgeversauteursrecht gelden, als het schrijven ervan binnen de taakomschrijving van de werknemer valt.
• Stagiairs: vallen in beginsel buiten het werkgeversauteursrecht, omdat een stage primair gericht is op het opdoen van kennis en ervaring, niet op het verrichten van arbeid.
• Freelancers en ZZP’ers: het uitgangspunt is dat freelancers of ZZP’ers buiten de reikwijdte van werkgeversauteursrecht vallen, maar wat indien een externe programmeur al ellenlang werkzaamheden verricht voor een bedrijf? Of er sprake is van een arbeidsovereenkomst hangt namelijk niet alleen af van wat er op papier staat, maar ook hoe de samenwerking in de praktijk eruitziet, zo bevestigde ook de Hoge Raad in het Deliveroo-arrest (HR 24 maart 2023, ECLI:NL:HR:2023:443).
• Brede taakomschrijving: hoe gedetailleerder de taakomschrijving, hoe makkelijker het is om vast te stellen of de software eronder valt. Maar let op: een expliciete opdracht van de werkgever kan bij twijfel alsnog leiden tot werkgeversauteursrecht.

Actuele ontwikkeling: het ONB-arrest (HvJ EU, 6 maart 2025, ECLI:EU:2025:141)

Interessant om te benoemen. Recent heeft het Hof van Justitie van de Europese Unie een opvallende uitspraak gedaan. Het Hof zette daarmee vraagtekens bij wettelijke regelingen die zonder toestemming auteursrecht overdragen. In de ONB-zaak (een geschil tussen het Orchestre National de Belgique en haar muzikanten) oordeelde het Hof dat een Belgisch Koninklijk Besluit waarbij naburige rechten van muzikanten verplicht werden overgedragen, niet door de beugel kon.

Afijn, hoewel de zaak betrekking had op naburige rechten, stellen Nederlandse juristen zich inmiddels de vraag of het werkgeversauteursrecht in het licht hiervan nog houdbaar is. Voorlopig lijkt het Nederlandse systeem stand te houden, dankzij de tenzij-clausule in artikel 7: partijen kunnen contractueel afwijken van de hoofdregel, waardoor er geen sprake is van een volstrekt verplichte overdracht zoals in België. Desalniettemin is dit natuurlijk enorm interessant en verdienen de ontwikkelingen zeker nog de nodige opvolging.

Wil je hier meer over weten? Lees dan dit blog.

Uitzondering 2: fictief makerschap

Een minder bekende uitzondering is het fictief makerschap: niet de persoon die de code schrijft, maar de persoon die toezicht houdt en leiding geeft, wordt als maker aangemerkt, mits die persoon ook daadwerkelijk de creatieve keuzes maakt.

Bij software is dit een bijzonder hoge lat. De toezichthouder of leidinggevende moet inhoudelijke, creatieve beslissingen nemen, terwijl de programmeur slechts uitvoerend werk verricht. Dit komt in de praktijk zelden voor. Een uitzondering is denkbaar bij een zeer gedetailleerd ontwerp, waarbij de programmeur eigenlijk alleen maar technisch vertaalt wat al volledig is uitgedacht door een ander.

Uitzondering 3: opdrachtsituatie

Een veelvoorkomend misverstand: de opdrachtgever die een softwarebedrijf of freelanceontwikkelaar inhuurt, gaat er nogal eens vanuit dat hij of zij de auteursrechthebbende is van het geleverde werk. Er is toch immers voor betaald?

Ook hier geldt de hoofdregel: wie het maakt, heeft de rechten. De softwareontwikkelaar- of leverancier blijft de auteursrechten bij zich houden, ook al is de factuur nog zo hoog. Onthoud dus: wie betaalt, bepaalt niet. Betaling is auteursrechtelijk gezien compleet irrelevant.

Wat krijgt de opdrachtgever dan wél? In beginsel een licentie (ook wel een gebruiksrecht genoemd) op de software. De exacte reikwijdte van dat gebruiksrecht hangt af van:

• Wat er tijdens het offertetraject is besproken en afgesproken
• Het doel van de opdracht
• Wat er in de ontwikkelovereenkomst en/of de algemene voorwaarden staat

Wil de opdrachtgever meer dan alleen een gebruiksrecht? Dan moet de overdracht van auteursrecht expliciet in het contract worden vastgelegd. Zonder zo'n bepaling blijven de rechten bij de softwareontwikkelaar- of leverancier, en dat is vaak ook precies de bedoeling.

Want ook vanuit de ontwikkelaar bezien, is het gebruiksrecht geen toevallige constructie. Softwareontwikkelaars werken doorgaans met herbruikbare bouwstenen: bibliotheken, standaardmodules en architectuurpatronen die zij bij uiteenlopende projecten inzetten. Deze componenten vormen in veel gevallen de kern van hun vakmanschap en bedrijfsvoering. Wanneer een ontwikkelaar het volledige auteursrecht op zijn software overdraagt, dreigt hij zichzelf te beperken in het gebruik van zijn eigen coderingen, ook al heeft hij die zelf van de grond af opgebouwd. Het gebruiksrecht biedt uitkomst: de opdrachtgever krijgt wat hij nodig heeft om de software te exploiteren, terwijl de ontwikkelaar zijn bouwstenen vrij kan blijven inzetten voor andere projecten.

De reikwijdte van het gebruiksrecht heeft ook praktische gevolgen: het is vaak niet toegestaan om zomaar een derde in te schakelen voor onderhoud of doorontwikkeling. Daarvoor is toestemming nodig van de oorspronkelijke ontwikkelaar, en die toestemming is echt niet vanzelfsprekend.

Dit neemt overigens niet weg dat er vaak wél ruimte is voor gedeeltelijke overdracht. Elementen die specifiek en uitsluitend voor de opdrachtgever zijn ontwikkeld, denk aan een op maat gemaakte module of een klantspecifiek ontwerp, lenen zich er juist wel voor om apart te worden overgedragen. Op die manier behoudt de ontwikkelaar de rechten op zijn generieke bouwstenen, terwijl de opdrachtgever volledige rechthebbende wordt van wat specifiek voor hem is gemaakt. Dit vereist wel dat die splitsing uitdrukkelijk in het contract wordt vastgelegd en goed scheidbaar is van de rest van de code.

Tot slot nog een bijzondere situatie: wanneer een rechtspersoon software voor het eerst openbaar maakt, bijvoorbeeld via een post op GitHub of de livegang van een app, zonder dat daarbij een natuurlijk persoon als maker wordt vermeld, wordt de rechtspersoon zelf als maker aangemerkt. Wil de daadwerkelijke ontwikkelaar alsnog aanspraak maken op de auteursrechten, dan zal hij moeten bewijzen dat de openbaarmaking onder die omstandigheden onrechtmatig was.

Praktische aanbevelingen: regel het contractueel

De wet regelt veel, maar lang niet alles. Een goede contractuele structurering is daarom onmisbaar. Per doelgroep het volgende advies:

Werkgevers: leg in de arbeidsovereenkomst expliciet vast dat alle intellectuele eigendomsrechten op werken die in het kader van het dienstverband worden gemaakt, toekomen aan de werkgever. Twijfel je of iets onder de taakomschrijving valt? Regel dan een overdracht achteraf via een aparte overeenkomst.

Opdrachtgevers: zorg dat in het contract staat dat de auteursrechten aan jou worden overgedragen. Is volledige overdracht niet haalbaar, regel dan op zijn minst het recht om onderhoud en doorontwikkeling door een derde naar keuze te laten uitvoeren. Controleer ook altijd de algemene voorwaarden van de leverancier, daarin staan vaak afwijkende bepalingen over eigendom.

Werknemers en ontwikkelaars: heb je software geschreven buiten werktijd en wil je die voor jezelf houden? Leg dat dan contractueel vast, bij voorkeur voordat je in dienst treedt. Na indiensttreding is het lastiger om hier alsnog afspraken over te maken.

Voor iedereen: overdracht van auteursrecht is alleen geldig als dit schriftelijk is vastgelegd in een akte, dat wil zeggen: een ondertekend document waarin de overdracht expliciet en ondubbelzinnig is opgenomen. Een mondelinge afspraak of een e-mail volstaat niet. Hetzelfde geldt voor een exclusieve licentie: ook die moet schriftelijk in een akte worden vastgelegd om rechtsgeldig te zijn. Wil je de rechten niet volledig overdragen en geen exclusiviteit afspreken? Dan is een niet-exclusieve licentie een goed alternatief: hiervoor is geen akte vereist. De maker behoudt het auteursrecht, maar verleent de andere partij het recht om de software te gebruiken, aan te passen of door te ontwikkelen, op de voorwaarden die jullie samen overeenkomen. Al is het ook verstandig om de afspraken hieromtrent schriftelijk vast te leggen, al was het maar om discussie achteraf te voorkomen.

Conclusie

Wie de auteursrechten op software heeft, hangt sterk af van de situatie: loondienst, opdracht of toezicht. De wet geeft antwoord, maar dat antwoord valt partijen in de praktijk regelmatig tegen. Een goede contractuele structurering is daarom van groot belang. Regel het zo vroeg en zo concreet mogelijk.

Heb je nog vragen over je eigen IE-strategie, je arbeids- of inkoopcontracten, of een lopend geschil over software-eigendom? Wij adviseren ondernemers over intellectueel eigendom en de juridische kant van digitale infrastructuur. Met IP Proof helpen wij organisaties om hun digitale IE-portefeuille in kaart te brengen en te bepalen waar bijsturing nodig is.