Felbegreppet vid leverans av programvara

 

 

Av bolagsjuristen ViVECA BERGSTEDT STEN

Artikeln diskuterar köplagens tillämplighet på fel i programvara och tar också upp hur frågan behandlas i de skandinaviska grannländerna.
Felbegreppet i systemleveransavtal analyseras i ljuset av IT-branschens standardavtal, som generellt intar en säljarvänlig hållning med snäva möjligheter för köparen att åberopa fel. Författaren menar att säljaren inte kan undgå ett mer vidsträckt felansvar och föreslår införandet av en felbestämningsmodell som tar sikte på det förväntade resultatet snarare än avtalade systemspecifikationer. Avslutningsvis betonas vikten av att noga utforma och precisera innehållet i systemleveransavtal, så att köparens förväntningar på slutprodukten tydligt framgår av avtalet.

 

1. Inledning
Inköp av skräddarsydda ADB-system1 utvecklade för att möta köparens särskilda behov får allt större ekonomisk och strategisk betydelse. Upphandlingar av dessa system, som med Seipels ord2 beskrivs som en ”totalitet av datorutrustning, kommunikationsutrustning, programvaror, beskrivningar, persontjänster och kunnande”, illustrerar väl IT-juridikens komplexitet. Dessa systemleveransavtal3 reglerar något som till sin natur är immateriellt, som vid avtalsögonblicket kanske bara finns i sinnevärlden som en tanke, och den färdiga produkten är undflyende4 i bemärkelsen att det enda fysiska resultatet kommer att vara magnetdiskar och maskiner, men det som ska utföras och resultatet av detta är högst konkret, i synnerhet om ADB-systemet inte utför sina avtalade funktioner.5

 

1 ADB-system definieras i Smitt, R., Ossmer, P., Lindberg A., Brinnen, M., 1991, Databranschens standardavtal, som en kombination av maskin- och programprodukter och tjänster, vilka gemensamt ska fungera som en produktionsenhet med ett eller flera ändamål. Beteckningen känns idag något föråldrad, men då den i stor utsträckning används i refererad litteratur, har jag valt att ändå använda uttrycket i denna artikel. 2 Seipel, P., 1986, ADB-avtalens fallgropar, Nordisk Årsbok i Rättsinformatik 1986, s. 11. 3 varmed avses avtal om systemleveranser då flera produkter ska integreras såväl med varandra som med andra produkter hos kunden, Christner, A., 1995, Kommentarer till IT-branschens standardavtal, sid 1. 4 Seipel, a. a. s. 12 beskriver vanliga anledningar till att ADB-avtal havererar och säger bl. a. att ”produkterna och tjänsterna är komplicerade och svårbeskrivna”. 5 Norager-Nielsen, J. EDB kontrakter, 1987, beskriver på s. 46 vad som hände då det amerikanska rymdskeppet Mariner 1 skulle skickas upp för att fotogra-

Systemleveransavtal slutar inte sällan i oenighet om vad som utgör en korrekt och fullständig leverans där köparen gör gällande fel i levererat gods, säljaren försvarar sig med att ha levererat enligt specifikation och avtalet ger liten vägledning i frågan.
    Denna artikel behandlar problematiken kring köprättsligt fel i samband med köp av särskilt utvecklade (customized) ADB-system. Inledningsvis diskuteras tillämpligheten av köplagen, därefter behandlas det konkreta och abstrakta felansvaret mot bakgrund av IT-branschens standardavtal. Avslutningsvis skissas ett förslag på en funktionell feldefinition i tillägg till nuvarande standarddefinition. Framställningen tar närmast sikte på faktiska fel och behandlar inte s. k rättsliga fel.

 

2. Tjänst eller lös egendom?
2.1 Köplagens tillämpningsområde
I ett systemleveransavtal ska säljaren normalt tillhandahålla en slutprodukt som, utöver eventuell maskinvara, består av flera olika programvaror, dels specialutvecklad programvara, dels standardprogram och slutligen kundspecifika anpassningar som gör att helheten fungerar som ett system. Med undantag för standardprogrammen, övergår många gånger de immateriella rättigheterna till den specialutvecklade programvaran till köparen. Säljarens prestation omfattar således flera moment — dels utvecklingsarbetet för att färdigställa ny programvara, dels anpassningar av eventuell standardprogramvara, och dels installationsarbetet när programvaran installeras i kundens hårdvara.
    För att avgöra om systemleveransavtal faller inom ramen för köplagen måste köplagens 2 § studeras, där gränsdragningen mot avtal om tjänster (arbetsbeting) görs. Paragrafen lyder:

 

”Lagen gäller beställning av en vara som ska tillverkas utom när beställaren ska tillhandahålla en väsentlig del av materialet. Lagen gäller inte avtal om uppförande av byggnad eller annan fast anläggning på mark eller i vatten.
    Lagen gäller inte avtal som innebär att den som ska leverera en vara även skall utföra arbete eller någon annan tjänst, om tjänsten utgör den övervägande delen av hans förpliktelse.”

 

Objektet för köplagen är lös egendom,6 vilket utöver sedvanliga varor även kan omfatta rättigheter, skuldebrev och byggnad på annans mark. I köplagspropositionen7 uppmärksammas avtal där varan ska tillverkas efter avtalsslutet — det diskuteras huruvida sådana avtal ska betraktas som tjänst eller köp. Lyfter man fram

 

fera Venus, och störtade i Atlanten bara några få minuter efter uppskjutningen. Det påstås att orsaken till olyckan var ett felaktigt programmerat minustecken..! 6 SOU 1976:66 s. 63. 7 Prop. 1988/89:76 s. 62.

