Wie eigenaar wordt van de broncode van je product is een van de belangrijkste contractuele vragen die founders het vaakst overslaan. In het begin van een samenwerking met een ontwikkelpartner draait alles om het product en de planning, en raakt de vraag wie straks eigenaar wordt van de code al snel op de achtergrond. Juist die vraag bepaalt of jij later vrij bent om te doen wat je wilt met je eigen product, of dat je afhankelijk blijft van een enkele partij. Dit sluit aan op het bredere stappenplan dat ik beschrijf in van idee naar succesvolle software.
Waarom eigendom van de code niet vanzelfsprekend bij jou ligt
In veel landen, waaronder Nederland, ligt het auteursrecht op software in eerste instantie bij de maker, niet automatisch bij de opdrachtgever. Dat betekent dat je expliciet in het contract moet vastleggen dat de broncode en alle bijbehorende rechten overgaan naar jouw bedrijf zodra je hebt betaald. Zonder deze afspraak kan een ontwikkelpartner formeel rechten op je product behouden, ook als jij het volledige bedrag hebt betaald.
Wat vendor lock-in is en hoe je het voorkomt
Vendor lock-in ontstaat wanneer je zo afhankelijk wordt van een ontwikkelpartner dat overstappen naar een andere partij praktisch onmogelijk of extreem kostbaar wordt, bijvoorbeeld doordat alleen zij de code begrijpen of doordat je geen toegang hebt tot de broncode zelf. Je voorkomt dit door van meet af aan toegang tot de broncode te eisen, bijvoorbeeld via een gedeelde, actuele repository, in plaats van pas bij het einde van het project.
Wat een goed contract hierover regelt
Een goed contract legt minstens drie dingen vast, wie eigenaar wordt van de broncode en op welk moment, of je doorlopende toegang hebt tot de meest actuele versie van de code, en wat er gebeurt met documentatie en technische kennis als de samenwerking eindigt. Deze afspraken voorkomen discussie op het moment dat het er echt toe doet, namelijk wanneer je wilt overstappen of uitbreiden.
Wat er gebeurt als je van ontwikkelpartner wisselt
Zelfs met een goed geregeld eigendom kan overstappen naar een nieuwe partner lastig zijn als niemand anders de code en de gemaakte keuzes begrijpt. Zorg daarom dat je ontwikkelpartner onderweg documentatie bijhoudt over belangrijke technische beslissingen, zodat een nieuwe partij niet bij nul hoeft te beginnen.
De rol van software escrow
Voor start-ups die extra zekerheid willen, bestaat er een tussenoplossing genaamd software escrow. Daarbij wordt een kopie van de broncode bij een onafhankelijke derde partij bewaard, die deze vrijgeeft als je ontwikkelpartner onverwacht wegvalt, bijvoorbeeld door een faillissement. Ik leg deze constructie verder uit in software escrow.
Een praktisch startpunt
Vraag bij je volgende gesprek met een ontwikkelpartner expliciet naar het moment waarop broncode-eigendom overgaat, en vraag om doorlopende toegang tot een gedeelde repository vanaf het begin van het project, niet pas bij oplevering.
Waarom dit ook in je gesprek met een nieuwe partner terugkomt
Deze vraag over eigendom van de broncode hoort thuis in het rijtje vragen dat ik elke founder aanraad te stellen voordat ze een ontwikkelpartner kiezen. Ik heb ze allemaal gebundeld in 7 vragen voordat je een ontwikkelpartner kiest.
Wat dit betekent voor de waarde van je bedrijf
Zeker als je ooit investeerders wilt aantrekken of je bedrijf wilt verkopen, is duidelijk vastgelegd eigendom van de broncode essentieel. Onduidelijkheid hierover is een van de eerste dingen die tijdens due diligence naar boven komt, en kan de waardering van je bedrijf direct beinvloeden.
Wat je moet vastleggen naast het eigendom zelf
Naast wie eigenaar wordt van de code, is het minstens zo belangrijk vast te leggen wat er gebeurt met eventuele herbruikbare onderdelen die een ontwikkelpartner ook bij andere klanten inzet. Onduidelijkheid hierover leidt soms tot verrassingen als je later een concurrent tegenkomt met een verrassend vergelijkbaar stuk techniek.
Wat er verandert als je een externe developer aanneemt
Zodra je overstapt van een bureau naar een zelfstandige developer, verandert vaak ook wie standaard eigenaar wordt van de code. Regel dit expliciet in de overeenkomst, want de standaardregels rond auteursrecht werken anders uit bij een zelfstandig professional dan bij een bureau.
Regel dit voordat je het nodig hebt
De vraag wie eigenaar wordt van je broncode voelt in het begin van een samenwerking als een formaliteit, maar is precies het soort afspraak dat je achteraf niet meer kunt repareren als je het vooraf hebt overgeslagen. Leg deze afspraken altijd schriftelijk vast voordat je start, ook als de samenwerking op basis van vertrouwen begint. Leg deze afspraken bij voorkeur vast voordat de eerste regel code wordt geschreven, in plaats van halverwege het traject. Controleer deze afspraken ook nog eens goed als je van ontwikkelpartner wisselt, want stilzwijgende aannames uit een eerdere samenwerking gelden niet automatisch bij de volgende. Een heldere afspraak hierover geeft je ook meer onderhandelingsruimte mocht je later besluiten je product aan een derde partij te verkopen. Wil je hierover sparren? Plan een vrijblijvende sparsessie of download het volledige handboek voor meer praktijkvoorbeelden.