Hva du eier når systemet er ferdig: kode, data og avhengighet av utvikleren

Systemet er overlevert, fakturaen er betalt, og etter et halvår bestemmer bedriften seg for å bytte utvikler, og akkurat da blir spørsmålet stilt som til da ikke virket presserende for noen: hvem eier det det ble betalt for. Svaret i Norge overrasker nesten alle som hører det første gang, for betaling for utviklingen gir i seg selv ikke bestilleren opphavsrett til datamaskinprogrammet som er laget, og det er ikke en juridisk spissfindighet, men utgangspunktet som gjelder hver gang avtalen ikke sier noe annet.

Denne artikkelen handler om det som blir igjen i hendene dine etter overleveringen, og det er ikke det samme spørsmålet vi allerede har tatt opp da vi sammenlignet et ferdig produkt med skreddersydd programvare. Der gjaldt det hva du skal velge; her gjelder det hva du holder i hendene når valget allerede er tatt og systemet kjører. Svaret faller i tre deler: koden og retten til den, dataene sammen med stedet der de ligger, og avhengigheten av menneskene som kjenner systemet.

Opphaveren er alltid et menneske, ikke et selskap

Etter åndsverkloven er opphaveren den som skaper et åndsverk, og det betyr at et selskap aldri er opphaver: opphaverne er programmererne, designerne og tekstforfatterne som arbeidet med systemet. Datamaskinprogrammer står oppført blant åndsverkene, slik de også er vernet i EUs direktiv 2009/24/EF, og opphavsretten oppstår i det øyeblikket verket er skapt, uten registrering, uten merke og uavhengig av om verket er ferdig.

Opphavsretten faller i to deler, som norsk praksis kaller økonomiske rettigheter og ideelle rettigheter, og i praksis er det det viktigste skillet i hele dette emnet, for bare den ene kan i det hele tatt havne hos selskapet. Den økonomiske delen er den som kan overdras til en annen, og for et datamaskinprogram omfatter den å fremstille eksemplar og gjøre programmet tilgjengelig for allmennheten, i opprinnelig eller endret skikkelse, i oversettelse eller annen bearbeidelse. Den ideelle delen blir hos opphaveren og kan ikke fraskrives, med mindre det gjelder en bruk som er avgrenset etter art og omfang, og nettopp derfor kan ingen avtale skrive at selskapet blir opphaver.

Det finnes én grense til, som sjelden blir lagt merke til, og den kan bli dyr. § 71, som lar opphavsretten til et datamaskinprogram gå over til arbeidsgiveren, taler bare om datamaskinprogram, mens alt annet prosjektet skaper — design, dokumentasjon, tekster og instruksjoner — mangler en alminnelig ansatteregel: de blir hos opphaveren med mindre avtalen klart gir uttrykk for at de overdras, etter § 67. Praktisk betyr det at to ting skapt i ett og samme prosjekt kan ha to ulike rettighetshavere, og en avtale som bare taler om programvare, kan la designet ligge utenfor.

Derav følger de første praktiske virkningene, som er verdt å forstå før alt det andre: når et selskap bestiller et system hos et byrå, er rettighetskjeden minst to ledd lang, for først er programmererne opphavere, deretter har byrået eller har det ikke fått den økonomiske delen fra dem, og først da kan byrået overdra noe til deg. Mangler et ledd, lover byrået mer enn det eier, og det merkes først når noen begynner å sjekke.

Ansatt og bestilling er to ulike utgangspunkt

Her ligger kjernen i artikkelen, og det er her intuisjonen leder galt. Åndsverkloven § 71 fastsetter at opphavsrett til datamaskinprogram som er skapt av en arbeidstaker under utførelsen av oppgaver som omfattes av arbeidsforholdet, eller etter arbeidsgivers anvisninger, går over til arbeidsgiveren, og det samme gjelder adgang til endring og videreoverdragelse, hvis ikke annet er avtalt. Det er Norges svar på artikkel 2 nr. 3 i direktiv 2009/24/EF, og det gjelder bare arbeidsforhold og bare datamaskinprogrammer. Ideelle rettigheter etter § 5 går ikke over.

