MKB Juristen stelt juridische documenten op maat op
Het beste is om belangrijke contracten, algemene voorwaarden en andere juridische documenten niet zelf te knutselen of te kopiëren. Wij helpen ondernemers budgetvriendelijk met juridisch maatwerk, vooraf duidelijke kosten en praktische uitleg.
- Contracten, voorwaarden en juridische documenten op maat
- Budgetvriendelijk en vooraf duidelijk over de kosten
- Gratis adviesgesprek of vrijblijvend een offerte aanvragen
Algemene voorwaarden softwarebedrijf opstellen betekent: de spelregels vastleggen rond ontwikkeling, oplevering, acceptatie, intellectueel eigendom, onderhoud, meerwerk, aansprakelijkheid en betaling. Anders dan bij een SaaS-dienst draait het hier om het bouwproces en de eigendom van de code — niet om toegang tot een online platform. Hieronder staat per onderdeel wat erin hoort, welke wettelijke regels gelden en waar softwareontwikkelaars het vaakst de mist in gaan.
Het korte antwoord
- IE en licentie: regel wie de broncoderechten krijgt en onder welke licentie de klant de software gebruikt.
- Ontwikkeling en oplevering: werkwijze, mijlpalen, opleverdata en de definitie van “af”.
- Acceptatie: testtermijn, criteria en wanneer software als geaccepteerd geldt.
- Meerwerk: hoe wensen buiten scope worden geregeld en gefactureerd.
- Aansprakelijkheid en SLA: plafond, uitgesloten schade, onderhoud en reactietijden.
- Betaling: facturatie per fase, termijnen en opschortingsrecht.
Intellectueel eigendom en licentie
Dit is het belangrijkste en meest onderschatte onderdeel. Wie de broncode maakt, heeft in beginsel het auteursrecht (art. 1 Auteurswet). Voor een ontwikkelaar betekent dit dat je zonder afwijkende afspraak eigenaar blijft van de code — ook als de klant ervoor heeft betaald.
Kies bewust tussen twee modellen:
- Licentie. Je houdt de IE en verleent de klant een gebruiksrecht. Voordeel: je kunt (delen van) de code hergebruiken voor andere klanten. Leg de reikwijdte vast: exclusief of niet, overdraagbaar of niet, voor welke gebruikers.
- Overdracht. De klant wil de volledige rechten. Dat kan, maar overdracht van auteursrecht vereist een akte (art. 2 lid 2 Auteurswet) — een enkele zin in de voorwaarden volstaat niet altijd. Reken hiervoor doorgaans een hogere prijs.
Vergeet open-source componenten niet: benoem dat de software libraries van derden kan bevatten met eigen licentievoorwaarden.
Ontwikkeling, oplevering en acceptatie
Softwareontwikkeling is een proces met momenten waarop iets “af” is. Zonder acceptatieregeling blijft onduidelijk wanneer je hebt geleverd — en dus wanneer je mag factureren. Leg vast:
- Werkwijze en mijlpalen. Fasegewijze oplevering (bijvoorbeeld per module of sprint) met duidelijke opleverdata.
- Acceptatietest. De klant test binnen een vaste termijn (bijvoorbeeld 10 werkdagen) tegen vooraf afgesproken criteria.
- Fictieve acceptatie. Reageert de klant niet binnen de termijn, of neemt hij de software in productief gebruik, dan geldt die als geaccepteerd. Zonder deze clausule blijft een klant eeuwig “nog niet tevreden”.
- Herstel van gebreken. Alleen tekortkomingen die de afgesproken functionaliteit raken, blokkeren acceptatie — cosmetische puntjes niet.
Meerwerk
Bijna elk softwareproject groeit tijdens de bouw. De klant bedenkt nieuwe wensen, de scope schuift. Zonder meerwerkbepaling voer je dat gratis uit of ontstaat er ruzie over de factuur. Regel daarom:
- Dat werk buiten de oorspronkelijke opdracht als meerwerk geldt.
- Dat meerwerk vooraf schriftelijk (of per e-mail) wordt bevestigd.
- Tegen welk uurtarief of welke methode meerwerk wordt berekend.
- Dat meerwerk de oorspronkelijke opleverdata kan verschuiven.
Aansprakelijkheid en garantie
Software bevat fouten — dat is een technisch gegeven, geen wanprestatie. Toch kan een bug schade veroorzaken bij de klant. Begrens dat risico:
- Plafond. Beperk de aansprakelijkheid tot bijvoorbeeld de opdrachtwaarde of de factuurwaarde over de laatste periode.
- Gevolgschade uitsluiten. Sluit indirecte schade uit: gederfde winst, gemiste omzet, dataverlies, reputatieschade.
- Garantietermijn. Bied gedurende een afgebakende periode kosteloos herstel van gebreken die binnen de afgesproken functionaliteit vallen.
- Grenzen. Let op: aansprakelijkheid voor opzet of bewuste roekeloosheid kun je niet uitsluiten (art. 6:233 BW).
Onderhoud, SLA en betaling
Levert je bedrijf ook onderhoud, dan hoort een SLA-kader in de voorwaarden of in een aparte onderhoudsovereenkomst:
- Reactietijden per prioriteit (bijvoorbeeld kritieke storing binnen 4 uur).
- Beschikbaarheid en onderhoudsvensters.
- Wat wél en niet onder onderhoud valt (updates versus nieuwe functionaliteit).
- Kosten: vast onderhoudsabonnement of per uur.
Voor betaling: factureer per fase of mijlpaal, hanteer een betaaltermijn (bijvoorbeeld 14 dagen), en neem een opschortingsrecht op — bij niet-betaling mag je het werk stilleggen en de toegang tot geleverde software beperken tot betaling volgt.
Voorbeeld uit de praktijk
Een ontwikkelaar bouwt een maatwerk-planningssysteem voor een installatiebedrijf. Halverwege wil de klant koppelingen met twee externe systemen erbij. Omdat de voorwaarden een meerwerkclausule bevatten, wordt dit apart geoffreerd en gefactureerd, en schuift de opleverdatum mee. Bij oplevering test de klant 10 werkdagen; na akkoord — of bij ingebruikname — geldt het systeem als geaccepteerd en volgt de slotfactuur. De IE blijft bij de ontwikkelaar; de klant krijgt een gebruikslicentie. Eén set voorwaarden voorkomt hier drie mogelijke conflicten.
Eerlijke aanbeveling
Stem de voorwaarden af op wat je bouwt. Bouw je maatwerk, dan zijn IE-, acceptatie- en meerwerkbepalingen het hart — kopieer geen SaaS-voorwaarden die over abonnementen gaan. De grootste risico’s zitten in onbegrensde aansprakelijkheid en een ontbrekende acceptatieregeling.
Wanneer heb je géén jurist nodig? Voor een eenvoudige, terugkerende opdracht met een laag risico kun je met een degelijk model uit de voeten, mits je het aanpast aan je eigen werkwijze en aantoonbaar meestuurt met de offerte. Zodra opdrachten groter worden, je code hergebruikt of klanten zelf voorwaarden opleggen, is juridische toetsing verstandig — één slecht geformuleerd IE- of aansprakelijkheidsbeding kan duur uitpakken.
Verder lezen en regelen: wat zijn algemene voorwaarden softwarebedrijf, laten opstellen: kosten en proces en de algemene voorwaarden softwarebedrijf.
Veelgestelde vragen
Bepalingen over intellectueel eigendom en licentie op de broncode, ontwikkeling en oplevering, acceptatie, meerwerk, onderhoud en SLA, aansprakelijkheid met een plafond, en betaling per fase. Bij maatwerk zijn IE-, acceptatie- en meerwerkbepalingen het belangrijkst.
Zonder afwijkende afspraak houdt de ontwikkelaar het auteursrecht (art. 1 Auteurswet), ook als de klant betaalt. Kies bewust: licentie (jij houdt de IE, klant krijgt gebruiksrecht) of overdracht (klant krijgt alle rechten via een akte, art. 2 lid 2 Auteurswet). Leg de keuze vast in de voorwaarden.
Een regeling die bepaalt hoe en binnen welke termijn de klant de software test en wanneer die als geaccepteerd geldt. Neem een fictieve-acceptatieclausule op: reageert de klant niet binnen de termijn of neemt hij de software in gebruik, dan is deze geaccepteerd. Anders kun je nooit definitief opleveren en factureren.
Bepaal dat wensen buiten de oorspronkelijke opdracht als meerwerk gelden, dat meerwerk vooraf schriftelijk wordt bevestigd, tegen welk tarief het wordt berekend en dat het de opleverdata kan verschuiven. Zonder deze clausule voer je scope-uitbreidingen feitelijk gratis uit.
Beperk de aansprakelijkheid tot bijvoorbeeld de opdrachtwaarde, sluit indirecte schade uit (gederfde winst, dataverlies) en bied een garantietermijn voor kosteloos herstel van gebreken. Let op: aansprakelijkheid voor opzet of bewuste roekeloosheid kun je niet uitsluiten (art. 6:233 BW).
Als je onderhoud levert, wel. Neem reactietijden per prioriteit, beschikbaarheid, onderhoudsvensters en de scope (updates versus nieuwe functionaliteit) op. Dat kan in de voorwaarden zelf of in een aparte onderhoudsovereenkomst waarnaar de voorwaarden verwijzen.
Nee. SaaS-voorwaarden gaan over toegang tot een bestaande dienst (abonnement, uptime, opzegging) en missen de kern van ontwikkelwerk: broncode-eigendom, acceptatie en meerwerk. Voor maatwerk heb je voorwaarden nodig die op het bouwproces zijn toegesneden.