förpliktelsen att leverera en färdig vara bör avtalet betraktas som köp, ser man istället till arbetet för att åstadkomma produkten ligger det närmare till hands att se avtalet som ett arbetsbeting. Lagstiftaren drar gränsen då säljaren ska tillhandahålla materialet till det beställda — är detta fallet till övervägande del, anses det som köp av lös egendom. Detta upprepas i konsumenttjänstlagens förarbeten,8 ”avtal om tillverkning av lös sak faller utanför lagens tillämpningsområde, om näringsidkaren helt eller delvis ska tillhandahålla materialet”. Det kan noteras att även internationella köplagen (CISG) innehåller en liknande bestämmelse i artikel 3, med motsvarande gränsdragning beroende på om material tillhandahålls eller ej.9 Systemleveransavtal är till sin karaktär avtal som sluts innan den färdiga produkten föreligger, res futura.10 Utvecklingsarbetet påbörjas efter avtalsslutandet. Då programvara utvecklas på beställning är det inte aktuellt för köparen att tillhandahålla material. Första stycket i 2 § skulle alltså inte innebära att köp av specialutvecklad programvara exkluderas från köplagens tillämpningsområde. Snarare förefaller detta slags köp stämma in just på det av lagstiftaren uppmärksammande fallet då varan tillverkas efter det att avtal ingåtts.

 

2.2 Kringtjänster
2 § andra stycket i köplagen, som f. ö. inte hade sin motsvarighet i 1905 års köplag, avser fall då leveransåtagandet kombineras med en förpliktelse att också utföra en tjänst eller annat. Om tjänsten utgör den övervägande delen av säljarens förpliktelse faller avtalet utanför köplagen. Andra stycket siktar emellertid endast på ”kringtjänster”, alltså åtaganden som sker i samband med varuleveransen. I propositionen11 uttrycks det på följande sätt — ”med arbete eller annan tjänst avses i andra stycket prestationer som typiskt sett sker i samband med eller efter leveransen av varan och som går ut på något annat än tillverkning (författarens kursivering) av varan. Om ett avtal enbart går ut på tillverkning av en vara skall det bedömas bara enligt första stycket.” Andra stycket skulle i vårt exempel endast aktualiseras i förhållande till t. ex. installationsarbete och underhåll, alltså kringtjänster som tillhandahålls i samband med leveransen av huvudprestationen — det färdiga systemet. Regeln får inte någon självständig effekt i betydelsen att köp av programvara exkluderas från

 

8 SOU 1979:36 s. 413. 9 Här förekommer dock inget undantag för uppförande av byggnad eller dylikt, men däremot exkluderas köp av fartyg och flygplan, Hellner J., Ramberg J, Speciell Avtalsrätt I, 1989, s. 45. 10 Avtal avseende en framtida sak, Hellner a. a. s. 43. 11 Prop. 1988/89:76, s. 65.

köplagens tillämpningsområde därför att tillverkningsarbetet består av ett tjänstearbete.

 

2.3 Blandade avtal
Systemleveransavtal innehåller normalt även en installationsdel — varan är inte avlämnad förrän den är installerad och fungerar på köparens datorer — och kan också omfatta ytterligare kringtjänster, t. ex. utbildning av köparens personal eller underhåll.
    I konsumenttjänstlagens förarbeten uppmärksammas problemen med s. k. blandade avtal, då en näringsidkare åtagit sig att utföra visst arbete i samband med att han tillhandahåller en lös sak.12 Utredningen kom fram till att man bör göra en helhetsbedömning av avtalssituationen varvid även individuella förhållanden bör kunna beaktas. Utslagsgivande är om avtalet, trots tjänstemomentet, vid en helhetsbedömning väsentligen framstår som ett köp. I köplagspropositionen13 pekas på värdet av tjänsteåtagandet som en betydelsefull faktor jämfört med värdet av den köpta varan för att avgöra frågan. Ramberg säger kort och gott att köplagen inte gäller vid blandade avtal om tjänstedelen utgör den övervägande delen av de sammanlagda förpliktelserna.14 Frågan har också behandlats i NU 1984:515 där gränsen dragits vid förhållanden där tjänstedelen utgör en större del av säljarens förpliktelse än varuleveransen. Om köpet och tjänsten är åtminstone lika stora skulle köplagen vara tillämplig. Ett förhållandevis enkelt sätt att avgöra om köplagen ska tillämpas på ett blandat avtal är enligt Traung16 att istället se till om köparen avtalat om ett resultat, t. ex. köp av monterat gods, eller, i vårt exempel, köp av installerat system. Om huvudförpliktelsen innebär leverans av en vara i visst skick, vars skick förutsätter vissa tjänstemoment, bör hela avtalet falla inom ramen för köplagen. Sveriges advokatsamfund instämmer i detta i sitt remisssvar på köplagspropositionen,17 där man uttalar: ”det förefaller sannolikt att slutproduktens karaktär bör vara bestämmande för vilka rättsregler som skall tillämpas snarare än enskildheter i leverantörens åtaganden”. Visar det sig däremot att avtalet låter sig inordnas i två avgränsade delar, t. ex. leverans av ett ADB-system med biförpliktelsen underhåll i två år från

 

12 SOU 1979:36 s. 134. 13 Prop. 1988/89:76, s. 64. 14 Ramberg J. (I), Inledning till köprätten, 1991, s. 25, se även Ramberg, J. (II), Köpavtal samt transportavtal och andra anslutande avtal, 1993, s. 31. 15 s. 199. 16 Traung P., Fel och dröjsmål vid kommersiella tillverkningsavtal, 1986, s. 32. 17 Prop. 1988/89:76, s. 76, yttrande över 2 §.

leverans, är det inget som hindrar att man tillämpar köprättsliga regler på den ena delen och tjänsteregler på den andra.18

 

2.4 Doktrin och praxis
I doktrinen har gjorts gällande19 att köplagen inte är tillämplig vid utveckling av produkter, i vart fall om resultatet är ett programsystem. Något försiktigare uttrycker sig Dejve och Wahlin,20 som menar att det råder diskussion om graden av vägledning som kan sökas i köplagens regler i frågor som rör köp av datorer med programvara och kringtjänster. Motsatt ståndpunkt intar Ahlstedt21 som konstaterar att köplagen gäller för köp/försäljning av maskin- och programvara.
    I praxis märks framför allt ett fall från Hovrätten över Skåne och Blekinge,22 där tvisten gällde om ett avtal rörande utveckling av ett administrativt dataprogram för fiskeersättning inkluderade överlåtelse av äganderätten/upphovsrätten eller endast omfattade en nyttjanderätt. I målet invände svaranden att köplagen inte var tilllämplig vad avsåg äganderätten till dataprogrammet eftersom det var fråga om arbetsbeting. Hovrätten tog emellertid inte ställning till köplagens tillämplighet, utan nöjde sig med att konstatera att avtalet, i brist på uttryckliga bestämmelser om övergång av upphovsrätten, inte fick anses ha inkluderat äganderätten utan endast omfattade nyttjanderätten till datorprogrammet.

 

