1. Home
  2. Kennis
  3. Artikelen
  4. IT-contracten (deel 14): Intellectuele Eigendom

IT-contracten (deel 14): Intellectuele Eigendom

Als je een IT-contract sluit tot de levering of terbeschikkingstelling  van bijvoorbeeld een website of software is het belangrijk na te denken over de intellectuele eigendomsrechten. Het auteursrecht is veruit het belangrijkste intellectuele eigendomsrecht om software te beschermen. Op het moment dat je hiertoe niets regelt, komen de rechten aan de ontwikkelaar toe. Met name in geval van maatwerksoftware kan dit verstrekkende gevolgen voor de afnemer hebben: zo mag je niets (laten) wijzigen en kan je zelfs gedwongen worden te stoppen met het gebruik van de software. Het is dan ook belangrijk de intellectuele eigendomsrechten contractueel goed te regelen. In dit blog ga ik in op de contractuele afspraken omtrent intellectuele eigendomsrechten. Hierbij komen zowel de vermogensrechtelijke handelingen als enkele andere belangrijke regelingen aan bod. Ik sluit af met enkele praktische tips.
Leestijd 
Auteur artikel Ernst-Jan van de Pas
Gepubliceerd 15 augustus 2019
Laatst gewijzigd 20 augustus 2019

Eigendom of gebruiksrecht/licentie?

Bij het sluiten van een IT-contract vormen in de regel één van deze twee (vermogensrechtelijke) handelingen de basis voor de levering van software: ofwel de overdracht van het auteursrecht ofwel de verlening van een gebruiksrecht (ook wel aangeduid als een (auteursrecht)licentie).

Wie is eigenaar van de geleverde software?

Meestal wordt gedacht: ‘ik betaal, dus ik word eigenaar’. Dit is een van de meest voorkomende misverstanden bij software ontwikkeling omdat dit niet geldt. Software wordt auteursrechtelijk beschermd. Deze auteursrechten komen volgens artikel 2 Auteurswet (“Aw”) in beginsel toe aan de maker (de programmeur) of – als hij in loondienst werkt - zijn werkgever (7 Aw). Dit is in geval van een IT-contract in de regel de opdrachtnemer of eventueel de door hem ingehuurde derde. Het enkele feit dat de afnemer gedetailleerde specificaties heeft verstrekt en volledig voor de ontwikkeling heeft betaald, doet hier niets aan af.

Bij de ontwikkeling van software geldt: ‘ik maak, dus ik ben eigenaar’ in plaats van 'ik betaal, dus ik ben eigenaar'

Dit is alleen anders als de software helemaal naar het ontwerp van een ander en onder diens leiding en toezicht wordt ontwikkeld (6 Aw). Maar die situatie doet zich bijna nooit voor omdat dit veronderstelt dat de programmeurs vrijwel geen enkele keuzevrijheid hebben bij het ontwikkelen van software en enkel het ontwerp en de instructies van de leidinggevende uitvoeren.

Hoe word je dan als afnemer eigenaar van de geleverde software?

Zonder contractuele afspraken over de overdracht van auteursrechten, wordt de afnemer (juridisch bezien) geen eigenaar. De afnemer verkrijgt dan hooguit een gebruiksrecht/licentie op de software of applicatie.

Het overdragen van de auteursrechten moet volgens de wet bij schriftelijk contract (vgl. art. 2 Aw). Een voorbeeld van een clausule uit de GIBIT-voorwaarden om de overdracht van de intellectuele eigendomsrechten te regelen is: Indien de Overeenkomst (mede) ziet op het door Leverancier ontwikkelen van een aanvulling op bestaande Programmatuur, niet zijnde een aanvulling op bestaande Programmatuur, dan berusten de rechten van intellectuele eigendom op die te ontwikkelen Programmatuur (..) bij de opdrachtgever.”.

Zin en onzin van eigenaar worden van software