Ved bestilling er utgangspunktet det motsatte, og nettopp derfor må de to tilfellene ikke blandes: en avtale om bestilt verk forplikter opphaveren til å utføre arbeidet og levere det til bruk, men den sier ikke at den økonomiske delen går over til bestilleren ved betalingen. En oppdragsavtale sier ingenting om opphavsrett i det hele tatt, for den regulerer utførelse og overlevering, ikke omsetningen av rettigheter. § 67 sier at opphaveren ikke skal anses for å ha overdratt en mer omfattende rett enn det avtalen klart gir uttrykk for, og at overdragelse av et eksemplar ikke innbefatter overdragelse av opphavsretten.

Legg de to sammen, og du får situasjonen et typisk selskap havner i uten å vite det: kunden bestiller systemet hos byrået; programmererne er byråets ansatte, derfor går opphavsretten etter § 71 over til byrået; avtalen mellom kunden og byrået er en oppdragsavtale, som ikke fører den videre. Resultatet blir at kunden har betalt for resultatet og mottatt resultatet, men den økonomiske delen er blitt igjen hos byrået, og det eneste kunden har, er en uklar underforstått opphavsrettslig lisens til å bruke systemet til det formålet det ble bestilt for.

Forestillingen om at retten til et datamaskinprogram tilhører den som har bestilt og betalt utviklingen, er en utbredt misforståelse, og åndsverkloven gir ingen automatisk overgang til bestilleren. Innholdet i en underforstått lisens blir stående uklart, og fordi begge deler er nettopp det som skal skrives inn i avtalen, er § 67 og § 71 verdt å lese sammen med denne teksten: lovteksten bekrefter skillet.

Å få filene er ikke å få rettighetene

Den andre antakelsen som ikke holder, er at mottak av koden avgjør noe, men åndsverkloven § 67 tredje ledd fastsetter at overdragelse av eksemplar ikke innbefatter overdragelse av opphavsretten eller noen del av denne, selv om det er et originaleksemplar som overdras. I praksis betyr det at et arkiv med all kildekoden, tilgang til repositoriet og til og med full dokumentasjon likevel ikke er det samme som retten til å bruke den koden, omarbeide den og overdra den til en annen utvikler.

Det virker også motsatt vei, og den siden er mindre kjent, for selskapet kan ha fått de økonomiske rettighetene gjennom en vel skrevet avtale og likevel ikke ha mottatt kildekoden, hvis avtalen ikke hadde en egen plikt til å overlevere den. En tillatelse uten filen er like ubrukelig som en fil uten tillatelse, derfor trenger avtalen begge, og de er to selvstendige punkter, ikke ett punkt som rommer det andre av seg selv.

Når rettighetene overdras riktig, krever loven en viss presisjon, og det er ingen formalitet, for åndsverkloven tillater at den økonomiske delen overdras helt eller delvis, og avtalen kan angi både territorium og tid, men den fyller ikke et taust territorium med det landet der avtalen ble inngått. § 67 sier i stedet at opphaveren ikke skal anses for å ha overdratt en mer omfattende rett enn det avtalen klart gir uttrykk for. For et selskap som virker i flere land, eller planlegger å gjøre det, er det en direkte grunn til å skrive territoriet inn, og en formulering om én bruksform åpner ikke de øvrige.

Det venter én overraskelse til på selskapet som lever på en underforstått lisens og aldri har satt den på papiret. I norsk rett finnes det ingen regel om at en tidsubegrenset opphavsrettslig lisens kan sies opp med seks måneders varsel, eller at et avkall på den retten er ugyldig. Selskapet hvis eneste grunnlag for å bruke systemet er en uskreven forståelse, lever derfor med § 67: bare det avtalen klart dekker, og en uskreven forståelse dekker lite.

Ideelle rettigheter, og det de ikke stanser