2.5 Skandinavisk rätt
Den norska föregångaren till nuvarande norsk köplag, som tillkom efter nordiskt samarbete (kjopslov 24.5.1907), vilken motsvarar den tidigare svenska köplagen av 1905, har i norsk praxis och doktrin ansetts tillämplig på köp av programvara23. I en skiljedom från 197224 befanns ”utveckling av speciell programutrustning” falla under köplagen och i en opublicerad skiljedom från 198125 uttalade rätten: ”De vesentligste komponenter i det som skulle leveres, var kontorkomputeren og...programmene. Det er etter voldgiftsrettens oppfattning artsbestemte ting, som faller inn under bestemmelsene i kjöpslovens § 43.26” Christophersen

 

18 Prop. 1988/89:76 s. 65. 19 Christner a. a. s. 26, menar att det inte finns någon lag som är direkt tillämplig, varför vägledning måste hämtas från rättsfall och allmänna rättsgrundsatser. 20 Dejve, K., Wahlin, T. Att köpa ADB-system med AVTAL 90, 1991, s. 10 och 12. 21 Ahlstedt H., Datarättens ABC, 1991, s. 59. 22 Dom 1993-04-14, DT 4149, mål nr T 197-92. 23 Christophersen, O.E, Foyer A., EDB-anskaffelser, fremgangsmåte og avtaleutformning, 1981, s. 65 ff. 24 Christophersen a. a. s. 66. 25 Christophersen, a. a. s. 66. 26 Motsvarande 39–40 §§ i 1988 års norska kjopslov.

hänvisar samtidigt till den allmänna uppfattningen27 att också immateriell egendom omfattas av köplagen.
    I Danmark tillämpas i första hand den danska köplagen (med beaktande av reglerna om beställningsköp), på ADB-avtal. Noerager-Nielsen28 slår fast att standardhårdvara respektive programvara faller inom ramen för köplagen och att detta även bör gälla med hänsyn till utvecklingsprogramvara, inte minst då även sådan numera i hög grad baseras på standardiserade produkter.

 

2.6 Reflektioner
Utvecklingsarbetet vid programvarutillverkning kan jämställas med tillverkningsarbetet i t. ex. bilfabriker. Resultatet är detsamma, en lös sak. Eller, annorlunda uttryckt, få skulle ifrågasätta att ett köp av en ny bil faller inom ramen för köplagen (eller motsvarande konsumentköplagen om den köps för enskilt bruk). Om en konsument istället avtalar med en bilhandlare om att köpa en specialbeställd gul Volvo som ska utrustas med taklucka, airbags, lila skinnklädsel och så många finesser att bilen måste specialtillverkas efter avtalsslutet, innebär monteringsarbetet då att avtalsobjektet till övervägande del ska anses som en tjänst, och att den slutgiltiga bilen endast är en produkt av detta, vilket leder till att reglerna om köp av tjänst (konsumenttjänstlagen) blir tillämplig? Sannolikt skulle svaret bli nej på den frågan vilket uppenbarar svagheterna i resonemanget om köplagens bristande tillämplighet. Det faktum att programvara tillverkas delvis genom intellektuellt arbete i interaktion med en dator innebär knappast att det inte ska ses som en tillverkningsprocess vars slutresultat — lös egendom — faller under köplagen.
    1976 års köplagsutredning diskuterar29 om det, vid avgörandet huruvida köparen tillskjutit material eller ej, även ska tas hänsyn till den ”intellektuella komponenten”. I exemplet nämns en uppfinnare som beställer tillverkning av en vara i enlighet med sin uppfinning. Innebär tillskjutandet av den intellektuella vägledningen att uppfinnaren därmed består säljaren med material i köplagens mening, varför detta utgör ett tillverkningsavtal som faller utanför köplagen? Utredningen stannar för att man inte behöver ta sådana hänsyn, men omvänt kan konstateras, att det vid programutvecklingsarbete är säljaren som tillhandahåller det intellektuella arbetet vilket utgör ”tillverkningskomponenten” vid köp av programvara.
    Ett välkänt faktum är att köpare till programvara inte alltid erhåller hela den immateriella rätten till varan. Detta är dock inte något som med automatik exkluderar köplagen. Motsvarande äger rum,

 

27 Hänvisning till Kreuger, Norsk Kjöpsrett, Bergen, Oslo, tromso, 1977, s. 2. 28 Noerager-Nielsen, J. EDB-kontrakter, 1987, s. 25 ff. 29 SOU 1976:66 s. 205.

som Christophersen exemplifierar,30 då man köper t. ex. en maskin som omfattas av patenträttigheter. Köparen förvärvar fortfarande exklusiva rättigheter till den köpta kopian — begränsningen ligger i upphovsrättigheterna till produkten i bemärkelsen att kunden inte utan vidare kan kopiera varan. Det får man å andra sidan inte göra med en bok eller en CD-skiva heller.
    Skulle man finna att köplagen trots allt inte medger att köp av specialutvecklad programvara låter sig inordnas under dess regelverk ligger det ändå närmast till hands att tillämpa köplagens regler analogt, eftersom köp av programvara i allt väsentligt låter sig inordnas i det köprättsliga regelverket. Fördelarna med att inordna näraliggande avtalstyper som inte omfattas av köplagen, t. ex. byggnadsentreprenader och blandade avtal, påpekas f. ö. av Ramberg31 även om han ser svårigheter med att tillämpa alla regler fullt ut. Christners förslag att istället uttömmande avtalsreglera parternas rättigheter låter sig inte helt lätt göras.32 Hultmark diskuterar effekterna av att låta ett visst köpeobjekt falla utanför köplagens regelsystem,33 och konstaterar att slutresultatet många gånger innebär en analog tillämpning av köplagen — detta, skriver Hultmark, ”framstår som en omotiverad omväg”.

 

