Auteursrecht op software: wie heeft de rechten en wat moet je regelen?

Het komt vaak voor dat softwareleveranciers pas met intellectueel eigendom worden geconfronteerd wanneer er iets verandert. Een belangrijke ontwikkelaar vertrekt. Een klant wil exclusiviteit. Een investeerder voert een due diligence-onderzoek uit, of de onderneming wordt verkocht. Op dat moment blijkt ineens dat het auteursrecht op software niet goed is geregeld, onduidelijk is welke rechten aan klanten zijn verstrekt of dat een externe ontwikkelaar zijn auteursrechten nooit heeft overgedragen.

Deze risico’s kunnen direct gevolgen hebben voor de waarde van je onderneming en de manier waarop je jouw software commercieel kunt exploiteren. Door vooraf duidelijke afspraken te maken, kan je dit voorkomen.

​Auteursrecht op software begint niet bij een geschil

​Veel ondernemers denken pas aan intellectueel eigendom wanneer iemand software kopieert of wanneer een conflict ontstaat over het gebruik daarvan. Dat is eigenlijk te laat. Auteursrecht op software kan al vanaf het moment van ontwikkeling automatisch ontstaan. Daarvoor is geen registratie of depot nodig.

Dat betekent overigens niet dat jouw onderneming automatisch eigenaar is van de auteursrechten op de software. Wie auteursrechthebbende is, hangt onder meer af van wie de software heeft ontwikkeld en onder welke omstandigheden dat is gebeurd. Was dat een werknemer, een zzp’er, een softwarehuis of een combinatie van verschillende partijen? En als de rechten oorspronkelijk bij een externe ontwikkelaar lagen: zijn die vervolgens rechtsgeldig overgedragen?

Het antwoord op die vragen bepaalt uiteindelijk wie juridisch over de software mag beschikken.

Auteursrecht op software: betalen maakt je nog geen eigenaar

​Een hardnekkig misverstand is dat degene die voor de ontwikkeling van software betaalt, automatisch eigenaar wordt van de auteursrechten op de software. Dat is niet juist.

Met de betaling van een factuur betaal je in eerste instantie voor de overeengekomen ontwikkelwerkzaamheden. De auteursrechten op de ontwikkelde software gaan daardoor niet automatisch over. Voor de overdracht van auteursrecht is een daartoe bestemde akte vereist (artikel 2 Auteurswet). Het is daarom belangrijk om expliciet vast te leggen welke rechten worden overgedragen en op welk moment die overdracht plaatsvindt. Schakel je een externe ontwikkelaar in en regel je niets over de overdracht van auteursrechten, dan blijven die auteursrechten in beginsel bij de ontwikkelaar.

Stel dat een softwarebedrijf een externe ontwikkelaar inschakelt om een belangrijke module te bouwen in bestaande software. De werkzaamheden worden uitgevoerd, de facturen betaald en de module wordt jarenlang gebruikt. Pas wanneer een investeerder een due diligence-onderzoek uitvoert, blijkt dat de auteursrechten nooit zijn overgedragen. De onderneming gebruikt de software wel, maar kan niet zonder meer aantonen dat zij over de auteursrechten op een belangrijk onderdeel van haar product beschikt.

Het achteraf herstellen van zo’n situatie is lang niet altijd eenvoudig. De ontwikkelaar kan om een aanvullende vergoeding vragen, niet willen meewerken of inmiddels zelfs niet meer bereikbaar zijn.

​Auteursrecht op software bij werknemers en zzp’ers

​Software wordt tegenwoordig zelden door één persoon ontwikkeld. Veel softwarebedrijven werken met een combinatie van werknemers, zzp’ers, consultants en gespecialiseerde softwarehuizen.

Voor software die werknemers in het kader van hun werkzaamheden ontwikkelen, gelden bijzondere wettelijke regels waardoor de auteursrechten in veel gevallen bij de werkgever komen te liggen (artikel 7 Auteurswet). Toch is het verstandig om ook in arbeidsovereenkomsten expliciet aandacht te besteden aan intellectuele eigendomsrechten. Dat kan discussie voorkomen, bijvoorbeeld over software die buiten de gebruikelijke werkzaamheden wordt ontwikkeld.

Bij zzp’ers ligt dat anders. Een externe ontwikkelaar blijft in beginsel zelf auteursrechthebbende, tenzij de auteursrechten rechtsgeldig worden overgedragen. Dat verandert niet doordat jouw onderneming de volledige ontwikkeling betaalt of de ontwikkelaar uitsluitend voor jouw onderneming werkt. Werk je met ontwikkelaars via een softwarehuis, detacheerder of andere tussenpartij? Controleer dan of jouw contractspartij over de benodigde auteursrechten beschikt. Controleer ook of deze partij de rechten aan jouw onderneming kan overdragen.

​Heeft de ontwikkelaar de auteursrechten niet overgedragen? Kijk dan welke gebruiksrechten de opdrachtgever wél heeft gekregen. De gemaakte afspraken bepalen bijvoorbeeld of de opdrachtgever de software mag aanpassen, doorontwikkelen of aan derden beschikbaar mag stellen.