I den ideelle delen inngår retten til å bli navngitt og vernet mot at verket endres eller gjøres tilgjengelig på en måte eller i en sammenheng som er krenkende for opphaverens eller verkets anseelse eller egenart, og det blir hos opphaveren, for opphaveren kan ikke fraskrive seg disse rettighetene med mindre det gjelder en bruk avgrenset etter art og omfang. En lovfestet rett til å kalle verket tilbake fra bruk finnes ikke. For et selskap som har bestilt et system, høres det i starten truende ut, for inntrykket oppstår at den tidligere utvikleren på et tidspunkt kan kreve at systemet stanses.

I praksis er det likevel ikke en pålitelig måte å stanse et system på. § 5 verner mot krenkende bruk, og det gir ikke den tidligere programmereren et verktøy til å stanse vanlig vedlikehold eller en omskriving, så lenge endringen ikke krenker det vernet. Norge har ingen regel fra 2023 som slår av omarbeiding som ideell rett for datamaskinprogrammer, og § 71 tar uttrykkelig ikke § 5: den tidligere programmereren beholder de ideelle rettighetene. § 68 sier dessuten at overdragelse av opphavsrett ikke gir rett til å endre verket med mindre annet er avtalt.

§ 69 gir opphaveren krav på rimelig vederlag når retten til å råde over et åndsverk overdras utenfor forbrukerforhold, og bestemmelsen kan ikke fravikes til skade for opphaveren. Den har ingen unntak for datamaskinprogrammer. Direktiv (EU) 2019/790 står i EØS-avtalen, men den norske gjennomføringen er ikke i kraft: Prop. 41 LS (2025–2026) er fortsatt til behandling i komiteen. En programmerer som mener at systemet viste seg mer verdifullt enn partene ventet, kan derfor fortsatt kreve rimelig vederlag på dette grunnlaget.

Det som blir igjen, er muligheten til å bli navngitt som opphaver og vernet mot slik bruk av verket som krenker anseelse eller egenart, og det er en vesentlig mindre risiko å leve med. Det viktige er bare ikke å blande to ting: omarbeiding som ideelt spørsmål stanser ikke vanlig vedlikehold, men omarbeiding som økonomisk rett krever fortsatt rettighetshaverens tillatelse, og utgangspunktet i § 68 er at den som har fått retten overdratt, ikke får endre verket hvis det ikke er avtalt. Har den økonomiske delen blitt igjen hos byrået, trengs altså fortsatt byråets samtykke for å skrive om systemet.

Hva loven gir også uten en god avtale

Også for et selskap som ikke har formalisert noe, gir loven noen muligheter, og det er verdt å vite hvilke av dem avtalen kan ta fra deg, og hvilke den ikke kan. Åndsverkloven § 41 første ledd lar den som har rett til å bruke et datamaskinprogram, fremstille eksemplar av, endre og bearbeide programmet i den utstrekning det er nødvendig for å bruke programmet i samsvar med dets formål, herunder også for å rette feil. Første ledd står ikke blant de leddene som ikke kan fravikes ved avtale, så avtalen kan innskrenke denne retten, og mange avtaler gjør det også.

Å fremstille sikkerhetseksemplar er et annet tilfelle, og det er det eneste i dette avsnittet som avtalen ikke kan ta fra deg, for § 41 andre ledd gir den som har rett til å bruke et datamaskinprogram, rett til å fremstille sikkerhetseksemplar i den utstrekning det er nødvendig for bruken, og det svarer til artikkel 5 nr. 2 i direktiv 2009/24/EF. Direktivets artikkel 8 fastsetter dessuten at avtalevilkår som strider mot artikkel 6 eller mot unntakene i artikkel 5 nr. 2 og 3, er uten virkning.

Her er det verdt å være presis, for forskjellen er fin og lett å overdrive. Åndsverkloven sier for sikkerhetseksemplaret at andre, tredje og fjerde ledd i § 41 ikke kan fravikes ved avtale, og i paragrafen om omvendt utvikling (dekompilering) sier § 42 tredje ledd det samme: bestemmelsene kan ikke fravikes ved avtale. Derfor er det riktig å skrive at norsk rett tar inn direktivets artikkel 8 både for sikkerhetseksemplaret og for omvendt utvikling; det er ikke slik at unntaket for omvendt utvikling bare står i direktivet.