3. Felbegreppet
3.1 Allmänna felbestämningsregler
Fel i vara innebär att det föreligger kontraktuell brist eller avvikelse i varan efter dess avtalsenliga leverans till köparen. Som Grobgeld och Hertzman framhåller34 är felbegreppet som sådant inte definierat i de skandinaviska köplagarna. Eftersom det saknas en legaldefinition av köprättsligt fel får vägledning istället35 sökas i doktrinen, vilket ger vid handen att fel är en typ av kontraktsbrott som säljaren, enligt skandinavisk rättstradition, svarar strikt för.36 Säljarens skyldighet att leverera en felfri vara understryks såväl i köplagspropositionen37 som av Hellner.38 Innebörden av ”fel” blir i första hand de möjligheter till påföljder ett konstaterat ”fel” utlöser. Då ett fel i juridisk bemärkelse föreligger erbjuds köparen en meny av sanktioner — från rättelse

 

30 Christophersen, a. a. s. 66. 31 Ramberg I, a. a. s. 89. 32 I den revisionsrapport som publicerades 1987 av Riksrevisionsverket, Dnr 1986:1007, vilken omfattade en genomgång av avtalssituationen för ADB-drift i statsförvaltningen, konstaterades (s. 8 f.) att många avtal inte innehöll ”någon utförlig specificering av de olika momenten i uppdraget...därmed lämnas många frågor oreglerade, alternativt att de regleras genom muntliga överenskommelser”. 33 Hultmark C., JT 1993, nr 4, s. 690. 34 Grobgeld, L, Hertzman, O. SvJT 1981, s. 242. 35 Grobgeld, Hertzman, a. a. s. 243. 36 Grobgeld, Hertzman, a. a. s. 248. 37 Prop. 1988/89:76 s. 32. 38 Hellner, a. a. s. 59.

och omleverans till prisavdrag, hävning och skadestånd (beroende på vilka ytterligare rekvisit som är för handen) men konstaterandet av fel är i första hand ett preludium till köparens möjligheter att utlösa en eller flera av de sanktioner som står till buds. Av 17 § KöpL framgår att en vara ska stämma överens ifråga om art, mängd, kvalitet, andra egenskaper och förpackning med vad som följer av avtalet. Varan ska också vara ägnad för det ändamål varor av samma slag används till (”merchantable”) och passa för köparens särskilda ändamål (”fitness for purpose”).39 Varan ska vidare vara korrekt förpackad, inte avvika från köparens berättigade förväntningar och får ej brista i egenskaper som säljaren hänvisat till.
    Bestämmelsen ger uttryck för den grundläggande principen att bedömningen av om fel föreligger skall ske med utgångspunkt från vad som kan anses avtalat.40 Någon uttömmande feldefinition för generellt bruk har dock ej varit avsikten, istället erbjuds en vägledning för bedömningen i det enskilda fallet.41

 

3.2 Köplagens felregler
Hellner delar i pedagogiskt syfte in köprättsligt fel i följande kategorier:42 förutom rättsliga fel, rådighetsfel (avvikelse från köparens möjlighet att begagna varan på grund av förbud, t. ex. då myndighet utfärdat förbud mot viss användning), immaterialrättsliga fel (avvikelse från köparens rätt att begagagna varan beroende på annans immaterialrätt, t. ex. då licensrätten till viss programvara tillkommer någon annan) och faktiska fel. De faktiska felen kan i sin tur indelas i två kategorier — konkreta fel och abstrakta fel. Ett konkret fel karakteriseras av att köparen erhåller något annat än avtalat, dvs säljarens prestation avviker från det som överenskommits, (i skolexemplet levereras en blå bil istället för den beställda röda43). Ett abstrakt fel utmärks av att det föreligger en avvikelse från standard, det man normalt kan förvänta sig av en motsvarande vara.
    Om ett ADB-system ska levereras och det avtalats om en särskild norm för svarstider, säg 0,1 sekund och svarstiden istället uppgår till 1,5 sekunder, föreligger ett konkret fel. Om man i Sverige avtalat om leverans av ett bokföringssystem och detta levereras, men på ryska med kyrilliska bokstäver, föreligger ett abstrakt fel. En allmän norm för bokföringsystem i Sverige är rimligen att dessa in dubio begagnar sig av svenska kommandon och beteckningar.

 

 

39 Ramberg I, a. a. s. 37. 40 Prop. 1988/89:76 s. 84. 41 Prop. 1988/89:76 s. 33. 42 Hellner, a. a. s. 168. 43 Hellner, a. a. s. 168.

4. IT-branschens standardavtal
Befintliga standardavtal i branschen låter felbedömningen huvudsakligen utgå från vad som är konkret avtalat. Genomgående hänvisas till avtalade specifikationer som utgångspunkt, och f. ö. enda, tolkningsfakta vid felbestämningen. I Avtal 9044 definieras fel som varje avvikelse från avtalad specifikation45 vid leveranstidpunkten samt under ansvarstiden. Fel i Avtal 90 är alltså detsamma som att avtalad specifikation inte är uppfylld46 och leverantören är skyldig att på egen bekostnad avhjälpa sådana fel. Felansvaret omfattar dock inte fel som är utan betydelse för leveransens avsedda användning. Christner47 betecknar dessa som småfel, vilka inte innebär mer än marginella besvär och merkostnader för kunden (dessutom undantas en rad andra felorsaker från säljarens ansvar).48 Abdaka-85,49 som är ett avtal avsett för konsultuppdrag, gör inte ens ett försök att definiera fel utan hänvisar istället till ”fel som dokumenterats vid leveransprov” eller fel som framträder före garantitidens utgång. En felaktig konsultprestation beskrivs dock av Hansson50 som en avvikelse från avtalade egenskaper eller vad beställaren annars har rätt att kräva, bl. a. med hänsyn till marknadsföring m. m. som beställaren haft anledning att räkna med.
    Standardavtalet Utveckling 92, som utgivits enbart av SITO, är avsett att användas för uppdrag vid utveckling av såväl program som maskinprodukter.51 Avtalet utgår från att köparen lämnar en kravspecifikation varefter säljaren tar fram en produktspecifikation baserad på den förra, som ligger till grund för utvecklingsarbetet.

 

