Wat gebeurt er met maatwerksoftware als de leverancier stopt?

Als een softwareleverancier stopt, hangt het af van je contract en de eigendomssituatie van de broncode wat er precies gebeurt. In het beste geval heb je de broncode in bezit of toegang via een escrow-regeling, en kun je een nieuwe leverancier inschakelen. Zonder die afspraken loop je het risico dat je applicatie niet meer onderhouden kan worden, kwetsbaarheden niet worden opgelost, en je uiteindelijk gedwongen bent opnieuw te beginnen. Goede contractuele afspraken vooraf voorkomen de meeste problemen.

Wat is leveranciersafhankelijkheid bij maatwerksoftware?

Leveranciersafhankelijkheid bij maatwerksoftware betekent dat je organisatie voor het functioneren, onderhouden of doorontwikkelen van een applicatie volledig afhankelijk is van één specifieke leverancier. Zonder die leverancier kun je de software niet aanpassen, beveiligen of overdragen aan een andere partij.

Dit verschilt wezenlijk van standaardsoftware. Bij een standaardpakket zijn er doorgaans meerdere implementatiepartners en is de broncode eigendom van de softwarefabrikant. Bij maatwerksoftware is de applicatie uniek gebouwd voor jouw organisatie. Dat maakt de relatie met de leverancier intensiever, maar ook kwetsbaarder als die relatie eindigt.

In de zorgsector speelt dit extra sterk. Maatwerksoftware in de zorg is vaak diep verweven met primaire processen: cliëntregistratie, rapportage, planning of financiële verantwoording. Als de leverancier wegvalt, staat niet alleen de IT stil, maar ook de bedrijfsvoering.

Wat zijn de risico's als een softwareleverancier stopt?

Als een softwareleverancier stopt, loop je risico op vier concrete problemen: geen toegang tot de broncode, geen updates of beveiligingspatches, geen technische ondersteuning, en mogelijk verlies van kennis over hoe de applicatie werkt. In het ergste geval wordt de software onbruikbaar zonder dat er een directe vervanger is.

De praktische gevolgen variëren afhankelijk van hoe de samenwerking was ingericht:

• Geen broncode-eigendom: Je kunt geen andere ontwikkelaar inschakelen om de software te onderhouden of door te ontwikkelen.
• Geen documentatie: Zonder technische documentatie is het voor een nieuwe partij bijna onmogelijk om snel grip te krijgen op de applicatie.
• Beveiligingsrisico's: Software die niet meer gepatcht wordt, wordt een kwetsbaarheid in je infrastructuur.
• Operationele stilstand: Als de applicatie kritische processen ondersteunt, kan uitval direct impact hebben op je dienstverlening.

Voor organisaties in de zorg, waar continuïteit van dienstverlening wettelijk verplicht is, zijn dit geen theoretische risico's. Ze zijn reëel en vermijdbaar.

Wie is eigenaar van de broncode van maatwerksoftware?

De eigenaar van de broncode van maatwerksoftware is degene aan wie het auteursrecht toebehoort. Standaard ligt dat bij de ontwikkelaar of het ontwikkelbedrijf, tenzij contractueel anders is vastgelegd. Zonder expliciete eigendomsoverdracht in het contract, bezit de opdrachtgever de broncode niet.

Dit is een veelgemaakte misvatting. Omdat een organisatie de software heeft laten bouwen en betaald, gaan veel mensen ervan uit dat ze ook eigenaar zijn. Juridisch is dat niet automatisch het geval. Het intellectueel eigendom blijft bij de maker, tenzij er een overdracht of licentie is afgesproken.

Er zijn drie gangbare constructies:

1. Volledige eigendomsoverdracht: De opdrachtgever wordt eigenaar van alle broncode na oplevering.
2. Gebruikslicentie: De leverancier blijft eigenaar, maar de opdrachtgever krijgt het recht de software te gebruiken.
3. Broncode-escrow: De broncode wordt bij een derde partij gedeponeerd en vrijgegeven bij bepaalde omstandigheden, zoals faillissement van de leverancier.

Welke constructie het beste past, hangt af van de situatie. Maar zonder schriftelijke afspraken hierover sta je bij een conflict altijd met lege handen.

Hoe bescherm je je organisatie tegen uitval van de leverancier?

Je beschermt je organisatie tegen uitval van de leverancier door drie dingen goed te regelen: duidelijke eigendomsafspraken in het contract, een broncode-escrow voor kritische applicaties, en actuele technische documentatie die bijgehouden wordt gedurende de samenwerking.