Omvendt utvikling er tillatt smalt og på vilkår: den kan gjøres for å oppnå funksjonelt samvirke mellom et selvstendig utviklet datamaskinprogram og andre programmer, hvis opplysningene ikke tidligere har vært lett tilgjengelige, den utføres av den som har rett til å bruke et eksemplar, og handlingene er begrenset til de delene som samvirket krever. Opplysningene som er innhentet, må ikke brukes til andre formål eller til utvikling av et program som vesentlig svarer til det opprinnelige, og denne utveien er nyttig, men smal, og ingen bedrift ønsker at den skal være den eneste.

I systemet er det mye kode som aldri blir din

Et skreddersydd system er nesten aldri bare den koden utvikleren skrev, for det meste av volumet kommer fra biblioteker og rammeverk som allerede fantes. Den koden blir aldri din eiendom, ikke i noen avtale, for du får en lisens fra dem som har skapt den, og denne forskjellen er viktig nettopp når noen lover å overdra alle rettigheter til systemet.

De permissive lisensene skaper ikke noe problem, for de krever lite og begrenser ikke hvordan det ferdige systemet kan brukes i næringsvirksomhet. MIT-lisensen tillater å bruke, kopiere, endre, slå sammen, publisere, spre og selge, så lenge opphavsrettsmerknaden og selve lisensen beholdes, og programvaren overleveres som den er, uten garantier, mens Apache 2.0-lisensen legger til en uttrykkelig patentlisens og krever at endringer merkes. Begge er forenlige med et lukket kommersielt system, de fleste moderne rammeverk er den ene av dem, og nettopp derfor krever denne delen av systemet vanligvis ingen forhandling.

Copyleft-lisenser krever oppmerksomhet, ikke panikk, og det er nettopp her det oftest fortelles halve sannheter, selv om Free Software Foundation på GPL-spørsmålssiden sin skriver klart at et selskap som kjører et endret GPL-program på sitt eget nettsted, ikke er nødt til å publisere den endrede kildekoden, for copyleft-plikten inntrer når kopier overlates til andre, ikke når programmet brukes hos en selv. Å fremstille og bruke flere kopier innenfor én organisasjon er ikke spredning, mens å overlate kopier til andre organisasjoner, også oppdragstakere til bruk utenfor bedriften, allerede er det.

Unntaket er Affero-lisensen, og det er nettopp dens § 13 — nettverksinteraksjonsklausulen (AGPL §13) — som overrasker, for hvis du endrer programmet og den endrede versjonen lar brukere kommunisere med den på avstand over et datanett, da skal disse brukerne tilbys mulighet til å motta den tilsvarende kildekoden. Vilkårene er to, og begge trengs: endring og fjerninteraksjon med brukere, derfor er det ikke riktig å si at all bruk av en Affero-lisens krever publisering av kildekode, og det er ikke riktig å si at ett slikt bibliotek automatisk legger hele systemet under seg, for det avhenger av hvordan komponentene er koplet.

Kildekode-deponering hos tredjepart, og hva den faktisk gir

Kildekode-deponering (source code escrow) er en trepartsordning der utvikleren overleverer kildekoden til en nøytral oppbevarer, men oppbevareren utleverer den til bestilleren først når det tilfellet som er beskrevet i avtalen, inntreffer, og typiske tilfeller er insolvens, at virksomheten opphører, eller vesentlig mislighold av vedlikeholdsplikten etter varsel. I Norge finnes det ingen lov som fastsetter eller engang lister opp disse tilfellene, derfor er alt som virker her, det partene selv har skrevet, og derfor skal deponeringsavtalen leses like nøye som selve utviklingsavtalen.