Vergeet open source en software van derden niet

​Niet alle software binnen jouw product is noodzakelijk door jouw eigen werknemers geschreven. Vrijwel iedere moderne applicatie maakt gebruik van bestaande libraries, frameworks en andere componenten van derden. Daaronder valt ook open-sourcesoftware.

​Open source betekent niet dat je deze software zonder voorwaarden mag gebruiken. Voor open-sourcesoftware gelden vaak specifieke licentievoorwaarden. Die voorwaarden kunnen je bijvoorbeeld verplichten om naams- en licentievermeldingen op te nemen, broncode beschikbaar te stellen of bepaalde voorwaarden te hanteren wanneer je afgeleide software verspreidt.

​Breng daarom in kaart wie jouw software heeft ontwikkeld en of de auteursrechten correct zijn overgedragen. Controleer daarnaast welke externe componenten in het product zijn verwerkt en welke licenties daarop van toepassing zijn. Bij een investering of overname zal een investeerder of koper hier vaak ook naar kijken tijdens een due diligence-onderzoek.

Een ontwikkelovereenkomst is veel meer dan een offerte

In de praktijk zien wij nog regelmatig dat softwareprojecten starten op basis van een offerte, een e-mailwisseling of een opdrachtbevestiging. Over de planning, de prijs en de opleverdatum zijn duidelijke afspraken gemaakt. Over intellectueel eigendom nauwelijks of simpelweg helemaal niet. Dat is een gemiste kans.

Een goede ontwikkelovereenkomst legt niet alleen vast wat wordt ontwikkeld, maar regelt ook het auteursrecht op software die tijdens het project wordt ontwikkeld. Welke rechten hebben partijen na oplevering? Wie wordt auteursrechthebbende en wanneer gaan eventuele rechten over? Vallen toekomstige uitbreidingen ook onder de afspraken? Welke bestaande software of frameworks brengt de leverancier zelf mee, en wie mag de software daarna verder ontwikkelen? En wat gebeurt er met broncode en documentatie als de samenwerking eindigt? Deze afspraken voorkomen discussies wanneer de software succesvol blijkt of wanneer partijen uit elkaar gaan.

Auteursrecht op software bij maatwerk: geef niet ongemerkt je rechten weg

Veel softwareleveranciers ontwikkelen maatwerk voor klanten. Daarbij ontstaat vaak de vraag wie eigenaar wordt van de ontwikkelde software. In de praktijk zien wij dat opdrachtgevers regelmatig vragen om overdracht van alle intellectuele eigendomsrechten. Dat is begrijpelijk vanuit hun positie, maar voor softwareleveranciers lang niet altijd wenselijk. De vraag is daarom niet alleen welke rechten de opdrachtgever wil krijgen, maar vooral welke rechten jij als leverancier wilt behouden.

De waarde van een softwarebedrijf zit namelijk vaak niet in één specifiek project, maar juist in de kennis, architectuur, frameworks en generieke bouwstenen die in verschillende projecten opnieuw worden gebruikt. Wanneer je zonder onderscheid alle intellectuele eigendomsrechten overdraagt, loop je het risico dat je die onderdelen later niet zonder meer opnieuw kunt inzetten. Daarmee beperk je niet alleen toekomstige commerciële mogelijkheden, maar ook de waarde van je onderneming. Het is daarom belangrijk om vooraf te bepalen welke rechten je commercieel gezien daadwerkelijk wilt overdragen.

Eigendom of een gebruiksrecht?

Bij auteursrecht op software is overdracht lang niet altijd noodzakelijk. Vraag jezelf daarom bij iedere opdracht af: heeft mijn klant daadwerkelijk de auteursrechten nodig, of kan een voldoende ruim gebruiksrecht hetzelfde praktische doel bereiken?

Door de auteursrechten zelf te behouden, behoud je als leverancier de mogelijkheid om generieke onderdelen, kennis en bouwstenen ook in andere projecten te gebruiken. De klant kan tegelijkertijd een ruime licentie krijgen die aansluit bij het beoogde gebruik van de software.

Je kunt daarbij onderscheid maken tussen bestaande software en generieke componenten van de leverancier enerzijds en specifiek voor de klant ontwikkeld maatwerk anderzijds. Vervolgens leg je per onderdeel vast wie de auteursrechten houdt en welke gebruiksrechten de andere partij krijgt. Denk daarbij ook aan de vraag of de klant de software mag aanpassen, door derden mag laten onderhouden of doorontwikkelen en of toegang tot de broncode nodig is. Welke constructie het beste past, hangt af van het project en de belangen van beide partijen.

Een goed opgestelde licentieovereenkomst biedt daarvoor vaak de oplossing. Daarin leg je vast welke rechten de klant krijgt en welke rechten juist bij jou als leverancier blijven. Zo kun je bepalen of de software alleen intern mag worden gebruikt, of koppelingen met andere systemen zijn toegestaan, of de software mag worden aangepast en onder welke voorwaarden onderhoud en updates plaatsvinden. Ook afspraken over aansprakelijkheid, beschikbaarheid en beëindiging horen daarin thuis. Zo voorkom je dat klanten meer rechten krijgen dan jij wilt verlenen.

