Wie is de eigenaar van de code? Alles over auteursrecht en broncode bij softwareontwikkeling.

1. De “auteursrecht-paradox”: de factuur betalen is geen eigendomsoverdracht

De meest hardnekkige mythe is dat de betaling van de eindfactuur automatisch betekent dat de klant eigenaar wordt van de software.

De wet is hier onverbiddelijk in: het auteursrecht ontstaat bij de maker (het agency of de freelance developer). Het feit dat een klant betaalt voor de ontwikkeling, verandert daar niets aan. Zonder een contract waarin de auteursrechten expliciet worden overgedragen, blijft de intellectuele eigendom voor 100% bij de bouwer.

Wat heeft de klant dan wel? Meestal impliceert de betaling enkel een gebruikslicentie. Je mag de software gebruiken voor het doel waarvoor hij gemaakt is. Maar mag je de code aanpassen? Doorverkopen? Of meenemen naar een andere IT-partner? Zonder die schriftelijke overdracht is het antwoord vaak “nee”.

2. De gouden kooi: eigendom versus bezit van de broncode

Zelfs als je juridisch gezien de eigenaar bent, kan je business nog steeds gegijzeld worden. Dit fenomeen heet vendor lock-in, een buzzword, maar in de praktijk is dit een technische wurggreep. 

Vendor lock-in betekent dat je zo afhankelijk bent van één leverancier, dat overstappen naar een concurrent praktisch onmogelijk is. Bij maatwerksoftware ontstaat dit vaak door een gebrek aan toegang tot de broncode (source code).

Vaak levert een developer enkel de objectcode. Dit is de gecompileerde reeks nullen en enen die de computer begrijpt. Je software werkt daarmee wel, maar geen enkele mens kan dit lezen of aanpassen. De broncode daarentegen is de leesbare blauwdruk (in PHP, Java, Python, etc.). Heb je die niet? Dan moet je voor elke bugfix of update terug naar je oorspronkelijk agency. Zij kunnen de prijs dicteren, want een andere partner kan niets met alleen de objectcode.

De oplossing is simpelweg een exit-proof contract. Je voorkomt deze gijzeling door vooraf duidelijke afspraken te maken. Een goed IT-contract bevat specifieke clausules over de feitelijke oplevering:

• Definitie van oplevering: je legt vast dat oplevering niet alleen betekent dat de software werkt, maar dat ook de volledige, leesbare broncode en de technische documentatie zijn overhandigd.
• Het moment van overdracht: spreek af wanneer je de code krijgt. Is dat na elke sprint? Aan het einde van het project? Of pas na betaling van de laatste factuur?
• Toegankelijkheid: zorg dat je als klant toegang krijgt tot de repository (zoals GitHub of GitLab), zodat je zeker weet dat je altijd de laatste versie hebt.

3. De nuance voor agencies: maatwerk vs. background IP

Wij treden vaak op voor agencies (en zijn legal partner van FeWeb). Voor hen is de eis van een klant “ik wil alle rechten” vaak onmogelijk in te willigen. Een modern agency schrijft bijna nooit 100% nieuwe code from scratch. Ze bouwen op hun eigen fundering: bibliotheken, frameworks en standaardmodules die ze over jaren hebben ontwikkeld. Dit noemen we Background IP of standaardprogrammatuur.

Als een agency de eigendom van deze code zou overdragen aan Klant A, mogen ze die code juridisch gezien niet meer gebruiken voor Klant B. Dat zou het einde van hun businessmodel betekenen. Tegelijkertijd wil Klant A niet met een lege doos achterblijven als hij ooit weg wil bij het agency.

De oplossing is een hybride licentiemodel, dit wil zeggen dat je contract een strikt onderscheid maakt tussen twee stromen code, met elk hun eigen juridisch regime:

• Foreground IP (maatwerk): dit is de unieke code, logica en “look & feel” die specifiek voor de klant is ontwikkeld.

Juridische status: Hier draag je als agency de volledige intellectuele eigendom over aan de klant. De klant wordt eigenaar en mag ermee doen wat hij wil.

• Background IP (de toolbox): dit zijn de generieke modules van het agency (bijv. een CMS-kern, een authenticatie-module, API-koppelingen).
• • • Juridische status: het agency blijft eigenaar.
    • De cruciale licentie: de klant krijgt hierop een niet-exclusieve licentie.

Let op: Een “standaard licentie” is hier niet genoeg voor de klant. Om een vendor lock-in te vermijden, moet deze licentie aan zeer specifieke voorwaarden voldoen. In het contract moet staan dat deze licentie:

• • • Wereldwijd, eeuwigdurend en onopzegbaar is (zodat het agency de stekker er niet uit kan trekken).
    • Het recht geeft om de software te gebruiken én te laten onderhouden door derden (zodat een andere IT-partner de code mag zien en bewerken in functie van de klant).
    • Overdraagbaar is (zodat de licentie meegaat als de klant zijn bedrijf verkoopt).

Alleen met deze “verzwaarde” licentie is de klant veilig, zonder dat het agency zijn kroonjuwelen weggeeft.

4. De AI-revolutie: wie is de auteur van de “Prompt-code”?

Tegenwoordig wordt een aanzienlijk deel van de broncode gegenereerd door AI-tools zoals GitHub, Copilot of ChatGPT. Dit zorgt voor een juridische aardbeving.

• Geen mens, geen auteursrecht
  Volgens de huidige Belgische en Europese wetgeving (Boek XI WER) kan enkel een menselijke creatie beschermd worden door het auteursrecht. Als software voor 100% door AI is gegenereerd zonder substantiële menselijke tussenkomst, dan rust er simpelweg geen auteursrecht op.
• Het gevaar
  Als de code niet beschermd is door auteursrecht, kan iedereen (ook je concurrent) die code in theorie kopiëren zonder dat je daar juridisch veel tegen kan doen.
• De menselijke touch
  Om eigenaar te worden, moet er sprake zijn van “creatieve keuzes” door de developer. Het schrijven van een complexe architectuur of het specifiek verfijnen van AI-output telt wél. Maar wie bewijst welk deel door een mens en welk deel door de machine is geschreven?