HEVING AV IT-KONTRAKTER

Det juridiske fakultet HEVING AV IT-KONTRAKTER - En analyse av hva som kan lede til heving, kundens hevingsadgang og virkningene av hevning i utviklingskontrakter, med henblikk på utvalgte standardkontrakter Marte Sofie Hatling Masteroppgave i Rettsvitenskap, mai 2017

Innholdsfortegnelse 1 INNLEDNING... 1 1.1 Presentasjon av tema og problemstilling... 1 1.2 Avgrensninger... 3 1.3 Metode og rettskildebildet... 4 1.3.1 Lovgivning og obligasjonsrettslige prinsipper... 4 1.3.2 Kontrakter og kontraktspraksis... 4 1.3.3 Rettspraksis... 5 1.3.4 Juridisk teori... 6 1.4 Videre fremstilling... 6 2 IT-KONTRAKTER... 7 2.1 Avtaleinngåelse, valg av kontrakt og kontraktsutforming... 7 2.2 Utvalgte standardkontrakter... 9 2.2.1 SSA-S... 10 2.2.2 PS 2000 Sol... 10 2.2.3 IKT SUP-04... 11 2.3 Tolking og utfylling av standardvilkår i utviklingskontrakter... 11 2.4 Særtrekk med IT-kontrakter... 14 2.4.1 Primærytelsen... 14 2.4.2 Spesifikasjons- og løsningsbeskrivelse... 15 2.4.3 Modeller for utviklingen... 16 2.4.4 Kundens medvirkning... 19 2.4.5 Testing av ytelsen... 20 3 KUNDENS HEVINGSRETT ETTER KONTRAKTENE... 21 4 MISLIGHOLD AV KONTRAKTEN... 22 4.1 Om mislighold... 22 4.2 Antesipert mislighold... 23

4.3 Levering, godkjennelse og risikoovergang... 25 4.3.1 Risikoen for mislighold... 26 4.3.2 Betydningen av godkjennelse av leveransen... 27 4.4 Forsinkelse i levering av programvaren... 29 4.4.1 Konvensjonalbot eller dagbot... 30 4.5 Mangel ved programvaren... 32 4.5.1 Konkret mangelsvurdering... 32 4.5.2 Abstrakt mangelsvurdering... 34 4.5.3 Krav til funksjonalitet og ikke-funksjonelle krav... 36 4.5.4 Undersøkelses- og opplysningsplikt... 37 5 VILKÅRET OM VESENTLIG MISLIGHOLD... 41 5.1 Terskelen for heving av utviklingskontrakter... 41 5.2 Momenter i helhetsvurderingen... 43 5.2.1 Misligholdets karakter og omfang... 43 5.2.2 Spesifikasjonsbeskrivelse og løsningsbeskrivelse... 44 5.2.3 Formålet med kontrakten og produktet... 45 5.2.4 Misligholdets betydning for kunden... 46 5.2.5 Skyld og aktsomhet... 46 5.2.6 Forbehold fra leverandøren... 47 5.2.7 Profesjonalitet, kyndighet og styrkeforhold... 47 5.2.8 Prosjektets omfang og kompleksitet... 48 5.2.9 Virkningen av heving... 48 5.3 Avveining av momentene... 49 6 HEVINGSOPPGJØRET... 51 6.1 Standardkontraktene... 51 6.2 Bakgrunnsretten... 52 7 AVSLUTTENDE BEMERKNINGER... 53

8 REFERANSELISTE... 56 Vedlegg... 60 Vedlegg 1: Den Norske Dataforening Veiledning for utarbeidelse og bruk av kontrakten. 60

1 INNLEDNING 1.1 Presentasjon av tema og problemstilling Temaet for avhandlingen er heving av IT-kontrakter. Å bidra til avklaring rundt temaet heving av IT-kontrakter, nærmere bestemt utviklingskontrakter og angi retningslinjer for hevingsvurderingen er formålet med avhandlingen. IT er en forkortelse for informasjonsteknologi. Med informasjonsteknologi menes teknologi som muliggjør behandling av informasjon i digital form. 1 Rettslige problemstillinger som oppstår i tilknytning til informasjonsteknologi, omtales som IT-rett. 2 Tjenestene innenfor IT-rett er ulikeartede. Man kan skille mellom kjøp, utvikling, konsulent- eller bistandstjenester og driftstjenester. For samme ytelse kan det foreligge en kombinasjon av to eller flere av disse tjenestene, som ofte vil være regulert i ulike kontrakter. IT-kontrakter utgjør en særegen kontraktstype, og plasserer avhandlingen innenfor den spesielle kontraktsrett. Utviklingskontrakter er en type IT-kontrakter og er den kontraktstype avhandlingen tar for seg. For avhandlingen er det utvalgt tre ulike utviklingskontrakter fra ulike aktører i bransjen, som vil presenteres i pkt. 2.2. Utviklingskontrakter omhandler utvikling av programvare. Programvare er binære (bestående av enere og nuller) filer som gjør det mulig å bruke elektronikk. 3 Programvare vil normalt skapes gjennom prosessen programmering. Ved programmering konstrueres kildekode som kan sette i gang prosesser eller mekanismer. Når programvaren er ferdig produsert, kan den integreres på en maskinvare. 4 Programvaren kan brukes gjennom ulike former for maskinvare i elektroniske apparater. Maskinvaren er en fysisk gjenstand, mens programvaren kan anses som elektronisk skrift og er ikke i seg selv håndgripelig. I de fleste maskindrevne apparater vi benytter i dagliglivet 1 Henrik Udsen. IT-RET. 3. utgave, København, 2016 s. 25 2 Op. cit 3 https://snl.no/programvare (sist lest 02.04.17) 4 https://snl.no/dataprogram (sist lest 02.04.17) Side 1 av 60

finnes det programvare. Programvare kan finnes i alt fra mobiltelefoner til satellitter og atomraketter. I dagens samfunn forbindes programvare trolig ofte med applikasjoner, også kalt brukerprogrammer. 5 Applikasjonene er laget for å anvendes på medier som mobiltelefoner, nettbrett og datamaskiner. I IT-bransjen skilles det mellom spesialutviklet og standard masseprodusert programvare. 6 Microsoft Office, Mac OS X 10, Google Chrome, itunes og Outlook er eksempler på standard masseprodusert programvare. Spesialutviklet programvare er programvare som utvikles helt fra bunnen, uten bruk av tidligere utviklet programvare. En mellomting mellom spesialutviklet og standard masseprodusert programvare er tilpasset standard programvare. 7 Denne formen for programvareutvikling har blitt mer vanlig, og er muligens blitt den vanligste utviklingsformen. 8 Slik tilpasning kan for eksempel skje av moduler, som er biter av ferdig programvare. 9 Modulene kan igjen videreutvikles på ulike måter, og etter tilpasning for kunden. Det er først og fremst spesialutviklet og tilpasset standard programvare som behandles i avhandlingen. Standard masseprodusert programvare vil som oftest være ferdig utviklet, og omfattes dermed ikke direkte av kontraktsformen utviklingskontrakter. Alle disse formene for programvare har likevel noen likhetstrekk, som det senere vil belyses. I et utviklingsprosjekt vil en leverandør vanligvis være ansvarlig for utvikling av programvaren til en kunde. Partsforholdet leverandør og kunde er det normale i en utviklingskontrakt. Leverandøren er ofte den sterkere part med særskilt kyndighet og erfaring. 10 At kunden mangler den kunnskap og erfaring leverandøren besitter, vil gjerne være bakgrunnen for at kunden henvender seg til leverandøren. Hevingsmulighetene i IT-kontrakter er normalt gjensidig for kunden og leverandøren. Kundens hevingsrett anses å være den mest interessante fordi spørsmål tilknyttet mangler og 5 https://snl.no/dataprogram (sist lest 02.04.17) 6 Arve Føyen, Kristine M. Madsen, Christine Klûwer og Elisabeth Wille. Kontrakter for utvikling av programvare. Oslo, 2006 s. 42 7 Olav Torvund. Kontraktsreguleringer - IT-kontrakter. Oslo, 1997 s. 24 8 Udsen (2016) s. 483 9 Føyen (2006) s. 41 10 Torvund (1997) s. 23 og Føyen (2006) s. 31 Side 2 av 60

