Met software zijn aanzienlijke belangen gemoeid die juridische bescherming verdienen. Daar is niet altijd oog voor. De kiem voor een geschil over de rechten is vaak onbewust al gezaaid vóór aanvang van het ontwikkelingsproces. Inzicht in de juridische aspecten draagt bij aan het veiligstellen en adequaat beheren van de rechten op software. Bovendien kan het aan de onderhandelingstafel winst opleveren. In deze bijdrage worden knelpunten en misverstanden uit de praktijk besproken.

1. Bent u eigenaar van een lege huls?
Juridische aspecten
Met software zijn aanzienlijke belangen
gemoeid die juridische bescherming verdienen. Daar is niet altijd oog voor. De
kiem voor een geschil over de rechten is
vaak onbewust al gezaaid vóór aanvang
van het ontwikkelingsproces. Inzicht in
de juridische aspecten draagt bij aan het
veiligstellen en adequaat beheren van de
rechten op software. Bovendien kan het
aan de onderhandelingstafel winst opleveren. In deze bijdrage worden knelpunten en misverstanden uit de praktijk
besproken.
door: Robert Grandia
De juridische bescherming van software is
een specialistisch vakgebied en de kennis
hierover schaars. Discussies over de rechten op de software gaan vaak over de vraag
van wie de intellectuele eigendomsrechten zijn, of aan wie ze moeten toekomen.
Intellectuele eigendomsrechten is de benaming voor een aantal wettelijke beschermingsregimes zoals het merkenrecht,
het auteursrecht, het databankrecht, het
octrooirecht en het tekeningen- en modellenrecht. Voor software is hoofdzakelijk het
auteursrecht van belang.
14
Het auteursrecht komt op grond van de
Auteurs­wet toe aan de maker van een werk.
Software kan een werk zijn. De rechthebbende
van het auteursrecht heeft het exclusieve recht
handelingen met het werk te verrichten zoals
het openbaar maken en het verveelvoudigen
(reproduceren, kopiëren, bewerken of nabootsen). Tot het verveelvoudigen van software
behoren ook typische (gebruiks)handelingen
zoals het laden, het in beeld brengen, de uitvoering, de transmissie of de opslag van de
software. De rechthebbende kan een ander
toestemming (licentie) geven tot een bepaald
gebruik van de software via een licentieovereenkomst.
Voor het ontstaan van auteursrecht op software gelden geen formele vereisten. Het
auteursrecht op een boek ontstaat bij het
beschrijven van de bladzijden. Het auteursrecht op software ontstaat door het maken
van de software. Vermelding van een copyright
notice (©) is niet nodig om bescherming van
de Auteurswet te krijgen. Wel moet sprake
zijn van oorspronkelijkheid van het werk.
Wie heeft wat gemaakt?
Geregeld blijkt het bezit van het auteursrecht op software niet een feit, maar een
veronderstelling. Volgens de hoofdregel van
de Auteurswet is de maker van het werk
rechthebbende. De knel zit dan in de dubbele
vraag: wie is de maker en van welk werk?
Softwareontwikkeling is doorgaans een
samenwerking van meerdere personen die,
tegelijk of opvolgend, ieder voor zich of tezamen bijdragen leveren. Het is denkbaar dat
er een maker kan worden aangewezen van
het functioneel ontwerp en dat een ander
kan worden aangemerkt als maker van het
technisch ontwerp. Weer een ander is maker
van een bepaald deel van de software (bijvoorbeeld een specifieke module of routine).
Ook kunnen meerdere personen samen de
makers zijn. Het overzichtelijk beeld van dé
maker van dé software komt daarmee, voorzichtig gezegd, onder spanning te staan.
Werknemers. Binnen een werkgever-werknemerrelatie kan het makerschap in één hand
blijven. Als het tenminste goed is geregeld.
Artikel 7 van de Auteurswet wijst de werkgever aan als maker en daarmee rechthebbende indien sprake is van een dienstverband (een arbeidsovereenkomst) en indien
het betreft “arbeid, bestaande in het vervaardigen van werken”. Met andere woorden:
het maken van het werk moet ook binnen
de taakomschrijving of aanvaarde opdracht

