Broncode: eigendom en overdracht

Het is de hardnekkigste misvatting in softwareprojecten, en hij komt op het slechtst denkbare moment aan het licht: als u van leverancier wilt wisselen. De facturen zijn betaald, de applicatie draait al jaren, en dan blijken de rechten op de code nog bij de bouwer te liggen.

De Nederlandse Auteurswet legt het auteursrecht bij de maker van een werk (artikel 1). Een opdracht verstrekken en een rekening voldoen zijn geen overdracht. Voor overdracht van auteursrecht, en ook voor het verlenen van een exclusieve licentie, vraagt de wet om een daartoe bestemde akte (artikel 2, derde lid): een ondertekend stuk waarin staat wat er overgaat. Zonder dat stuk blijft het recht liggen waar het ontstond.

Ligt die akte er, dan volgt een vraag die zelden gesteld wordt: had uw leverancier die rechten zelf? Voor mensen in loondienst zit dat meestal goed, want de wet wijst de werkgever aan als maker van werk dat in dienstverband is vervaardigd, tenzij anders is overeengekomen (artikel 7). Voor zelfstandigen en onderaannemers geldt die regel niet, en zonder eigen akte blijven de rechten bij hen.

Eén bepaling geeft opdrachtgevers soms hoop: wie een werk laat maken naar zijn eigen ontwerp en onder zijn leiding en toezicht, geldt zelf als maker (artikel 6). Wensen aanleveren en opleveringen goedkeuren is iets anders. Reken er niet op.

In offertes lopen ze door elkaar, samengevat als "de code krijgt u". Ze regelen iets anders.

Auteursrecht

Het recht om de software te verveelvoudigen, aan te passen en openbaar te maken. Gaat alleen over via een ondertekende akte. Wie dit heeft, mag de software door wie dan ook laten doorontwikkelen.

Gebruiksrecht

Toestemming om de software te gebruiken, binnen de grenzen van de rechthebbende. Kan begrensd zijn in gebruikers, doel of looptijd, en kan uitsluiten dat een derde de code aanpast of dat u het recht meeneemt bij een overname.

Toegang tot de broncode

Feitelijk kunnen inzien, kopiëren en draaien van de code. Zegt niets over wat u ermee mag, en verdwijnt ook niet vanzelf als een licentie eindigt.

De ongemakkelijke combinaties zijn de leerzame. U kunt de volledige code op een schijf hebben en toch niet het recht hebben er een ander bureau mee aan het werk te zetten. Omgekeerd kunt u alle rechten op papier hebben en bij een breuk ontdekken dat de enige draaiende versie bij uw leverancier stond. De rechten regelt u in het contract, de toegang in de techniek.

Het praktische probleem komt eerder dan het juridische: alles staat bij de leverancier. De repository in zijn omgeving, de hosting op zijn account, de domeinnaam en de storeaccounts op zijn bedrijf. Niemand richt dat kwaadwillend zo in; het is op dag één sneller, en niemand stelt later voor het om te draaien.

Wat u bij een breuk krijgt is een bestandsarchief. Zonder projecthistorie, zonder configuratie per omgeving, zonder de sleutels naar de diensten waar de applicatie op leunt, zonder de uitrolscripts. Een nieuwe partij kan daarmee verder, maar begint met reconstrueren in plaats van bouwen. Dat werk betaalt u. Daar loopt wisselen van softwarebureau op stuk. Bij een faillissement kan bovendien niemand meer meewerken: een curator heeft andere zorgen dan uw uitrolscript.

Wat u regelt is saai en effectief. Repository, domeinnaam, hosting, storeaccounts en betaalproviders staan vanaf de eerste dag op uw naam, met de leverancier als beheerder. Overdracht is dan geen gebeurtenis meer maar het intrekken van toegang.

Hier lopen de belangen uiteen, en dat mag gezegd. Voor een bureau is de eigen gereedschapskist kapitaal: bouwstenen voor inloggen, rechtenbeheer en beheerschermen die bij tientallen klanten terugkomen. Die exclusief weggeven is geen redelijke vraag. Wat wel werkt is een splitsing: overdracht van wat specifiek voor u is gemaakt, en op de generieke onderdelen een eeuwigdurende, overdraagbare licentie die aanpassing door derden toestaat. Wie dat onderscheid weigert, verkoopt geen software maar een abonnement op zichzelf. Neem die vraag mee als u een softwareleverancier kiest.

