Intellectueel eigendom in de arbeidsovereenkomst

Nederlandse MKB-bedrijven omarmen AI in hoog tempo. Medewerkers gebruiken het om code te schrijven, content te genereren, processen te automatiseren en producten te bouwen. Dat levert waarde op, maar het creëert ook intellectueel eigendom. En daar wringt de schoen. De meeste arbeidsovereenkomsten in het MKB bevatten namelijk geen IE-beding. Er is niets geregeld over wie eigenaar is van wat een medewerker maakt: met AI, buiten werktijd, in een rol die niet in de functiebeschrijving stond, of op basis van kennis die hij bij jou heeft opgedaan. De wet biedt een basis, maar die heeft te veel scheuren om op te bouwen als jouw bedrijfswaarde schuilt in software, data en algoritmen (en dat komt tegenwoordig vaker voor dan we denken!).

In dit artikel leggen we uit wat de wet al regelt, waar de echte risico’s liggen en hoe een goed IE-beding die risico’s sluit. We benaderen dit artikel vanuit de ‘bril’ van een platformontwikkelaar.

1. Wat regelt de wet al?

De wet biedt werkgevers al een belangrijke basisbescherming.

Als een werknemer in dienstverband software, documentatie, ontwerpen of andere werken maakt als onderdeel van zijn functie of in opdracht van de werkgever, komen de rechten daarop vaak bij de werkgever terecht. Denk aan een developer die tijdens zijn werk broncode schrijft voor het platform, een product owner die functionele specificaties uitwerkt of een UX-designer die schermontwerpen maakt.

Voor software gelden bovendien bijzondere regels. In gewone taal komt het erop neer dat de werkgever in veel gevallen de economische rechten kan uitoefenen op software die een werknemer maakt bij de uitvoering van zijn werkzaamheden of instructies.

Ook voor uitvindingen bestaat een wettelijke regeling. Als een werknemer een technische uitvinding doet die past binnen zijn functie of opdracht, kan de werkgever aanspraak hebben op de octrooirechten. Daarbij kan in sommige gevallen wel een billijke vergoeding voor de werknemer aan de orde zijn. Dit klinkt stevig, maar de praktijk is vaak minder netjes dan de wet veronderstelt. Zeker bij MKB-platformbedrijven lopen functies, werktijden en projecten snel door elkaar.

2. Waarom heb je dan toch een IE-beding nodig?

Een IE-beding is nodig omdat de wet vooral goed werkt in duidelijke situaties. Bijvoorbeeld: een backend developer schrijft tijdens werktijd code voor jouw SaaS-platform, precies volgens zijn functieomschrijving.

Maar veel discussies ontstaan juist in de grijze gebieden. Denk aan situaties zoals:

• een werknemer bouwt ’s avonds een module die later in het platform wordt gebruikt;
• een developer gebruikt oude eigen code of een persoonlijke GitHub-library;
• een werknemer werkt mee aan open-sourcecomponenten;
• een medewerker ontwikkelt een side project dat lijkt op jouw platform;
• een werknemer vertrekt en bouwt kort daarna iets vergelijkbaars.

In zulke situaties wil je niet pas achteraf discussiëren over eigendom, gebruiksrechten, geheimhouding of bewijs. Je wilt vooraf duidelijke afspraken.

Een goed IE-beding doet daarom drie dingen:

1. het legt vast welke rechten bij het bedrijf horen;
2. het verplicht de werknemer om mee te werken aan overdracht, registratie of bevestiging;
3. het maakt duidelijk wat de werknemer juist buiten de overdracht mag houden.

3. Wat moet je in ieder geval regelen?

A. Een brede maar redelijke overdracht van rechten

Het IE-beding moet bepalen dat rechten op werkresultaten die de werknemer maakt in verband met zijn werkzaamheden voor het bedrijf aan de werkgever toekomen of worden overgedragen.

Denk niet alleen aan broncode. Neem ook mee:

• software en scripts;
• API’s, plug-ins en technische koppelingen;
• databases en datastructuren;
• datamodellen en technische ontwerpen;
• documentatie en handleidingen;
• UX/UI-ontwerpen;
• productconcepten en functionele specificaties;
• testmateriaal;
• technische tekeningen;
• configuraties, workflows en deployment-informatie;
• teksten, designs en marketingmateriaal voor het platform;
• verbeteringen, uitbreidingen en afgeleide werken.

