Hvem eier koden du betaler for?
Uten en tydelig avtale beholder leverandøren ofte opphavsretten til kode du har betalt for, og da får du bare en bruksrett. Ønsker du å kunne bytte leverandør, videreutvikle eller selge selskapet, må avtalen uttrykkelig overføre eiendomsretten til deg og gi deg tilgang til repo og kontoer fra start.
Mange kunder oppdager for sent at de ikke eier systemet de har betalt hundretusenvis av kroner for. De har et produkt som fungerer, men ikke retten til å endre det, flytte det eller engasjere noen andre. Det skyldes sjelden ond vilje. Det skyldes at ingen skrev ned hvem som eier hva. Her er det du må vite før neste faktura sendes.
Eiendomsrett, eksklusiv lisens og bruksrett
Tre begreper avgjør hvor fri du er, og de blandes ofte sammen.
- Eiendomsrett (opphavsrett). Du står fritt til å bruke, endre, selge og viderelisensiere koden som du vil. Det er den sterkeste posisjonen og den eneste som gjør deg helt uavhengig av leverandøren.
- Eksklusiv lisens. Leverandøren beholder opphavsretten, men gir bare deg rett til å bruke koden. Det er bedre enn en vanlig lisens, men du kan fortsatt være begrenset i hva du har lov til å endre og hvem som får gjøre det.
- Bruksrett. Du har lov til å bruke systemet til et avgrenset formål. Ofte følger verken kildekode eller rett til å la en tredjepart videreutvikle med. Det er dette du får som standard hvis avtalen er taus.
Poenget er enkelt: Det er avtalen, ikke betalingen, som avgjør hva du eier. Etter åndsverkloven oppstår retten hos den som skaper verket, og den forblir der til noe annet avtales.
Avtaleformuleringene du skal kreve
En god avtale trenger ikke å være komplisert, men den må være uttrykkelig. Sørg for at dette er med:
- Overføring av opphavsrett. All opphavsrett til spesialutviklet kode går over til deg ved full betaling. Uten koblingen til betaling kan retten henge i løse luften hvis et prosjekt avbrytes.
- Rett til kildekode og dokumentasjon. Du skal ha den lesbare kildekoden, ikke bare et kjørbart system, og den dokumentasjonen som trengs for at en annen utvikler skal kunne ta over.
- Håndtering av tredjepartskode og åpen kildekode. Nesten alle systemer bygger delvis på ferdige komponenter. Avtalen bør liste opp disse og lisensene som gjelder for dem slik at du vet hva du har og ikke har lov til å gjøre med dem.
- Ingen innlåsing via avhengigheter. Slå fast at leverandørens egne rammeverk eller verktøy som systemet hviler på, også får brukes og overleveres. Ellers eier du en bil uten nøkkel.
En kort gjennomgang av dette med en jurist før prosjektstart koster en brøkdel av det en tvist eller en påtvunget reinstallasjon koster senere.
Praktisk eierskap: repo, kontoer og nøkler fra dag én
Juridisk eierskap er verdiløst hvis du i praksis ikke får tilgang til noe. Den vanligste feilen er å la leverandøren eie infrastrukturen «for enkelhets skyld».
| Tilgang | Hvem skal stå som eier |
|---|---|
| Koderepo (f.eks. GitHub, GitLab) | Selskapets egen konto, leverandøren inviteres inn |
| Skykonto og servere | Selskapet ditt betaler og eier kontoen |
| Domene og DNS | Selskapet ditt |
| Appbutikk- og tjenestekontoer | Selskapet ditt |
| Deploy- og API-nøkler | Oppbevares hos deg, deles ved behov |
Regelen er at alt som ville vært smertefullt å miste, skal stå i ditt navn fra start. Leverandøren får selvsagt tilgang for å jobbe, men som invitert gjest, ikke som eier. Da blir et leverandørbytte et administrativt grep i stedet for en forhandling der du sitter i en svak posisjon.
Et konkret scenario
Et selskap lot et byrå bygge kundeportalen sin og betalte drøyt 1,2 millioner kr over to år. Alt lå i byråets repo og byråets skykonto, og avtalen sa ingenting om eierskap. Da samarbeidet begynte å skurre, ønsket selskapet å flytte systemet, men fikk beskjed om at det bare hadde bruksrett, og at en eksport ville koste ekstra. Med en eierskapsklausul og et eget repo fra begynnelsen hadde flyttingen vært en ettermiddags arbeid i stedet for en måneds juristarbeid.
Vil du unngå å havne i samme situasjon, lønner det seg å avklare eierskapet før utviklingen starter. Når vi leverer tjenestene våre, jobber vi alltid i kundens repo og overleverer kode og kontoer fortløpende, og en teknisk due diligence av et pågående prosjekt gir deg raskt svart på hvitt hvor du faktisk står i dag.
Ofte stilte spørsmål
Eier jeg automatisk koden hvis jeg betaler for den?
Nei. Etter åndsverkloven oppstår opphavsretten hos den som skriver koden, altså leverandøren eller konsulenten. At du betaler for arbeidet, gir deg ikke automatisk eiendomsretten; du får bare det avtalen uttrykkelig overfører. Mangler avtalen en klausul om dette, får du normalt en bruksrett, ikke eierskap.
Hva er forskjellen på eiendomsrett og bruksrett?
Eiendomsrett betyr at du står fritt til å bruke, endre, selge og lisensiere koden. Bruksrett betyr at du har lov til å bruke den til et avgrenset formål, ofte uten rett til å røre kildekoden eller engasjere noen andre. Forskjellen avgjør om du er fri eller innelåst.
Trenger jeg kildekoden hvis systemet fungerer likevel?
Ja, hvis du ønsker å kunne videreutvikle, feilsøke eller bytte leverandør. Uten kildekoden og retten til å endre den sitter du fast hos én eneste part. Krev at koden ligger i et repo du eier, ikke bare i et driftsmiljø du ikke har tilgang til.
Hva skjer med koden hvis leverandøren går konkurs?
Har du allerede eiendomsrett og tilgang til repoet, blir du lite berørt, for du kan flytte arbeidet til noen andre. Har du bare bruksrett og koden ligger hos leverandøren, risikerer du å miste alt. Derfor bør tilgangen sikres fortløpende, ikke først når samarbeidet en gang avsluttes.
Hva skal jeg skrive inn i avtalen?
En klausul som overfører all opphavsrett til levert kode til deg ved betaling, rett til kildekode og dokumentasjon, og tilgang til repo, kontoer og deploy-nøkler. Reguler også åpen kildekode og eventuelle gjenbrukte komponenter slik at ingen uventede lisensvilkår følger med.