Vrijwel elke applicatie leunt op tientallen opensourcebibliotheken. Daar wordt u geen eigenaar van, en uw leverancier evenmin: die componenten blijven van hun makers. U krijgt een gebruiksrecht onder hun voorwaarden, en die reizen mee met de software.

Meestal is dat ruim, doorgaans op voorwaarde dat u de licentietekst en de vermelding van de makers meelevert. Een deel van de licenties koppelt zwaardere verplichtingen aan het moment waarop u de software aan anderen verstrekt, tot en met het onder dezelfde voorwaarden beschikbaar stellen van broncode. Er zijn ook licenties die het aanbieden via een netwerk als zo'n moment aanmerken, wat voor een webapplicatie veel uitmaakt.

Wat precies waar geldt verschilt per licentie en is werk voor een jurist. Zelf regelt u iets simpelers: vraag bij elke oplevering om een lijst van gebruikte componenten met hun licentie, en spreek af dat er niets bij komt met voorwaarden die botsen met uw plannen. Wie die lijst niet kan leveren, weet zelf niet wat er in uw applicatie zit. Auteursrecht beschermt overigens de uitwerking, niet de gedachte erachter; over dat laatste leest u meer in uw app-idee beschermen.

Soms weigert een leverancier over te dragen, en soms is dat te verdedigen: bij een productoplossing die tientallen klanten delen kan hij aan één klant geen exclusiviteit geven. De vraag verschuift dan naar continuïteit.

De gebruikelijke tussenweg is een depotregeling, ook escrow genoemd. De leverancier deponeert de broncode bij een onafhankelijke derde, met alles wat nodig is om die te bouwen en te draaien. Bij vooraf omschreven gebeurtenissen, zoals faillissement of het staken van de dienstverlening, geeft die derde het materiaal aan u vrij. U bent dan niet afhankelijk van een partij die op dat moment andere zorgen heeft.

Drie dingen bepalen of het meer is dan papier. De actualiteit: een depot dat één keer bij oplevering is gevuld, is bij vrijgave verouderd, dus laat het meebewegen met de releases. De volledigheid: laat periodiek controleren dat wat er ligt ook echt te bouwen en te draaien is. En het recht dat bij vrijgave meekomt: krijgt u alleen bestanden, dan staat u met code die u niet mag laten aanpassen.

Een depot is zinvol als de software bedrijfskritisch is en de leverancier klein. Kunt u de rechten gewoon overgedragen krijgen, dan is het een omweg met terugkerende kosten.

Achteraf onderhandelt u over software die al draait, met een leverancier die weet dat u nergens heen kunt. Vooraf kost hetzelfde gesprek vrijwel niets.

1. Splits maatwerk en hergebruikte bouwstenen

   Benoem wat specifiek voor u wordt gemaakt en wat de leverancier uit eigen voorraad meebrengt. Voor het eerste overdracht, voor het tweede een eeuwigdurende, overdraagbare licentie.

2. Zet de akte in de overeenkomst

   Een zin in een offerte die niemand tekent, of algemene voorwaarden waarin het tegenovergestelde staat, is precies wat later ter discussie komt.

3. Regel de keten achter uw leverancier

   Laat hem verklaren dat hij de rechten heeft van iedereen die aan de code werkt, inclusief zelfstandigen, en u vrijwaren als dat niet blijkt te kloppen.

4. Zet repository en accounts meteen op uw naam

   Geen wantrouwen, maar de enige inrichting waarin overdracht nooit een project op zichzelf wordt.

5. Spreek af wat "de code" omvat, en test het

   Broncode, projecthistorie, configuratie, databasestructuur, uitrolscripts en een instructie waarmee een buitenstaander de applicatie draaiend krijgt. Laat iemand anders dan de bouwers dat tijdens de bouw een keer doen.

Dit artikel geeft algemene uitleg over hoe eigendom en overdracht van broncode werken. Het is geen juridisch advies en vervangt geen beoordeling van uw eigen contract door een jurist.

• Een softwareleverancier kiezen
• Van softwarebureau wisselen
• Uw app-idee beschermen