Maak het beding breed genoeg voor de praktijk, maar niet zo extreem dat het ook alle privéprojecten van de werknemer lijkt op te eisen. Dat werkt averechts en kan tot weerstand of discussie leiden.

B. Een bijlage voor bestaande code en privéprojecten

Dit is een van de belangrijkste praktische maatregelen.

Veel developers hebben al eigen libraries, templates, scripts, GitHub-projecten of side projects voordat zij bij jou beginnen. Als je dat niet vastlegt, kan later discussie ontstaan: was die code van de werknemer, van het bedrijf of allebei?

Laat de werknemer daarom vóór de eerste werkdag een korte bijlage invullen met:

• bestaande eigen software;
• persoonlijke GitHub-repositories;
• open-sourceprojecten waaraan de werknemer bijdraagt;
• bestaande templates, scripts of libraries;
• lopende side projects;
• andere relevante IP-rechten die de werknemer wil uitzonderen.

Spreek daarbij af dat deze bestaande materialen buiten de overdracht blijven, tenzij jullie apart schriftelijk iets anders afspreken.

C. Open source: maak daar een aparte afspraak over

Voor platformbedrijven is open source onmisbaar, maar ook risicovol als niemand de voorwaarden controleert.

Open source betekent niet: gratis en zonder verplichtingen. Sommige licenties eisen bronvermelding, behoud van notices, publicatie van broncode of het beschikbaar stellen van wijzigingen. Vooral bij platformen en SaaS-producten moet je goed opletten met licenties zoals GPL en AGPL.

Neem daarom in de arbeidsovereenkomst of een aparte policy op:

• welke open-sourcelicenties werknemers mogen gebruiken;
• welke licenties vooraf toestemming vereisen;
• wie toestemming mag geven;
• waar gebruikte componenten worden geregistreerd;
• of je een SBOM of dependency-overzicht bijhoudt;
• hoe je omgaat met bijdragen aan externe open-sourcerepositories;
• of werknemers bedrijfssoftware mogen uploaden naar publieke repositories.

Praktische hoofdregel: geen open-sourcecomponenten in je platform zonder dat duidelijk is welke licentievoorwaarden gelden.

D. AI-tools: regel wat werknemers wel en niet mogen doen

De afgelopen jaren zijn AI-tools zoals codegenerators, copilots en generatieve AI-systemen normaal geworden in softwareontwikkeling. Dat levert nieuwe vragen op.

Mag een developer bedrijfsbroncode in een publieke AI-tool plakken? Mag hij AI-output direct in productiecode verwerken?

Neem daarom een korte AI-bepaling of AI-policy op. Regel in ieder geval:

• dat vertrouwelijke informatie, broncode, klantdata en bedrijfsgeheimen niet zomaar in publieke AI-tools mogen worden ingevoerd;
• dat AI-output altijd moet worden gecontroleerd voordat die in het platform wordt gebruikt;
• dat gebruik van AI-tools moet passen binnen security-, privacy- en licentiebeleid;
• dat de werknemer moet melden wanneer AI-output substantieel is gebruikt voor belangrijke code, documentatie of productontwikkeling;
• dat het bedrijf niet automatisch mag aannemen dat AI-output exclusief beschermde eigendom is.

AI kan nuttig zijn, maar moet niet leiden tot onduidelijke rechten, datalekken of oncontroleerbare code.

E. Bedrijfsgeheimen en knowhow: regel meer dan alleen geheimhouding

Niet alles wat waardevol is, is auteursrechtelijk beschermd. Denk aan:

• architectuurkeuzes;
• algoritmische aanpak;
• klantinzichten;
• pricinglogica;
• roadmaps;
• datamodellen;
• technische workarounds;
• deploymentprocessen;
• commerciële strategie.

Dit valt vaak eerder onder bedrijfsgeheimen en knowhow dan onder klassieke IE-rechten.

Een geheimhoudingsbeding is noodzakelijk, maar niet genoeg. Je moet ook praktisch laten zien dat bepaalde informatie geheim is. Dat betekent:

