Hvem ejer koden du betaler for?
Uden en klar aftale beholder leverandøren ofte ophavsretten til kode du har betalt for, og du får så kun en brugsret. Vil du kunne skifte leverandør, videreudvikle eller sælge virksomheden, skal aftalen udtrykkeligt overdrage ejendomsretten til dig og give dig adgang til repo og konti fra start.
Mange kunder opdager for sent at de ikke ejer det system de har betalt hundredtusindvis af DKK for. De har et produkt der virker, men ikke retten til at ændre det, flytte det eller hyre en anden. Det skyldes sjældent ond vilje. Det skyldes at ingen skrev ned hvem der ejer hvad. Her er det du skal vide før den næste faktura bliver sendt.
Ejendomsret, eksklusiv licens og brugsret
Tre begreber afgør hvor fri du er, og de bliver ofte blandet sammen.
- Ejendomsret (ophavsret). Du må bruge, ændre, sælge og viderelicensere koden som du vil. Det er den stærkeste position og den eneste der gør dig helt uafhængig af leverandøren.
- Eksklusiv licens. Leverandøren beholder ophavsretten, men giver kun dig ret til at bruge koden. Bedre end en almindelig licens, men du kan stadig være begrænset i hvad du må ændre og hvem der må gøre det.
- Brugsret. Du må bruge systemet til et afgrænset formål. Ofte følger hverken kildekoden eller retten til at lade en tredjepart videreudvikle med. Det er det du får som standard hvis aftalen ikke siger noget.
Pointen er enkel: Betalingen afgør ikke hvad du ejer, det gør aftalen. Efter dansk ophavsret opstår retten hos den der skaber værket, og den bliver der indtil andet aftales. Det bør ske skriftligt.
De aftaleformuleringer du skal kræve
En god aftale behøver ikke være kompliceret, men den skal være udtrykkelig. Sørg for at følgende er med:
- Overdragelse af ophavsret. Al ophavsret til specialudviklet kode overgår til dig ved fuld betaling. Uden koblingen til betalingen kan retten hænge i luften hvis et projekt bliver afbrudt.
- Ret til kildekode og dokumentation. Du skal have den læsbare kildekode, ikke kun et kørbart system, plus den dokumentation der skal til for at en anden udvikler kan tage over.
- Håndtering af tredjepartskode og open source. Næsten alle systemer bygger delvis på færdige komponenter. Aftalen bør angive dem og deres licenser så du ved hvad du må og ikke må gøre med dem.
- Ingen fastlåsning via afhængigheder. Aftal at leverandørens egne frameworks eller værktøjer som systemet hviler på, også må bruges og overdrages, ellers ejer du en bil uden nøgle.
En kort gennemgang af det her med en jurist før projektstart koster en brøkdel af hvad en tvist eller en tvungen geninstallation gør senere.
Ejerskab i praksis: repo, konti og nøgler fra dag ét
Juridisk ejerskab er værdiløst hvis du i praksis ikke har adgang til noget. Den mest almindelige fejl er at lade leverandøren eje infrastrukturen “for nemheds skyld”.
| Adgang | Hvem skal stå som ejer |
|---|---|
| Koderepo (f.eks. GitHub, GitLab) | Din virksomheds konto, leverandøren bliver inviteret |
| Cloudkonto og servere | Din virksomhed betaler og ejer kontoen |
| Domæne og DNS | Din virksomhed |
| App store- og tjenestekonti | Din virksomhed |
| Deploy- og API-nøgler | Opbevares hos dig, deles efter behov |
Reglen er at alt det der ville være smertefuldt at miste, skal stå i dit navn fra start. Leverandøren får selvfølgelig adgang for at kunne arbejde, men som inviteret gæst og ikke som ejer. Så bliver et leverandørskifte en administrativ opgave i stedet for en forhandling hvor du står svagt.
Et konkret scenarie
En virksomhed fik et bureau til at bygge sin kundeportal og betalte et millionbeløb over to år. Alt lå i bureauets repo og bureauets cloudkonto, og aftalen nævnte intet om ejerskab. Da samarbejdet begyndte at knirke, ville virksomheden flytte systemet, men fik at vide at den kun havde brugsret og at en eksport ville koste ekstra. Med en ejerskabsklausul og et repo i eget navn fra begyndelsen havde flytningen været en eftermiddags arbejde i stedet for en måned med jurister.
Vil du undgå samme situation, kan det betale sig at få styr på ejerskabet før udviklingen går i gang. Når vi leverer vores ydelser, arbejder vi altid i kundens repo og overdrager kode og konti løbende, og en teknisk due diligence af et igangværende projekt giver dig hurtigt sort på hvidt hvor du faktisk står i dag.
Ofte stillede spørgsmål
Ejer jeg automatisk koden hvis jeg betaler for den?
Nej. Efter dansk ophavsret opstår retten hos den der skriver koden, altså leverandøren eller konsulenten. At du betaler for arbejdet, giver dig ikke automatisk ejendomsretten, kun det som aftalen udtrykkeligt overdrager. Mangler der en klausul om det, får du normalt en brugsret og ikke ejerskab.
Hvad er forskellen på ejendomsret og brugsret?
Ejendomsret betyder at du frit må bruge, ændre, sælge og licensere koden. Brugsret betyder at du må bruge den til et afgrænset formål, ofte uden ret til at røre kildekoden eller hyre en anden. Forskellen afgør om du er fri eller låst fast.
Har jeg brug for kildekoden hvis systemet alligevel virker?
Ja, hvis du vil kunne videreudvikle, fejlsøge eller skifte leverandør. Uden kildekoden og retten til at ændre den sidder du fast hos én enkelt part. Kræv at koden ligger i et repo du ejer, ikke kun i et driftsmiljø du ikke har adgang til.
Hvad sker der med koden hvis leverandøren går konkurs?
Har du allerede ejendomsretten og adgang til repoet, bliver du kun minimalt påvirket, for du kan flytte arbejdet til en anden. Har du kun brugsret og ligger koden hos leverandøren, risikerer du at miste det hele. Derfor bør adgangen sikres løbende og ikke først ved en planlagt afslutning.
Hvad skal jeg skrive ind i aftalen?
En klausul der overdrager al ophavsret til leveret kode til dig ved betaling, ret til kildekode og dokumentation samt adgang til repo, konti og deploy-nøgler. Regulér også open source og eventuelle genbrugte komponenter så der ikke følger uventede licensvilkår med.