Wie is eigenaar van de code die je laat bouwen?

Bijna niemand stelt deze vraag bij het tekenen. Vrijwel iedereen stelt hem op het moment dat hij weg wil bij zijn leverancier — en dan is het antwoord niet meer te veranderen. Hieronder wat er geregeld moet zijn, en de drie plekken waar je alsnog vast kunt komen te zitten terwijl het contract in orde lijkt.

De hoofdregel verrast de meeste mensen

Wie software laat maken, is niet automatisch eigenaar van de code. Het auteursrecht ligt in beginsel bij de maker — het bureau of de ontwikkelaar — ook als jij de rekening betaalt. Wil je het zelf hebben, dan moet dat in de opdracht staan. Staat er niets, dan heb je meestal alleen een gebruiksrecht op iets waar jij voor betaald hebt.

Dat is geen valstrik van kwaadwillende bureaus; het is gewoon hoe het auteursrecht werkt. Maar het betekent wel dat je het expliciet moet regelen, en dat het geen onbeleefde vraag is om te stellen.

Wat er in de opdracht moet staan

• Overdracht van rechten — dat de auteursrechten op wat er voor jou gebouwd wordt bij oplevering overgaan, of dat je op zijn minst een onbeperkt, overdraagbaar gebruiksrecht krijgt.
• De broncode zelf — niet alleen het recht erop, maar het bestand. Rechten op code die je niet in handen hebt, zijn een papieren garantie.
• Toegang tot de omgeving — hosting, domein, database, en de accounts van diensten die het systeem gebruikt. Op jouw naam, niet op die van het bureau.
• Je gegevens — dat je je data op verzoek in een gewoon leesbaar formaat krijgt, zonder afkoopsom en zonder dat er iets achterblijft.

Drie plekken waar je alsnog vastzit

Een eigen platform van het bureau. Veel partijen bouwen op hun eigen framework of low-code-platform. Je krijgt dan misschien wel "jouw code", maar die draait alleen op hun fundering, en die fundering is niet van jou. Vraag daarom niet alleen wie eigenaar is, maar ook: kan een andere ontwikkelaar hier morgen mee verder?

Accounts op naam van het bureau. Het contract kan perfect zijn, maar als het domein, de hosting en de mailprovider op hun naam staan, moet je bij elke stap om medewerking vragen. Bij een nette leverancier is dat geen probleem. Bij een conflict is het precies waar het pijn doet.

Geen documentatie en geen sleutel. Code zonder uitleg over hoe je hem draait, is voor een opvolger soms duurder om te doorgronden dan opnieuw te bouwen. Vraag om wat er nodig is om het systeem zelfstandig te kunnen starten.

De vraag die je in het eerste gesprek moet stellen

Niet "is de code van mij" — daar zegt iedereen ja op. Vraag: als we over twee jaar met iemand anders verder willen, wat krijgen we dan precies mee, en op welke techniek draait het? Het antwoord daarop zegt meer dan een alinea in de algemene voorwaarden.

Bij ons is het antwoord: de volledige broncode, de toegang tot alles waar het op draait, en je gegevens in een leesbaar bestand. We bouwen op gangbare open technieken, zodat een andere ontwikkelaar er zonder ons mee verder kan. Dat staat bij de afspraken die hoe dan ook gelden en het is geen verkoopargument maar het uitgangspunt: een klant die kan vertrekken en toch blijft, is de enige soort klant die iets zegt.