Deponeringen gir nøyaktig det som er deponert, og først når det som er beskrevet, inntreffer, men den overdrar ikke i seg selv opphavsrett, for der gjelder igjen § 67 tredje ledd om at overdragelse av eksemplar ikke innbefatter overdragelse av opphavsretten, og den lærer ingen å kjøre systemet. Selskapet NCC Group, som har solgt denne tjenesten i flere tiår, innrømmer det selv i materialet sitt: at kildekoden finnes i depotet, er én ting, evnen til å kompilere den en annen, og nettopp derfor selger det samme selskapet også kontroll av det deponerte innholdet. Det er en parts vurdering, men det er en innrømmelse om kjernetjenestens svake punkt, og derfor kan den brukes.

Moderne systemer har også en annen brist, som ikke har med den juridiske siden å gjøre i det hele tatt: hvis systemet kjører som tjeneste på utviklerens infrastruktur, løser kildekode uten kjøremiljø, konfigurasjon og data den minste delen av problemet, for mottakeren sitter igjen med et arkiv, ikke et virkende system. I praksis tettes den bristen ved å utfylle deponeringen med en avtale om hvem som overtar miljøet, og hva som skjer hvis regningene for webhotellet blir stående ubetalt, og nettopp disse punktene mangler vanligvis på deponeringens standardskjemaer.

Det finnes også et rettslig hinder som ligger i insolvens, ikke i opphavsrett: i et konkursbo kan det deponerte og utleveringen av det komme i strid med boets råderett, altså nettopp i det tilfellet deponeringen oftest kjøpes for. Den praktiske slutningen er ikke å avstå fra deponering, men ikke å betrakte den som en erstatning for skriftlig overdragelse av rettigheter og jevnlig utlevering av kildekode.

Hvor repositoriet ligger, og hvor dataene ligger

Spørsmålet om hvor koden og dataene ligger, avgjør mer enn spørsmålet om hvem de tilhører, for rettigheter uten tilgang er et langsomt problem. GitHubs dokumentasjon beskriver klart at en organisasjon er en felles konto som eier repositorier, at man ikke logger inn som organisasjonen, for mennesker logger inn med personlige kontoer, og at eierne av organisasjonen alltid har tilgang til alle repositoriene; et repositorium kan tilhøre enten en personlig konto eller en organisasjon, og dette valget er viktigere enn det ser ut.

Hvis repositoriet tilhører utviklerens personlige konto, er kundens tilgang bare medarbeidertilgang, som kontoeieren kan ta fra deg når som helst, og når hen går fra prosjektet, tar hen også med seg selve adressen. Hvis repositoriet tilhører kundens organisasjon, der utvikleren er invitert som medlem, betyr et farvel at én tilgang tas bort og ingenting mer, og det er en av de få tingene i denne artikkelen som kan rettes på én dag og uten advokat.

Data er et eget spørsmål, og der handler det ikke lenger om opphavsrett: hvis utvikleren behandler personopplysninger på dine vegne, altså kjører produksjonsmiljøet, kommer til kunde- eller ansattopplysninger eller tar sikkerhetskopier, da er du behandlingsansvarlig og utvikleren databehandler i personvernforordningens forstand. Forordningens artikkel 28 krever en skriftlig avtale der gjenstanden for og varigheten av behandlingen, behandlingens art og formål, typen personopplysninger og kategorier av registrerte samt den behandlingsansvarliges rettigheter og plikter er fastsatt.

Rent kodeskrivingsarbeid uten tilgang til personopplysninger utløser ikke artikkel 28, derfor trenger ikke hver utviklingsavtale en databehandleravtale. Grensen er enkel og etterprøvbar: hvis utvikleren kan se ekte kundedata, trengs den, men hvis utvikleren bare arbeider med testdata og ikke ser produksjonsmiljøet, trengs den ikke, og det i seg selv er et argument for at testmiljøet skal være atskilt.

Hva du får, og hva du samtidig tar på deg

Logikken i denne artikkelen har så langt vært ensidig, derfor er det ærlig også å si den andre siden: full kontroll over et skreddersydd system er ikke bare en gevinst, men også et sett forpliktelser som ikke forsvinner. For ferdig programvare sørger produsenten for vedlikehold, sikkerhetsoppdateringer og kompatibilitet med nye miljøer, og det ligger i abonnementet, mens det for et skreddersydd system sørger eieren for, altså du, og det er en direkte utgift som dukker opp hvert år enten noe i systemet endres eller ikke.