Daarnaast helpt het om de kennisafhankelijkheid te beperken. Als alleen de leverancier weet hoe de applicatie werkt, ben je kwetsbaar. Zorg dat technische documentatie, architectuurbeschrijvingen en procesbeschrijvingen altijd beschikbaar zijn voor je eigen organisatie.

Praktische stappen die je nu kunt zetten:

• Controleer je huidige contract op eigendomsbepalingen en licentieafspraken.
• Vraag om toegang tot de broncode of een escrow-regeling als die er niet is.
• Zorg voor up-to-date technische documentatie als onderdeel van de lopende samenwerking.
• Bespreek een exitstrategie met je leverancier, ook als de relatie goed is.

Wat is een broncode-escrow en wanneer is het nodig?

Een broncode-escrow is een regeling waarbij de broncode van een applicatie bij een onafhankelijke derde partij wordt gedeponeerd. Die partij geeft de broncode vrij aan de opdrachtgever als een vooraf bepaalde omstandigheid optreedt, zoals faillissement of het staken van de bedrijfsactiviteiten van de leverancier.

Een escrow is nuttig wanneer de software bedrijfskritisch is en je de broncode niet in eigen bezit hebt. Het is een vangnet, geen vervanging voor goede contractafspraken. De escrow regelt dat je toegang krijgt tot de code, maar het lost niet op dat je daarna nog steeds een partij nodig hebt die de software kan begrijpen en onderhouden.

Voor maatwerksoftware in de zorg, waar applicaties soms tien jaar of langer in gebruik zijn, is een escrow-regeling een verstandige aanvulling op het contract, zeker bij kleinere leveranciers.

Wat moet er in een contract met een softwareleverancier staan?

Een contract met een softwareleverancier moet in ieder geval afspraken bevatten over eigendom van de broncode, toegang tot documentatie, onderhoud en support, een exitregeling, en wat er gebeurt bij faillissement of beëindiging van de samenwerking.

Specifieke onderdelen die je niet mag vergeten:

• Broncode-eigendom of licentie: Wie bezit de code en onder welke voorwaarden mag je die gebruiken of overdragen?
• Documentatieverplichtingen: Is de leverancier verplicht technische documentatie bij te houden en aan jou beschikbaar te stellen?
• SLA en support: Wat zijn de afspraken over beschikbaarheid, responstijden en onderhoud?
• Exitbepaling: Hoe verloopt de overdracht als de samenwerking eindigt, en welke overdrachtsverplichtingen heeft de leverancier?
• Escrow-regeling: Is er een verplichting om de broncode bij een derde te deponeren?

Laat contracten voor maatwerksoftware altijd beoordelen door een jurist met ervaring in IT-recht. De standaardvoorwaarden van een leverancier zijn geschreven in het belang van de leverancier, niet van jouw organisatie.

Hoe verloopt een overdracht van maatwerksoftware naar een nieuwe leverancier?

Een overdracht van maatwerksoftware naar een nieuwe leverancier verloopt in drie fasen: kennisoverdracht door de oude leverancier, analyse en inwerking door de nieuwe leverancier, en een stabiele overgangsperiode waarin beide partijen tijdelijk samenwerken. Hoe soepel dit gaat, hangt sterk af van de kwaliteit van de documentatie en de medewerking van de vertrekkende partij.

In de praktijk zijn dit de stappen:

1. Broncode en documentatie ophalen: Zorg dat je alle broncode, technische documentatie en configuratiebestanden ontvangt.
2. Analyse door de nieuwe leverancier: De nieuwe partij brengt de architectuur en kwaliteit van de code in kaart.
3. Overdracht van omgevingen: Servers, databases en externe koppelingen worden overgezet of opnieuw ingericht.
4. Parallelle periode: Waar mogelijk draaien beide omgevingen tijdelijk naast elkaar om risico te beperken.
5. Formele overdracht: Na validatie neemt de nieuwe leverancier volledig het beheer over.

Een overdracht duurt zelden minder dan een paar weken, en bij complexe applicaties eerder meerdere maanden. Plan dit dus ruim van tevoren en leg de overdrachtsverplichtingen contractueel vast, zodat je niet afhankelijk bent van de goodwill van de vertrekkende leverancier.

Bij Corver Development werken we al meer dan vijftien jaar samen met organisaties in het sociaal domein en de zorg aan maatwerksoftware die écht meebeweegt met de organisatie. We geloven in transparantie: jij hoort altijd eigenaar te zijn van wat we samen bouwen. Benieuwd wat wij voor jouw organisatie kunnen betekenen? Bekijk onze diensten en ontdek hoe wij samenwerken.