forsinkelse aktualiseres, noe som igjen reiser særskilte problemstillinger for utviklingskontrakter. Kundens medvirkningsplikt og brudd på denne kan gi grunnlag for heving. Medvirkningsplikten vil likevel i noen grad bli behandlet i tilknytning leverandørens forpliktelser, fordi dette kan være innvirkende på leverandørens mislighold. Oppstår problemer under utviklingen av programvaren eller etter at programvaren er levert, kan det være grunnlag for misligholdsbeføyelser. Heving er en av flere misligholdsbeføyelser innenfor kontraktsretten. Av alle misligholdsbeføyelsene vil heving kunne være den mest inngripende, og benyttes derfor gjerne etter forsøk på andre løsninger og beføyelser. De problemstillingene som vil bli behandlet er hva som kan lede til et hevingsspørsmål, hva som gir grunnlag for heving og virkningene av heving. Herunder reises også flere underproblemstillinger. Spørsmålet om heving av IT-kontrakter vil aktualisere et eget sett med problemstillinger, som avhandlingen vil ta sikte på å redegjøre for. Dersom en av partene ønsker å heve kontrakten, vil kontraktsforholdet normalt ha nådd et konfliktfylt og kritisk punkt. I 2016 viste forskningsresultater at halvparten av alle offentlige IT-prosjekter møter på vanskeligheter. 11 De konflikter som forskningen utpeker er ikke spesielt for det offentlig, og vil også kunne ramme private prosjekter. Fordi konfliktnivået i IT-prosjekter er av et slikt nivå, er heving av IT-kontrakter en aktuell problemstilling. 1.2 Avgrensninger Partsforholdet mellom leverandør og kunde vil være utgangspunktet for avhandlingen. Forholdet til underleverandører og andre tredjepersoner faller dermed utenfor avhandlingen. Heving kan ikke skje ipso facto, altså uten forutgående kommunikasjon. 12 Avhandlingen forutsetter at det foreligger en hevingserklæring eller en reklamasjon i forkant av kravsfremsettelsen. Reklamasjon som et mulig vilkår for heving av utviklingskontrakter er derfor ikke omfattet av avhandlingen. 11 https://www.regjeringen.no/contentassets/9018344feae44c1f9a2a114e768ebd1b/suksess_fiasko_offentlige_iktprosjekter.pdf (sist lest 02.04.17) og http://www.tv2.no/a/8353567/ (sist lest 02.04.17) 12 Hagstrøm (2011) s. 462 Side 3 av 60

Typer av kontraktsbrudd kan inndeles i forsinkelser, faktiske mangler og rettsmangler. 13 Det avgrenses mot rettsmangler fordi problemstillingen fordrer en for omfattende drøftelse. I tilfeller hvor heving er aktuelt, vil kravsfremsetteren ofte også ha lidt et tap. Erstatning vil derfor være nærliggende. Erstatning i form av konvensjonalbot vil kort behandles i tilknytning forsinkelser. En utførlig behandling av erstatning og andre misligholdsbeføyelser faller utenfor problemstillingen. Opphavsretten til produktet vil etter bearbeidelsen tilkomme leverandøren etter åndsverksloven 1 nr. 12. 14 Når programvaren er ferdig utviklet vil kunden kunne få eiendomsrett, og eventuelt opphavsrett til produktet. 15 Disse reglene vil ikke bli behandlet nærmere. Brudd på immaterielle rettigheter som et eventuelt hevingsgrunnlag vil heller ikke bli behandlet. Dette er sideordnede problemstillinger, og faller utenfor avhandlingens kjerneområde. 1.3 Metode og rettskildebildet 1.3.1 Lovgivning og obligasjonsrettslige prinsipper Det finnes ingen særlov for IT-kontrakter. Hvilken lov som kan anvendes for utfylling av utviklingskontrakter kan ikke besvares entydig, og er nærmere behandlet i pkt. 2.4. Obligasjonsrettslige prinsipper kan uavhengig av kontraktsområdet, benyttes for utfylling av kontrakten. Deriblant er vilkåret om vesentlig mislighold for å foreta heving. 16 Prinsippene er deklaratoriske, og partene kan velge å avtale løsninger utenfor disse. 17 1.3.2 Kontrakter og kontraktspraksis En kontrakt vil normalt være den primære rettskilde for et utviklingsprosjekt. Kontrakten danner utgangspunktet for forholdet mellom partene og prosjektets utvikling. 13 Torvund (1997) s. 171 og Føyen (2006) s. 459-460 14 Lov om opphavsrett til åndsverk m.v 12. mai 1965 nr. 2 15 Torvund (1997) s. 28 16 Rt. 1999 s. 408 på s. 420 17 Erlend Haaskjold. Kontraktsforpliktelser. 2. utgave, Oslo, 2013 s. 132 Side 4 av 60

Det er vanlig at standardkontrakter benyttes ved levering av IT-ytelser. På grunn av manglende lovregulering, er IT-bransjen i stor grad selvregulert. 18 De ulike kontraktsreguleringene er mangfoldige. Området er søkt regulert gjennom standardkontrakter for utvikling av programvare av flere ulike aktører, hvorav de mest kjente omtales i pkt. 2.2. Når en standardkontrakt blir vedtatt, har denne vanligvis kun betydning for partene. Standardkontrakter kan også gi uttrykk for bransjesedvane, og dermed i en viss utstrekning få betydning for utenforstående parter. 19 I tillegg utgjør kontraktspraksis en relevant rettskilde. 20 Å avdekke bransjesedvane og kontraktspraksis byr imidlertid på et eget sett av utfordringer. Disse utfordringene skyldes blant annet behovet for bransjekunnskap, og som det vil vises til i de neste punktene, manglende rettskilder. Avhandlingen undersøker hevingsadgangen med utgangspunkt i utvalgte standardkontrakter. Disse presenteres i pkt. 2.2 1.3.3 Rettspraksis Det foreligger lite rettspraksis som omhandler utviklingskontrakter i IT-retten. Noe av årsaken kan være at kontraktspartene ofte avtaler at tvisten skal løses gjennom voldgift, og at resultatet skal holdes fortrolig etter voldgiftsloven 5 jf. 2. 21 I andre tilfeller kan kostnadene allerede ha nådd et svært høyt nivå og partene anser risikoen for tap som avgjørende for å unngå prosessen. Det er nok derfor ikke uvanlig at partene i et utviklingsprosjekt inngår forlik, fordi de ser seg bedre tjent med å gå i null eller med et visst tap, enn å risikere et betydelig større tap. I tillegg vil behandling for domstolene være tidkrevende, noe som også kan begrunne hvorfor parter i et utviklingsprosjekt unngår å foreta rettslige skritt. Konsekvensen av privat behandling i voldgift og vegringen mot å bringe saker for domstolene, gjør trolig at det per i dag ikke foreligger noen avgjørelser fra Høyesterett som omhandler IT-kontrakter. Antallet saker fra underretten er heller ikke mangfoldig. Praksis fra underretten har også begrenset rettskildemessig verdi og er ikke alltid tilgjengelig. Hvilken 18 Mads Bryde Andersen. IT-RETTEN. København, 2005 s. 250 19 Haaskjold (2013) s. 25 20 Op. cit 21 Lov om voldgift (voldgiftsloven) 14. mai 2004 nr. 25 Side 5 av 60

vekt underrettsdommer kan tillegges har vært omdiskutert i teorien. 22 Høyesterett må ikke ta hensyn til underrettspraksis, og kan sette denne til side. Underrettspraksis kan sies å ha vekt på linje med juridisk teori. 23 Hvor det er lite eller ingen høyesterettspraksis vil underrettspraksis som tar stilling til tvilsomme juridiske spørsmål, derimot ha større interesse. 24 Underrettspraksis benyttes for å belyse hvordan enkelte av problemstillingene som reises i avhandlingen kan løses. Det lave antallet saker for domstolene, gjør at det gjennom rettspraksis ikke er mulig å gi et helhetlig bilde av konfliktene innenfor IT-kontraktsrett. Å konstatere gjeldende rett vedrørende heving av utviklingskontrakter basert på rettspraksis, er derfor vanskelig. Likevel har rettspraksis om heving fra andre rettsområder som angir generelle betraktninger, relevans ved vurderingen av heving av utviklingskontrakter. 25 Slik rettspraksis vil bli benyttet for å angi generelle utgangspunkter og retningslinjer. 1.3.4 Juridisk teori Omfanget av juridisk teori som omhandler utviklingskontrakter er begrenset. Den nyeste juridiske teori på området fra Norge er fra 2006. Fra våre naboland finnes det også nyere relevant juridisk teori. På privatrettens område har nordisk rett mange likhetstrekk som følge av det nordiske lovsamarbeidet. 26 Juridisk teori fra andre nordiske land kan derfor benyttes for nærmere avklaring av avhandlingens problemstillinger. 1.4 Videre fremstilling I pkt. 2 vil det vises til hvordan valg ved avtaleinngåelsen kan få betydning for det videre kontraktsforholdet. Kontraktene som benyttes i avhandlingen og prinsipper for tolking og utfylling av standardkontrakter vil bli presentert og redegjort for. Til slutt vil enkelte særtrekk ved IT-kontrakter av relevans for spørsmål om kundens hevingsrett, trekkes frem. 22 Nygaard (2004) s. 210 23 Op. cit 24 Op. cit 25 Torvund (1997) s. 29 26 Nygaard (2004) s. 220 Side 6 av 60