44 Ett s. k. agreed document avsett att användas vid systemleveranser baserade på standardprodukter, utarbetat i samarbete mellan branschorganisationerna SITO, Svenska IT-företagens Organisation (tidigare Leverantörsföreningen Kontor och Data, LKD), Dataföreningen i Sverige (DF), och Sveriges inköps- och logistikförbund (Silf). 45 Smitt, a. a. s. 73. 46 Dejve, Wahlin, a. a. s. 71. 47 Christner, a. a. s. 64. 48 Avtal 90, p. 12.4 a-b undantar följande fel: a) fel p. g. a. kundens användning med annan utrustning/tillbehör, b) fel p. g. a. kundens ändringar i strid med leverantörens instruktioner, c) fel p. g. a. kundens användning på annat sätt än vad som framgår av användardokumentationen eller p. g. a. försummelse hos kunden, hos tredje man eller omständigheter utanför leverantörens kontroll och, d) normal förslitning eller behov av förbrukningstillbehör. Fel ska avhjälpas genom rättelse, kringgåendeanvisningar eller andra åtgärder, t. ex. byte av programvara, under förutsättning att reklamation skett inom skälig tid, dock högst 1 år från effektiv leveransdag. Om felet inte avhjälps har köparen rätt till prisavdrag, eller, om felet är väsentligt och leverantören insett eller bort inse detta, hävning av avtalet i dess helhet (partiell hävning tillåts ej) samt vid hävning skadestånd, som dock begränsas till 15 procent av kontraktssumman. 49 ABDAKA-85, som även finns utgivet som ABDAKA-93, är utarbetat av Dataföreningen i Sverige. 50 Hansson, U. 1984, Konsultansvar på informationsbehandlingsområdet, artikel i Nordisk Årsbok i Rättsinformatik, 1984. 51 Christner, a. a. s. 5.

Leverantörens felansvar regleras i p 10, som anger att leverantören måste avhjälpa fel bestående i att produkten inte uppfyller produktspecifikationen. Felansvaret begränsas dock av att fel, som är utan betydelse för användningen och endast innebär ringa olägenhet (småfel), inte behöver åtgärdas. Christner påpekar52 att man i Utveckling 92 tillåter ett större utrymme för småfel än i Avtal 90.53 Säljaren svarar inte heller för fel som beror på att köparen lämnat felaktiga eller ofullständiga uppgifter eller urval av testdata eller felaktiga eller bristfälliga systemförutsättningar.54 Slutligen kan, för helhetens skull, en jämförelse göras med det licensavtal — EDEL 90 licensavtal — som framtagits av föreningen Svensk Programvaruindustri och Elektronikindustriföreningen, och anpassats efter svensk rätt55 för licensiering av datorprogram. Edel 90 saknar felbestämmelser, men garantibestämmelsen i p 7.1 innebär att licensen kan annulleras inom 30 dagar om licensobjektet (dvs. programvaran) ej uppfyller av licensgivaren i avtalet specificerade funktioner, således återigen en stark koppling till funktionsspecifikationerna. Även här finner man ett undantag för småfel, avtalstexten slår t. o. m. fast att avsaknad av småfel inte är möjligt inom programvaruindustrin.56 Genomgående för IT-branschens standardavtal är den starka kopplingen mellan feldefinition och avtalets tekniska (produkt-) specifikationer. Fel beskrivs uteslutande som en bristande överensstämmelse mellan produkt och specifikation.57 De felbegrepp som återfinns i köplagens 17 § vad avser t. ex. ändamålsenlighet, köparens förväntningar och utfästa egenskaper lyser med sin frånvaro. Samtidigt beskärs säljarens felansvar genom en rad inskränkningar, från undantag för småfel till fel p. g. a. köparens användning i strid med användardokumentationen. Det säljarvänliga felansvar som framtonar i standardavtalen förutsätter

 

52 Christner, a. a. s. 144. 53 I Utveckling 92 används uttrycket ”ringa olägenhet” medan Avtal 90 endast undantar småfel som inte innebär ”olägenhet” för kunden. I likhet med Avtal 90 undantas en rad andra felorsaker, se fotnot 48. Leverantören är skyldig att avhjälpa fel genom rättelse eller kringgåendeanvisningar, under förutsättning att felet reklamerats inom 6 månader från effektiv leveransdag. Avhjälps inte felet har köparen rätt till prisavdrag, men saknar rätt att häva respektive kräva skadestånd. 54 Christner, a. a. s. 144. 55 Smitt, a. a. s. 218. 56 P 7.2 stadgar: ”licensgivarens garanti innebär dock inte att licensgivaren garanterar att licensobjektet är helt fritt från programfel. Licenstagaren är införstådd med att sådan frihet från programfel ej kan uppnås inom programvaruindustrin”. 57 En jämförelse med standardavtalet AB 92 för byggnads-, anläggnings- och installationsentreprenader, och ABT 94 för totalentreprenader avseende byggnads-, anläggnings- och installationsarbeten kan vara av intresse. I dessa definieras fel som ”när del av entreprenaden inte utförts eller utförts kontraktsenligt”. Felbegreppet ses alltså mot bakgrund av hela avtalet, inbegripet syftesparagrafer och resultatförväntningar, liksom ändamålsbeskrivningar, snarare än enbart avtalets specifikationer.

slutligen att de funktionella specifikationerna är fullständiga och heltäckande vad avser avtalade funktioner i programvaran, något som knappast överensstämmer med verkligheten.

 

5. Faktiska fel i systemleveransavtal
5.1 Specifikationernas betydelse
Ett ADB-systems omfattning bestäms av innehållet i avtalsspecifikationerna. Syftet med dessa är dels att lämna en detaljerad beskrivning av säljarens leveransåtagande, dels ge köparen en möjlighet att stämma av faktisk leverans mot avtalad leverans58. Normalt tas specifikationerna fram sekventiellt — först tar köparen/beställaren fram egna kravspecifikationer, som specificerar köparens förväntningar. Därefter levererar säljaren funktionella specifikationer, eller produktspecifikationer,59 som närmare beskriver ADB-systemet och dess funktioner. I specifikationerna anges bl. a. funktionella krav och nivåer för kapacitet, svarstider, systemtillgänglighet (driftseffektivitet), prestanda och kompatibilitet.60 Ofta utförs arbetet med att ta fram specifikationerna efter avtalets undertecknande. Vid avtalets ingående föreligger alltså varken ett färdigt system eller ens kompletta ”ritningar” till det färdiga systemet.61

 

