Licentieovereenkomst software: voorbeelden, valkuilen en tips
Als softwareleverancier hulp nodig bij het opstellen of controleren van een licentieovereenkomst voor software? Neem gerust contact met ons op.
Als softwareleverancier hulp nodig bij het opstellen of controleren van een licentieovereenkomst voor software? Neem gerust contact met ons op.
Ontwikkel je software of bied je softwareoplossingen aan? Dan is het cruciaal om goed vast te leggen wie wat mag en onder welke voorwaarden. Software is geen tastbaar product dat je overdraagt, maar intellectueel eigendom waarvoor je gebruiksrechten verleent. Die rechten leg je vast in een juridische constructie: de licentieovereenkomst software.
Als leverancier behoud jij de controle over je software. De klant krijgt toegang, maar alleen onder voorwaarden die jij bepaalt. Denk aan gebruiksduur, aantal gebruikers, supportafspraken en beperkingen op hergebruik of doorverkoop. Met een duidelijke licentie voorkom je discussies, versterk je je juridische positie én bescherm je je verdienmodel.
In deze gids vind je de juridische, commerciële en operationele basis van een solide softwarelicentie, speciaal geschreven voor (SaaS-)leveranciers die hun producten én belangen professioneel willen afdekken.
Als je software ontwikkelt, behoud je in principe altijd het intellectuele eigendom. Wat je aan je klant aanbiedt, is geen eigendomsoverdracht, maar een tijdelijk of beperkt gebruiksrecht, vastgelegd in een licentieovereenkomst software.
Dat onderscheid is belangrijk. Want wie eigenaar blijft van de software, behoudt controle over hoe die software gebruikt mag worden, door wie, en onder welke voorwaarden. Een goede licentieovereenkomst zorgt ervoor dat jij als leverancier juridisch beschermd bent, maar ook commercieel flexibel blijft. Wil je het gebruik beperken tot één organisatie? Of net schaalbaar maken met meerdere eindgebruikers? Moet de licentie tijdelijk zijn, of juist doorlopend met jaarlijkse vernieuwing? Het zijn allemaal strategische keuzes die je contractueel borgt.
Daarnaast kun je in de licentieovereenkomst duidelijk vastleggen wat níét is toegestaan: herdistributie, reverse engineering, overdracht aan derden. Zonder zulke bepalingen is je software kwetsbaar voor misbruik of onbedoelde verspreiding.
Een licentie is dus geen detail achterin je offerte. Het is de juridische verankering van je hele verdienmodel. Zeker in SaaS-constructies of bij maatwerkoplossingen waarin broncode en knowhow samenkomen, is een heldere licentieovereenkomst essentieel.
Er is een wereld van verschil tussen kant-en-klare software en maatwerk.
Als softwareleverancier heb je meerdere mogelijkheden om je software aan te bieden, elk met hun eigen juridische, commerciële en technische implicaties. De keuze voor een bepaald type licentie is geen puur juridische beslissing, maar raakt aan je verdienmodel, positionering en relatie met klanten. Hieronder een overzicht van de meest voorkomende licentievormen – met de kanttekening dat mengvormen steeds vaker voorkomen.
Met een perpetuele licentie krijgt de klant een onbeperkt gebruiksrecht: geen tijdslimiet, geen jaarlijkse hernieuwing. Maar ‘levenslang gebruik’ betekent niet automatisch ‘volledige vrijheid’. In de licentieovereenkomst kun je duidelijke beperkingen opnemen over bijvoorbeeld het aantal gebruikers, installaties of updates. Perpetuele licenties worden steeds minder populair in de SaaS-wereld, maar zijn nog steeds relevant bij on-premise software of sectoren waar langetermijnzekerheid belangrijk is.
Hierbij geef je gebruiksrecht voor een bepaalde periode, vaak op maand- of jaarbasis. Dit licentiemodel sluit goed aan bij SaaS-diensten, omdat het terugkerende inkomsten genereert en je als leverancier meer flexibiliteit geeft om voorwaarden aan te passen. Denk aan automatische verlengingen, jaarlijkse indexatie van prijzen of gefaseerde toegang tot functionaliteiten. Let op: communiceer helder wat er gebeurt bij opzegging of niet-betaling.
Open source betekent níet dat er geen juridische structuur nodig is. Integendeel: veelgebruikte open source licenties zoals de MIT-licentie, de GPL of de Apache License bevatten strikte voorwaarden. Soms moet je aangepaste broncode weer vrijgeven (copyleft), in andere gevallen volstaat een vermelding. Als je als leverancier eigen software bouwt op open source componenten, is het essentieel om te weten welke verplichtingen je overneemt – en hoe je dat contractueel borgt richting je eindklant.
Soms kies je er als leverancier voor om (een deel van) je software gratis aan te bieden – bijvoorbeeld als instapmodel of voor niet-commercieel gebruik. Ook dan blijft het auteursrecht volledig bij jou. Je kunt in een licentieovereenkomst software precies afbakenen wat wel en niet mag: commercieel hergebruik, aanpassingen, integratie met andere systemen. En je behoudt de mogelijkheid om het gebruik op termijn om te zetten in een betaalde licentie.
Een sterke licentieovereenkomst software bevat bepalingen over:
Een goed contract voorkomt niet alleen conflicten, maar ondersteunt je businessmodel.
Voor softwareleveranciers zit de waarde van een goede licentieovereenkomst software niet alleen in de intellectuele eigendomsrechten, maar ook in de operationele afspraken die je maakt. Zeker bij complexe software is het belangrijk om vast te leggen wat klanten mogen verwachten – én wat jij verplicht bent te leveren.
Acceptatietests zijn essentieel bij oplevering. Wanneer is de software ‘af’? Wie beoordeelt dat? En wat als de klant onterecht weigert goed te keuren? Door heldere acceptatiecriteria en een procedure voor herstelrondes vast te leggen, voorkom je eindeloze discussie na oplevering.
Onderhoud gaat verder dan een paar updates. Wat valt onder regulier onderhoud? Zijn upgrades inbegrepen? En voor hoelang bied je ondersteuning op oudere versies? Door dit vooraf af te bakenen, houd je de regie over je ontwikkelagenda én voorkom je claims.
Support is vaak het eerste contactpunt na livegang. Leg in SLA’s vast welke responstijden gelden, hoe escalatie werkt en wat ‘kritieke storingen’ zijn. Zo manage je verwachtingen én kun je je dienstverlening opschalen op je eigen voorwaarden.
Is dit soort operationele informatie niet geregeld in de licentieovereenkomst software? Dan ontstaat onduidelijkheid zodra de eerste bug, storing of mismatch in verwachtingen zich aandient.
Als softwareleverancier houd je in de regel de source code in eigen beheer. Je levert de software uit in object code – uitvoerbaar voor de klant, maar niet leesbaar of aanpasbaar. Dat geeft jou controle over je product én je intellectuele eigendom. Maar voor veel klanten is dat ook een kwetsbaarheid. Wat gebeurt er als jij je verplichtingen niet meer kunt nakomen? Denk aan faillissement, contractbreuk of een verkoop van je bedrijf.
Om die onzekerheid te ondervangen, kun je een escrow-regeling aanbieden. Daarbij wordt de broncode veilig opgeslagen bij een onafhankelijke derde partij. In de licentieovereenkomst software leg je vast in welke gevallen die code vrijgegeven mag worden – bijvoorbeeld bij langdurige supportuitval of beëindiging van je bedrijfsactiviteiten.
Voor jou als leverancier is escrow geen zwaktebod, maar een professioneel signaal richting klanten: je denkt mee over risicobeheersing, zonder je IP los te laten. Kies je voor escrow, zorg dan dat je ook helder afbakent wat er precies wordt gedeponeerd (broncode, documentatie, build-instructies) en hoe vaak dit wordt geüpdatet.
Als softwareleverancier sta je soms voor de keuze: draag ik het eigendom van de software over, of verleen ik een licentie? Juridisch en strategisch is het verschil groot.
Bij een verkoop draag je het auteursrecht volledig over. De koper wordt dan eigenaar van de broncode en mag de software zelfstandig doorontwikkelen of hergebruiken – vaak buiten jouw controle om. Dat kan een eenmalige opbrengst opleveren, maar je verliest blijvend grip op je product.
Met een licentie blijf jij eigenaar van de software en geef je alleen gebruiksrechten onder jouw voorwaarden. Dit model biedt:
Kortom: met een goed ingerichte licentieovereenkomst software bouw je ook een schaalbaar en controleerbaar verdienmodel.
Deze checklist helpt je om niets over het hoofd te zien:
Bij verkoop draag je het volledige auteursrecht over. Bij een licentie geef je alleen gebruiksrechten. Met een licentie houd je controle over je software, updates en verdienmodel.
Nee, dat is niet verplicht. Wel komt het bij maatwerk vaker voor dat klanten hierom vragen. Let op: een exclusieve licentie moet volgens de Auteurswet altijd via een akte worden vastgelegd.
Zorg dat je in de licentieovereenkomst expliciet verbiedt wat niet mag: herdistributie, reverse engineering, sublicentie etc. En zorg voor handhaafbare clausules bij schending.
Als je software open source onderdelen bevat, moet je transparant zijn over de gebruikte licenties (bijv. MIT, GPL). Vermeld dit expliciet en zorg dat jouw commerciële licentie daarmee verenigbaar is.
Lees hier meer over hoe je het best kunt omgaan met (open source) licenties die kleven aan dependencies.
Leg helder vast welke servicelevels je aanbiedt: responstijden, bereikbaarheid, escalatieprocedures. Dit voorkomt discussie én geeft structuur aan je dienstverlening.
Om vertrouwen te wekken bij klanten die afhankelijk zijn van jouw software. Je behoudt het auteursrecht, maar toont aan dat je verantwoordelijkheid neemt voor continuïteit bij uitval.
Dat hangt af van je softwaretype. Per gebruiker, per maand, per feature of een combinatie. De licentieovereenkomst biedt ruimte om dit flexibel te structureren – zolang het goed wordt vastgelegd.
Regel in de overeenkomst dat de klant het gebruik moet staken, software moet verwijderen, en eventueel verklaringen van verwijdering moet overleggen. Bij SaaS kun je toegang automatisch blokkeren.
We zorgen dat jouw rechten als leverancier juridisch stevig verankerd zijn én passen de overeenkomst aan op jouw verdienmodel. Neem gerust contact met ons op voor een vrijblijvende kennismaking.
Co-founder & Senior Legal Counsel
We zijn gevestigd op de Vijzelstraat 68 (1017 HL) in het mooie Amsterdam en sinds 2018 ingeschreven in het register van de Kamer van Koophandel onder nummer: 71533230.
Ons BTW-nummer: NL858752530B01.
Vijzelstraat 68
1017 HL, Amsterdam
KvK: 71533230
BTW-nummer: NL858752530B01
Hester is een van de oprichters van Spaans&Spaans en werkt als General Legal Consultant. Ze heeft meerdere masters in het recht afgerond aan de Universiteit van Amsterdam en het voorrecht gehad een half jaar aan de University of Hong Kong te mogen studeren. Gefrustreerd over de stoffige juridische wereld, besloot ze destijds het heft in eigen hand te nemen en als ondernemer te starten.
Inmiddels werkt ze al zo’n 5 jaar bij Spaans&Spaans en heeft ze honderden ondernemers mogen bijstaan met vraagstukken op het snijvlak van IT en recht.
Haar passie voor tech (en met name web3!) is van grote waarde bij het ‘vertalen’ van juridische regelgeving op het gebied van ICT/internet-en privacyrecht naar de dagelijkse technische realiteit. Klanten omschrijven haar als doortastend, vakkundig en pragmatisch. Om haar kennis op peil te houden is ze o.a. lid van de Vereniging voor Auteursrecht.
Lucia is mede-oprichter van Spaans&Spaans en werkt gedreven samen met het team aan het leveren van onze juridische diensten op top niveau.
Ze is enorm gemotiveerd en een perfectioniste (soms, oké, dikwijls, op het irritante af) die alles tot in de puntjes geregeld wil zien. Haar passie voor het recht kwam al naar voren tijdens haar studietijd in Amsterdam, waar ze ervoor koos om twee juridische masters te volgen. Het liefst controleert ze alle juridische stukken en correspondentie die dagelijks bij Spaans&Spaans de deur uitgaan meerdere malen, zodat de cliënt er zeker van kan zijn dat alles perfect geregeld is.
Verder is ze een groot fan van koffie, reist ze graag en is ze actief als gitariste (ja, echt).