Hevingsadgangen beror på nærmere bestemte vilkår. Det overordnede spørsmålet er om det foreligger en rett til å heve kontrakten, og for denne avhandlingen, om kunden har hevingsrett. I pkt. 3 presenteres kundens hevingsrett etter de utvalgte standardkontraktene. Heving forutsetter at mislighold inntrer. Mislighold og de ulike formene for mislighold og tilhørende vilkår vil bli behandlet i pkt. 4. Hovedvilkåret for heving er ofte at det foreligger vesentlig mislighold. Hva som ligger i vesentlig mislighold, hvilken terskel vilkåret oppstiller for utviklingskontrakter og momenter i vurderingen vil være sentralt for avhandlingen. Dette behandles i avhandlingens pkt. 5. Videre vil hevingsoppgjøret og hvilke virkninger heving kan få for kontraktsforholdet behandles i pkt. 6. Endelig vil det gis et par avsluttende bemerkninger i pkt. 7. 2 IT-KONTRAKTER 2.1 Avtaleinngåelse, valg av kontrakt og kontraktsutforming Prekontraktuelle forhold kan være av betydning for om kontraktsforholdet leder til heving. Valg av leverandør og kontrakt, samt kontraktens innhold vil være blant disse forholdene. For større prosjekter gjør viktigheten av valg av kontrakt og dens innhold seg særlig gjeldende. Partene kan etter prinsippet om avtalefrihet velge hvem de vil inngå avtale med og hva denne skal omhandle. Det praktiske vil være at kunden fremsetter en spesifikasjonsbeskrivelse med angivelse av ønsker og behov for leverandørens primærytelse. Deretter vil kunden kunne bli møtt med et tilbud fra en leverandør, gjerne i form av en løsningsbeskrivelse, for gjennomføring av utviklingen. 27 Godtar kunden tilbudet foreligger det en bindende avtale. Prinsippet om formfrihet gir avtalepartene valg mellom hvorvidt hele eller deler av avtalen skal inngås i muntlig eller skriftlig form. Ved større og mer kompliserte avtaleforhold om utvikling av programvare er muntlig avtaleinngåelse uvanlig og lite praktisk. Oslo tingretts dom fra 27. november 2001 (TOSLO-2001-11218) belyser hvordan et utviklingsprosjekt basert på muntlig avtaleinngåelse kan lede til vanskeligheter. Saken omhandlet heving av en 27 Torvund (1997) s. 37 Side 7 av 60

muntlig utviklingsavtale om et internettbasert regnskapsprogram. Det forelå en bindende avtale om utvikling, men partene var uenige om innholdet i avtalen. Uenigheten knyttet seg til betaling og ferdigstillelsestidspunkt. Retten måtte derfor vurdere basert på skriftlig dokumentasjon og partenes opptreden hva de hadde forpliktet seg til. Partene hadde begge fremsatt krav om heving. Tingretten kom til slutt frem til at leverandøren ikke hadde forpliktet seg til en fast pris og et endelig ferdigstillelsestidspunkt, og ga følgelig leverandøren medhold i kravet om heving på grunn av kundens betalingsmislighold. Partene kan velge å benytte standardkontrakter utformet av andre, en av partenes egne standardkontrakter eller konstruere en helt ny kontrakt for det aktuelle prosjektet. 28 Preseptorisk lovgivning begrenser kontraktsreguleringene, og vil således kunne innvirke på kontraktsutformingen. Det må bl.a. tas hensyn til regler om straff, personvern, skatt og import/eksport. Hvordan reglene er utformet vil bidra til å minimere usikkerheter og konflikter, og kan motvirke at prosjektet leder til heving. Valg av kontrakt vil følgelig kunne få stor betydning for hvilke rettigheter og krav partene har dersom mislighold inntrer. Kontrakten kan benyttes som et styringsverktøy for gjennomføring av prosjektet. Betydningen av valg av kontrakt fremheves i dom fra Borgarting lagmannsrett 9. desember 2015 (LB-2015-34400). Saken gjaldt et nyoppstartet gründerfirma som hadde engasjert et ITselskap for utvikling av et nytt konsept for salg av klær på internett. Leveransen skulle basert på eksisterende programvare, utvikles spesielt for kunden. Partene inngikk en avtale basert på leverandørens standardvilkår for konsulentarbeid. Retten anså valg av kontrakt som uhensiktsmessig, og uttalte at den har bidratt til at leveransen kom galt ut fra starten av. Det ble lagt til grunn at kontrakten ikke var beregnet på utviklingsprosjekt, men på et konsulentforhold, noe som gjorde avtaleforholdet uregulert på flere punkter. I tillegg ble kontrakten ansett å være ubalansert og leverandørvennlig. Retten konkluderte til slutt med at det forelå grunnlag for heving av kontrakten. Valg av uegnet kontrakt kan dermed være et forhold som potensielt leder til heving. 29 28 En av få retningslinjer kontrakts forfattere og avtaleparter må forholde seg til følger av forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger (nr. 732/2013). 29 For å motvirke en slik situasjon, vil veiledninger til valg av kontrakt kunne være hensiktsmessig. Difi har utarbeidet en veiledning, for å forenkle valg av kontrakt. Se https://www.anskaffelser.no/it/statensstandardavtaler/velg-riktig-avtale (sist lest 02.04.17) Side 8 av 60

2.2 Utvalgte standardkontrakter For å belyse hvordan heving og andre forhold av relevans kan reguleres, vil et sett av utvalgte standardkontrakter fra Direktoratet for forvaltning og IKT (Difi), IKT-Norge og Den norske dataforening (DND) bli anvendt i avhandlingen. Difi er en offentlig aktør som står for utformingen av statens standardavtaler (SSA), som kan anvendes for kontrakter vedrørende IT-tjenester. Deres standardavtaler er hovedsakelig utformet for det offentlige. 30 Kontraktene er utformet etter innspill fra leverandør- og kundesiden. 31 IKT-Norge er en interesseorganisasjon bestående av medlemmer med ulik erfaring og kunnskap innenfor IT. 32 Organisasjonen tilbyr medlemmene ulike juridiske tjenester. IKT- Norge representerer leverandørsiden. 33 Kontraktene søker likevel å være balansert mellom kunde og leverandør. 34 DND er ifølge foreningen selv Norges største IT-faglige forening. Foreningen er et forum og fagmiljø av og for profesjonelle og avanserte brukere av IT. 35 Representanter fra kunde og leverandørsiden har i like stort omfang tatt del i utformingen av deres kontrakter, samt juridiske aktører med praktisk erfaring. 36 De nevnte kontraktsutformerne har alle på bakgrunn av kunnskap om IT-bransjen, utformet kontrakter for utvikling av programvare. Aktørene er kjent og deres kontrakter utbredt i bransjen. 37 Kontraktene har flere likhetstrekk, men også forskjeller som gir grunnlag for sammenligning. Disse består av en generell del, men forutsetter også bruk av forhåndsdefinerte bilagssett. 30 https://www.difi.no/om-difi (sist lest 02.04.17) 31 https://www.anskaffelser.no/it/statens-standardavtaler/statens-standardavtaler-ssa 32 https://www.ikt-norge.no/om-ikt-norge/ (sist lest 02.04.17) 33 Føyen (2006) s. 63 34 https://www.ikt-norge.no/butikk/ (sist lest 02.04.17) 35 https://www.dataforeningen.no/om-dnd.134466.no.html (sist lest 02.04.17) 36 https://www.dataforeningen.no/it-kontrakter.160152.no.html (sist lest 02.04.17) 37 Føyen (2006) s. 62 Side 9 av 60

For å ha et best mulig sammenligningsgrunnlag, vil de kontraktene som er beregnet på større utviklingsprosjekter benyttes. For spørsmålet om heving er prosjekter av et visst omfang mest interessante. Begrunnelsen er at disse prosjektene vil ha større sannsynlighet for å møte på utfordringer som igjen kan lede til heving. I likhet med valg av kontrakt vil valg av utviklingsmetode eller modell kunne få betydning for et eventuelt hevingsspørsmål. Det skilles både i kontraktene og for utviklingen mellom fossefallsmodellen og smidig utviklingsmodell. Disse modellene er også utbredt i bransjen. 38 Utviklingsmodellene står på mange måter i motsetning til hverandre. Etter fossefallsmodellen fastsettes kravspesifikasjon og pris ved avtaleinngåelsen, mens utviklingen etter smidig metodikk avtales og foretas gradvis. 39 Skillet mellom disse utypes nærmere under pkt. 2.4.3. 2.2.1 SSA-S For utvikling av programvare tilbyr Difi utviklings- og tilpasningsavtalen (SSA-T) og smidigavtalen (SSA-S) fra juli 2015. Disse kontraktene inneholder svært mange like reguleringer. Det anses likevel som mest hensiktsmessig å anvende smidigavtalen. Denne kontrakten kan i større grad anvendes på både spesialutviklet og standard programvare som tilpasses kunden. 40 SSA-S har derfor noe videre bruksområde enn SSA-T. SSA-S er den mest omfattende av de utvalgte kontraktene hvor den generelle avtaleteksten består av 43 sider. Dette skyldes sannsynligvis at kontraktene fra Difi er utformet med sikte på offentlige anskaffelser. 41 Denne prosessen er lovregulert i lov om offentlige anskaffelser, og fordrer i utgangspunktet en mer omfangsrik kontraktsinngåelse. 42 Samtidig er det mulig å benytte kontrakten for andre kontraktsforhold, og uten en omfattende prosess. Partene kan gjøre endringer i avtaleteksten, og kan således tilpasse kontrakten etter behov. 2.2.2 PS 2000 Sol DND tilbyr blant annet kontraktsstandard for oppdragsbasert, smidig leveranse av programvare (PS 2000 Sol). Kontrakten er oppdatert i 2013 og er beregnet på større prosjekter. I tillegg til bilag, består kontrakten av Avtale som er en fellesbetegnelse for 38 Udsen (2016) s. 506 39 Udsen (2016) s. 507 40 Bekreftet gjennom korrespondanse med Difi 41 Føyen (2006) s. 63 42 Lov om offentlige anskaffelser 17. Juni 2016 nr. 73 Side 10 av 60