5.2 Abstrakt fel
Ett abstrakt fel föreligger om en vara avviker från den allmänna norm som föreligger för den aktuella varan, även om det inte är särskilt avtalat.62 Om det är nödvändigt att falla tillbaka på allmänna marknadsmässiga bedömningar, dvs. vad en köpare normalt förväntar sig, utgör avvikelsen ett abstrakt fel.63 En stol ska kunna bära upp vikten av en vuxen person,64 ett datasystem ska ha egenskaper som gör det ägnat för databehandling.65 Säljaren bär ett strikt ansvar för att varan motsvarar köparens befogade förväntningar.66 Även om ett kontrakt inte uttryckligen specificerar kvalitetsnivån på ett ADB-system, står det inte säljaren fritt att leverera vilken kvalitet som helst — köparen har rätt att begära en ”alminnelig god vara” om inte en uttrycklig friskrivning före-

 

58 Christophersen, a. a. s. 206, se även Noerager-Nielsen, a. a. s. 60. 59 Christner, a. a. s. 128, Utveckling 92, p. 1. 60 Noerager-Nielsen, a. a. s. 63 ff. 61 Bull, a. a. s. 77, ”Den ydelse man her kontraherer forefinnes ikke vid kontraktsinngåelsen og kan derfor ikke examineres eller proeves av noen av partene”. 62 Bergem J.E., Rognlien S., 1991, Kjopsloven kommentarutgave, s. 98. 63 Hellner, a. a. s. 169. 64 Bergem, a. a. s. 99. 65 Bull, a. a. s. 110, se även Noerager-Nielsen, a. a. s. 59: ”kan der ikke i aftalen eller i de ledsagende omständigheter ioevrigt findes nogen stoette for mangelsbedoemmelsen, anses kontraktsgenstanden alligevel for mangelfuld, hvis den ikke har den brugbarhed og vaerdi som er almindelig for genstande af den pågaeldende slags”. 66 Hultmark, a. a. s. 692.

ligger.67 Eftersom det ofta är svårt att bestämma kvalitetsnivån på säljarens förpliktelse endast med utgångspunkt i avtalet, kan man inte undgå att tillämpa allmänna principer om god standard i programvara, skriver Noerager-Nielsen.68 Köparen har rätt att begära ett ADB-system med sådana databehandlingsegenskaper att det kan användas i rimlig utsträckning för det avsedda ändamålet, även om inte avtalet specificerar detta.

 

5.3 Konkret fel
För att avgöra om ett konkret fel föreligger måste det först69 fastställas vilka förpliktelser säljaren åtagit sig ifråga om varans beskaffenhet, dvs. se till vad som egentligen är avtalat.
    Systemspecifikationerna i ett systemleveransavtal, hur detaljerade de än är, är sällan heltäckande. Lika lite som en arkitekts husritningar specificerar att dörrhandtagen ska sitta horisontellt och inte vertikalt, lika lite återfinns alla detaljer i ADBsystemets specifikationer (dörrhandtagen kan dock reklameras antingen genom att avtalet innehåller en hänvisning till allmänna byggnormer, Bygg-AMA, eller genom att köparen helt enkelt går in i grannens hus, pekar på dennes dörrhandtag och hävdar att det är sedvänja att skruva fast dörrhandtag horisontellt, något som inte låter sig göras lika enkelt vid systemleveransavtal). Under utvecklingsprocessen inträffar också normalt behov av tillägg och justeringar — och dessa tillägg regleras inte sällan muntligt eller inte alls. Svårigheten i att uteslutande tillämpa en konkret felbedömning på ett systemleveransavtal ligger inbyggd i prestationens karaktär. Eftersom avtalsobjektet, som tidigare nämnts, utgör ett slags res futura, skall köparen på förhand specificera varjehanda detaljer i den färdiga produkten utan att veta hur slutresultatet i detalj ser ut. Vanligtvis innebär utvecklingsprocessen att behov uppstår av justeringar och tillägg under resans gång för att den slutgiltiga produkten ska utföra avsedda funktioner. Många gånger kan emellertid dessa justeringar inte genomföras eller ens upptäckas förrän utvecklingsarbetet hunnit en bit på väg eller t. o. m. avslutats. Sådana ändringar, som alltså till sin natur uppträder som ett resultat av en långt gången utvecklingsprocess, låter sig naturligtvis svårligen beskrivas i de specifikationer som ska tas fram i inledningsskedet. Ytterligare en komplikation som tillstöter är det faktum att systemfunktionernas interagerande ibland uppträder på sätt som programeraren inte avsett — även om två separata funktioner programmerats korrekt kan dessa ”störa” varandra på så sätt att de ger upphov till en tredje funktion som inte är önskvärd.

 

67 Bull, a. a. s. 95 f. 68 Noerager-Nielsen, a. a. s. 61. 69 Hellner, a. a. s. 164.

Dessa störningar i form av nya funktioner — vilka kanske inte ens kan förutses vid programmeringen — utgör ytterligare en svårighet för köparen då systemspecifikationerna ska tas fram.
    Den konkreta felbestämningen blir därför behäftad med många svagheter, eftersom det underliggande materialet omöjligt kan vara komplett p. g. a. avtalsobjektets natur. Därvidlag blir köparen den part som drar det kortaste strået, speciellt i de fall då branschens standardavtal använts, då dessa lyfter fram systemspecifikationerna som rättesnören lika perfekta som de stentavlor Moses en gång erhöll.

 

5.4 Följden av branschpraxis
Då felansvaret kopplas endast till avvikelser eller brister i systemspecifikationerna, innebär detta en otillfredsställande lösning på många punkter.
    Rätten att förvänta sig ett system som är ändamålsenligt i generell bemärkelse har redan berörts under p 5.2 ovan, men även i det enskilda fallet får man förutsätta att en köpare har ett särskilt avsett ändamål för det system som beställs. En försiktig köpare gör klokt i att låta huvudavtalet noggrant beskriva syftet70 med ADB-systemet och även ange de förutsättningar och förväntningar som ligger till grund för avtalet — annars riskerar han att en eventuell tvist om fel i programvara endast behandlar innehållet i avtalsspecifikationerna. Ett systemleveransavtal bör även innehålla en fullgod beskrivning av ADB-systemet uttryckt i funktioner, kapacitet och kvalitet på ”vanlig svenska” (alltså inte uttryckt i tekniska termer), utöver innehållet i specifikationerna.71 Det är angeläget att alla sådana beskrivningar är så ”objektivt mätbara som möjligt”, samt att kontraktet slår fast vilken hårdvara den färdiga produkten ska kunna användas på.72 Svagheten i att låta felbedömningen utgå endast från avvikelser i specifikationerna illustreras också av problematiken kring rättsliga fel. Antag att en leverantör av ett ADB-system infogat en inköpt programvara där upphovsrätten tillkommer någon annan, och avtalet säger att köparen ska erhålla hela upphovsrätten till det färdiga ADB-systemet. Genom att upphovsrätten till det slutgiltiga systemet delvis tillkommer tredje man, kan köparen inte oinskränkt förfoga över slutprodukten, t. ex. för kopieringsändamål eller för vidareutveckling. Detta utgör inte ett sådant fel som skulle framgå av specifikationerna, men likväl rör

 

