Bestaande software nabouwen: mag dat?

Bestaande software nabouwen roept al snel de vraag op of dat eigenlijk wel mag. Het systeem is ooit door een andere partij gebouwd, of het is een pakket waar je een licentie voor hebt. Het korte antwoord: de werking van software nabouwen mag in de regel, de code kopiëren niet. Maar contracten, licenties en de manier waarop je de nabouw aanpakt maken het verschil. In dit artikel zetten we de belangrijkste punten op een rij.

Let op: dit artikel geeft een algemeen beeld en is geen juridisch advies. Twijfel je over jouw situatie, leg je contract dan voor aan een jurist die gespecialiseerd is in IT-recht.

Mag je bestaande software nabouwen?

Ja, bestaande software nabouwen mag in de regel, zolang je de functionaliteit opnieuw bouwt en geen beschermde onderdelen kopieert. Het auteursrecht beschermt de manier waarop software is geschreven, niet het idee of de functie erachter. Een systeem dat orders verwerkt, planningen maakt of offertes berekent, mag dus opnieuw worden gebouwd door een andere partij.

Of het in jouw geval mag, hangt daarnaast af van wat je met de oorspronkelijke bouwer of leverancier hebt afgesproken. Daar zit in de praktijk het grootste verschil tussen situaties.

Wat is het verschil tussen nabouwen en namaken?

Nabouwen is je eigen bestaande systeem opnieuw bouwen, namaken is andermans product kopiëren. Wij bedoelen met slim software nabouwen altijd het eerste: de software waar jouw organisatie al jaren mee werkt, met jouw processen, jouw rekenregels en jouw data, bouwen we opnieuw op moderne techniek. We nemen geen product van een ander over om het zelf te gebruiken of te verkopen.

Dat onderscheid is belangrijk, ook juridisch. Wie zijn eigen werkwijze opnieuw laat bouwen, zit in een heel andere situatie dan wie een bestaand pakket probeert te kopiëren.

Wat is auteursrechtelijk beschermd aan software?

Beschermd is vooral de concrete uitwerking: de broncode, de gecompileerde code en het voorbereidend ontwerpmateriaal. Niet beschermd zijn de ideeën en principes waarop de software is gebaseerd.

De Europese softwarerichtlijn legt dat onderscheid vast, en het Hof van Justitie van de EU heeft in 2012 bevestigd dat de functionaliteit van een programma, de programmeertaal en het formaat van databestanden niet onder het auteursrecht vallen. Wie de werking van een programma bestudeert en die met eigen code opnieuw bouwt, maakt dus geen inbreuk.

In de praktijk betekent dat:

• Wel toegestaan: dezelfde stappen, rekenregels en functies opnieuw bouwen met eigen code.
• Wel toegestaan: het oude systeem gebruiken en observeren om te begrijpen wat het doet, als je er rechtmatig mee werkt.
• Niet toegestaan: broncode kopiëren of overnemen zonder toestemming van de rechthebbende.
• Voorzichtig mee: het letterlijk overnemen van een herkenbaar ontwerp, iconen, handleidingen of teksten. Die kunnen apart beschermd zijn.

Wat staat er in je contract of licentie?

Je contract met de oorspronkelijke bouwer of leverancier bepaalt vaak meer dan de wet. Kijk vooral naar deze punten:

• Wie is eigenaar van de code? Bij maatwerk is soms afgesproken dat de rechten naar jou overgaan. Dan heb je veel ruimte, ook om bestaande code te laten hergebruiken.
• Welke licentie heb je? Bij een gebruikslicentie blijven de rechten bij de leverancier. Je mag de software gebruiken, maar de code niet zomaar aanpassen of overnemen.
• Staat er een verbod op reverse engineering? Het observeren van de werking mag wettelijk, maar sommige contracten bevatten extra afspraken. Laat die beoordelen.
• Zijn er exit-afspraken? Afspraken over het teruggeven van data, broncode in escrow of medewerking bij een overstap maken een nabouw een stuk eenvoudiger.
• Zijn er geheimhoudingsafspraken? Die kunnen beperken welke documentatie je mag delen met een nieuwe partij.

Van wie is de data in het oude systeem?

De data die jouw organisatie in het systeem heeft ingevoerd, is in de regel van jou. Klantgegevens, orders, dossiers en productinformatie mag je meenemen naar een nieuw systeem. Let wel op de vorm: sommige leveranciers maken het lastig om data in een bruikbaar formaat te exporteren, en soms staat in het contract hoe en wanneer je een export kunt opvragen.

Gaat het om persoonsgegevens, dan gelden daarnaast de regels van de AVG. Een nieuwe partij die de data verwerkt, heeft een verwerkersovereenkomst nodig. Hoe je data zorgvuldig overzet, lees je in data migreren naar nieuwe software.

In welke situaties moet je extra opletten?

Een paar situaties vragen meer aandacht dan gemiddeld.

• Je werkt nu met een pakket van een leverancier. Dan bouwen we niet dat pakket na, maar jouw proces. Uiterlijk, naam, teksten en handleidingen van het pakket nemen we niet over.
• Decompileren. Gecompileerde code terugvertalen naar leesbare code mag alleen onder strikte voorwaarden, bijvoorbeeld voor het maken van een koppeling. Voor een nabouw is het zelden nodig.
• Een ontwikkelaar die eigenaar is gebleven. Als de rechten bij de oorspronkelijke bouwer liggen, is een gesprek vaak de snelste route. Veel ontwikkelaars werken mee aan een overdracht. Meer daarover in afhankelijk van één ontwikkelaar.
• Bibliotheken en componenten van derden. Het oude systeem kan onderdelen bevatten met een eigen licentie. Die neem je niet automatisch mee.

Hoe bouw je bestaande software zorgvuldig na?

Je bouwt zorgvuldig na door de werking vast te leggen en die met eigen code opnieuw te bouwen, zonder code over te nemen. Wij werken in deze volgorde:

1. Contract en licentie bekijken. Weten we wat er is afgesproken over eigendom, data en reverse engineering, dan weten we waar de grenzen liggen.
2. De werking beschrijven. We leggen vast wat het systeem doet: schermen, stappen, rekenregels, rapporten. Dat doen we door het te gebruiken en gebruikers te observeren. Zie ook onderzoek en analyse.
3. Eigen ontwerp en eigen code. Op basis van die beschrijving bouwen we een nieuw systeem, met een eigen datamodel en een eigen interface die herkenbaar is maar niet gekopieerd.
4. Data overzetten. Jouw data gaat via een export mee naar het nieuwe systeem.
5. Eigendom vastleggen. We spreken vooraf af dat de nieuwe code en documentatie van jou zijn, zodat je niet opnieuw afhankelijk wordt.

Deze werkwijze is de basis van slim software nabouwen: herkenbaar voor je team, maar volledig nieuw gebouwd. Zo blijft een nabouw ook juridisch overzichtelijk.

Wat betekent dit voor jouw situatie?

Voor de meeste organisaties die hun eigen verouderde systeem willen vervangen, is nabouwen goed mogelijk. Het grootste werk zit niet in juridische drempels, maar in het zorgvuldig vastleggen van wat het systeem doet. Begin met het opzoeken van je contract en het in kaart brengen van wie de rechten heeft. Weet je dat, dan kun je een bewuste keuze maken.

Wil je sparren over het nabouwen van jouw software en wat daarbij komt kijken? Bij strategie en advies helpen we je met de eerste stappen. Neem contact op voor een gesprek.