oppdragsavtale og bistandsavtale jf. kontraktens pkt. 1.2. PS 2000 Sol den klart mest solgte kontrakten fra DND for utviklingsprosjekter. 43 Det anses derfor som hensiktsmessig å benytte denne for nærmere vurdering. DND har utarbeidet veiledning for utarbeidelse og bruk av PS 2000 Sol. 44 Det følger blant annet av pkt. 1.4 at det er en forutsetning for bruk av kontrakten at partene har en viss erfaring med og modenhet innenfor smidig systemutvikling. Ytterligere fremgår det av pkt. 2.2 at kontrakten er beregnet på prosjekter av lenger varighet. Veiledningen bidrar til større forutberegnelighet for partene ved kontraktsutformingen, og ved valg av kontrakt. 2.2.3 IKT SUP-04 I motsetning til Difi og DND tilbyr IKT-Norge ingen kontrakter for smidig leveranse. Dette utelukker imidlertid ikke at smidig metodikk kan benyttes i kontraktsforholdet. Utviklingskontraktene til IKT-Norge legger likevel i større grad opp til utvikling etter fossefallsmodellen. Avtale om systemutviklingsprosjekt 04 fra september 2010, versjon 5, (heretter forkortet til IKT SUP-04) vil bli anvendt i avhandlingen. Dette er fordi kontrakten er beregnet for større og mer kostbare utviklingsprosjekter. 45 2.3 Tolking og utfylling av standardvilkår i utviklingskontrakter I Høyesteretts dom fra 28. juni 2016 (HR-2016-1447) som omhandler tolking av en standard entreprisekontrakt, gis en rekke generelle uttalelser om tolking av standardvilkår. Høyesterett viser til tidligere avgjørelser hva angår den generelle tolkingen, og fastslår derfor at tidligere rett fortsatt er gjeldende. Når man står overfor en standardavtale, viser retten at alminnelige avtalerettslige prinsipper får betydning. Det gjelder ikke kun en ren ordlydsfortolkning. Andre momenter utenfor avtaledokumentet kan trekkes inn ved tolkingen, herav kontraktens formål og andre reelle hensyn. 46 Videre kan de føringer kontrakten gir for forståelsen av den aktuelle 43 Bekreftet gjennom korrespondanse med IKT-Norge 44 Vedlegg 1 45 https://www.ikt-norge.no/butikk/ (sist lest 02.04.17) 46 HR-2016-1447 avsnitt 38 med henvisning til Rt. 2010 s. 961 Side 11 av 60

bestemmelse, med sikkerhet trekkes inn. 47 Det er også rom for å ta standardens forarbeider og utvikling med hensyn til tidligere versjoner og bakgrunnsrett, i betraktning. 48 For tolking av SSA-S, IKT SUP-04 og PS 2000 Sol er utgangspunktet at den standardiserte kontrakten må tolkes etter ordlyden i sin objektive form. Tolkingsmomenter utenfor kontraktenes ordlyd er imidlertid begrenset. Det foreligger ikke rettspraksis, forarbeider eller juridisk teori som omhandler kontraktene. 49 Ordlyden er således essensiell for å avklare innholdet. De eldre kontrakteksemplarene kan benyttes for å vurdere endringer og som et tolkingsmoment. Veiledningen fra DND kan også være et bidrag i tolkingen av PS 2000 Sol. Om det er tale om ensidige eller gjensidige utformede kontrakter, vil dette også kunne få betydning for tolkingen. 50 Ved gjensidige kontrakter har partene normalt lik mulighet til å påvirke kontraktens innhold. Det vil derfor være større grunn til å ta kontrakten på ordet. De utvalgte standardkontraktene er alle utformet for leverandører og kunder. Imidlertid er de utformet fra ulike hold. Dette gjør at PS 2000 Sol er den eneste av kontraktene som kan anses som fullstendig gjensidig utformet. SSA-S er også utformet av leverandører og kunder, men har vært hevdet å være mer kundevennlig. 51 IKT SUP-04 er utformet av leverandørsiden. Hvem som står for utformingen av bilagene, vil derimot kunne variere. Bilagene er ikke nødvendigvis gjensidige, slik som den generelle del i standardkontrakten. Ved ensidige kontraktsreguleringer vil uklarhetsregelen kunne få betydning. Kontraktsutformeren må bære tvilsrisikoen ved en eventuell uklarhet i kontrakten, typisk leverandøren. 52 Fremstår kontrakten som fordelaktig for leverandøren eller kunden, vil dette også kunne få betydning for tolkingen. 53 Fordi IKT SUP-04 er utformet av leverandørsiden, er det derfor mulig at kontrakten er mer gunstig for leverandører, noe som kan få utslag i tolkingen. Selv om det 47 HR-2016-1447 avsnitt 43 48 HR-2016-1447 avsnitt 45 49 Juridisk teori er ikke oppdatert hva gjelder de nyeste standardkontraktene som anvendes i avhandlingen. 50 HR-2016-1447 avsnitt 45 51 Føyen (2006) s. 63 52 Se LB-2015-34400 53 I LB-2015-34400 ble kontrakten ansett som leverandørvennlig. Kontrakten ble tolket i leverandørens disfavør. Side 12 av 60

utformes andre løsninger i bilag, må det også tas hensyn til rangbestemmelser som løser en eventuell motstrid med den generelle del. 54 Bakgrunnsretten vil også kunne få betydning for tolkingen, når løsningen ikke klart følger av kontrakten. 55 Som det vil vises i den videre fremstillingen, er heving og tilhørende problemstillinger i de utvalgte kontraktene ikke uttømmende regulert. Et visst rom for utfylling vil derfor være aktuelt hvor kontrakten er taus eller ufullstendig. Å gi et entydig svar på valg av bakgrunnsrett er imidlertid vanskelig, fordi kontrakter om utvikling av programvare har elementer fra flere kontraktsområder. 56 Obligasjonsrettslige prinsipper kan som nevnt få betydning. Prinsippene løser imidlertid ikke med sikkerhet alle problemstillinger, og er ikke nødvendigvis uttrykt i alle bestemmelsene i kontraktslovgivningen. 57 En mer utførlig vurdering av om bestemmelsen skal gis anvendelse, bør da foretas. For utviklingskontrakter er kjøpsloven fremhevet i juridisk teori som den mest anvendelige loven. 58 Føyen m.fl. drøfter på bakgrunn av ulik teori om kjøpsloven kan gis direkte anvendelse. 59 Det fremholdes at det for rene salg av standard programvare vil kjøpsloven kunne gis anvendelse. Derimot vil spesialutviklet programvare falle helt utenfor. 60 I LB-2015-34400 som omtalt i pkt. 2.1 anvendte lagmannsretten obligasjonsrettslige prinsipper ved løsning av tvisten om heving. Valg av bakgrunnsrett var ikke et tema. Årsaken kan være at retten anså bruk av kjøpsloven eller prinsippene som lite betydelig, fordi de ofte gir uttrykk for det samme. 61 54 Rangordningen er regulert i SSA-S pkt. 1.3 og i PS 2000 Sol Del 1. IKT SUP-04 inneholder derimot ikke en en slik bestemmelse. 55 HR-2016-1447 avsnitt 46 56 Føyen (2006) s. 47 57 Hagstrøm (2011) drøfter dette på s. 70-76 58 Lov om kjøp 13. mai 1988 nr. 27 59 Føyen (2006) s. 47 60 Føyen (2006) s. 52 61 I Rt. 1999 s. 404 uttalte retten at direkte anvendelse av kjøpsloven ikke har stor praktisk betydning, da lovens sentrale bestemmelser i stor grad gir uttrykk for obligasjonsrettslige prinsipper. Side 13 av 60