Auteursrecht op software bij SaaS vraagt om andere afspraken

Steeds meer softwarebedrijven leveren hun software als Software as a Service (SaaS). Dat betekent dat de klant geen software meer koopt of op zijn eigen servers installeert, maar via internet toegang krijgt tot een applicatie. Dat heeft ook gevolgen voor de contractuele afspraken.

Bij traditionele maatwerksoftware ligt de nadruk vaak op de ontwikkeling en oplevering van de software. Bij een SaaS-oplossing draait het juist om het gebruik van de software gedurende de looptijd van de overeenkomst. De klant hoeft de software niet te bezitten om er optimaal gebruik van te kunnen maken. Integendeel: voor de meeste klanten is het verkrijgen van auteursrechten helemaal geen doel op zich. Zij willen een goed werkende applicatie, ondersteuning en continuïteit. Juist daarom is het belangrijk om in een SaaS-overeenkomst duidelijk onderscheid te maken tussen de software, de klantdata en het gebruiksrecht.

Ook bij SaaS is het belangrijk om het auteursrecht op software goed te regelen. Doorgaans blijven de auteursrechten bij de leverancier, voor zover deze rechten bij hem berusten. De klant krijgt gedurende de looptijd van de overeenkomst een gebruiksrecht dat aansluit bij de dienstverlening. Vaak is dat een niet-exclusief en beperkt gebruiksrecht voor de duur van de overeenkomst.

Een SaaS-overeenkomst vraagt om afspraken over onderwerpen als beschikbaarheid, onderhoud en updates, beveiliging, back-ups, ondersteuning en beëindiging van de dienstverlening.

​Maak afzonderlijke afspraken over klantdata

Klantdata vraagt om afzonderlijke afspraken. Leg bijvoorbeeld vast welke rechten en zeggenschap de klant ten aanzien van zijn data behoudt, voor welke doeleinden de leverancier deze data mag verwerken en wat er met de data gebeurt wanneer de overeenkomst eindigt. Denk daarbij ook aan de termijn en het formaat waarin gegevens kunnen worden geëxporteerd of teruggegeven en wanneer resterende gegevens worden verwijderd.

Zo voorkom je dat auteursrechten op de software, het gebruiksrecht van de klant en de afspraken over klantdata juridisch door elkaar gaan lopen.

Broncode en escrow​

Ook de broncode verdient aandacht. Een klant kan toegang tot de broncode verlangen omdat hij zekerheid wil over de continuïteit van de software, bijvoorbeeld wanneer de leverancier zijn dienstverlening niet langer kan voortzetten of in geval van faillissement.

Dat betekent niet automatisch dat de auteursrechten of de broncode aan de klant moeten worden overgedragen. Afhankelijk van de situatie kan een escrow-regeling een alternatief bieden. Daarbij kunnen partijen afspreken dat de broncode onder bepaalde vooraf omschreven omstandigheden beschikbaar komt voor de klant. Het is daarbij belangrijk om niet alleen de voorwaarden voor vrijgave vast te leggen, maar ook wat de klant na vrijgave daadwerkelijk met de broncode mag doen.

​Auteursrecht op software: wat moet je in ieder geval regelen?

Controleer in ieder geval:

• wie de auteursrechten op de software heeft;
• of externe ontwikkelaars hun auteursrechten rechtsgeldig hebben overgedragen;
• de gebruiksrechten van klanten;
• de rechten die je als softwareleverancier zelf behoudt;
• ​het gebruik van open-sourcecomponenten en andere software van derden;
• wat er bij het einde van de overeenkomst met broncode en klantdata gebeurt.

Goede contracten beschermen de waarde van je onderneming

Softwarebedrijven investeren veel tijd en geld in de ontwikkeling van hun product. Die waarde zit niet alleen in de software zelf, maar ook in de juridische positie eromheen. Is het auteursrecht op software binnen jouw onderneming goed geregeld? Zijn de auteursrechten van externe ontwikkelaars daadwerkelijk overgedragen? Welke rechten hebben klanten gekregen? Welke open-sourcecomponenten worden gebruikt? En sluiten de contracten nog aan bij de manier waarop de software inmiddels wordt aangeboden?

Wie daar vooraf duidelijke afspraken over maakt, voorkomt dat intellectuele eigendomsrechten versnipperen, klanten meer rechten krijgen dan bedoeld of tijdens een investering of overname discussie ontstaat over de juridische basis van de software.

Weet je niet zeker of de rechten op jouw software goed zijn geregeld? Of wil je weten of jouw ontwikkel-, licentie- of SaaS-overeenkomsten nog aansluiten bij de manier waarop je onderneming werkt? Wij kunnen je helpen door de ontwikkel-, licentie- en SaaS-overeenkomsten te beoordelen en in kaart te brengen of de afspraken over intellectueel eigendom nog aansluiten bij de manier waarop jouw onderneming software ontwikkelt en exploiteert.