2. rondom software
van de werknemer vallen. Niet alles valt
hieronder. Als de programmeur (eventueel
na werktijd) een programma maakt, wie is
dan rechthebbende? Dat ligt aan de omstandigheden.
Gedetacheerden. In het geval van detacheringskrachten wordt in de rechtsliteratuur verdedigd dat niet de formele werkgever (het detacheringsbedrijf), maar het inlenende bedrijf
(de klant) in veel gevallen als materieel werkgever kan worden beschouwd en dus rechthebbende zal zijn. Ter voorkoming van onzekerheden doen het detacheringsbedrijf en de
klant er echter beter aan om uitdrukkelijk af
te spreken wie rechthebbende wordt.
Freelancers en stagiairs. Freelancers (werkzaam
op basis van opdracht) vallen niet onder
artikel 7 en zijn dus als maker van de software zelf rechthebbenden. Artikel 7 geldt
evenmin voor stagiairs. Onlangs nog kwam
het Hof te Arnhem in een geschil tussen
een stagiair en het stagebedrijf tot het oordeel dat de stagiair als rechthebbende moest
worden beschouwd van de voor het stagebedrijf gemaakte applicatie1.
Bij het ontwikkelingsproces is het zonder
meer denkbaar dat een ander rechthebbende
is geworden van een geheel of een gedeelte
van de software. Het is noodzakelijk eerst
de contractuele relatie met alle betrokkenen (werknemers, detacheringskrachten,
freelancers, stagiairs) te beoordelen en zonodig alsnog contractueel in het juiste vat te
gieten. Reparatie achteraf is veel lastiger.
Eigendom of intellectueel eigendom?
Een softwareleverancier ontwikkelt vaak
software specifiek in opdracht van een klant.
Kenmerkend is dat de klant de kosten (volledig) draagt en een actieve rol vervult. De
klant dient inzicht te geven in de wensen en
verwachtingen van de te ontwikkelen software en in zijn relevante (administratieve,
technische, organisatorische) processen en
bedrijfsinformatie. Ook zullen ook medewerkers en faciliteiten beschikbaar moeten
worden gemaakt. Het plan om de software
te gaan ontwikkelen, kan bij de klant zijn
oorsprong hebben. Geregeld ontstaat dan
het idee dat de software wordt gekocht en
in eigendom wordt verkregen. Dat is echter
een misverstand. Intellectueel eigendom en
eigendom zijn twee werelden op zich. Van
een auto of een cd kan men de eigendom verkrijgen. Wat er vervolgens op de cd staat –
muziek van de Red Hot Chili Peppers, een foto
van je kind of software – het behoort tot het
domein van het auteursrecht. Het auteursrecht komt toe aan de maker.
Soms kan de klant als opdrachtgever zelf
maker en dus rechthebbende zijn. Op grond
van artikel 6 van de Auteurswet kan dat
“indien een werk is tot stand gebracht naar het
ontwerp van een ander en onder diens leiding en
toezicht”. Daarvan is niet snel sprake. En al
helemaal niet wanneer de rol van de klant
zich beperkt tot het aangeven van wensen
en ideeën over de functionaliteit, terwijl de
vervaardiging van voorbereidende materialen (functioneel ontwerp, technisch ontwerp) en de vervaardiging van de uiteindelijke software wordt uitgevoerd door de
softwareleverancier.
De softwareleverancier (als rechthebbende)
en de klant kunnen ertoe overgaan het
auteursrecht op de software over te dragen
aan de klant. De klant wordt dan in zijn
plaats de (nieuwe) rechthebbende. Daarvoor
is wel een schriftelijke overeenkomst tot
overdracht nodig.
Licentieovereenkomsten
Nog te vaak wordt aangenomen dat het
gebruik van software is toegestaan zodra
een licentieovereenkomst voorhanden is.
Dat is te kort door de bocht.
15