Føyen m.fl. har også gitt uttrykk for at det foreligger en alminnelig enighet om at det kan trekkes analogier fra kjøpsloven. 62 Bruk av analogi er i tillegg konstatert i etterfølgende rettspraksis. Dom fra Oslo tingrett av 26. november 2009 (TOSLO-2009-72662) omhandlet heving av kontrakt om utvikling av EDB programvare for inkasso og realisasjon av panteobjekter. For spørsmålet om bakgrunnsrett, uttalte retten at det bør kunne trekkes analogier fra kjøpsloven hvor kontrakten er taus. At dette må avgjøres konkret for hvert enkelt spørsmål, ble også presisert. Uttalelsene fra teorien forstås slik at jo større element av standard programvare ytelsen inneholder, jo mer taler dette for å gi kjøpsloven direkte anvendelse. Legges det til grunn at det er mindre vanlig at programvare utvikles helt fra bunnen av som omtalt i pkt. 1.1, tilsier dette at kjøpsloven for de fleste utviklingskontraktene vil kunne få anvendelse. Samtidig er det slik teorien og rettspraksis viser ikke nødvendig å gi kjøpsloven direkte anvendelse. Bruken av analogi eller av de alminnelige obligasjonsrettslige prinsipper er ikke like omstridt, og kan gi en like fullgod løsning. 2.4 Særtrekk med IT-kontrakter 2.4.1 Primærytelsen Leverandørens primærytelse i utviklingskontrakter er programvare, i mer eller mindre spesialisert form, jf. pkt. 1.1. Utvikling av programvare kjennetegnes ved at kontraktsgjenstanden skapes gjennom en tilvirkningsprosess, og kan som et endelig resultat representere noe helt nytt. 63 Dette selv om produktet inneholder deler fra ferdig utviklet programvare. Elementer fra kjøp, entreprise og konsulenttjenester er å gjenfinne ved utvikling av programvare, noe som nevnt i pkt. 2.4 gjør klassifiseringen utfordrende. 64 Det er også store variasjoner innenfor de ulike utviklingsprosjekt og kontrakter. 65 Utvikling av programvare kan anses å være i grenseland mellom tilvirkingskjøp og entreprise. 66 Samtidig kan 62 Føyen (2006) s. 42 63 Føyen (2006) s. 231 64 Torvund (1997) s. 27 og Føyen (2006) s. 47 65 Føyen (2006) s. 61 66 Torvund (1997) s. 24 Side 14 av 60

ytelsesformen anses som en særskilt form for tilvirking, slik som ved entreprise. 67 I alle hensender vil utvikling av programvare være nært opp mot tilvirkning, og kunne være omfattet av kjøpsloven 2. Veien frem til det endelige resultat kan by på helt nye utfordringer og usikkerheter. Utvikling av programvare er også et område i rask utvikling. 68 Disse utfordringene kan gi et eget rom for improvisasjon. 69 Likevel må leverandøren ta hensyn til at ytelsen kan utgjøre en sentral del av kundens organisasjon og drift, noe som gjør kunden mer sårbar ved kontraktsbrudd enn for lignende tjenester hvor denne er adskilt fra driften. 70 Klare angivelser av krav og ønsker fra kunden er derfor viktig for å gi nødvendige føringer for leverandørens spillerom. 2.4.2 Spesifikasjons- og løsningsbeskrivelse Utforming av spesifikasjon for utvikling av programvare kan få stor betydning for vurderingen av om det foreligger mislighold og grunnlag for heving. 71 Jo klarere kundens spesifikasjonsbeskrivelse og leverandørens løsningsbeskrivelse er utformet, jo enklere er det å konstatere mislighold og dets omfang. 72 En spesifikasjon bidrar til forutberegnelighet for partene og setter faste rammer for utviklingen. På den andre siden er det ikke alltid hensiktsmessig å angi en fullstendig og utfyllende spesifikasjon. Problemet med på forhånd å spesifisere ytelsen er at kunden ikke alltid har tilstrekkelig kunnskap til angi alle krav. 73 Hvor det er tale om et helt nytt produkt, vil kunden heller ikke kunne basere seg forutgående spesifikasjoner. 74 På denne bakgrunn vil angivelse av løpende spesifikasjoner være mer tilrådelig. Uten tilstrekkelige forkunnskaper og prognoser kan kunden risikere å komme med spesifikasjoner som leder prosjektet i feil retning og som gir uønskede resultater. Med andre ord kan en spesifikasjons- og også en løsningsbeskrivelse være en faktor som leder til heving. 67 Føyen (2006) s. 58 68 Torvund (1997) s. 28 69 Op. cit 70 Torvund (1997) s. 27 71 Omtalt i avhandlingens pkt. 2.1 72 Torvund (1997) s. 65 73 Torvund (1997) s. 66 74 Torvund (1997) s. 73 Side 15 av 60

Spesifikasjonsbeskrivelsen bør uansett inneholde et minimum av spesifikasjoner, for å få prosjektet i gang. Torvund fremhever fire hovedelementer, herav 1) formål, 2) krav til egenskaper ved det som skal leveres 75, 3) løsningsmodell 76, og 4) produkter og/eller tjenester. 77 Med produkter og tjenester menes tilleggsavtaler som for eksempel vedlikeholdsavtale. 78 Er det for eksempel tale om utvikling av en datingapplikasjon må dette angis i spesifikasjonens formål. Formålet kan utformes slik; Tjenesten skal gjøre det mulig for privatpersoner å lage en profil for å komme i kontakt med andre brukere. Videre må egenskaper som gjør det mulig å lage en datingprofil med navn, alder og bilde spesifiseres. Samt muligheten til å kunne bla gjennom og like andres profiler. I tillegg må brukeren kunne matches sammen med andre brukere basert på preferanser som geografi. Om applikasjonen skal kunne brukes på mobil, eller kun på en webside må også angis. Når det gjelder løsningsbeskrivelse anses det ikke som like hensiktsmessig å angi denne eller disse i spesifikasjonen, da det legger føringer for sluttresultatet. Skulle det være ønskelig å endre for eksempel operativsystem, kan dette by på vanskeligheter. Det kan derfor være mer fordelaktig å avvente med angivelse av løsningsmodell. Ved bruk av ovennevnte spesifikasjonsbeskrivelse kan leverandøren også komme med innspill, og nærmere utarbeide en løsningsbeskrivelse. På denne måten har kunden skapt en ramme for leverandørens videre arbeid og for hvilke krav som kan stilles til arbeidet. Forholdet mellom spesifikasjonsbeskrivelsen og løsningsbeskrivelsen er nærmere behandlet under pkt. 5.2.2. 2.4.3 Modeller for utviklingen Fossefallsmodellen, også betegnet som den tradisjonelle eller klassiske metode, forutsetter at det fastsettes en uttømmende kravspesifikasjon i starten av prosjektet. 79 Modellen legger opp til en forutberegnelig løsning, og kan for kunden fremstå som en trygg og kontrollert 75 Nærmere behandlet i avhandlingens pkt. 4.5.3 76 Torvund (1997) s. 80 nevner som et eksempel på løsningsbeskrivelse hvilket operativsystem som skal benyttes 77 Torvund (1997) s. 73 78 Op. cit 79 Føyen (2006) s. 127 Side 16 av 60

gjennomføringsmodell. Fossefallsmodellen gir derimot ikke stort rom for fleksibilitet. 80 Som et alternativ til tradisjonell metode, ble iterativ metode tidligere benyttet. En iterasjon kan defineres som en avgrenset og bestemt tidsperiode for utvikling av programvaren. 81 Eller som en utviklingssyklus/sprint. 82 Etter iterativ metode utvikles programvaren i iterative eller oppdelte utviklingstrinn. 83 Smidig utvikling og kontraktsregulering har i de senere årene blitt mer vanlig. 84 Metoden består blant annet av iterasjoner. Iterativ metode kan derfor anses som en del av smidig metode, og kan således behandles samlet. I tillegg består smidig metode normalt av inkrementell utvikling. 85 Ved inkrementell utvikling foregår utviklingen og iterasjonene i en gradvis økende prosess. For smidig metodikk vil det ikke foreligge en fullstendig kravspesifikasjon ved innledende fase i prosjektet. 86 Metoden innebærer at utviklingen foretas ved kortere og hyppige delfaser, og forutsetter i tillegg et tett samarbeid mellom kunde og leverandør. 87 Det er derfor viktig at samarbeidet og prosessen er godt regulert i kontrakten. At samarbeid er en slik viktig suksessfaktor for bruk av smidig metodikk, kan i enkelte tilfeller by på utfordringer. Manglende eller dårlig samarbeid kan dermed være grunnen til at kontraktsforholdet kan lede til mislighold og senere heving. Selv om prosjektets gjennomføring er fastsatt på forhånd, vil behovet for endringer kunne inntre utover i prosjektet. 88 Endringsbehovet kan belyses gjennom kappløpet mellom Apple og Google. Aktørene konkurrer konstant om å ha det beste operativsystemet for mobiltelefoner. Å kunne foreta tilpasninger og endringer raskt er derfor en nødvendighet for disse. Utviklingen foregår kontinuerlig. I slike tilfeller vil bruk av fossefallsmodellen kunne være uhensiktsmessig og en svakhet for fremdriften. Etter fossefallsmodellen er det ikke lagt opp til å foreta tilpasninger i samme grad som ved smidig utvikling. Behovet for endringer vil 80 Udsen (2016) s. 485 81 Definisjon er uttatt fra PS 2000 Sol pkt. 1.2 82 SSA-S pkt. 2.1.1 83 SSA-S pkt. 17 84 https://gemini.no/2014/03/norske-it-forskere-pa-topp-i-verden/ (sist lest 02.04.17) 85 SSA-S pkt. 17 86 Op. cit 87 Udsen (2016) s. 485 88 Føyen (2006) s. 125 Side 17 av 60