Een overdracht van de intellectuele eigendomsrechten is niet altijd relevant of zinvol.

  • Standaard: Bij standaardsoftware heb je als afnemer in de regel geen belang bij een dergelijke overdracht: in dat geval volstaat een licentie (hierover in de volgende paragraaf meer).
  • Maatwerk: Wordt er echter maatwerkprogrammatuur gemaakt, waarbij de bron- en objectcode en mogelijk enkele features speciaal voor een afnemer worden ontwikkeld, dan kan het wel degelijk van belang zijn de rechten daarop overgedragen te krijgen. Wordt er een maatwerkaanpassing gedaan specifiek voor jou bovenop of in bestaande standaardprogrammatuur, dan is het maar de vraag of je die rechten daarop moet willen hebben. Zonder de standaardprogrammatuur werkt die maatwerkaanpassing vaak niet. Het verkrijgen van de IE-rechten op het maatwerk heeft dan vanuit deze optiek niet veel toegevoegde waarde.

De vraag is wat de achterliggende reden is om de rechten te verkrijgen.

  • Wil je voorkomen dat de leverancier de maatwerkaanpassing ook aan anderen (bijvoorbeeld concurrenten) verstrekt, dan heeft het wel zin om de eigendomsrechten te verkrijgen. Maar je zou dan ook een contractuele voorziening kunnen maken in een licentieovereenkomst.
  • Wil je je investeringen in het maatwerk kunnen terugverdienen, dan kun je dat ook bewerkstelligen met een contractuele terugverdienregeling.

In veel gevallen kun je er zelfs belang bij hebben om de rechten niet te verkrijgen en de leverancier de ruimte te geven de software te laten vermarkten zodat de onderhoudskosten over meerdere partijen uitgesmeerd kunnen worden. Denk dus goed na wat je precies wilt bereiken en hoe noodzakelijk het is om de rechten te verkrijgen, of dat je andere contractuele maatregelen kunt treffen om je belangen vast te stellen (zoals exclusiviteit, terugverdienregeling, royaltyregeling, etc).

Wat houdt een gebruiksrecht / licentie in?

Op basis van de Auteurswet heeft een auteursrechthebbende het exclusieve recht tot het ‘verveelvoudigen’ (bijvoorbeeld kopiëren) en ‘openbaar maken’ (bijvoorbeeld distribueren) van de software. Hiernaast beschikt de auteursrechthebbende over de zogenoemde ‘persoonlijkheidsrechten’. Op grond van deze rechten kan een auteursrechthebbende zich bijvoorbeeld verzetten tegen de wijziging van de software.

Bij een gebruiksrecht / licentie verleent de leverancier (als auteursrechthebbende) het recht aan de afnemer om gedurende een bepaalde overeengekomen termijn de geleverde software te gebruiken.

De omvang van de licentie wordt vaak omschreven in de zogenoemde ‘licentievoorwaarden’. Hierin kunnen beperkingen worden gesteld aan het gebruik van de software in bijvoorbeeld tijd, gebruiksomgeving en het aantal gebruikers. Daarnaast is een gebruiksrecht in de regel erg beperkt: het is niet-exclusief, niet-overdraagbaar et cetera.

Een voorbeeld van een verstrekt gebruiksrecht uit de GIBIT-voorwaarden: 

“Alle rechten van intellectuele eigendom op de op grond van de overeenkomst ontwikkelde of aan klant ter beschikking gestelde programmatuur, websites (…) uitsluitend berusten bij de leverancier, dienst licentiegevers of dienst toeleveranciers. Klant verkrijgt de gebruiksrechten (…). Een aan klant toekomend recht tot gebruik is niet-exclusief, niet-overdraagbaar, niet-verpandbaar en niet-sublicentieerbaar.”

Let wel, het Europese Hof van Justitie heeft in het UsedSoft-arrest wel geoordeeld dat bepaalde software hoe dan ook overdraagbaar is. Daarnaast kan dit eveneens in het licht van de wettelijke rechten om bijvoorbeeld interoperabiliteit te realiseren toegestaan zijn (vgl. art. 45m Aw).

Wat kan men in dit licht nog meer regelen?

Naast het maken van contractuele afspraken over de overdracht van het auteursrecht en de verlening van licenties, is het in dit verband ook raadzaam om over de volgende zaken na te denken.

Overdracht broncode en documentatie