3. De praktijk kent veel verschillende licentieovereenkomsten, waaronder de End User
License Agreement, de evaluation license, de ontwikkellicentie, de site-licentie, de OEM-licentie (Original Equipment Manufacturer License) en
de volumelicentie. Bij licentieovereenkomsten
gaat het altijd om de inhoud en niet om de
naam die boven het contract staat. Het komt
ook voor dat overeenkomsten niet als zodanig worden benoemd, maar wel deels licentieovereenkomsten zijn (de resellerovereenkomst is daar nogal eens een voorbeeld van).
Voor een licentieovereenkomst is schriftelijkheid geen vereiste. Men zou de licentieovereenkomst achteraf nog kunnen
aantonen aan de hand van e-mails, besprekingsnotulen of verklaringen van getuigen. Om bewijsproblemen te voorkomen,
dient de licentieovereenkomst schriftelijk
te worden aangegaan.
Wijzigingen in gebruik?
De kern van iedere licentieovereenkomst
bestaat uit het toegestane gebruik:
Wie mag gebruiken (een bepaald bedrijf,
groep van bedrijven, gelieerde personen)?
Waarop mag gebruikt worden (op een
bepaalde computer of in een netwerk)?
Hoelang mag gebruikt worden (tot een nieuwe
versie verschijnt of eeuwigdurend)?
Waarvoor mag gebruikt worden (intern of
voor derden, zoals bij software as a service)?
Hoeveel gebruikers (een x-aantal concurrent
users of named users)?
Waar mag gebruikt worden (op een bepaalde
locatie of onafhankelijk van de locatie,
binnen Nederland of wereldwijd)?
Welke software mag worden gebruikt (versies, updates, upgrades, broncode)?
Wat is de omgeving waarin mag worden
gebruikt (is portering van de software naar
een andere hardware-omgeving of een ander
besturingsysteem toegestaan)?
Dikwijls bevat de licentieovereenkomst een
verbod tot overdracht van de licentieovereenkomst en een verbod om aan anderen een
sublicentie te geven. Dat heeft onder meer
gevolgen voor de outsourcingpraktijk (outtasking, offshoring, facilities management,
ASP). Vaak zal de licentieovereenkomst een
overgang van het gebruik van software (in
het kader van een overgang van een bedrijfsfunctie) in de weg staan. Dat geldt ook voor
extern beheer en onderhoud.
De licentieovereenkomst moet voortdurend
kritisch tegen het licht worden gehouden.
Als zich wijzigingen in het gebruik voordoen die niet met de licentieovereenkomst
zijn te verenigen, dan zullen de klant en de
rechthebbende opnieuw met elkaar moeten
onderhandelen.
Geen maatpak
Het recht tot gebruik van software op grond
van een licentieovereenkomst zal in de regel
niet tevens de afgifte van de broncode omvat16
Het plan om de
software te gaan
ontwikkelen, kan
bij de klant zijn
oorsprong hebben.
Geregeld ontstaat dan het idee
dat de software
wordt gekocht
en in eigendom
wordt verkregen. Dat is echter
een misverstand.
Intellectueel
eigendom en eigendom zijn twee
werelden op zich
ten. In veel gevallen zal dat ook niet bespreekbaar zijn. Door afgifte zou immers de broncode in verkeerde handen kunnen vallen en
de software uiteindelijk in een concurrerend
product kunnen worden toegepast. De afgifte
van de broncode leidt niet tot verlies van het
auteursrecht op de software, maar kan wel de
deur openzetten naar inbreuk.
In de rechtspraak is desalniettemin een aantal
keer geoordeeld tot afgifte van de broncode
aan de klant (licentienemer) waarbij het ging
om software die ontwikkeld was in opdracht
en op kosten van de klant. Het betrof dan
gevallen waarin de klant stelde de broncode
nodig te hebben voor het (laten) plegen van
onderhoud van de bij de klant draaiende maatwerksoftware. In de rechtspraak is daarmee
een belangrijke rol toegekend aan de term
‘maatwerksoftware’ en dat heeft geleid tot
rechterlijke uitspraken die onvoldoende recht
doen aan de werkelijkheid.
Maatwerk is iets anders dan beginnen met
niets en eindigen met maatwerksoftware. Er
wordt gebouwd op basis van bestaande software (zoals een CRM-systeem), routines of
modules die al in andere producten zijn toegepast of ook voor toekomstige producten
bruikbaar zullen blijven. Het is ook mogelijk dat een rechthebbende software ontwikkelt in eerste instantie specifiek voor een
bepaalde klant (launching customer) met de
bedoeling om, bij gebleken succes, het product breder in de markt te gaan zetten. De
rechthebbende loopt in voorkomende gevallen het risico door de rechter te worden veroordeeld tot afgifte van de broncode van de
maatwerksoftware. De rechthebbende geeft
daarmee veel meer uit handen dan gewenst.
Een strijd over afgifte van de broncode kan
worden voorkomen door tijdig een deugdelijke escrowovereenkomst aan te gaan voor
de broncode van het specifieke maatwerk.
Op grond van een escrowovereenkomst
wordt de broncode in bewaring gegeven bij
een onafhankelijke derde (een escrowbureau, een notaris). Deze mag onder bepaalde
omstandigheden en alleen voor bepaalde
doeleinden (bijvoorbeeld uitsluitend voor
onderhoud) overgaan tot afgifte.
Inbreuk aanpakken
Vaak wordt bij inbreuk op het auteursrecht
op software gedacht aan de strafrechtelijke
handhaving door Justitie. Ten onrechte.
Inbreuk is primair een zaak tussen de rechthebbende en de inbreukmaker. De inbreukmaker heeft meer te vrezen van aanpak door
de rechthebbende zelf dan voor (de kans op)
strafrechtelijke vervolging. De rechthebbende kan de inbreukmaker voor de civiele
rechter ter verantwoording roepen. Er hoeft
geen sprake te zijn van opzettelijke inbreuk,
zoals in het strafrecht. Ook als een werknemer vanuit een vorige baan software heeft
‘meegenomen’ en dit – zonder te melden –

