Intellectueel eigendom zonder lock-in
Wie betaalt voor maatwerksoftware moet niet alsnog klem komen te zitten zodra een samenwerking verandert. Daarom leggen we intellectueel eigendom, toegang en overdraagbaarheid expliciet vast.
Ontwikkelde code gaat over naar de klant
Vrijheid voor interne doorontwikkeling of een andere partij
Accounts en infrastructuur liefst op naam van de klant
Waar dit over gaat
Eigenaarschap moet ook praktisch kloppen
Intellectueel eigendom is meer dan een nette contractzin over code. Het gaat ook over toegang tot repositories, documentatie, infrastructuur en externe diensten. Als die onderdelen verspreid blijven over accounts van de leverancier, ontstaat alsnog afhankelijkheid, ook als de juridische basis op papier goed lijkt.
Daarom kiezen we liever voor een opzet waarin de klant zelf toegang heeft tot broncode, accounts en hosting. De klant moet met de software verder kunnen, intern of met een andere partij.
Wat we expliciet regelen
Van eigendom naar overdraagbaarheid
De ontwikkelde code voor het project dragen we volledig en zonder voorbehoud over aan de klant.
Voor hosting, monitoring en tooling kiezen we waar mogelijk voor registratie op naam van de klant. Dat maakt eigenaarschap tastbaar.
De klant moet met dezelfde software verder kunnen, of dat nu met een intern team is of met een andere leverancier.
Overdraagbaarheid vraagt om meer dan broncode alleen. Ook documentatie, release-informatie en toegangen moeten onderweg al op orde zijn.
We gaan ervan uit dat goed werk klanten bindt, niet het moeilijk maken van een vertrek.
Code blijft niet hangen
Intellectueel eigendom gaat naar de klant
De ontwikkelde code voor het project dragen we volledig en zonder voorbehoud over aan de klant.
Waarom dit belangrijk is
Keuzevrijheid is geen bijzaak
Bij maatwerksoftware voelt Woordenboek · In het kortvendor lock-inVendor lock-in is afhankelijkheid van één leverancier waardoor overstappen naar een alternatief moeilijk, duur of ontwrichtend wordt.Lees meer vaak pas laat als probleem, namelijk wanneer prioriteiten verschuiven, een team wisselt of een overdracht nodig is. Dan blijkt opeens hoe belangrijk het is dat code, accounts en infrastructuur niet impliciet bij de leverancier zijn blijven hangen.
Dat zie je ook terug in trajecten zoals Zetprofiel, waar infrastructuur als code op naam van de klant juist belangrijk is voor overdraagbaarheid en helder eigenaarschap. Het gaat dus niet om wantrouwen, maar om een gezonde samenwerking die ook standhoudt als omstandigheden veranderen.
Wat dit je oplevert
Code en intellectueel eigendom bij de klant
Meer vrijheid om later van team of leverancier te wisselen
Minder operationele afhankelijkheid van één partij
Overdraagbaarheid die niet pas op het einde begint
Veelgestelde vragen
Van de klant. Het intellectueel eigendom van de ontwikkelde code dragen we volledig over.
Nee. In de praktijk kijken we ook naar accounts, infrastructuur, documentatie en andere onderdelen die overdraagbaarheid bepalen.
Dat heeft wel onze voorkeur voor externe diensten zoals hosting, monitoring en tooling, juist omdat het eigenaarschap en continuïteit duidelijk houdt.
Omdat keuzevrijheid pas echt bestaat als je ook praktisch kunt overstappen of zelf verder kunt, zonder blokkades rond toegang of eigendom.
Staat je vraag hier niet tussen?
Neem contact op