ikke være det samme ved smidig utvikling, fordi partene underveis avtaler hva som skal inngå i den enkelte fase. En illustrasjon av fossefallsmodellen og smidig utviklingsmodell vises herunder i figur 1. Kravspesifikasjon og kontraktsinngåelse FOSSEFALLSMODELLEN Utvikling Levering SMIDIG UTVIKLINGSMODELL Testing og godkjenning ITERASJON 3 Testing og godkjenning ITERASJON 2 Reprioritering ITERASJON 1 Testing og godkjenning Reprioritering og spesifisering Testing og godkjenning Spesifisering og prioritering Ved smidig metode vil kvaliteten på selve prosessen i større grad stå i fokus ved misligholdsog hevingsvurderingen. 89 Mens det for utvikling etter fossefallsmodellen vil være større fokus på ytelsen som et resultat. Utviklingsmodellene har derfor visse likheter opp mot inndelingen innsats/omsorgs- og resultatforpliktelser i den alminnelige kontraktsretten. Samtidig er det vanlig for utviklingskontrakter at det foreligger en kombinasjon av både resultat- og innsatsforpliktelse. 90 Leverandøren vil ofte være forpliktet til å yte en faglig forsvarlig innsats gjennom hele prosjektet, samt levere et bestemt resultat. 91 Å fastsette et absolutt skille mellom forpliktelsene til tross for valgte utviklingsmodell, lar seg derfor ikke alltid gjøre. 89 Føyen (2006) s. 461 90 Op. cit 91 Se TOSLO-2001-11218 Side 18 av 60

2.4.4 Kundens medvirkning Kundens medvirkningsplikt kommer til uttrykk i PS 2000 Sol pkt. 3, IKT SUP-04 pkt. 3.2.2 og SSA-S pkt. 6.1. Som omtalt innledningsvis, kan kundens medvirkningsplikt ha betydning for spørsmålet om leverandørens mislighold. I utviklingsprosjektet vil leverandøren i enkelte tilfeller være avhengig av kundens medvirkning for oppfyllelse av egne forpliktelser. Regjeringen har basert på forskning på IT-prosjekter, kommet til at omfattende medvirkning er et viktig element for prosjektets suksess. 92 De kravene som stilles til kundens medvirkning kan anses som særlig strenge og vidtfavnende, og av sentral betydning i et utviklingsprosjekt. Angivelser av prioriteringer i produktkøen er blant annet en viktig del av kundens medvirkning. I PS 2000 Sol pkt. 4.1.4 kommer det til uttrykk at kunden er ansvarlig for klargjøring og prioritering av Produktkøen. Overholdes ikke denne plikten må leverandøren foreta prioriteringene for å fortsette fremdriften, og kan risikere å ta valg som kunden ikke ønsker. En produktkø illustreres nedenfor i figur 2. 93 Høy prioritet Detaljerte funksjoner De prioriterte funksjoner Mindre detaljerte funksjoner Lav prioritet Arbeidsfunksjoner 92 https://www.regjeringen.no/contentassets/9018344feae44c1f9a2a114e768ebd1b/suksess_fiasko_offentlige_iktprosjekter.pdf 93 Illustrasjonen er inspirert av Scott W. Ambler Side 19 av 60

Partene bør som fremhevet under pkt. 2.4.3 sørge for et nært og ryddig samarbeid. 94 Et godt samarbeid påkrever følgelig medvirkning fra kunden. Graden av medvirkningsplikt avhenger blant annet av hvilken utviklingsmodell partene har valgt. Ved bruk av smidig metode er siktemålet at kunden skal bidra aktivt under utviklingen. 95 Det er derfor grunn til å stille strengere krav til medvirkning ved smidige kontraktsforhold enn for utvikling etter fossefallsmodellen. 2.4.5 Testing av ytelsen En viktig del av et utviklingsprosjekt er å foreta tester av produktet. Testing er nødvendig for å avklare om produktet er i kontraktsmessig stand, og om det foreligger grunnlag for heving. Partene kan selv avtale når og hvordan testingen skal gjennomføres. Etter SSA-S pkt. 2.3.2 skal leverandøren først foreta testingen. Kunden vil deretter gis anledning til å foreta tester for så å komme med tilbakemeldinger etter pkt. 2.3.3. Kundens testing etter pkt. 2.3.3 skal foregå av alle delleveranser. Testing utgjør således en sentral del av kontraktens gjennomføring, og gir kunden en aktiv rolle i prosjektet. En slik kontinuerlig testing kjennetegner kontraktens utviklingsmetodikk. I likhet med SSA-S skal testing etter PS 2000 Sol foretas etter hver iterasjon iht. kontraktens pkt. 5.5. Bestemmelsen regulerer ytterligere at testingen skal skje i samarbeid mellom kunden og leverandøren. På denne måten kan testingen foregå mer effektivt, og bidra til større fremdrift i prosjektet. Testing etter IKT SUP-04 følger ikke av kontraktens generelle del, men må avtales nærmere mellom partene og inntas i bilag 6. På grunn av at kontrakten legger opp til utvikling gjennom fossefallsmodellen, vil ikke testing nødvendigvis utgjøre en like sentral rolle i prosjektet som figur 2 belyser. 96 Testing har flere sider til den alminnelige undersøkelsesplikten i kontraktsretten og om misligholdet kan gjøres gjeldende, noe det i pkt. 4.5.4 vil behandles nærmere. 94 Udsen (2016) s. 484 95 Se Føyen (2006) s. 45 96 Se pkt. 2.4.4 Side 20 av 60

3 KUNDENS HEVINGSRETT ETTER KONTRAKTENE I det følgende vil det gis en oversikt og presentasjon av vilkårene for kundens hevingsrett etter de utvalgte standardkontraktene. Vilkårene vil sammenlignes, og presentasjonen vil gi et naturlig utgangspunkt for den videre fremstillingen. I SSA-S pkt. 11.5.4 er kundens hevingsrett regulert. Det oppstilles her krav om vesentlig mislighold. Vilkåret om vesentlig mislighold vil behandles nærmere under pkt. 6. Videre kan kunden etter pkt. 11.5.4 annet avsnitt heve ved vesentlig forsinkelse, som er nærmere regulert i kontraktens pkt. 11.5.2. Forsinkelse vil bli behandlet i avhandlingens pkt. 4.4. Etter PS 2000 Sol pkt. 10.1.2 kan kunden heve ved forsinkelse. En generell hevingsadgang er regulert i pkt. 10.5. Rett til heving foreligger dersom dette fremgår av en av de andre bestemmelsene i kontrakten, eller ved annet vesentlig mislighold. Retten til heving gjelder imidlertid bare heving av den aktuelle Avtalen, som er som omtalt i pkt. 2.2.2, en av kontraktens tilleggsavtaler. For å gjennomføre kontrakten er det ifølge pkt. 1.2 i kontraktens veiledning nødvendig med disse tilleggsavtalene. 97 Skal hele kontrakten heves må det etter PS 2000 Sol pkt. 10.5 annet avsnitt, foreligge gjentatt eller vesentlig mislighold av Avtaler som omtalt i avhandlingens pkt. 2.2.2. Hva som ligger i gjentatt beror på en annen vurdering enn vesentlig mislighold. Ordlyden tilsier at det er tilstrekkelig at det aktuelle misligholdet har inntrådt minst to ganger. For heving av kontrakten er det ikke tatt hensyn til mislighold av selve kontrakten, kun Avtaler. Hva årsaken til dette er, er uvisst. Selv om det ikke fremgår uttrykkelig, må det likevel kunne innfortolkes at gjentatt eller vesentlig mislighold av kontraktens generelle del også gir grunnlag for heving. At brudd på kontraktens generelle del ikke gir grunnlag for å heve kontrakten, kan gi svært urimelige resultater. I IKT SUP-04 er kundens hevingsrett regulert i pkt. 16.2.1 for forsinkelse og pkt. 16.2.2 for mangler. Heving på bakgrunn av mangler vil behandles nærmere i avhandlingens pkt. 4.5. Etter pkt. 16.2.2 bokstav d kan kunden heve kontrakten dersom det allerede når mangelen er påberopt er åpenbart at Leverandøren ikke kan oppfylle avtalen innen 90 dager etter avtalt 97 Vedlegg 1 Side 21 av 60

