Alleen een rechthebbende kan software bij een vertrouwde derde (bijvoorbeeld een IT-notaris) deponeren. De rechthebbende is de auteursrechthebbende op de software of in een uitzonderlijk geval een partij die een gebruiksrecht (licentie) van de rechthebbende heeft gekregen die het recht op deponeren omvat.
Het auteursrecht is het exclusieve recht van de maker van een werk van letterkunde, wetenschap of kunst, of van diens rechtverkrijgenden, om dit openbaar te maken en te verveelvoudigen (art. 1 Auteurswet, verder Aw). Onder werken van letterkunde, wetenschap of kunst verstaat de Aw ook computerprogramma’s en het voorbereidend materiaal (art 10 lid 1 sub 12 Aw). De feitelijke maker (de programmeur) is dus in beginsel de auteursrechthebbende. Als er meerdere makers zijn dan hebben zij op grond van dit makersbeginsel ieder auteursrecht op de door hen zelf gemaakte onderdelen. Zij hebben gezamenlijk auteursrecht op door hen samen gemaakte onderdelen. Het auteursrecht op het gehele werk berust op grond van dit makersbeginsel bij de makers als zij het gehele werk samen hebben gemaakt. Op dit makersbeginsel bestaat een aantal belangrijke uitzonderingen. (1) Het auteursrecht van een gezamenlijk werk berust bij degene onder wiens leiding en toezicht het tot stand is gebracht of degene die de afzonderlijke onderdelen heeft verzameld (art. 5 lid 1 Aw). (2) Het auteursrecht op een al dan niet gezamenlijk werk berust bij degene naar wiens ontwerp en onder wiens leiding en toezicht het tot stand is gebracht (art. 6 Aw). (3) Het auteursrecht op een al dan niet gezamenlijk werk berust bij degene in wiens dienst het is gemaakt, waarbij de overeengekomen dienst bestaat uit het vervaardigen van dit werk of dit type werken (art. 7 Aw).[1] Bij oppervlakkige lezing lijkt dit een min of meer sluitend systeem te zijn waarmee het makerschap kan worden bepaald. Complicaties ontstaan daarbij alleen als er onduidelijkheid is over het feitelijk makerschap van het geheel of van onderdelen van het werk en over de gezagsverhoudingen bij het maken van het werk.
De praktijk en in het bijzonder de praktijk van het maken van software is echter veel weerbarstiger. Software is een complex begrip en het hiervoor beschreven systeem van de wet is niet sluitend. Het beantwoorden van de vraag of er afdoende auteursrechten zijn om de continuïteit van software door het deponeren van software te kunnen garanderen, vereist daarom behoorlijk wat kennis van zowel techniek als recht.
Software is een verzameling van werken: de ontwerpspecificaties, de broncode, de machinecode, de documentatie en in niet standaardgevallen zelfs de beschrijving van de installatie in een specifieke omgeving. Onder omstandigheden (noodzakelijk onderhoud, herinstallatie) zijn rechten op al deze of meerdere van deze werken vereist om de software te kunnen blijven gebruiken. Bij het ontwikkelen van software wordt bovendien vrijwel altijd voortgebouwd op bestaande routines[2] en wordt vaak door meerdere makers samengewerkt. Elke gebruikte routine kan daardoor onder een ander auteursrechtregime vallen. Het auteursrecht op de interpreters en compilers die worden gebruikt om de broncode (source code) naar machine code (object code) te vertalen kan een rol meespelen bij het beschikkingsrecht over de software. Hetzelfde geldt voor het auteursrecht op software van derden die vereist is om de eigen software te kunnen installeren en executeren. IT dienstverleners mogen bijvoorbeeld veelal hun fees niet mede baseren op geïntegreerde onderdelen van de door hen aangeboden software en de (her)gebruiksrechten daarvan niet beperken, maar wie leest ooit die verdomde GNU licentie? Vrij herbruikbare software heeft wel degelijk gebruiksbeperkingen.
Alsof dit nog niet genoeg is, ook het juridische systeem vertoont complicaties, in het bijzonder door onvolledigheid. Alleen als een programmeur in zijn eentje een volledig softwarepakket met al de hiervoor genoemde onderdelen ontwikkelt, zijn er geen juridische complicaties. Dat is echter zoals gezegd vrijwel ondenkbaar. De ontwikkeling en het gebruik van het meest onbeduidende appje op uw telefoon vereist nog het hiervoor beschreven gebruik van software van derden. Het makersbeginsel is daardoor wat achterhaald. De wereld van auteursrecht op software is een wereld van uitzonderingen. En daar zien we meteen het grootste gat in het wettelijk systeem. Wie heeft het auteursrecht op het hele werk als dit niet onder leiding of toezicht van een derde is ontwikkeld, maar gewoon door een paar aardige jongens samen op een zolderkamer of in een garage? Zeker als deze jongens ieder hun eigen onderdelen hebben geprogrammeerd op basis van hun specifieke kennis en ervaring. De een de 3d-visualisatie, de andere de calculatiemodellen en een derde de modellen van juridische normen voor bouwkundige software, waarbij de laatste voor de specificatie nog heeft samengewerkt met een bouwrecht juriste? In kleine teams is het goed mogelijk, uitgaande van een globaal ontwerp op grond van een eenvoudige oplossing van een praktisch probleem, elk je eigen aandeel te programmeren. Het ontwerp van het gehele systeem heeft dan geen enkele originaliteit (is louter gebaseerd op de eenvoudige oplossing van het praktische probleem) en kan zowel door een (potentiele) afnemer, als door een of meer van de teamleden in informele gesprekken zijn geschetst. Het ontwerp kan in dit geval dan ook niet als grondslag dienen voor het auteursrecht.
Ook als er sprake is van een dienstverband is het bepalen van het auteursrecht vaak niet eenvoudig. Software bevat niet alleen een veelheid aan routines van derden zoals hierboven is uiteengezet, maar programmeurs maken ook vaak opnieuw gebruik van eerder door hen geschreven code, bijvoorbeeld tijdens hun studie, bij stages, voor afstudeeronderzoeken of promotieonderzoek of in het kader van eerdere opdrachten geschreven code. Behoort deze code tot de kennis die de werkgever heeft ingekocht of is deze als eerder ontwikkelde code voorwerp van een zelfstandig auteursrecht? Omgekeerd kan er ook een probleem ontstaan als de relatie tussen opdrachtgever en programmeur formeel als overeenkomst van opdracht of aanneming van werk is gestart, maar achteraf wordt vastgesteld dat er toch sprake is van een arbeidsovereenkomst, bijvoorbeeld omdat er slechts sprake is van een enkele opdrachtgever waarvoor de programmeur werkte. Hier kan het onzekere belang van de programmeur om over het auteursrecht te beschikken botsen met zijn belang om een zekere arbeidsrelatie te hebben. Ook kan de opdracht van een werkgever aan een werknemer niet expliciet genoeg zijn om het auteursrecht op grond van uitzondering (3) aan de werkgever toe te kennen.
Een laatste complicatie is dat software steeds meer als zaak wordt beschouwd, waardoor de eigendom van de zaak de rol van het auteursrecht kan overnemen (uitputting van het auteursrecht). Het is bijvoorbeeld mogelijk dat het nemen van een licentie op software kan worden beschouwd als koop van software als aan de criteria van het Usedsoft arrest is voldaan.[3] De licentienemer kan vervolgens zijn kopie van de software verkopen.
Het makersbeginsel en de uitzonderingen daarop zijn ontworpen in een tijd van schrijvers, uitgevers en drukkers. Programmeurs zijn geen schrijvers. Zij werken vrijwel zonder uitzondering met een netwerk van componenten, waarmee een samengesteld product wordt ontwikkeld. Dit netwerk bestaat niet alleen op een bepaald moment in de tijd maar heeft ook een voorgeschiedenis en ontwikkelt zich verder waarbij opnieuw verschillende programmeurs, opdrachtgevers en werkgevers hun bijdrage leveren. De wet geeft geen aanwijzingen waarmee het begrip software op een ongecompliceerde wijze kan worden afgebakend. De wet bevat evenmin een sluitend (volledig) juridisch systeem voor het beoordelen van het makerschap. De jurisprudentie repareert deze tekortkomingen niet en is grotendeels casuïstisch. Er lijken slechts twee oplossingen voor het hieruit voortkomende probleem van een eenduidige bepaling van het beschikkingsrecht over software. (1) Het vraagstuk sterk vereenvoudigen door steeds duidelijke afspraken met alle betrokken partijen te maken over de auteursrechten. (2) Voor ieder geval opnieuw de complexe feitelijke en juridische situatie in kaart brengen, waarvoor een behoorlijke niveau van technische en juridische kennis vereist is. De eerste oplossing is echter slechts een schijnoplossing omdat deze veronderstelt dat alle betrokken partijen al in kaart gebracht zijn en bijvoorbeeld de eerder genoemde jongens op hun zolder ook al duidelijke afspraken met elkaar gemaakt hebben en dat is nu eenmaal niet ‘des jongens op een zolder’.
Dr. mr. C.N.J. de Vey Mestdagh, dir. R&D Software Borg Instituut
Een arbeidsrelatie: HR 17 november 1967, NJ 1968, 162 Den Hollander/Luitingh
O.a. samengebracht in zgn. libraries met extensies als .lib, .so,.dylib, .dll , .jar, etc. waarvan u er tienduizenden op elke gewone PC vindt. Ook wordt steeds meer open source software geïntegreerd in de source code van software.
EHvJ 3 juli 2012, zaak C‑128/11, ECLI:EU:C:2012:407