70 Bull, a. a. s. 63, genom att ange syftet med avtalet slår man fast det överordnade ändamålet för kontraktet. 71 Bull, a. a. s. 64 f. exemplifierar med en person som köper ett rör — det väsentliga för köparen är inte att få reda på att röret har två öppningar, det som ska beskrivas är hur mycket vätska som kan rinna genom röret, hur stort tryck röret tål och om alla slags vätskor kan passera igenom. 72 Bull, a. a. s. 82, särskilt om standardprogramvara.

det sig om ett fel, närmare bestämt ett rättsligt fel.73 Enligt Ramberg74 svarar säljaren, om inget annat avtalats, för att tredje man inte kan göra anspråk på en vara.75 Det är knappast troligt att det skulle vara acceptabelt att frånhända köparen rätten att påtala fel i gods med hänvisning till att detta inte utgör avvikelse från specifikationerna. Om säljaren inte ska ansvara för rättsliga fel måste det nog klart och tydligt framgå av avtalet.
    Konkreta fel i bemärkelsen bristande överensstämmelse med vad som är avtalat, kan med stor sannolikhet göras gällande utan att begränsas till fel som definieras som ”avvikelse från specifikationer”, även om avtalet använder sig av standardavtalsdefinitionen. Har ett avtal ingåtts där syftet beskrivs som utveckling av ett system som samtidigt kan användas av 1000tals användare, i minst tre olika länder, och det endast kan användas av 100 stycken i ett enda land, är även detta ett konkret fel som kan åberopas även om det inte uttryckligen framgår av specifikationerna. Av yttersta vikt för den konkreta felbedömningen är därför att avtalet tillhandahåller tillräckligt mycket information för att erbjuda tolkningsfakta vid en felbedömning. Ett avtal måste innehålla så tydliga och detaljerade beskrivningar av det slutliga ADB-systemet att dessa bildar en ram för specifikationernas innehåll så de senare kan förstås i sitt rätta sammanhang. Detta kan också uttryckas på så sätt att huvudavtalet måste vara styrande framför specifikationerna, inte tvärtom. Härigenom skapas en så bred bas som möjligt för den konkreta felbedömningen som ska utgå från avtalsinnehållet i dess helhet, dvs vad parterna totalt sett kommit överens om.
    Föreligger inga konkreta hållpunkter i ett avtal där tvist råder om det föreligger fel eller ej, måste en generell bedömning göras. Köparen har rätt att erhålla en programvara som lever upp till normal standard för motsvarande programvaror.76 Enligt Bull77 ska felbedömningen regelmässigt utgå från ADB-systemets databehandlingsegenskaper, även om det vid avtalstolkningen inte klart framgår vilka databehandlingsegenskaper parterna specifikt avtalat om.
    För att återgå till ovanstående exempel med ADB-systemet som skulle användas av 1000-tals användare i flera länder — finns det motsvarande system på marknaden som visar sig kunna användas av 1000-tals användare i olika länder, bör den bristande

73 I vissa avtal behandlas detta på så sätt att säljaren istället lämnar en garanti som innebär att köparen inte ska besväras av immateriella anspråk från tredje man. 74 Ramberg II, a. a. s. 64. 75 Ramberg II, a. a. s. 64: i CISG uttrycks detta så att varorna skall vara ”free from any right or claim of a third party”. 76 Blume, P., 1986, Edb-kontrakter — et unikt område?, Nordisk Årsbok i Rättsinformatik 1986, s. 24 ff. 77 Bull, a. a. s. 110.

egenskapen utgöra ett abstrakt fel som köparen kan göra gällande (förutsatt att det saknas en uttrycklig friskrivning i avtalet). Det är inte troligt att ansvaret för abstrakta fel försvinner därför att möda läggs ner på att begränsa omfånget på de konkreta fel som kan åberopas. Av ordalydelsen i köplagens 17 § framgår att lagstiftaren vinnlagt sig om att ta hänsyn till köparens berättigade förväntningar. Dessa förväntningar styrs av de jämförbara objekt som finns på marknaden, oavsett om dessa jämförelser flyter in i avtalet eller ej. Det abstrakta felansvaret kommer därför att belasta en säljare av ADB-system, också om denne vidtar mått och steg för att minimera sitt ansvar genom snäva feldefinitioner i avtalet.
    För en köpare innebär ovanstående resonemang att fel i ADBsystem bör angripas i två steg. I första hand bör avtalet vara så omsorgsfullt och tydligt utformat att den konkreta felbedömningen i mesta möjliga mån underlättas. Avtalet ska innehålla tillräckligt mycket information för att det överenskomna avtalsobjektet ska framgå klart och tydligt, varvid specifikationerna ska utgöra en teknisk beskrivning på lägre nivå som följer efter huvudavtalets bestämmande beskrivning.78 I andra hand får köparen förlita sig på den abstrakta felbedömningen, varvid de allmänna normer som föreligger på den aktuella marknaden är av stor betydelse. En försiktig köpare gör därför klokt i att hålla sig så välinformerad som möjligt om jämförbara produkter. En köpare ska inte låta sig nöja med en starkt beskuren feldefinition som i mesta möjliga mån skyddar säljaren. Måste emellertid en sådan bestämmelse accepteras p. g. a. säljarens relativa styrka gentemot köparen, bör köparen ändå kunna falla tillbaka på det abstrakta felansvaret genom att åberopa en brist i programvaran om denna innebär en avvikelse från vad som objektivt sett kan förväntas vid köp av motsvarande ADB-system.

 

