Wat is een softwareontwikkelingsovereenkomst? Uitleg en gebruik

Wat is een softwareontwikkelingsovereenkomst? Het is het contract waarmee je een ontwikkelaar opdracht geeft om software voor jou te bouwen op basis van jouw specificaties. Anders dan bij kant-en-klare software of een licentie gaat het hier om maatwerk: er ontstaat nieuwe code die speciaal voor jouw doel wordt gemaakt. De overeenkomst legt vast wat er gebouwd wordt, in welke fasen, wanneer het is opgeleverd en goedgekeurd, wat het kost en, cruciaal, wie na oplevering eigenaar wordt van de code.

Het korte antwoord

• Een softwareontwikkelingsovereenkomst is de opdracht tot het bouwen van maatwerksoftware.
• Juridisch is het meestal aanneming van werk (artikel 7:750 BW): een concreet resultaat tegen een prijs.
• De kern is de specificatie: wat moet de software precies kunnen.
• Milestones, acceptatietesten en meerwerk regelen het bouwproces en de betaling.
• Zonder aparte overdracht blijft het auteursrecht bij de ontwikkelaar; overdracht vereist een akte (artikel 2 Auteurswet).

Wat is een softwareontwikkelingsovereenkomst juridisch

Bij maatwerk verbindt de ontwikkelaar zich tot het bouwen van een werkend resultaat tegen een afgesproken prijs. Dat maakt het meestal aanneming van werk in de zin van artikel 7:750 BW. Dat verschilt van een opdracht waarbij alleen een inspanning wordt beloofd: bij aanneming van werk moet er daadwerkelijk iets worden opgeleverd dat aan de afspraken voldoet. Voor jou als opdrachtgever is dat belangrijk, want het geeft je recht op een deugdelijk resultaat en niet alleen op een aantal gewerkte uren.

De praktijk is soms een mengvorm. Werk je in korte iteraties zonder vast eindresultaat, dan lijkt het meer op een opdracht met inspanningsverplichting. Werk je toe naar een omschreven product, dan overheerst het aannemingskarakter. Hoe je het ook inricht, de overeenkomst moet duidelijk maken wat als opgeleverd geldt en wanneer je moet betalen.

De specificatie als hart van het contract

Maatwerk staat of valt met de vraag wat er precies gebouwd moet worden. De functionele en technische specificaties horen daarom als bijlage bij de overeenkomst. Ze beschrijven de functies, de gebruikersrollen, de koppelingen met andere systemen en de eisen aan performance en beveiliging. Hoe scherper de specificatie, hoe kleiner de kans op discussie achteraf over de vraag of iets binnen de opdracht viel.

Milestones, acceptatie en meerwerk

• Milestones. Het project wordt opgeknipt in fasen met deeloplevering en deelbetaling. Zo houd je grip op voortgang en budget.
• Acceptatietest. Bij elke oplevering test je of het resultaat aan de specificatie voldoet. Pas na goedkeuring geldt het als aanvaard.
• Meerwerk. Wat buiten de specificatie valt, is meerwerk. Leg vast hoe meerwerk wordt aangevraagd, geprijsd en goedgekeurd.
• Onderhoud. Wat gebeurt er na oplevering met bugs en updates? Regel garantie en eventueel een onderhoudscontract.

Een praktijkvoorbeeld: een groothandel laat een voorraadsysteem bouwen dat koppelt met de bestaande webshop. De overeenkomst kent drie milestones: inrichting van de database, de koppeling met de webshop en het rapportagedashboard. Per milestone volgt een acceptatietest van twee weken en betaling van een derde van de prijs. Toen de groothandel halverwege een extra rapportage wilde, werd dat als meerwerk apart geoffreerd. Zo bleef het budget beheersbaar en was steeds duidelijk wat af was.

Wie wordt eigenaar van de code

Dit is het punt waarop maatwerkprojecten het vaakst misgaan. Het auteursrecht op software ontstaat bij de maker. Ook al betaal je voor de ontwikkeling, zonder aparte afspraak blijft het auteursrecht bij de ontwikkelaar en krijg jij als rechtmatige gebruiker alleen een gebruiksrecht (artikel 45j Auteurswet). Wil je echt eigenaar worden van de code, bijvoorbeeld om die later door een andere partij te laten doorontwikkelen, dan moet het auteursrecht worden overgedragen. Die overdracht vereist een akte, een ondertekend stuk (artikel 2 Auteurswet).

Regel dit vooraf. Bepaal of je volledige overdracht wilt, een ruime exclusieve licentie, of dat de ontwikkelaar bepaalde generieke onderdelen mag hergebruiken. Vraag daarbij ook naar de broncode en documentatie via een escrow- of overdrachtsafspraak, zodat je niet afhankelijk blijft van één leverancier.

Privacy bij maatwerk

Verwerkt de ontwikkelaar tijdens het bouwen of testen persoonsgegevens uit jouw systemen, bijvoorbeeld bij het overnemen van bestaande data, dan handelt hij als verwerker. Artikel 28 AVG verplicht dan tot een verwerkersovereenkomst met afspraken over beveiliging, testdata, bewaartermijnen en het wissen van gegevens na oplevering. Ook in de gebouwde software zelf moet privacy by design zijn meegenomen als er persoonsgegevens door heen gaan.

Eerlijke aanbeveling

Gaat het om een klein bouwklusje bij een ontwikkelaar die je vertrouwt, met een beperkt budget en zonder dat de code cruciaal is voor je bedrijf, dan kun je met een korte, heldere opdrachtbevestiging vooruit. Een jurist is dan niet nodig. Zodra de software echter belangrijk wordt voor je bedrijfsvoering, zodra de bedragen oplopen of zodra je later van leverancier wilt kunnen wisselen, is de overdracht van het auteursrecht het belangrijkste punt om goed te regelen. Ontwikkelaars leveren standaard alleen een gebruiksrecht en houden de code zelf. Laat de overeenkomst dan opstellen of toetsen, vooral op de specificatie, de acceptatie en de eigendom van de code.

Meer weten? Bekijk de softwareontwikkelingsovereenkomst, lees wat er precies in hoort bij een softwareontwikkelingsovereenkomst opstellen en wat het kost om er een te laten opstellen.

Veelgestelde vragen