• beperk toegang tot repositories en documentatie;
• gebruik rechtenbeheer;
• label vertrouwelijke documenten;
• log toegang en downloads waar passend;
• scheid klantdata, testdata en productiegegevens;
• trek accounts en tokens direct in bij vertrek;
• leg vast welke informatie een werknemer moet teruggeven of verwijderen.

Zonder praktische maatregelen wordt het lastiger om later te bewijzen dat iets echt een bedrijfsgeheim was.

F. Medewerking tijdens en na het dienstverband

Soms is een handtekening of extra verklaring nodig om rechten formeel over te dragen, een octrooi aan te vragen of documentatie voor een investeerder compleet te maken.

Neem daarom een medewerkingsplicht op. Die moet bepalen dat de werknemer, ook na het einde van het dienstverband, redelijk moet meewerken aan:

• bevestiging van overdracht;
• registratie van rechten;
• octrooiaanvragen;
• overdrachtsakten;
• verklaringen voor due diligence;
• technische overdracht en documentatie.

Maak dit wel redelijk. Bij uitgebreide werkzaamheden na het dienstverband kan een vergoeding of praktische afspraak nodig zijn.

G. Persoonlijkheidsrechten: regel praktisch gebruik

Bij auteursrecht kunnen ook persoonlijkheidsrechten een rol spelen. Denk aan het recht om als maker genoemd te worden of bezwaar te maken tegen bepaalde wijzigingen.

Voor softwarebedrijven is het belangrijk dat code, documentatie, ontwerpen en teksten kunnen worden aangepast, gerefactord, gecombineerd, opgesplitst, herschreven of zonder naamsvermelding gebruikt.

Neem daarom op dat de werknemer, voor zover wettelijk toegestaan, afstand doet van of geen beroep zal doen op persoonlijkheidsrechten voor zover dat nodig is voor normaal zakelijk gebruik van de werkresultaten.

Formuleer dit zorgvuldig. Niet alle persoonlijkheidsrechten kunnen onbeperkt worden uitgesloten.

H. Uitvindingen en octrooien

Niet ieder platformbedrijf vraagt octrooien aan, maar technische uitvindingen kunnen wel waardevol zijn. Denk aan een nieuwe technische methode voor dataverwerking, beveiliging, matching, compressie of systeemarchitectuur.

Regel daarom dat werknemers relevante uitvindingen direct moeten melden. Leg ook vast dat zij moeten meewerken aan octrooiaanvragen en dat rechten, voor zover mogelijk, bij de werkgever komen te liggen.

Let op: bij werknemersuitvindingen kan in sommige gevallen een billijke vergoeding verschuldigd zijn. Neem daarom geen harde tekst op waarin de werknemer “voor altijd en zonder vergoeding” afstand doet van alle mogelijke aanspraken. Dat kan later problemen geven.

Praktische oplossing: neem op dat eventuele wettelijke vergoedingsaanspraken worden gerespecteerd en dat partijen daarover in overleg treden als de situatie zich voordoet.

4. Let op nevenwerkzaamheden en side projects

Veel developers werken naast hun baan aan eigen projecten. Dat hoeft geen probleem te zijn, maar het moet wel duidelijk zijn waar de grens ligt.

Een algemeen verbod op alle nevenwerkzaamheden is meestal niet de beste oplossing. Beter is een duidelijke toestemmingsregeling voor situaties waarin risico’s ontstaan.

Bijvoorbeeld wanneer het side project:

• concurreert met het platform van de werkgever;
• gebruikmaakt van bedrijfscode, klantdata of documentatie;
• draait op bedrijfsmiddelen;
• gebaseerd is op bedrijfsgeheimen;
• leidt tot belangenconflicten;
• de werknemer belemmert in zijn werkzaamheden;
• security- of privacyrisico’s oplevert.

Maak duidelijk dat privéprojecten mogen, zolang ze de bedrijfsbelangen niet schaden en geen gebruik maken van bedrijfsmiddelen of vertrouwelijke informatie.

5. Werknemers, zzp’ers, stagiairs en founders: gebruik niet één standaardtekst

Een arbeidsovereenkomst is niet genoeg voor iedereen die aan je platform werkt.

Gebruik aparte afspraken voor:

• werknemers;
• zzp’ers;
• stagiairs;
• werkstudenten;
• founders;
• aandeelhouders die ook meewerken;
• externe bureaus;
• developers die eerst freelancer waren en later werknemer worden.