Godkjennelsesdag. Ordlyden åpenbart forstås som at det må foreligge klare holdepunkter. Bestemmelsen er rettet mot fremtidige forhold, og kan derfor forstås som en regulering av heving ved antesipert mislighold. Leverandøren har på den annen side adgang til å heve ved vesentlig mislighold av kontrakten etter pkt. 16.3.1. Hevingsadgangen ved mangler er dermed for kunden snevrere enn for leverandøren. Reguleringen er også snevrere enn etter de andre standardkontraktene. Dette kan tyde på at kontrakten i større grad er leverandørvennlig og ikke fullstendig balansert. Spørsmålet er om pkt. 16.2.2 bokstav d begrenser bakgrunnsretten, eller om den gir rom for utfylling. At kunden i IKT SUP-04 ikke er gitt samme hevingsadgang som leverandøren, kan tvilsomt være en glipp. På den annen side har kunden en hevingsadgang gjennom kontrakten. Det har formodningen mot seg at kontrakten ikke skal kunne utfylles. Skulle det i kontrakten være ment å begrense kundens hevingsadgang, burde dette være uttrykt i klartekst. Samtidig kan bestemmelsen forstås slik at kunden ikke kan heve på bakgrunn av vesentlige forhold innen utgangen av de 90 dagene. Oppsummert er retten til heving for kunden er etter SSA-S og PS 2000 Sol gjensidig, og ivaretar hensynet til likevekt i kontraktsforholdet. I IKT SUP-04 er imidlertid hevingsadgangen for kunden og leverandøren ulik. Etter IKT SUP-04 vil hevingsadgangen for kunden variere etter om det er tale om en forsinkelse eller en mangel. 4 MISLIGHOLD AV KONTRAKTEN 4.1 Om mislighold Mislighold kan forekomme i ulike former. Det kan enten være tale om: feil eller mangler med varen, forsinkelser, eller brudd på andre avtalebestemmelser Side 22 av 60

At enkelte feil og forsinkelser kan oppstå under utviklingen er nærmest uunngåelig. 98 Selve utviklingen byr tross alt på et eget sett med utfordringer, og etter at produktet er ferdig utviklet og klar for bruk er det en risiko for at produktet lider av barnesykdommer. 99 Dersom det foreligger flere mislighold, kan disse kumuleres og sammen utgjøre et grunnlag for misligholdsbeføyelser. 100 Hvor krav om heving er fremsatt vil det vanlige være at det er tale om flere forhold, og ikke et enkeltstående tilfelle. 101 Et enkeltstående tilfelle kan gi grunnlag for heving, men må normalt være av graverende art. Vurderingen av forsinkelse og mangler kan bli overlappende. 102 Forklaringen er at det ofte avtales at produktet først er levert, når dette er undersøkt og godkjent av kunden. Slik er ordningen for SSA-S og PS 2000 Sol. 103 Det vil kunne ta noe tid før det er testet om produktet fungerer slik det skal. Dette vil igjen kunne lede til forsinkelser i avtalt levering. Avdekkes mangler ved produktet, kan dette også medføre at forsinkelser inntrer. For å avgjøre om det foreligger mislighold, må det vurderes om det foreligger et objektivt avvik mellom utført arbeid eller manglende utførelse og kontrakten. Dette kommer til uttrykk i SSA-S pkt. 11.1 og 12.1 og i rettspraksis, blant annet Rt. 2015 s. 321. Hva som menes med mislighold er derimot ikke regulert i PS 2000 Sol og IKT SUP-04. For disse kontraktene kan det ses hen til forannevnte rettspraksis, og foreta samme avviksvurdering. Det er derfor ikke nødvendig å angi hva som menes med mislighold, med mindre det ønskes en særskilt regulering. 4.2 Antesipert mislighold Dersom det på forhånd foreligger tilstrekkelig grunnlag til å tro at mislighold vil inntre, foreligger såkalt antesipert eller forventet mislighold. Antesipert mislighold kan gi grunnlag for heving. 98 Torvund (1997) s. 23 og Udsen (2016) s. 471 99 Jf. LB-2015-34400 og Udsen (2016) s. 484 100 Hagstrøm (2011) s. 430 101 Hagstrøm (2011) s. 132 102 Føyen (2006) s. 468 103 Se avhandlingens pkt. 4.3 Side 23 av 60

IKT SUP-04 inneholder som omtalt i pkt. 3 en særskilt form for hevingsadgang for kunden ved antesipert mislighold. Kontrakten regulerer ikke antesipert mislighold generelt. SSA-S og PS 2000 Sol har ingen reguleringer av antesipert mislighold. Retten til heving ved antesipert mislighold er et obligasjonsrettslig prinsipp. 104 Prinsippet kommer til uttrykk i kjøpsloven 62. Etter kjøpsloven 62 første ledd må det være klart at kontraktsbrudd som vil gi en part hevingsrett, vil inntre. Ordlyden angir at vurderingen må foretas konkret for hver enkelt kontrakt. Det er ikke oppstilt et eksplisitt krav om vesentlig mislighold. Ordlyden klart forstås som at det må foreligge lite rom for tvil om at rett til heving vil inntre. Kravet gjør at terskelen for heving ved antesipert mislighold er opphøyd, ift. heving etter inntrådte forhold. Med hjemmel i kjøpsloven 62, kan heving ved antesipert mislighold forekomme også hvor dette ikke er regulert i kontrakten. En vurdering av hva som vil komme til å skje i utviklingsforløpet vil trolig være enklere for kontrakter som benytter fossefallsmodellen, som IKT SUP-04. Dette fordi utviklingsforløpet er fastlagt allerede fra starten. For PS 2000 Sol og SSA-S er heving på bakgrunn av antesipert mislighold derimot vanskeligere å forestille seg. Ved bruk av smidig metode avtaler partene som nevnt hvordan utviklingen skal skje underveis. Samtidig kan enkelte alvorlige forhold også inntre for disse prosjektene, som gjør at det vil være lite tvilsomt at mislighold av en vesentlig art også vil inntre. Eksempelvis kan antesipert mislighold kan forekomme, dersom bruk av avtalte nøkkelpersoner slutter og leverandøren ikke straks får erstattet disse. I et slikt tilfelle kan det for øvrig også være nærliggende å påberope bristende forutsetninger. 105 Sentralt i vurderingen av antesipert mislighold er om det er en en risiko for at misligholdet vil gjenta seg. 106 En slik risiko foreligger dersom leverandøren har innrømmet feil og foretatt retting, men feilene er så store at budsjettet brukes opp allerede midt i prosjektet. Av særlig betydning er også om leverandøren har vist vilje og evne til å gjennomføre de gjenstående 104 Føyen (2006) s. 483 105 Hagstrøm (2011) viser på s. 336 til at grensen mellom relevant bristende forutsetning og kontraktsbrudd er diskutabel. 106 Hagstrøm (2011) s. 436 Side 24 av 60

oppgaver. 107 Vurderingen av leverandørens gjennomføringsvilje- og evne beror en vurdering av hva leverandøren har foretatt seg så langt i prosjektet, og hva som sannsynligvis vil skje. 4.3 Levering, godkjennelse og risikoovergang Etter tradisjonelle regler i kontraktsretten forbindes flere rettsvirkninger til leveringstidspunktet og risikoovergangen. Disse tidspunktene kan være sammenfallende. 108 I IT-retten må det også normalt tas hensyn til godkjennelse av leveransen, noe som adskiller seg fra kontraktsretten ellers. Alle disse tidspunktene vil innvirke på vurderingen av mislighold og heving. Etter SSA-S pkt. 2.5.2 og 2.5.5 foreligger leveringsdag; Første Virkedag etter at leveransen er eller anses godkjent. 109 Formuleringen anses godkjent forstås som en bevisregel. Foreligger tilsynelatende godkjennelse, tilsier avtalerettslige hensyn at kunden som et utgangspunkt må ha bevisbyrden for at godkjenning ikke foreligger. Tidspunktet for endelig levering er ikke regulert i PS 2000 Sol. Dette er naturlig for kontraktens gjennomføringsmåte. For prosjekter av et visst omfang og varighet kan det være vanskelig å angi hvor lang tid utviklingen vil ta, og hvor mye som gjenstår og ferdigstille etter en viss tid. 110 I PS 2000 Sol pkt. 1.2 er leveranse definert som; Det til enhver tid avtalte resultat av utvikling av Programvaren gjennom en eller flere Iterasjoner og som er godkjent av Kunden i Godkjenningsprøven. Etter denne bestemmelsen foreligger leveranse ved innfrielse av to forhold; Avtalt resultat og godkjennelse fra kunden. Skulle det senere vise seg at resultatet ikke oppfyller det avtalte resultat, og dette er godkjent av kunden, foreligger ikke leveranse. En slik fortolkning følger naturlig av bestemmelsens ordlyd. IKT SUP-04 skiller seg imidlertid fra de andre kontraktene hva gjelder leveranse og godkjenning. Etter kontraktens pkt. 8.1 skal partene avtale en leveringsdato. Godkjenning skal i motsetning til de andre kontraktene foretas etter levering. Levering foreligger derfor på avtalt dato og ikke ved godkjenning. Her vil løsningen være levert før den er testet i bruk. For 107 Hagstrøm (2011) s. 437 108 Etter kjøpsloven 13 går risikoen over på kjøperen når tingen er levert som avtalt. 109 Virkedager er de dagene som ikke er lørdager, søndager og offentlige høytids- og helligdager, og heller ikke jule- og nyttårsaften. Jf. SSA-S pkt. 17. 110 Torvund (1997) s. 27 Side 25 av 60