4. RG
naar de rechter
Een brief van een advocaat met een ingebrekestelling of een door de deurwaarder
bezorgde laatste sommatie kunnen de eerste
stappen zijn in de richting van een gerechtelijke procedure. Procederen kan echter lang
duren en veel kosten. De tarieven van een
advocaat beginnen rond € 175,00 per uur en
lopen vervolgens snel op naar enkele honderden euro’s per uur. Dit is afhankelijk van
het kantoor, de ervaringsjaren en de specialisatiegraad van de advocaat. Een procedure is
bovendien zeker niet altijd de oplossing voor
ieder geschil of voor alle geschilpunten.
Binnen de ict-branche staat de mogelijkheid open van ict-mediation bij de Stichting
Geschillenoplossing Automatisering­2. Mediation is een vorm van alternatieve geschillenoplossing (bemiddeling) die zich laat vergelijken met een onderhandelingsproces.
Mediators begeleiden partijen bij het vinden
van een praktische oplossing voor de gerezen problemen. Vrijwillige deelneming is een
vereiste. Verreweg de meeste mediations blijken tot een oplossing te leiden, waardoor een
gerechtelijke procedure wordt vermeden.
Het is raadzaam in de licentieovereenkomst
of de algemene voorwaarden op te nemen
dat bij een geschil eerst het pad van mediation zal worden bewandeld. De Fenit-voorwaarden bevatten een dergelijk beding3.
Mediation schept de mogelijkheid voor partijen bij een geschil om zelf oplossingsrichtingen voor te stellen en samen naar een
win-win-situatie te zoeken.
robert grandia was van 1999 tot medio 2006
advocaat in Rotterdam en werkt sindsdien als juridisch adviseur bij ICT~Office, de branchevereniging
voor de IT-, Telecom-, Internet- en Officebedrijven
in Nederland.7
1 Hof Arnhem 7 november 2006, nr. LJN AZ2563,
gepubliceerd op www.rechtspraak.nl
2 Voor meer informatie zie www.sgoa.org
3 De Fenit-voorwaarden (de laatste versie dateert
van 2003) zijn algemene voorwaarden die in de ictsector veelvuldig worden gehanteerd. Voor meer
informatie zie www.ictoffice.nl/voorwaarden
effectieve middelen tot zijn beschikking om
inbreuk aan te pakken.
N
verwerkt in een product, kan dat inbreuk en
schadeplichtigheid van zijn nieuwe werkgever betekenen.
Tegen een (potentiële) inbreukmaker kan
allereerst in een kort gedingprocedure een
verbod tot het maken van inbreuk worden
gevorderd. Dit kan op zeer korte termijn
als dat nodig is. De rechter verbindt aan het
verbod meestal een dwangsom. Bij overtreding is de dwangsom verschuldigd en kan
de gerechtsdeurwaarder beslag leggen om
het bedrag te incasseren en aan de rechthebbende af te dragen.
De inbreukmaker kan ook worden veroordeeld tot een product recall (het terughalen
van zijn inbreukmakende producten) of tot
opgave van de namen van zijn klanten en
zijn toeleverancier.
De rechthebbende staat verder de mogelijkheid open om bij de rechter schadevergoeding te vorderen. Die schade kan bestaan
uit geleden verlies en gederfde winst (misgelopen omzet, extra kosten). Soms kan de
inbreukmaker ook worden veroordeeld tot
afdracht van de met de inbreuk gemaakte
winst. Voorafgaand aan een procedure kan
de rechthebbende, met rechterlijke toestemming, door een gerechtsdeurwaarder beslag
laten leggen, bijvoorbeeld op inbreukmakende goederen.
De rechthebbende heeft kortom een aantal
1