In het kader van de overdracht van het auteursrecht op software is het van belang dat je ook altijd de toegang tot de broncode overgedragen krijgt. Deze toegang heb je immers nodig om aanpassingen en wijzigingen aan de software aan te kunnen verrichten. Zorg er ook voor dat je de documentatie aangaande de software overgedragen krijgt. Eigenaar zijn van iets waar je niet bij kunt of dat je bij gebreke van documentatie niet snapt (en niet snappen kunt) is immers weinig zinvol.

Overdracht van aanpassingen en afstand persoonlijkheidsrechten

Bij overdracht van auteursrechten is het voor een afnemer raadzaam een regeling op te nemen waardoor de rechten op eventuele aanpassingen van de software alvast vooraf worden overgedragen. Daarnaast dient de afnemer, met name bij maatwerkprogrammatuur ook op te letten dat de maker afstand doet van eventuele persoonlijkheidsrechten. Deze rechten – op grond waarvan de maker zich bijvoorbeeld kan verzetten tegen wijzigingen in software – gaan niet automatisch mee over bij een overdracht en de maker dient daar dan ook afstand van te doen.

Een voorbeeld van een dergelijke clausule uit de GIBIT-voorwaarden is: ”Deze overdracht ziet op alle huidige en toekomstige rechten in de meest ruime zin van het woord. Leverancier doet reeds nu voor alsdan voorts – voor zover de wet dat toestaat – onherroepelijk afstand van eventuele persoonlijkheidsrechten op de ICT Prestaties.”

Vrijwaring en garantie

Hiernaast is het voor een afnemer aan te raden een vrijwaringsclausule ten aanzien van de intellectuele eigendomsrechten van een ander in de overeenkomst op te nemen. Middels een dergelijke clausule bevestigt de afnemer dat de leverancier hem vrijwaart voor mogelijke claims die het gevolg zijn van een inbreuk op de auteursrechten van derden. Let wel: die verplichting tot vrijwaring vervalt mogelijk indien de door de derde ingestelde vordering verband houdt met door of namens de opdrachtgever aangebrachte wijzigingen.

Daarnaast is ook het opnemen van een garantie verstandig. Een voorbeeld van een garantieclausule uit de GIBIT-voorwaarden is:  “Leverancier garandeert dat de door hem aan Opdrachtgever verstrekte ICT Prestaties geen inbreuk maken op enige intellectuele eigendomsrechten, van derden.”

Praktische tips:

  1. Ga als opdrachtgever na of het verkrijgen van de auteursrechten op (maatwerk)software in uw geval relevant en zinvol is;
  2. Denk bij de overdracht van auteursrecht ook aan de persoonlijkheidsrechten. Deze gaan niet automatisch over bij overdracht. Een afnemer doet er dan ook goed aan om in de overeenkomst op te nemen dat de maker afstand – voor zover de wet dit toelaat - doet van zijn persoonlijkheidsrechten;
  3. Denk ook aan de overdracht van toekomstige auteursrechten, zoals eventuele aanpassingen aan de programmatuur al dan niet in het kader van onderhoud;
  4. Zorg voor een vrijwaring en garanties inzake mogelijke claims van derden;
  5. In het geval geen overdracht maar een licentie wordt overeengekomen, zorg er dan voor dat duidelijk is wat de licentievoorwaarden zijn (duur, aantal gebruikers, wel/niet exclusief, etc).

Leest u vooral ook de andere onderwerpen uit onze serie IT-contracten en blijf het geheel in samenhang bekijken.

Serie IT-contracten
Deel 1: Dwarsdoorsnede van IT-contract
Deel 2: Overwegingen Deel 10: Garantie
Deel 3: Definities Deel 11: Aansprakelijkheid
Deel 4: Onderwerp van de overeenkomst Deel 12: Overmacht
Deel 5: Levering, implementatie en opleiding Deel 13: Verwerking van persoonsgegevens
Deel 6: Acceptatieprocedure Deel 14: Intellectuele eigendom
Deel 7: Onderhoud en beheer (volgens SLA) Deel 15: Duur en beëindiging
Deel 8: Governance en evaluatie Deel 16: Gevolgen van de beëindiging/transitie
Deel 9: Prijs en betaling Deel 17: Toepasselijk recht en geschillen