å avdekke barnesykdommer som nevnt i pkt. 4.1, er det nødvendig å foreta testing. En slik regulering fremstår dermed som streng, i forhold til de andre kontraktene. 4.3.1 Risikoen for mislighold En forutsetning for å konstatere mislighold og for å gjøre misligholdsbeføyelser gjeldende er at risikoen påhviler misligholderen. Dette kommer til uttrykk i kjøpsloven 22, 30 og 51. Hvordan risikoen er fordelt mellom partene kan variere. Virkningen av levering etter IKT SUP-04 pkt. 8.1 er blant annet at risikoen for produktet overføres til kunden iht. pkt. 8.2. Reguleringen samsvarer med kjøpsloven 13. Inntrer mislighold etter risikooverføringen, kan misligholdet i utgangspunktet ikke gjøres gjeldende av kunden. 111 Reguleringen av levering og risikooverføring etter IKT SUP-04 kan begrunnes i bruk av utviklingsmodell. Benyttes fossefallsmodellen vil det være mer naturlig at risikoen overføres til kunden ved leveringen. Mens det for utvikling etter smidig metodikk er mer naturlig at risikoen er mer fordelt mellom partene gjennom prosjektet, noe juridisk teori også gir støtte for. 112 SSA-S og PS 2000 Sol inneholder derimot ikke reguleringer av risikoovergangen. Spørsmålet er da når risikoen for produktet overføres til kunden etter disse kontraktene. Kjøpsloven 13 kan anvendes for utfylling. Torvund gir uttrykk for en slik løsning, og er av den mening at man bør holde fast ved utgangspunktet om risikoovergang ved levering, også for IT-kontrakter. Så lenge kunden har ansvaret for installasjonen, hevder han at regelen er uproblematisk. 113 Et av problemene er imidlertid at SSA-S og PS 2000 Sol ikke sammenholder levering med installasjon. Det kan ikke innfortolkes at levering og installering skal foregå på samme tid. At risikoen overføres ved levering, vil også være mindre praktisk for et utviklingsprosjekt. Selv om leverandøren er ferdig med utviklingen, kan feil komme til syne i etterkant. Det kan derfor ikke uten videre legges til grunn at den løsning kjøpsloven 13 gir uttrykk for, skal benyttes. Kontraktspraksis på dette punkt kan i tråd med smidig utvikling fremstå som endret siden Torvunds fremstilling. 111 Jo Hov. Avtalebrudd og partsskifte. Kontraktsrett II. 4. utgave, Oslo, 2002 s. 73 112 Torvund (1997) s. 58 113 Torvund (1997) s. 109 Side 26 av 60

Ytterligere fremholder Torvund at det tidspunkt når kildekoden 114 er overtatt av kunden kan være veiledende. 115 IKT SUP-04 og PS 2000 Sol inneholder ingen regulering vedrørende kildekode. Forklaringen kan være at overlevering av kildekode i dag vil være mer komplekst enn ved overlevering av kildekode på en CD. Det vanlige i dag er at kildekoden gjøres tilgjengelig for brukeren i et egnet elektronisk form. 116 I tillegg kan overføring av kildekode være betinget av egne avtaler som begrenser rettighetene til kildekoden. 117 Etter SSA-S pkt. 10.1.5 skal leverandøren overlevere kildekode innen 10 virkedager etter godkjennelse av akseptansetest for hver delleveranse. Hensynet til nyttiggjøring taler i en viss utstrekning for at risikoen burde påhvile kunden ved delleveranser av kildekoden. Dette forutsetter at denne delen har en selvstendig nytteverdi. Beror imidlertid bruken på en fremtidig leveranse fra leverandøren, vil risikooverføring kunne lede til urimelige resultater. Når kildekoden er fullstendig, og denne skal overtas av kunden, vil det derimot være naturlig å anse risikoen som overført. 4.3.2 Betydningen av godkjennelse av leveransen For utviklingsprosjekter kan godkjennelse av leveransen medføre at hevingsadgangen for kunden er tapt jf. dom fra Borgarting lagmannsrett 13. oktober 2005 (LB-2004-8893). Dommen omhandler heving etter levering av et talesvarsystem til NSB. Kontrakten mellom partene ble konstatert å være en standard EDB-kontrakt for kjøp. Kontrakter om kjøp av elektronisk databehandling (EDB), atskiller seg fra utviklingskontrakter i en viss utstrekning. Kontrakten omhandlet likevel programvare, og har derfor også en viss relevans for utviklingskontrakter. Lagmannsretten vurderte i LB-2004-8893 om godkjennelsen omfattet leveransen i sin helhet, noe som ble besvart negativt. De kom dermed frem til at hevingsretten ikke var tapt. Det må altså kunne stilles krav til at godkjennelsen etter en konkret vurdering omfatter leveransen i sin helhet, dersom hevingsadgangen skal være tapt. En slik betraktning underbygges av at kontraktene selv har formalisert en godkjenningsprosedyre. Det er derfor hensiktsmessig å 114 Se avhandlingens pkt. 1.1 for beskrivelse av kildekode 115 Torvund (1997) s. 109 116 James Cadle & Donald Yeates. Project Management for Information Systems. 5. edition, England, 2008 s. 105 117 Se Føyen (2006) s. 438 om avtaler om utlevering av kildekode, såkalte deponeringsavtaler Side 27 av 60

angi et tidspunkt for når levering og når godkjennelse anses å foreligge i kontrakten. For ordens skyld burde virkningene av levering og godkjennelse også presiseres i kontrakten. For SSA-S er det uttrykkelig fastsatt at gjennomføringen skal skje gjennom delleveranser bestående av en eller flere iterasjoner jf. pkt. 2.1.1. Det samme er forutsatt i PS 2000 Sol, men ikke regulert eksplisitt. Etter IKT SUP-04 er det anledning for partene å avtale bruk av delleveranser. Godkjennelse av delleveranser vil i utgangspunktet ikke lede til at hevingsadgangen går tapt. Spørsmålet er om godkjennelse av delleveranse unntaksvis kan avskjære hevingsadgangen. I SSA-S pkt. 2.5.5 reguleres forholdet til godkjennelse og feil og mangler som blir synlige etter godkjennelsen. Kundens godkjennelse er ikke til hinder for at Kunden i garantiperioden kan kreve utbedret feil og mangler som Kunden ikke oppdaget i godkjenningsperioden, eller feil som ikke er rettet av Leverandøren i godkjenningsperioden. Retten til utbedring går altså ikke tapt ved godkjennelse. Dette kan i en viss grad tale for at hevingsretten også er i behold. Reguleringen gir større trygghet for kunden, og fremstår med dette som kundevennlig. Dette står i motsetning til PS 2000 Sol og IKT SUP-04, som ikke regulerer feil som nevnt i SSA-S pkt. 2.5.4 og har heller ikke garantiperiode. Det er derfor i større grad uvisst hvilken betydning godkjennelse av delleveranser etter disse kontraktene vil få med hensyn til spørsmålet om heving. Hensynet til innrettelse kan i enkelte tilfeller tale for hevingsadgangen er avskåret for den aktuelle del. Graden av innrettelse avhenger blant annet av om produktet kan nyttiggjøres. Hensynet til nyttiggjøring bør også her være det sentrale. Skulle for eksempel det viktigste av leveransen være levert i delleveranse 1 og 2, taler hensynet til nyttiggjøring for at hevingsadgangen er avskåret for disse delene. Oppstår mislighold for delleveranse 3 og 4 kan en eventuell hevingsadgang som omfatter delleveranse 1 og 2 gi urimelige resultater for leverandøren. Kunden kan benytte del 1 og 2, og gå til en annen leverandør for utvikling av de gjenstående og enklere delene. Samtidig kan feilen manifestere seg først etter godkjennelse. Skulle utviklingen av delleveranse 3 og 4 medføre at delleveranse 1 og 2 ødelegges, vil avskåret hevingsadgang gi et urimelig resultat for kunden. Synspunktene om virkningen av godkjennelse av delleveranser, henger også nært opp mot vurderingen av hevingsoppgjøret, som behandles under pkt. 6.2. Generelt kan det sies at virkningen av godkjennelse av delleveranse, må avgjøres konkret for det nærværende tilfellet. Side 28 av 60

4.4 Forsinkelse i levering av programvaren Levering av et avtalt produkt kan på bakgrunn av ulike forhold bli forsinket. En forsinkelse kan variere i omfang fra timer til måneder. Enhver forsinkelse vil ikke uten videre innebære et mislighold. Hva som er å anse som en forsinkelse som utløser misligholdsvirkninger, må avgjøres etter en tolking av kontrakten. I alle de utvalgte standardkontraktene er det angitt når det foreligger forsinkelse. Kontrakt Punkt Forsinkelse Blir ikke avtalt tidspunkt for Overlevering, eller annen frist som partene i bilag 4 har knyttet SSA-S 2015 11.5.2 dagbøter til overholdt, og det ikke skyldes force majeure eller Kundens forhold, foreligger en forsinkelse fra Leverandørens side som gir grunnlag for dagbot. Forsinkelse foreligger dersom Godkjennelsesdag ikke er inntruffet som 16.2.1 angitt i BILAG 5, eventuelt med Endringer partene har avtalt. Det foreligger forsinkelse fra Leverandørens side dersom en Leveranse knyttet til en Oppdragsavtale basert på definerte 10.1.2 godkjenningskriterier ikke kan godkjennes i Side 29 av 60