Van wie is de code? Eigendom broncode bij maatwerk software

Je hebt een webapplicatie laten bouwen. Het systeem werkt, je team is er blij mee en je bedrijf groeit erdoorheen. Maar dan stel je jezelf de vraag die eigenlijk al bij de start had moeten komen: van wie is die code eigenlijk? Als de leverancier morgen stopt, kun je dan verder? Mag je zelf een ontwikkelaar inhuren om aanpassingen te doen? Het eigendom van de broncode is een van de meest onderschatte onderwerpen bij softwareontwikkeling, en precies waar het later weleens fout gaat.

Eigendom broncode: wat zegt de wet?

In Nederland geldt dat software automatisch auteursrechtelijk beschermd is. De maker, in dit geval de ontwikkelaar of het bureau, is in principe de rechthebbende, tenzij contractueel iets anders is afgesproken. Dat klinkt technisch, maar de praktijk is helder: als jij een softwarebedrijf inhuurt en er staat niets over intellectueel eigendom in het contract, dan behoudt dat bedrijf alle rechten op wat er gebouwd wordt.

Je betaalt de facturen, maar je bezit de code niet. Je hebt hooguit een gebruikslicentie, soms zonder dat je dat weet. En een licentie is iets heel anders dan eigendom.

Licentie versus eigendom: het echte verschil

Een licentie geeft je toestemming om software te gebruiken. Eigendom van de broncode geeft je de vrijheid om ermee te doen wat je wilt. Dat is een fundamenteel verschil.

Met een licentie mag je de software gebruiken zolang de leverancier dat toestaat. De leverancier bepaalt de voorwaarden, de prijs en of hij ooit stopt met ondersteuning. Met eigendom van de broncode kun je zelf aanpassingen laten doorvoeren, van leverancier wisselen, de code in eigen beheer nemen of overdragen aan een andere partij.

Voor groeiende bedrijven is dat verschil cruciaal. Software die bij je bedrijf past, groeit mee. Maar als je afhankelijk bent van één partij die de sleutels beheert, heb je geen fundament, maar een huurcontract. En huurcontracten kunnen opgezegd worden.

Wat moet er in je contract staan?

Zorg dat het contract over softwareontwikkeling minstens deze punten dekt:

Overdracht van intellectueel eigendom. Staat er expliciet in dat de broncode na oplevering eigendom wordt van jou als opdrachtgever? Dan pas heb je zekerheid. Laat je dit open, dan is het aan de leverancier.

Toegang tot de broncode. Zorg dat je altijd toegang hebt tot de repository, ook als de samenwerking stopt. Dit is praktisch gezien minstens zo belangrijk als juridisch eigendom.

Documentatie en overdraagbaarheid. Code zonder documentatie is moeilijk over te dragen aan een nieuwe ontwikkelaar. Spreek af dat de code onderhoudbaar en gedocumenteerd wordt opgeleverd, niet als zwarte doos.

Gebruik van open source componenten. Vrijwel alle moderne software bevat open source bibliotheken. Die vallen onder aparte licenties (MIT, GPL, Apache, enzovoort). Weet welke licenties worden gebruikt en of ze je bedrijfsmodel toelaten, zeker als je commercieel wilt doorontwikkelen of als SaaS-product wilt verkopen. Als je overweegt een eigen SaaS-product te laten bouwen, is dit extra relevant.

Software escrow: wat is het en wanneer heb je het nodig?

Software escrow is een constructie waarbij de broncode bij een onafhankelijke derde partij wordt bewaard, de escrow-agent. Als de leverancier failliet gaat of stopt met ondersteuning, kun jij als opdrachtgever de broncode vrijgeven op basis van vooraf vastgestelde triggervoorwaarden.

Escrow is vooral zinvol als je werkt met een leverancier die het intellectueel eigendom zelf houdt, maar jou wel volledige continuïteit wil garanderen. Het is een vangnet, geen vervanging voor goede contractafspraken. Voor bedrijven die sterk afhankelijk zijn van één systeem, kan escrow het verschil maken tussen een tijdelijke verstoring en een volledige bedrijfscrisis.

Wat als je leverancier stopt?

Dit is het scenario dat niemand wil bedenken, maar iedereen beter wel kan voorbereiden. Je leverancier houdt op te bestaan, stopt het product, of de samenwerking loopt stuk. Wat dan?

Als je eigenaar bent van de broncode en toegang hebt tot de repository, kun je direct verder met een andere ontwikkelaar. Als de code goed gedocumenteerd is, is de overstap vervelend maar beheersbaar. Als je geen eigendom, geen toegang en geen documentatie hebt, ben je afhankelijk van wat er nog te redden valt.

Dat is precies de reden waarom de keuze voor een leverancier verder gaat dan prijs of portfolio. Offertes vergelijken is nuttig, maar vraag ook wat er in het contract staat over IE-rechten, code-eigendom en continuïteit. Wie niet transparant is op dat punt, geeft je al een antwoord.

Hoe Roesware hiermee omgaat

Bij Roesware bouwen we software die echt van jou is. Broncode-eigendom wordt standaard contractueel geregeld: na oplevering ben jij de rechthebbende. We werken met moderne, onderhoudbare technologie en zorgen dat de code leesbaar en overdraagbaar is, niet opgesloten in een eigen systeem waar alleen wij mee overweg kunnen.

We bouwen geen lock-in. In plaats van een afhankelijkheidsrelatie bouwen we een fundament, iets wat jij kunt meenemen, uitbreiden en doorgeven aan wie je wilt. Dat zie je terug in projecten zoals Channelmotive, waar we een volwaardig SaaS-platform hebben gebouwd, of DHK Kozijnen, waar een orderbeheer-integratie precies aansluit op hoe het bedrijf werkt.

Software die groei aanjaagt, begint met zekerheid. Zekerheid over wat je bezit, wat je kunt aanpassen en wat er gebeurt als omstandigheden veranderen. Dat is geen klein lettertje, maar het fundament van een goede samenwerking.

Klaar om het goed te regelen?

Heb je een softwareproject in gedachten en wil je weten hoe je het eigendom van de broncode goed borgt? Of wil je weten of jouw huidige situatie risico’s heeft? Neem contact op, dan denken we even mee, zonder verkooppraat.