Waarom dit voor de start geregeld moet zijn, niet erna
Wie software laat bouwen, gaat er vaak vanzelfsprekend van uit dat die van hen is omdat ze ervoor betaald hebben. Juridisch klopt dat niet automatisch. Zonder duidelijke afspraak blijft het auteursrecht op wat gebouwd is doorgaans bij wie het effectief geschreven heeft: de ontwikkelaar of het bedrijf erachter, ook al heeft de klant ervoor betaald. Dat wordt pas een probleem op het moment dat het er echt toe doet: bij een geschil, bij een overname, of wanneer een klant naar een andere partij wil overstappen. De precieze regels verschillen van land tot land, dus laat dit bij twijfel aftoetsen door een jurist. Het uitgangspunt hieronder is wat u vooraf sowieso schriftelijk zou moeten afdwingen, ongeacht wat de wet als vangnet voorziet.
Wat expliciet afgesproken moet worden
Drie dingen horen schriftelijk vastgelegd te zijn voor een traject start, niet erna onderhandeld.
Eigendom van de broncode. Dat is meer dan alleen “toegang” tot een werkende toepassing: het is de code zelf, in een vorm die een andere ontwikkelaar zou kunnen overnemen en verderzetten.
Overdracht van intellectueel eigendom. Een expliciete clausule die zegt dat het intellectueel eigendom op het geleverde werk overgaat op de klant bij oplevering, of bij betaling. Niet enkel een gebruiksrecht dat bij de bouwer blijft.
Toegang tot alles wat nodig is om het zelfstandig te laten draaien: de code, de configuratie, en de wachtwoorden of sleutels van de systemen waarop het draait. Wat dat concreet betekent als de ontwikkelaar er niet meer is, staat uitgebreider in wat als de ontwikkelaar er niet meer is?
Wat vaak over het hoofd gezien wordt
Een paar aandachtspunten die minder voor de hand liggen dan “wie is eigenaar”, maar in de praktijk even veel gewicht in de schaal leggen.
Bibliotheken en onderdelen van derden. De meeste software gebruikt bestaande, open source bouwstenen naast het eigen geschreven werk. Die blijven onder hun eigen licentie. Dat is normaal en geen probleem, maar goed om te weten: “volledig eigendom” slaat op het werk dat specifiek voor u geschreven is, niet op elk onderdeel dat daarin gebruikt wordt.
Wat er gebeurt bij een geschil over betaling. Sommige contracten koppelen de eigendomsoverdracht aan volledige betaling. Dat is op zich redelijk, maar zorg dat u weet wanneer precies dat omslagpunt ligt, in plaats van dat achteraf te ontdekken.
Documentatie als deel van de levering. Code zonder uitleg is voor een andere ontwikkelaar veel duurder om over te nemen dan code mét een beknopte uitleg van hoe alles in elkaar zit. Vraag daarom uitdrukkelijk om documentatie als onderdeel van wat opgeleverd wordt, niet als losse, optionele extra.
Hoe Kufu dit regelt
Bij een traject bij Kufu is de broncode van bij de start van u. Ze draait op hosting die u zelf beheert of waarvan u de toegang heeft, met de wachtwoorden en sleutels in uw bezit, niet enkel bij Kufu. Er is geen aparte “licentie” of gebruiksrecht dat achteraf losstaat van wat er gebouwd is. Wat gebouwd wordt tijdens Vijf dagen of via Losse dagen, is en blijft eigendom van uw bedrijf.
Wat u zelf kunt nagaan voor u start
Vraag expliciet, bij eender welke partij die iets voor u bouwt: krijg ik de broncode, of enkel toegang tot een werkende toepassing? Draait dit op hosting die ik zelf beheer, of bij de ontwikkelaar? Staat de eigendomsoverdracht duidelijk op papier, of wordt daarvan uitgegaan zonder dat het ergens staat? Zijn de antwoorden vaag, dan is dat een signaal om door te vragen voor er getekend wordt, niet erna.
Twijfelt u wat dit voor uw eigen situatie betekent, dan is dat een van de dingen die tijdens een gratis kennismaking van een half uur mee op tafel komen.