Vooral bij zzp’ers en externe bureaus is een schriftelijke overdracht van IE-rechten essentieel. Zonder goede overdrachtsclausule kan de maker eigenaar blijven van de code, ook als jij daarvoor hebt betaald.

Bij founders is dit extra belangrijk. Als founders vóór oprichting of vóór ondertekening van contracten al code, documentatie of productconcepten hebben gebouwd, moet die IP expliciet worden ingebracht of overgedragen aan de vennootschap.

6. Checklist vóór de eerste werkdag

Regel vóórdat iemand toegang krijgt tot de codebase:

• ondertekende arbeidsovereenkomst;
• IE-beding;
• geheimhoudingsbeding;
• regeling voor nevenwerkzaamheden en side projects;
• bijlage met bestaande code en privéprojecten;
• open-sourcebeleid;
• AI-toolbeleid;
• security- en toegangsbeleid;
• duidelijke functieomschrijving;
• afspraken over gebruik van bedrijfsmiddelen en privéaccounts.

Laat iemand niet alvast “even beginnen” zonder getekende afspraken. Juist in de eerste weken wordt vaak waardevolle code, documentatie en productkennis opgebouwd.

7. Actuele aandachtspunten voor platformbedrijven

De afgelopen jaren zijn een paar onderwerpen belangrijker geworden.

Open source en software supply chain

Bedrijven gebruiken steeds meer externe packages, libraries en dependencies. Daardoor wordt het belangrijker om te weten welke componenten in je platform zitten en onder welke licenties. Investeerders, klanten en kopers vragen hier steeds vaker naar.

AI in softwareontwikkeling

Developers gebruiken AI-tools voor code, documentatie, tests en debugging. Dat kan efficiënt zijn, maar geeft ook risico’s rond vertrouwelijkheid, herkomst van code, security, privacy en kwaliteit. Zorg daarom voor duidelijke interne regels.

Schijnzelfstandigheid en hybride werkvormen

Veel platformbedrijven werken met freelancers, werknemers, founders en parttime contributors door elkaar. Het label “zzp’er” of “werknemer” is niet genoeg. De feitelijke samenwerking en de contractuele IP-afspraken moeten kloppen.

Strengere blik op nevenwerk en concurrentie

Werkgevers mogen niet onbeperkt alle nevenactiviteiten verbieden. Ook concurrentiebedingen liggen onder een vergrootglas. Bescherm je platform daarom primair met goede IE-afspraken, geheimhouding, toegangsbeheer en exitprocessen. Gebruik zware beperkingen zoals concurrentiebedingen alleen gericht en onderbouwd.

8. Wat moet er minimaal in je IE-beding staan?

Een goed IE-beding bevat in ieder geval:

1. een duidelijke definitie van werkresultaten en IE-rechten;
2. een bepaling dat werkgerelateerde rechten bij de werkgever berusten of worden overgedragen;
3. een schriftelijke overdracht voor rechten die niet automatisch bij de werkgever terechtkomen;
4. een regeling voor bestaande code en privéprojecten;
5. een verplichting om uitvindingen, relevante verbeteringen en side-projectrisico’s te melden;
6. een medewerkingsplicht tijdens en na het dienstverband;
7. afspraken over persoonlijkheidsrechten;
8. bescherming van bedrijfsgeheimen en vertrouwelijke informatie;
9. regels voor open source;
10. regels voor AI-tools;
11. een praktische exitregeling.

9. Conclusie

De wet helpt je vaak al bij software die werknemers duidelijk binnen hun functie maken. Maar de praktijk is rommeliger: developers hebben privéprojecten, gebruiken open source, werken met AI-tools, wisselen tussen rollen en bouwen soms ook buiten kantooruren verder.

Daarom heb je niet alleen een brede clausule nodig, maar vooral een praktisch proces.

Wie dit goed regelt, voorkomt discussies over eigendom en maakt het bedrijf sterker bij groei, investering, verkoop of vertrek van belangrijke medewerkers.

Meer weten? Wij helpen je graag!

Hulp nodig bij IE-rechten in de arbeidsrelatie? Bel dan gerust naar ons kantoor (013 544 04 00) en vraag naar onze IT-recht advocaat Ruud de Kleijn of arbeidsrechtadvocaat Mindy Lodewijks, zij helpen je graag samen verder!