kort antwoord
Als je een webapp laat bouwen, word je niet automatisch eigenaar van de broncode: het auteursrecht ligt bij de maker. Wil je de code bezitten, leg dan een schriftelijke overdracht vast; anders heb je hooguit een gebruiksrecht.
Laat je een webapp op maat bouwen, dan word je niet vanzelf eigenaar van de broncode. Volgens de Auteurswet ligt het auteursrecht bij de maker. Wil je de code zelf bezitten, dan moet dat in een schriftelijke overdracht staan. Anders heb je hooguit een gebruiksrecht. Hieronder lees je wat dat in de praktijk betekent en wat je vooraf regelt.
Waarom ben je niet automatisch eigenaar?
Veel ondernemers denken: ik betaal de rekening, dus de software is van mij. Advocaat Ernst-Jan van de Pas van Dirkzwager noemt dat in een artikel over IT-contracten een misvatting. Het auteursrecht op software ligt bij de programmeur, of bij diens werkgever als de programmeur in loondienst is (artikel 7 van de Auteurswet). Bij een opdracht aan een bureau is dat dus meestal het bureau.
Ook als je alles volledig betaalt of zelf een gedetailleerde beschrijving aanlevert, verandert dat niet. Van de Pas wijst op één uitzondering in de wet: software die volledig naar jouw ontwerp en onder jouw leiding is gemaakt. Volgens hem komt dat bij softwareontwikkeling bijna nooit voor.
Wil je het auteursrecht wel overnemen, dan stelt de wet eisen. Artikel 2 van de Auteurswet zegt dat een overeenkomst waarmee het auteursrecht wordt overgedragen schriftelijk wordt aangegaan, en dat de overdracht zelf gebeurt met een akte. Een mondelinge afspraak of een zin in een e-mail is dus niet genoeg.
Wat is het verschil tussen eigendom en een licentie?
Er zijn grofweg twee smaken. Bij een overdracht krijg jij het auteursrecht. Je mag de code dan laten aanpassen door wie je wilt, hergebruiken en verkopen. Bij een licentie blijft het bureau eigenaar en krijg jij toestemming om de software te gebruiken, onder de voorwaarden in het contract.
| Vraag | Overdracht | Licentie |
|---|---|---|
| Van wie is de code? | Van jou | Van de maker |
| Mag een ander bureau verder bouwen? | Ja | Alleen als de licentie dat toestaat |
| Mag de maker dezelfde code elders gebruiken? | Alleen met jouw toestemming | Ja, tenzij je exclusiviteit afspreekt |
| Wat moet je regelen? | Schriftelijke overeenkomst en akte | Duidelijke voorwaarden: duur, gebruik, aantal gebruikers |
Een licentie hoeft geen probleem te zijn. Het hangt af van wat er in staat. Een licentie die voor altijd geldt, je toestaat de code door een ander te laten aanpassen en je toegang tot de broncode geeft, laat je weinig tekort. Een licentie die vervalt als je stopt met betalen, of die alleen het bureau toestaat wijzigingen te maken, maakt je afhankelijk.
Wanneer is eigendom echt belangrijk?
Niet elke webapp vraagt om een volledige overdracht. Van de Pas schrijft dat overdracht bij standaardsoftware vaak weinig toevoegt en dat een licentie dan meestal volstaat. Bij maatwerk ligt dat anders. Kijk vooral naar deze situaties:
- De webapp is de kern van je bedrijf. Draait je omzet erop, of is het de reden dat klanten voor jou kiezen, dan wil je niet dat je volledig afhankelijk bent van één partij.
- Je wilt de software later verkopen of verhuren. Wil je er een product van maken voor andere bedrijven, dan heb je het recht nodig om dat te doen.
- Je verwacht ooit een eigen ontwikkelteam. Dan moet dat team vrij verder kunnen bouwen.
- Je wilt investeerders of een koper aantrekken. Zij vragen vrijwel altijd wie de rechten op de software heeft.
Gaat het om een interne tool voor een klein team, of om een klantportaal dat grotendeels op standaardonderdelen leunt, dan is een ruime licentie met toegang tot de broncode vaak genoeg.
Welke onderdelen zijn nooit helemaal van jou?
Ook bij een volledige overdracht is niet elke regel code van jou. Een moderne webapp is gebouwd op een framework: een fundament van kant-en-klare code, zoals Laravel of Next.js. Daarbovenop komen pakketten van derden voor bijvoorbeeld betalingen, e-mail of kaarten. Die onderdelen vallen onder hun eigen licentie, vaak een open source licentie. Je mag ze gebruiken, maar je wordt er geen eigenaar van.
Dat is normaal en meestal geen risico. Het wordt pas lastig als een belangrijk onderdeel een betaalde licentie heeft die op naam van het bureau staat. Vraag daarom om een lijst van gebruikte externe pakketten en betaalde diensten, met wie de licentie houdt.
Daarnaast gebruiken bureaus vaak eigen bouwstenen die ze bij meerdere klanten inzetten, zoals een standaard inlogmodule. Het is redelijk dat het bureau die niet aan jou overdraagt, zolang jij er een blijvend gebruiksrecht op krijgt. Spreek dat expliciet af.
Wat leg je vast voordat je tekent?
Neem deze punten door met het bureau en zorg dat de antwoorden in de overeenkomst of de algemene voorwaarden staan:
- Overdracht of licentie. Staat er zwart op wit wie het auteursrecht krijgt op de code die speciaal voor jou is geschreven?
- Toegang tot de broncode. Krijg je de broncode zelf, bijvoorbeeld in een repository (een online opslagplaats voor code) op jouw naam, of alleen de werkende app? Van de Pas adviseert dat de opdrachtgever altijd toegang tot de broncode krijgt, omdat je die nodig hebt om iets te laten aanpassen.
- Documentatie. Hoort uitleg over de opbouw, de installatie en de koppelingen bij de oplevering? Zonder documentatie kost overdragen aan een ander veel tijd.
- Latere aanpassingen. Geldt de afspraak ook voor uitbreidingen die na de eerste oplevering worden gebouwd? Leg dat vooraf vast, anders moet je het per uitbreiding opnieuw regelen.
- Accounts op jouw naam. Domeinnaam, hosting, de database, de accounts in de App Store en Google Play als er een mobiele app bij hoort, en diensten zoals een betaalprovider: staan ze op jouw naam of heb je er in elk geval beheerrechten op?
- Wat gebeurt er als je stopt. Hoe en binnen welke termijn krijg je de code, de gegevens en de toegang mee als je naar een andere partij overstapt?
- Persoonlijkheidsrechten. De maker houdt ook na een overdracht bepaalde persoonlijke rechten, zoals het recht om zich te verzetten tegen bepaalde wijzigingen. Van de Pas raadt aan dat de maker daar afstand van doet, voor zover de wet dat toestaat.
Een bureau dat open is over deze punten, maakt het je makkelijker. Twijfel je over de juridische tekst, laat het contract dan nakijken door een jurist. Dit artikel is uitleg, geen juridisch advies.
Wat betekent dit voor jou?
Stel de vraag over eigendom bij je eerste gesprek, niet bij de oplevering. Dan weet je waar je aan toe bent en kun je offertes eerlijk vergelijken. Twee bureaus met dezelfde prijs kunnen heel verschillende afspraken maken over de code. Meer over wat een webapp is en hoe je er een laat bouwen, lees je in Wat is een webapplicatie.
Bij Smijters bouwen we webapps in Laravel en Next.js, en spreken we vooraf met je af wat er met de code gebeurt. Kijk op de pagina over webapps laten bouwen wat we doen.
Veelgestelde vragen
Nee, niet automatisch. Het auteursrecht ligt bij de maker of diens werkgever. Je wordt alleen eigenaar als dat schriftelijk is overgedragen. Zonder afspraak heb je hooguit een recht om de software te gebruiken.
De broncode is de leesbare code die ontwikkelaars schrijven en aanpassen. De werkende app is wat je gebruikers zien. Met alleen de werkende app kan een andere ontwikkelaar weinig. Voor aanpassingen of een overstap heb je de broncode nodig.
Dat hangt van de licentie af. Staat erin dat je de broncode krijgt en die door een ander mag laten aanpassen, dan kan dat. Staat dat er niet in, dan ben je afhankelijk van de maker. Regel dit vooraf.
Nee. Frameworks en pakketten van derden vallen onder hun eigen licentie. Je mag ze gebruiken binnen die licentie, maar ze worden geen eigendom. Een overdracht gaat over de code die speciaal voor jou is geschreven.
Bij een webapp die belangrijk is voor je bedrijf is dat verstandig. Een jurist kan controleren of de overdracht, de licentie en de afspraken over de broncode goed zijn vastgelegd.