Det andre du tar på deg, er at systemet eldes, stille og uten å vise seg på noen måte før noen leter etter det. Systemet hviler på språk- og rammeverkversjoner der produsentene setter støttetid, og etter at den tiden er ute, lappes ikke nye sårbarheter lenger, selv om systemet fortsetter å kjøre akkurat som før og ingen skjerm varsler om det. Det er ikke et forbud mot å kjøre et eldre system, men det er øyeblikket der eieren overtar risikoen, og de konkrete datoene for PHP og Laravel har vi samlet i artikkelen om hva det betyr å velge PHP og Laravel, derfor gjentar vi dem ikke her.

Det tredje er markedet, og til en ferdig plattform er en spesialist forholdsvis lett å finne, for de læres opp og det er flere av dem, mens et skreddersydd system bare er kjent av dem som bygde det, og en ny utvikler må få tid til å sette seg inn før hen kan endre noe trygt. Det betyr ikke at en overtakelse er umulig, men det betyr at den koster, og den kostnaden dukker opp akkurat når forholdet til den forrige utvikleren allerede er slutt.

Nettopp derfor er spørsmålet om hva du eier, ingen juridisk formalitet, men et spørsmål om hvor dyrt det neste valget blir. Et selskap med skriftlig overdragelse, kildekode i eget repositorium og en liste over komponentene som er brukt, kan lete etter en ny utvikler i løpet av en uke, mens et selskap uten alt dette først finner ut hva det i det hele tatt har lov til å gjøre, og først deretter begynner å lete, og det er forskjellen mellom en samtale fra en posisjon og en samtale fra et behov.

Hva du skal skrive inn i avtalen mens det ennå går

Alle de foregående avsnittene leder fram til et lite sett punkter som er verdt å skrive inn i avtalen før arbeidet starter, for etter overleveringen er forhandlingsposisjonen mye svakere. Det første er skriftlig overdragelse av de økonomiske rettighetene, med navn på hvilke rettigheter som går over, på hvilket territorium og for hvilken tid, for hvis territoriet ikke er angitt, fyller ikke loven inn med det landet der avtalen ble inngått: § 67 gir ikke mer enn det avtalen klart uttrykker. Det andre er en bekreftelse på at byrået har fått dem fra sine ansatte og underleverandører, for uten dette leddet kan selve overdragelsen være tom.

Det tredje er jevnlig overlevering av kildekoden og alt som trengs for å kompilere den, ikke en engangsoverlevering ved prosjektets slutt, og det fjerde er at repositoriet ligger på organisasjonskontoen din allerede fra første dag. Det femte er en liste over komponenter med åpen kildekode og lisensene deres, for uten denne listen vet ingen senere hva som er i systemet og på hvilke vilkår; det sjette er en databehandleravtale hvis utvikleren vil se ekte data, og det sjuende er en avtale om hva som skjer med miljøer, nøkler og tilganger når samarbeidet tar slutt.

Ingen av disse punktene krever en lang tekst, ingen av dem strider mot et godt samarbeid, og ingen ærlig utvikler innvender mot dem, for de skriver ned nettopp det begge parter likevel mener. Det eneste de endrer, er at avtalen ikke lenger avhenger av om de konkrete menneskene om tre år fortsatt arbeider i det samme selskapet, og om noen husker det som den gang ble sagt muntlig. Disse punktene er verdt å kreve av enhver utvikler, også av oss, og å skrive dem inn i avtalen før arbeidet starter. Vår side om utvikling av skreddersydde forretningssystemer lover i dag å overlevere kildekode, dokumentasjon og infrastrukturkonfigurasjon ved arbeidets slutt, og nettopp derfor er det tredje punktet på denne listen, altså jevnlig overlevering underveis, verdt å avtale særskilt, ikke å ta for gitt. Vil du at vi ser på en avtale du allerede har, skriv til oss.