Hvem ejer koden, når I har betalt for den?

En direktør vil skifte leverandør efter fire år. Hjemmesiden og bookingsystemet virker, men udviklingen går for langsomt. Da hun beder om koden, får hun at vide, at den kører på leverandørens platform, at domænet er registreret i deres navn, og at appen ligger på deres konto hos Apple. Ingen af delene er ulovligt. Det stod bare ingen steder, at det skulle være anderledes. Den slags opdages næsten altid først, når man vil ud.

Svaret på, hvem der ejer koden, afhænger af tre ting: hvad loven siger som udgangspunkt, hvad kontrakten siger, og i hvis navn kontiene er oprettet. Denne guide gennemgår alle tre, så I kan få det skrevet ind, før I skriver under, og har en tjekliste klar, hvis I en dag vil skifte.

Hvem ejer kildekoden efter dansk lov?

Software er beskyttet af ophavsretsloven som et værk. Udgangspunktet er, at ophavsretten ligger hos den, der har skabt værket. Når et softwarehus skriver kode til jer, ligger rettighederne altså hos softwarehuset, indtil de bliver overdraget. Er koden skrevet af softwarehusets ansatte, har loven en særlig regel om, at rettighederne til computerprogrammer går over til arbejdsgiveren. Den regel hjælper softwarehuset, men den flytter ikke rettighederne videre til jer som kunde.

Når en aftale ikke siger noget præcist om rettigheder, fortolkes overdragelsen typisk snævert. I får det, der var nødvendigt for det formål, I og leverandøren havde for øje. Det betyder normalt, at I må bruge hjemmesiden eller systemet, men det er langt fra sikkert, at I må ændre koden, give den til en anden leverandør eller bygge et nyt produkt på den. Den usikkerhed er det, en god kontrakt fjerner.

Hvad er forskellen på ejerskab, brugsret og licens?

Ingen model er forkert i sig selv. En platform på abonnement kan være det helt rigtige valg til et standardbehov, og vi har skrevet om afvejningen i eget system eller SaaS-abonnementer. Pointen er, at I skal vide, hvilken model I køber, og at prisen skal afspejle den. Betaler I for et system bygget til jer, bør I også eje det.

Hvad med open source og færdige komponenter?

Moderne software er bygget på tusindvis af open source-pakker. React, Next.js og TypeScript er selv open source. I ejer ikke React, og det behøver I heller ikke: licenser som MIT og Apache 2.0 giver bred ret til at bruge, ændre og videregive koden. Det, I skal eje, er den kode, der er skrevet til jer. Enkelte licenser, som GPL, stiller krav om, at afledt kode deles under samme licens, hvis den distribueres. Bed leverandøren om en liste over de vigtigste licenser.

Hvem skal eje domænet, hostingen og de andre konti?

Kontiene er i praksis lige så vigtige som koden. Ejer I koden, men ligger domænet, serveren og appen på leverandørens konti, kan I stadig ikke flytte uden deres hjælp. Reglen er enkel: alt, der identificerer jeres virksomhed eller indeholder jeres data, oprettes i jeres navn, og leverandøren får adgang som bruger.

Ejer I også jeres data?

Ja, og det bør stå i aftalen. Når leverandøren hoster og driver løsningen, er I typisk dataansvarlige efter GDPR, og leverandøren er databehandler. Det kræver en databehandleraftale, der beskriver, hvad leverandøren må med data, hvor de ligger, og hvad der sker ved ophør. Skriv også ind, at data udleveres i et almindeligt format som CSV, JSON eller en databasedump, og inden for en fast frist. Hosting i EU gør det enklere at overholde reglerne om overførsel. Læs mere i GDPR for hjemmesider og apps.

Hvad skal stå i kontrakten om ejerskab af koden?

• At alle rettigheder til kode, design og dokumentation, der er udviklet specifikt til jer, overgår til jer, og hvornår (fx ved betaling af hver milepæl).
• At I har ret til at ændre, videreudvikle og lade andre leverandører arbejde i koden.
• At leverandøren giver en varig og vederlagsfri brugsret til generelle komponenter, der indgår i løsningen.
• At underleverandører og freelancere har overdraget deres rettigheder, så de kan videregives til jer.
• At domæne, hosting, repository og app store-konti står i jeres navn.
• At data tilhører jer og udleveres i et almindeligt format ved ophør.
• En liste over tredjepartslicenser, der skal fornyes, og hvem der betaler dem.
• Hvad der udleveres ved opsigelse, i hvilket format og inden for hvilken frist.

Brug punkterne ovenfor, når I læser tilbud. Mangler de, er det et af de røde flag, vi gennemgår i røde flag i et IT-tilbud. Og stil spørgsmålene allerede på første møde; vi har en liste i spørgsmål til et webbureau.

Hvordan skifter man leverandør? Exit-tjeklisten

1. Lav en liste over alle systemer, konti, abonnementer og integrationer.
2. Bekræft, at I har administratoradgang til domæne og DNS.
3. Få adgang til repository og tjek, at den seneste kode faktisk ligger der.
4. Få dokumentation: opsætning, miljøvariabler, databaser og hvordan løsningen udrulles.
5. Få en komplet eksport af data og en backup af databasen.
6. Overfør eller bekræft ejerskab af hosting- og cloudkonti.
7. Overfør apps til jeres egne konti hos Apple og Google, hvis de ligger hos leverandøren.
8. Overtag API-nøgler og abonnementer hos tredjeparter, fx betaling og e-mail.
9. Lad den nye leverandør bygge og køre løsningen fra den udleverede kode, før I opsiger den gamle.
10. Skift adgangskoder og fjern den gamle leverandørs adgange, når flytningen er bekræftet.

Punkt ni er det vigtigste. En kode, der ikke kan bygges og køres af en anden, er i praksis ikke flytbar, uanset hvad kontrakten siger. Lad derfor den nye leverandør bekræfte, at de kan sætte løsningen op fra bunden, mens den gamle stadig er tilgængelig for spørgsmål.

Hvad koster det, når ejerskabet er uklart?

Forestil jer et typisk forløb. En virksomhed har betalt 220.000 kr. for et bookingsystem over to år. Leverandøren lukker, og koden ligger på deres server uden adgang for kunden. Alternativet er at bygge forfra, hvilket for et tilsvarende system typisk koster 150.000–250.000 kr. og tager flere måneder, mens den gamle løsning kører på lånt tid. Med adgang til repository og data havde den samme flytning typisk været et spørgsmål om uger. Den forskel er grunden til, at ejerskab hører hjemme i budgettet for IT-projektet som en risiko.

Hvordan håndterer vi ejerskab hos Ceptiv?

Vi bygger alt fra bunden i React, Next.js, TypeScript og React Native, som er udbredte open source-teknologier, mange udviklere kan arbejde i. Kunden ejer både kode og data. Driften kan opsiges med 30 dages varsel, og opsiger I inden for de første 15 måneder, er der et engangsgebyr, som står i tilbuddet fra start. Når I går, tager I koden med. Vi har beskrevet, hvordan det virker i praksis, under skræddersyet software eller standardsystem.

Har I et system i dag, hvor ejerskabet er uklart, kan vi hjælpe med at kortlægge det og flytte det; se modernisering af ældre systemer. Skal I i gang med noget nyt, så få et tilbud, hvor vilkårene for kode, data og konti står skrevet fra første side.