6. Funktionsfel som modell
Inte ens om systemleveransavtalet innehåller tydliga ändamålsbestämningar och detaljerade specifikationer kan en köpare vara säker på att alla funktionella fel kan åberopas. Många gånger kan specifikationerna ange vad som ska utföras och t. o. m. hur, men det brister ofta i varför och med vilket resultat.
    För att finna en tillfredsställande lösning kan avtalet kompletteras med en generell feldefinition kopplad till felets inverkan på hela ADB-systemet. Inom ramen för den konkreta felbedömningen behövs en generell norm som frikopplad från systemspecifikationerna kan tillämpas om systemet inte fungerar eller fungerar

 

78 Detta löses enklast genom att i huvudavtalet inta en klausul som anger i vilken ordning de olika avtalsdelarna ska äga tolkningsföreträde, varvid huvudavtalet ska gälla framför specifikationsbilagorna.

dåligt. Christophersen79 framhåller att även om programvaran isolerat sett överensstämmer med specifikationerna och även om hårdvaran är kontraktsenlig, kan det levererade systemet likväl vara felaktigt om det inte kan utföra den databearbetning som förutsattes vid avtalets ingående. En traditionell felbedömning där säljarens förpliktelser prickas av mot specifikationerna erbjuder en otillfredsställande lösning, eftersom köparen riskerar att varan visserligen bedöms som leveransgill, men inte är funktionsduglig.
    För att komplettera felbestämningen i ADB-system bör man ta sin utgångspunkt i de avsedda funktionerna hos ADB-systemet. Fungerar systemet som det är tänkt, snarare än fungerar systemet som det är specificerat. Genom att komplettera med en feldefinition som definieras i termer av påverkan på systemets funktionsduglighet skapas ytterligare en nivå av felbestämning.
    En sådan modell kan se ut på följande sätt: alla fel som uppstår delas in i en av tre kategorier — A, B eller C.
    A-fel definieras som sådana fel som har en sådan negativ inverkan på en eller flera väsentliga funktioner att köparens dagliga nyttjande av systemet störs avsevärt; B-fel definieras som sådana fel som har en avsevärd negativ effekt på köparens effektiva nyttjande av systemet utan att orsaka allvarliga avbrott i det dagliga nyttjandet; C-fel definieras som sådana fel som inte faller in i A- och B-kategorierna.
    Genom att använda ovanstående modell införs en feldefinition som tar sikte på användningen av det färdiga ADB-systemet snarare än utformningen.80 Den skeptiske läsaren invänder möjligen att ovanstående modell kan stöta på svårigheter i bevishänseende — hur avgöra vad som är A-, B- och C-fel respektive hur mäta felens inverkan på ADB-systemet. Utan att förringa dessa svårigheter kan det konstateras att köparen ändå alltid måste visa eller beskriva,81 eller t. o. m. återskapa de fel som ska påtalas inför säljaren. Svårigheterna i sådana fall skiljer sig inte nämnvärt från problematiken i modellen, däremot erbjuder modellen en betydligt större möjlighet att åberopa fel i ADB-system gentemot säljaren, eftersom felbegreppet byggs på med en bedömning som grundar sig på det förväntade resultatet, sådant det beskrivs i avtalet, snarare än de enskilda komponenterna. Istället för att se till de separata moment

 

79 A. a. s. 296. 80 Detta stämmer väl överens med den av Bull förespråkade lösningen att uttrycka systemkrav som databehandlingseffekter eller problemlösningar, a. a. s. 76. 81 Dejve, Wahlin, a. a. s. 79, vid reklamation (under Avtal 90) måste kunden både ange och visa hur felet yttrar sig, något som kan skapa problem då det inte alltid är helt lätt att återskapa ett fel i datormiljö.

som ska utföras betraktar man mervärdet av att de olika funktionerna samverkar för att uppnå önskat resultat. Eftersom summan av de enskilda funktionerna i ett ADB-system är större än delarna var för sig, innebär modellen att just detta kan läggas till grund för felbestämningen. Fel föreligger då den efterfrågade databearbetningen fallerar eller brister — oavsett om det fel som uppträder utgör en avvikelse från specifikationerna eller ej.

 

7. Några avslutande synpunkter
Denna artikel har diskuterat möjligheterna att göra gällande köprättsligt fel i ADB-system inom ramen för 1990 års svenska köplag. I likhet med tillämpningen i våra skandinaviska grannländer Norge och Danmark förefaller det riktigt att låta köp av hårdvara och programvara, inbegripet specialutvecklad sådan, falla under köplagens tillämpning. Då fel i ADB-system avhandlas vore det olyckligt om den snäva feldefinition som förekommer i ITbranschens standardavtal tilläts dominera. Kopplingen mellan avtalade specifikationer och feldefinitionen täcker endast en del av de fel som kan uppstå vid köp av programvara — allvarliga fel kan också förekomma med avseende på bristande funktioner, kvalitet och, framför allt, ändamålsenlighet. Det är därför angeläget att skapa tydliga och genomarbetade huvudavtal vars innehåll utgör en bred bas för den konkreta felbedömningen.
    Oaktat den syn som förekommer i standardavtalen bör abstrakta fel kunna göras gällande vid köp av ADB-system. Svårigheterna ligger snarare i bristen på jämförelseobjekt än rätten att föra fram sådana invändningar, men det abstrakta felansvaret faller inte bort som en följd av inskränkningar i den konkreta felbedömningen. I det konkreta fallet innebär användningen av en modell för feldefinition som tar sin utgångspunkt i felets inverkan på ADBsystemets funktioner, snarare än avvikelser från systemspecifikationerna, att en köpare väsentligt ökar sina möjligheter att påvisa fel i det levererade systemet.
    En försiktig köpare som ingår systemleveransavtal gör klokt i att noggrant utarbeta sitt huvudavtal och inte endast förlita sig på bilagda specifikationer uttryckta i tekniska termer. Genom att både ange sina förväntningar på det ADB-system som ska utvecklas och dessutom beskriva syftet med avtalet, liksom övergripande krav på det färdiga resultatet, kan köparen skapa en betydligt vidare ram för den tolkning som skall ske om avtalet — vilket inte sällan händer — slutar i tvist om vad som utgör leveransgill vara.