Sæt os gerne 30 år tilbage, tak!

Det burde vel egentlig være en slags logik for burhøns at man ikke kan læsse ansvareret for kodens opførsel over på nogen der ikke har den ringeste chance for at sætte sig ind i hvordan den er skrevet.

Man kan da heller ikke læsse ansvaret for flyrejser over på de rejsende eller ansvaret for hvorvidt vores samfund fungerer over på politikerne (eller hvad?)…

Jeg er dog bange for, at sådan et forslag vil blive kædet sammen med noget patent-halløj, da softwarefirmaerne nok ikke vil dele deres guldæg.

Jeg har tit hørt udtrykket "Who do you sue, when Linux doesn't work?" fra folk, der bruger kommercielt software. Det er let at sende den tilbage med spørgsmålet "Who do you sue, when Windows doesn't work?", for EULA'en for Windows giver ikke meget at komme efter.

Problemet er, at så længe hardware og software kommer fra hver sin leverandør, så er det en ukontrolabel risiko at indgå garantier for meget andet end mediets læsbarhed.

Jeg har i mit arbejde som konsulent mødt en del HP-UX og AIX installationer, hvor Linux eller FreeBSD kunne være en godt alternativ. Men HP og IBM kan tilbyde servicekontrakter over 10 år omfattende begge dele, hvori der indgår driftsgaranti.

Igen her er der selvfølgelig risici, for trediepartssoftware er ikke omfattet af garantien, og man kan komme i den situation, at HP eller IBM fremstiller en patch, der løser et givent problem, men den ødelægger noget for ens trediepartssoftware, så den ikke længere kan køre.

Det bedre svar på "Who do you sue?" er måske, "Who can you call, when your lawyer can't help?". Her kan man ringe til PHK eller andre, hvis man har kildeteksterne. Det er ikke gratis, men det er i det mindste muligt.

Thomas

Det er OK med mig at der er en NDA med kildeteksten, så patent-problematikken er ikke-existerende.

Velsagtens kun lige i denne sammenhæng?

/esni

Er nok lidt overdrevet. Der er meget lidt af det, almindelige brugere bruger computere til i dag, som man kunne med det software, man havde for 30 år siden.

Men krav om produktansvarlighed i et vist omfang kunne nok få nogle software leverandører til at fokusere mere på kvalitet end på at tilføje flere og flere features.

Et alternativ til Poul-Hennings forslag kunne være:

Hvis software ikke leveres med fuld produktansvar, skal brugeren hver gang programmet starter advares om, at softwaren ikke er egnet til anvendelser, der kræver stabilitet, sikkerhed eller bevarelse af brugerdata. Og først når brugeren har accepteret dette, kan softwaren bruges.

Det vigtigste i denne sammenhæng er, at beskeden er kortfattet og forståelig, så begrænsningerne ikke kan gemmes i en alenlang EULA, som ingen gider læse.

Umiddelbart et godt forslag, men så kom jeg til at tænke på, at det jo sådanset kun er nogle ganske få der har gavn af det. Det ville ikke hjælpe min mor det fjerneste, på samme måde som detaljerede tegninger til min bil, ikke ville hjælpe mig.
Det ville kun kunne bruges til noget, hvis man også fik lov til at distribuere rettelserne, men det tvivler jeg på kommer til at ske.

Men Ok, det er da et skridt i den rigtige retning, omend det kun er et meget lille et.

Er det nok at have kildekoden til rådighed? Hvad med compileren? Den kan have oversætter fejl.

Du kan ikke seriøst foreslå at vi skal have endnu flere idiotiske lawyer-inspired pop-ups ?

Hvis det var sagførerinspireret, ville det være langt og uforståeligt (ligesom EULA'er). Ideen var at gøre beskeden kort og forståelig.

Selvfølgelig er det ikke en ideel løsning -- den ideelle løsning ville være, at al software levede op til produktansvar. Men det er ikke realistisk, at al software kan gøre dette, så der skal være måder at tillade software uden produktansvar. Dit forslag var at give brugeren mulighed for selv at vurdere omfanget af problemet ved at analysere koden (og for at rette koden, så nogle problemer forsvinder). Det mener jeg ikke er realistisk for ret mange -- kode er vanskelig at analysere, uanset om man gør det med øjenæblet eller med kodeanalyseringsværktøjer.

Derfor foreslog jeg, at afskrivelse af ansvar skal være tydelig og med en beskrivelse af konsekvenserne: Uanvendelighed til seriøs brug, med mindre du tager meget omhyggelige forholdsregler ved brugen.

Evt. kunne kravet om advarsel udvides til også at omfatte services bygget ovenpå denne software: Når en bruger starter en service, skal denne advares om, at den er bygget på usikker software, og at brugeren risikerer datatab, maskinnedbrud og tab af sikkerhed ved brug af denne service.

Mon ikke dette er et stærkere incitament til at opfylde produktansvar end blot at skulle gøre (potentielt ulæselig) kode tilgængelig?

Jeg tror ikke på simple løsninger som den foreslåede.

Jeg tror i langt højere grad på færre regler, patenter osv. Det vil skabe et miljø konkurrence finder vinderne og ikke lovgivere og politikkere.

Slaget skal vindes i virkeligheden og ikke vha. lovgivning. Virkeligheden vinder altid til sidst.

Slaget skal vindes i virkeligheden og ikke vha. lovgivning. Virkeligheden vinder altid til sidst.

Helt sikkert. Spørgsmålet er så bare, om det er lige netop den virkelighed, vi bryder os om, som vinder. Jeg kunne nævne visse afrikanske lande, med megen lidt lovgivning. Der har 'virkeligheden' i den grad vundet...

For Hr. og Fru Jensen, og alle andre med ingen eller kun middelmådige programmørevner, vil en "spandfuld" kilde- eller klytkode være lige så uforståeligt som en lang sagførerinspireret EULA.

Jeg tvivler derfor på, at PHK's forslag har så stor virkning, hvis det blev gennemført.

Hvorfor skulle man egentlig kunne fraskrive sig ansvaret for et stykke software ved at levere kildekoden med? For at holde analogien, så kan bilfabrikanter jo heller ikke fraskrive sig produktansvar ved og levere tegninger og håndbog til deres biler ;-)

mvh
Allan Wermuth

For Hr. og Fru Jensen, og alle andre med ingen eller kun middelmådige programmørevner, vil en "spandfuld" kilde- eller klytkode være lige så uforståeligt som en lang sagførerinspireret EULA.

Kan Hr. og Fru Jensen forstå indholdsfortegnelsen på deres medicinæsker? Er det derfor ligegyldigt, at medicinalfirmaer skal oplyse, hvad de propper i deres produkter?

Hr. og Fru Jensen har vel øre og mund, og kunne spørge nogen, der rent faktisk læste i koden?

Og på Hr. og Fru Jensen arbejdsplads, hvor kvaliteten af softwaren rent faktisk betød noget, ville den vel blive udvalgt af en kompetent IT-afdeling?

@Jacob
Du tænker vel ikke på afrikanske lande hvor lovgivningen er simpel af en eneste årsag: Diktatoren bestemmer ...

Bingo!

Det er præcist derfor det er en god ide og at Microsoft m.m. kæmper imod mæd næb og klør. De er ikke bange for Hr og Fru Jensen, men de ER bange for Mærsk, TDC, VW, Arriva osv som vil have styrken til at tage kampen op med dem hvis de leverer noget klytkode der ikke virker og samtidig har krævet mange penge for det.

Derudover er de bange for gruppesøgsmål som er ved at blive mulige i EU hvor f.eks forbrugerstyrelsen kunne føre en sag for mange tusinde private mod Adobe eller Microsoft for at deres softvare er for dårlig for private (for mange sikkerhedshuller osv)

Jeg synes ikke, at kildekode gør nogen forskel. Du kan nemt lave total uoverskueligt kildekode, der er ligeså ubrugelig som maskinkode - naturligvis kan producenten hellerikke forstå den, men den kan genereres automatisk.

Derimod, bør tages hensyn til pris. Det siger sig selv, at hvis du forærer et program bort, så har du ikke mulighed for at yde økonomisk erstatning, hvis et program ikke fungerer. Gratis software, bør derfor friholdes fra ansvarsforpligtelsen.

Hvis der købes en bog, og der i bogen er vedlagt eksempler på software, som tjener til illustrative eksempler, så mener jeg også at det her er brugerens ansvar, at sikre koden fungerer.

Mange steder, hvor der opbevares personfølsomme oplysninger, eller sættes krav til sikkerhed, vil også kræves produktansvar, og dermed tvinges kunden bort fra open source.

For Microsoft, vil det være et fremskridt - man vil nærmest blive tvungen bort fra open source i det offentlige, og over på en kommerciel platform. Men, naturligvis følger forpligtelser med. Samme i erhvervslivet, hvis der opbevares personfølsomme oplysninger, eller sættes krav til produktansvar.

Garanti og produktansvar på kommercielt software, vil give det et skub fremad - måske ikke i features, og kompleksitet, men i funktion og stabilitet. Fungerer softwaren ikke, er der "bagdøre" osv, så vil producenten stå til ansvar, og binder økonomisk for skader, som minimum en pris, der svarer til produktets pris. Et operativsystem, der får "virus", eller på anden måde bliver gjort ufunktionsdygtig eller mindre funktionsdygtig, vil også være under produktansvar, og kunden kan kræve sine penge refunderet, eller en del heraf der tager hensyn til produktets mindre hastighed.

Tjae, og så ? Hvilken bedømmelse tror du sådan software vil få af dem der skal kigge på det ?

Som jeg nævner, så vil kildekode, der angives som del af litteratur (en bog), og hvor den tjener til illustration, samt oversættes af brugeren gå fri. Her, kan man sige, at brugeren med rimelighed sætter sig ind i koden, og skal forstå koden, for at "måtte" køre den. Samtidigt, må koden ikke ligge i binær format, da dette ikke tjener til illustration, men kun foreligge som sourcekode.

Du overser at med tilgængelige kildetekst kommer der en mulighed for uafhængig faglig kritik...

Du kan nemt frembringe automatisk kildekode, endog med kommentarer, som er umuligt at forstå. Og jeg skal gerne ligge en debugger på nettet, der udfra binære filer kan producere en total uforståelig men oversættebar kildekode på nettet, som du bare skal oversætte. Og den kan også få automatiske kommentarer, som den selv søger at opfinde, f.eks. "her adderes så tallene". Kildekode siger ikke et hak. Det er alene blærerøve, som skal gøre sig kloge på kodning, der har mening om kildekoder - specielt ved kode som produceres af kommercielle virksomheder, der ønsker at beskytte deres kode.

Laver du derimod en ordentlig dokumentation, i form af en bog, og har koder der illustrerer eksemplerne, så er såvel teksten, som koden, lavet med henblik på forståelse, og så er det noget andet. Dog, synes jeg også, man må sætte krav til at brugeren selv kan oversætte.

Langt det meste "open source" software, har ikke tilstrækkelig dokumentation til at kunne anvendes som undervisning, og koden kan kun i få tilfælde betragtes som illustration til en forklaring af hvordan noget fungerer.

Dette er - samtidigt med jeg synes det er rimeligt - årsagen til, at jeg også vil friholde gratis software. Du er inforstået med, når du køber et program, så kan du maksimalt få programmets pris refunderet i tilfælde af fejl og mangler, og for gratis softwere behøves ikke garanti og ansvarsforpligtelser.

Naturligvis, bør ingen programmør kunne gå fri og stilles udenfor ansvar, ved direkte kriminel kode, der bevidst har til henblik at ødelægge andres computersystemer, uanset om det er gratis eller med source.

F.eks. en bagdør, vil ofte kunne være et uheld, f.eks. lavet i forbindelse med debugging, til en beta udgave. For kommercielt software, er det virksomhedens ansvar, uanset om en fejl er bevidst, eller uheld. Men, skal personer straffes for det, og ikke kun et spørgsmål om refundering af programmets pris, så er det noget som må afgøres i hver enkelt tilfælde, om programmet er udviklet med henblik på terror, eller om det er et uheld. Er uheldet groft uansvarlig, kan man også dømmes for det.

Det ved vi allerede: De reagerer ikke. De køber gladeligt software, hvor der følger ansvarsfraskrivelse med, og ingen source. Præcis det samme, vil ske med dine krav: Virksomhederne leverer noget kunstigt frembragt source, som ingen kan overskue, og dette erstatter den nu obligatoriske ansvarsfraskrivelsesdokument. Det er jo logik - og det kan danske bank nemt forstå - at virksomhederne ikke kan give deres source gratis bort, da de er en kommerciel virksomhed, og at de ikke kan acceptere loven med hensyn til at skulle stå til ansvar for softwaren, da det vil sætte softwaren 30 år tilbage.

Naturligvis køber danske bank den - det har de allerede gjort. Ligesom alle andre, i det private erhvervsliv, stiller de sig gladeligt tilfreds med software der har ansvarsfraskrivelser.

Som køber, vil jeg på ingen måde acceptere at producenten kan vedlægge en CD med en ansvarsfraskrivelse - uanset at den nu også indeholder gyllesource - som er automatisk produceret. Jeg vil have, at alt software jeg giver penge for er i orden, og leveres med produkt og funktionsansvar, og holder hvad det lover.

Med hensyn til risikoen for at blive kanfølet, så er den langt større, hvis du vedlægger source, som faktisk forstås. Microsoft, vil blive kanøflet under alle omstændigheder - og som de fleste andre virksomheder, står de sig bedst ved at vedlægge automatisk genereret source. Derved, kan du af koden ikke se de reelle fejl og huller, mere end i de binære filer, som leveres nu.

De køber gladeligt software, hvor der følger ansvarsfraskrivelse med, og ingen source.

Du overser at der nu er blevet frembragt en mulighed for at vurdere kvaliteten af den medleverede kildekildekode - en mulighed, der ikke har været der før.

Og det er givet at en kompetent IT-afdeling vil kunne genkende disassembleret kode fra rigtig kildekode, og derefter stille leverandøren dette spørgsmål:

Mener i virkelig at I bør kunne slippe for produktansvaret, når I ikke tør fremlægge den rigtige kildekode?

Indenfor millitæret, mener jeg ofte der stilles krav til adgang til sourcen, ikke mindst for at kunne analysere sikkerhedsaspekter. Selvom sourcen leveres, kan den dog godt være fortrolig, eller hemmelig stemplet.

Men, i langt de fleste tilfælde, og dette gælder også banken, stiller man sig til tåls med, at der ikke medleveres source. Man kunne meget nemt have krævet det, og gået over til åben source. Men, det gør man ikke. Man accepterer endog ansvarsfraskrivelser, også selvom der ikke vedlægges source.

Naturligvis, kan du se på sourcen, om den er overskuelig, og hvis du som virksomhed virkeligt går op i sikkerheden, vil du kunne stille spørgsmål til uoverskuelig source, og hvis at sourcekoden tydeligt er svulmet op til meget mere end den reelle funktionalitet forlanger. Ikke desto mindre, så ved vi, at der ikke sættes spørgsmål. Der antages, at når softwaren kommer fra f.eks. Microsoft, så er den i orden... Og selv mange af deres pengeautomater anvender Microsoft operativsystem.

Selvfølgeligt, kunne banken sætte krav til operativsystemet - og vælge et andet, som laves under høje sikkerhedskrav, og med funktionalitet begrænset til hvad det er nødvendigt, indenfor banken, og f.eks. pengeautomater. Ved at begrænse funktionaliteten, bliver operativsystemet mindre, og nemmere at stå inde for sikkerheden for.

Bankerne behøver ingen EU lov for at kunne sætte krav. De, som behøver det, er os "private" kunder til software. Vi har ikke mulighed for at sige, at vi ikke vil have microsofts software, og betale for at få noget bedre.

Samtidigt, har vi ikke økonomi, til at smide ud efter ikke fungerende software. For privatkunder, er det derfor af utrolig vigtighed, at vi får en lov, så vi kan få pengene retur, hvis softwaren er noget lort.

Erhvervskunder, er jeg som sådan ligeglade med. De må selv kæmpe for 3 måneders reklamationsret. Og ønsker de den ikke, kan de også i fællesskab blive enige om, at de produkter de sælger alene indbyrdes, ikke bør have reklamation og garanti.

Det vigtige er, at der er garanti og reklamationsret, på det software, og service, som de tilbyder privat kunder.

For at lave en glidende overgang så kunne man måske starte med at lave følgende 3 regler skal være opfyldt for ALT software.

1) boundary checking, altid chekke at man ikke overskrider array, buffer, ... kan også kaldes input length validering

2) input value validering. Således at værdier uden for det forventede ikke behandles.

3) no client trust, således at når man laver en elektronisk multiple choice examen i geografi? så sender man ikke de korrekte oplysninger til clienten, da man ikke kan stole på clienten.

I andre brancher, fx. Revisor, Advokat, læge og sikkert bygningsingeniør, så kan man blive personligt straffet for fejl. Hvorfor kan en programmør så ikke også blive det? Man kan endda blive frakendt retten til at udøve sin praksis. Hvorfor skulle dette ikke gælde en programmør?

Visse dele, af dit forslag, kan give problemer, når vi senere kræver, at enhver linie og branch, skal være udført ved test. Problemet er, at dette krav, gør at kode der ikke "er adgang til", f.eks. valideringskode, som kun er sat ind for at tjekke for en sikkerhedsskyld, ikke altid reelt kan accesses. Det betyder ikke, at ovenstående krav ikke kan opfyldes - kun at det skal gøres på en måde, så det ikke medfører problemer, for et krav om at alle linier skal være "påvirket" under test, og enhver retning af branch, skal være taget. F.eks. vil man typisk ikke have lov at bruge sin egen kode til arraycheck.

Et krav, om at der skal udarbejdes test vektorer eller test programmer, således at enhver linie i programmet udføres, og enhver branch udføres i alle retninger, vil være med til at fjerne en del problemer. Dels, sættes automatisk krav til en rimelig test, og man kommer ikke igennem uden at have prøvet programmet. Testen, er samtidigt grundig. Og endeligt, er det muligt at tjekke automatisk med et valideringsværktøj: Får du givet program, og testvektorer, samt et valideringsværktøj, så er muligt at valideringsværktøjet automatisk siger ok til testen.

Dette er en meget vigtig egenskab, for et eventuelt lovkrav, at det er til at håndtere en automatisk form for test, der står inde for at lovkravet opfyldes.

Mit forslag er, at man fra starten sætter krav til testvektorer, eller testprogrammer skal foreligge, og at det skal være dokumentation for, at alle tests er gennemførte - f.eks. ved at kunden kan købe et valideringsværktøj, og anvende virksomhedens testvektorer/programmer, og se det opfylder kravet. Et sådant valideringsværktøj, kan eventuelt indbygges i operativsystemet, så det ligesom microsofts "signatur", angiver overfor kunden, at dette program er valideret.

Programmeringsteknisk, sættes dog også krav til, at man koder på en måde, så alt kode reelt kan tilgås med testvektorer, og ikke mindst når man er ude i "test" kode, så risikeres at der er problemer. Hvis der eksempelvis lægges en array test ind, og at programmet på naturligvis umuligt kan komme udenfor arrayet, så kan det ikke godkendes. Derfor, skal den type test være del af sproget, eller tjekket skal udføres på en måde, så der kaldes en rutine, hvor vi kan stå inde for, at denne rutine er testet og fungerer sikkert.

Hvis vi starter med, at sætte krav til programmørerne skal indbygge tests i deres software, og det ikke opfylder ovenstående krav - så riskerer vi nemt at skyde os selv i foden, fordi vi derved forhindrer at en ordentlige krav senere kan påtvinges. Med andre ord, er det dårligere at indføre, end undlade.

På den anden side, synes jeg det er en dårlig løsning, at bare fordi en programmør har gjort alt for at opfylde sådanne krav, at han så kan kræve penge for programmer som ikke fungerer. Den dur ikke. Udvikler du software til private, vil du kunne kræves at betale pengene retur, hvis dit software ikke lever op til det lovede, eller simpelthen ikke fungerer. Arbejder du for en virksomhed, er det væsentlige at du ikke har gjort noget kriminelt. Selve den økonomiske risiko, ved at betale penge tilbage, på grund af manglende funktion, ligger hos virksomheden, og ikke programmøren. Vurderes, at noget er direkte terror, er naturligvis risiko hos programmør, overordnede, og virksomheden.

PHK: Dit forslag er godt, meget godt vil jeg mene.

Jeg læser "... fuld kildetekst ..." som netop det - uden fusk, uden skjulte detaljer. Når nogle personer her tale om at gøre kilekoden uoverskuelig har de - ifølge mit verdensbillede - allerede brudt din regel. Jeg syntes at deres foreslag burde gøres ulovligt indirekte, ikke ved kryptiske modificeringer af din formulering.

Jon Bendtsen: Du siger

Er det nok at have kildekoden til rådighed? Hvad med compileren? Den kan have oversætter fejl.

Men compileren er jo også software - så kan firmaerne jo undersøge den, eller lade compiler producenterne have garanti. Husk nu at firmaer også for mulighed for at uddelegere noget af deres ansvar til underleverandører.

I en senere post med overskriften "Forslag til glidende overgang til produktansvar." giver du tre forslag til at løse et problem - men hvilket problem er det du tror dit forslag løser? De tre praktiske håndregler gør jo ikke software sikker el. korrekt. Havde dette været tilfældet havde mange flere firmaer brugt det og softwarekrisen være overvundet.

Nej tak, siger jeg. Ingen kunstige byrder til programmører som alligevel ikke ændrer det store. Hvis koden bliver set, og dine forholdsregler virker burde market jo bruge dem for ikke at tabe ansigt. Hvis de ikke virker vil det være dumt at have i loven.

Der vil være modvind, meget endda, men fortsæt Kamp'en!

Vi kan ikke lovgive os mod uoverskuelighed. I så fald, kunne vi risikere, at lovgivningen forbød sig selv.

I en senere post med overskriften "Forslag til glidende overgang til produktansvar." giver du tre forslag til at løse et problem - men hvilket problem er det du tror dit forslag løser? De tre praktiske håndregler gør jo ikke software sikker el. korrekt. Havde dette været tilfældet havde mange flere firmaer brugt det og softwarekrisen være overvundet.

Vi har lige set at COWI overtræder en af de regler ved at lade clienten verificere svar i en examen.

Nej tak, siger jeg. Ingen kunstige byrder til programmører som alligevel ikke ændrer det store. Hvis koden bliver set, og dine forholdsregler virker burde market jo bruge dem for ikke at tabe ansigt. Hvis de ikke virker vil det være dumt at have i loven.

Det ville sikkert have hjulpet hvis COWI havde offentliggjort deres kode, men så havde de ikke nået deadline før næste år.

Jeg tror, at love som direkte omhandler hvordan man skriver software på et teknisk niveau, ikke hører under lovgivningen. Sådanne love, vil nærmest tage friheden fra programmører. Naturligvis, skal du have lov at skrive "lortekode". Og, jeg synes også, at det er i orden at sælge, hvis det er under ansvar. Det siger sig selv, at hvis man skal betale alt tilbage, fordi det ikke fungerer, eller er usikkert, så vil man gøre noget for at opnå det bliver sikkert - også mere, end at opfylde nogle simple regler.

Derimod, er dine forslag gode, som en "standard" for funktionel kode. Her er mulighed for mange forskellige standarder, der dækker forskellige typer sikkerhedsaspekter, og hvilke krav der faktisk sættes, kan afhænge af opgaven. Da der ikke er en lov, der overordnet siger hvordan vi altid skal gøre, så er muligt, at kræve at visse standarder fyldes, for den kode som bruges. F.eks. kan det offentlige sige, at kode der bruges i det offentlige, skal opfylde nogle sikkerhedskrav, eller standarder, hvis det indeholder personfølsomme oplysninger.

Som eksempel på en sådan standard, har vi ISO 9001. Og der findes faktisk også standarder indenfor funktionel software, og i nogle tilfælde kræves at sådanne standarder er opfyldte.

Byggebranchen har jo allerede en fælles vedtagen standard, som alt byggeri stort set foregår efter. Der er helt sikkert også nogle rigtig gode grunde til at alle bygger på den måde.

Hvorfor kan IT branchen ikke have det samme? Både for special programmering og for hyldevarer.

Nogle taler om sikring af kvalitet, andre om brugers rettigheder. Skal vi lige tale om det samme?

... Det ville sikkert have hjulpet hvis COWI havde offentliggjort deres kode, men så havde de ikke nået deadline før næste år.

Ja der mener jeg problemet er i den sag - forkert fokus og ringe designere der ikke kender til basal sikkerhed. Manglende bevidsthed omkring sikkerhed findes, ligesom i byggebranchen. Byggesjusk er heller ikke et uddødet fænomen, trods standarder og branche.

Hvis man åbner for kildekoden og ser hvad sagen drejer sig om, giver det mulighed for at de gode kan få et godt ry, mens de dårlige kan sorteres fra.

Nogle taler om sikring af kvalitet, andre om brugers rettigheder. Skal vi lige tale om det samme?

Jeg tror, at bedre rettigheder for brugeren, tvinger virksomhederne til at hæve kvaliteten - ligesom kvaliteten gik op, da vi fik 2 års reklamationsret.

Men, ellers er korrekt, at vi ikke direkte kan sætte lighedstegn mellem kvalitetssikring og brugerrettigheder.

Kvalitetssikring, er noget som til dels klares gennem standarder.

EU har her mulighed for at hæve kvaliteten, ved at være med til at udvikle og forske, med henblik på at lave kvalitetssikringsstandarder. Dertil kommer, at der kan sættes krav om at visse standarder opfyldes, i bestemte indstallationer. Det kan være i tilfælde, hvor der gemmes personfølsomme oplysninger, hospitaler, millitær, steder hvor der er risiko for liv, transport osv. Ikke alle, behøver samme sikkerhedsstandarder, og kvalitet.

Jeg mener, at det er vigtigt at vores forskere på vore universiteter, er med til at udvikle metoder, der kan sænke antal softwarefejl. Og det er vigtigt, at undervise i metoder, så vi kan lave software og elektronik af højeste kvalitet. Netop at kunne dette, er ofte de studerendes årsag, til at vælge en længerevarende uddannelse.

Ikke mindst, er det vigtigt, at kunne være med til at påvirke programmeringssprogene, og værktøjerne, så de medfører højere kvalitet. Dette kan også ske, ved at udvikle nye programmeringssprog, for at vise metoder, eller operativsystemer. Som eksempel, synes jeg EU's satsning på MINIX, og ikke mindst den sikkerhed der opnås, ved at have en stor del af ens egen kode, samt alt 3. parts software, under sikre omgivelser, der svarer til brugermode, er interessant udfra såvel et forskningsmæssigt som sikkerhedsmæssigt aspekt. Dette kan - måske på sigt - være med til at præge operativsystemer i fremtiden, hvis projektet lykkedes, og ikke mindst få deres isolation mellem drivere, og kerne op, samt øge operativsystemets sikkerhed. Idag skriger seerne af science fictions efter fremtidsrealitet, når der ses en science fictions, hvor dørene ikke går i baglås fordi raketmotoren får klumper i brændstoffet. Selvom det måske for de fleste er fremtidsmusik at disse ting ikke påvirker hinanden gennemm software, og at det betragtes som helt usandsynligt, så skulle videnskaben gerne vise, at det i fremtiden faktisk er muligt, at kunne stole på dørene, uden de påvirkes af faktorer, de ikke skulle kunne påvirkes af. Operativsystemer og programmeringssprog er i nogen grad samme videnskab, hvor operativsystemet skal stå inde for f.eks. sikkerhed mellem programmer, meddens compiler, skal stå inde for sikkerheden indenfor selve de enkelte programmer, og de to dele vil ofte spille sammen, både for at opnå bedst mulige tilpasning til hardware og grænseflader, samt for at sikre bedst mulige anvendelse af hardwarens resourcer, for implementeringen af sikkerhed på alle niveauer.

På baggrund af forskning, skal man kunne udvikle bedre sprog, compilere, operativsystemer, automatiske tjek systemer osv. så man i videst muligt omfang automatisk kan sikre softwarens kvalitet og sikkerhed. Dertil, kan man udvikle metoder, som der programmeres efter, for at sikre programmøren opnår bedst mulige kvalitet. Automatik, er altid foretrukken - men i praksis, er det to ting, der arbejder side om side. Måske skal programmøren tilføje værktøjet informationer, for at automatikken fungerer, men er så i stand til at kunne stå inde for kvalitet.

...men er det nu også en god ting for open source?

Selvsagt, hvis ansvarsfraskrivelse i fx BSD-stil fortsat er muligt, så er der ingen problemer. Men hvis nu det i bedste EU-stil bliver noget med at man skal autoriseres, eller skal betale for en afprøvning ved en uafhængig testinstans (ala DEMKO?) så bliver det jo pludselig ret bøvlet at være udvikler?

Og hvad er lige den juridiske definition af et "produkt"? Er det når et program sælges til en kunde, som herefter tager det i brug? Eller er fx et gratis OS (fx BSD) også et produkt? Hvad med et regneark som en eller anden lige klasker sammen for at lave et eller andet, og som naboen så synes er smart og får en kopi af?

I en anden blogartikel skrev du at du skulle have været forfatter. Så vidt jeg kan se, er du forfatter. Så vidt jeg kan se må produktansvar for software svare til hvad der gælder for litteratur. Jeg formoder der er en eller anden slags produktansvar for møbler. Fx børnemøbler. Antag man køber en seng i IKEA, som er godkendt, men pga en fejl i samlevejledningen kan sengen samles forkert, og så kommer et barn til skade. Så står IKEA nok med ansvaret - med mindre de kan godtgøre at fejlen var af en sådan art, at kunden som samlede sengen, burde have kunnet konstatere fejlen. Hvis nu i stedet for et IKEA-møbel (hardware+software) vi ser på ren software: en gør-det-selv bog om snedkeri. Køberen af bogen bygger en vugge ud fra en vejledning i bogen, og resultatet bliver et dødt spædbarn. Er det så forfatterens ansvar? Eller påtager hjemmesnedkeren sig ansvaret ved at bruge vejledningen (hvilket for mig at se er analogt til at køre et program)? Er det anderledes hvis han sælger vuggen til naboen, og det er naboens unge det går ud over?

Produktansvar er naturligvis glimrende overordnet set, men man kan let forestille sig scenarier, hvor det kan bruges til ansvarsforflygtigelse hos brugeren, eller hvor velmenende (ha!) politikere laver - skal vi kalde det - problematisk lovgivning (som det fx er set mht fødevarehygiejne jf http://fpn.dk/mad/fodevaresikkerhed/article1627499.ece). Umiddelbart kunne det jo være en besnærende tanke at man skulle have et certifikat for at have lov til at have en compiler - ligesom jagttegn eller kørekort. Men måske alligevel ikke - vel?

Lur mig om ikke en nævenyttig flok lobbyister ret let kunne overbevise et passende flertal af folkevalgte, så vi fik den type tilstande - og så er det kun os der er SUN(tm) Java(tm) Certified Programmer eller noget tilsvarende fra Microsoft eller andre store aktører i IT-industrien, som må skrive kode (og selvsagt kun med deres produkter.)

Så vil jeg faktisk hellere selv tage ansvaret, når jeg accepterer at der kører Windows på knægtens PC. Mit gæt er at eksisterende lovgivning burde være tilstrækkeligt dækkende. Forudsat den bruges rigtigt, naturligvis.

/Lasse

Jeg er enig i problemet med certificering, og at kun "autoriserede" må skrive software. Det fungerer ikke. Men jeg synes ikke, at open source skal holdes fri - det er helt urimeligt, at fordi en virksomhed frigiver noget source, at de så kan fritages fra produktansvar. I så fald, bør det ihvertfald stå med store advarselssymboler udenpå, at dette produkt er uden produktansvar. Man kan ikke tillade sig at "skjule" det, og lægge sourcen på disketten, eller skrive det med små bogstaver, på en lap der ikke ses tydeligt. At noget er uden produktansvar, fordi det er open source, ved også kun de færreste - og derfor bør det ikke skjules gennem ord som "open source", eller ved at skrive "dette produkt indeholder en phenylalaninkilde", og så have forelagt indholdet af en "phenylaninkilde" til det offentlige som open source. Mener Poul Henning, at områder som medicin og madvarer, skal fungere på samme måde - at virksomheden skal "friholdes for ansvar", hvis de fremlægger indholdet, overfor myndighederne? Jeg kan tydeligt fornemme, at Poul Henning tilhører open source folket - og hvis en person havde foreslået samme med medicin, vil jeg også tro han havde en god stilling hos Novo. Naturligvis, skal vore lovgivninger ikke styres af den slags.

Det er - som jeg ser det bedst - at deffinere alt "gratis" som uden produktansvar. Normalt, vil produktansvaret alligevel kun gælde, op til produktets pris. Med mindre, at der direkte foreligger noget kriminelt naturligvis. I så fald, gælder produktetansvaret alt, da det i princippet ikke er produktansvar, men terror. Her skal man dog kunne bevise, at der ligger terror og en kriminel indstilling til hensigt.

Jens Madsen, nu fik du mig jo til at skimme produktansvarsloven (lov nr. 371 af 7. juni 1989), uha!

Det er vist ikke korrekt at produktansvar alene er begrænset til produktets pris; loven aler både om personskade og skade på ting, ved skade på ting er der desuden en selvrisiko på 4000 kr, og der er vist ikke nogen øvre grænse. (EU-direktivet som loven implementerer, taler om at medlemsstater kan fastsætte et loft på mindst 70 millioner ECU for alle skader pga samme defekt, men det fremgår ikke af loven.)

Det ville da også være ret latterligt, hvis ens barn brækkede halsen pga en defekt gynge, og man kun fik gyngens pris erstattet?

/Lasse

Hvem definere alt "gratis" som uden produktansvar?

Hvem holder open source fri? Intet forhindre mig idag i at bruge open source kommercielt, uden jeg skal vise min kildetekst.

Jens, de kommercielle producenter kan selv bestemme under hvilken forhold, jeg må se deres kildetekst.

Jeg kan ikke se problemet i PHK's forslag. Der findes "sjovt" nok kunder der godt må se kildetekst, vi andre ikke må se. Jeg er så træt af defekt software.

<p class=ironi>
Hvorfor sammenligner du IT med mad og medicin ... hvad er der galt med den klassiske bil analogi? (PS: Jeg er også træt af analogier :)
</p>

Jeg misforstod PH's oprindelige indlæg, som at han mente at Open Source godt måtte være med ansvarsfraskrivelse. Meddens, at han korrekt skrev, at for at et produkt kan være med ansvarsfraskrivelse, så skal det være med open source. Deri er en forskel - og jeg er helt enig med PH. Skal et produkt, være med ansvarsfraskrivelse, er det naturligvis et krav, at det er Open Source. Dog, mener jeg ikke, at det er et tilstrækkeligt krav. Skal det have ansvarsfraskrivelse, må produktet også være gratis, og koster det, så må pengene refunderes.

Så er vi enige.

Beklager meget, at jeg fik PH's oprindelige tekst galt i halsen.

Det er - som jeg ser det bedst - at deffinere alt "gratis" som uden produktansvar. Normalt, vil produktansvaret alligevel kun gælde, op til produktets pris. Med mindre, at der direkte foreligger noget kriminelt naturligvis.

Nu er det (som Lasse påpeger) ikke korrekt at produktansvar begrænses op til produktets pris. Produktansvaret kan heller ikke fraskrives i kontrakten, selvom mange leverandører prøver (med deres ofte amerikanske kontrakter og licenser).

Omkring manglende produktansvar ved gratis produkter, så er jeg ikke enig. En modtager af et "gratis" (vederlagsfrit) produkt sagtens blive bebyrdet i form af en licens eller en kontrakt. Derfor synes det urimeligt, at der kan foretages ansvarsfraskrivelse, på trods af at modtageren er bebyrdet af en aftale.

(jeg formoder, at en passus om ansvarsfraskrivelse i et vederlagsfrit program licensbehefætet program faktisk vil kunne tilsidesættes via de forbrugerretlige regler i aftaleloven)

Undtagelsen er selvfølgelig software der er i Public Domain. Her kan man sagtens argumentere for at der er total ansvarsfraskrivelse. Det er blot ikke "prisen" på programmet der gør ansvarsfraskrivelse iorden, men det faktum at brugeren af programmet ikke indgår i en licensaftale eller kontrakt.

Når alt dette er sagt, så virker det selvfølgelig oplagt, at verderlagsfrihed og evt. åben adgang til kildekode bør (og vil) have en betydning for vurdering af et ansvarsgrundlag.

Når alt dette er sagt, så virker det selvfølgelig oplagt, at verderlagsfrihed og evt. åben adgang til kildekode bør (og vil) have en betydning for vurdering af et ansvarsgrundlag.

Dokumentation for, hvordan kildekoden fungerer, er også vigtigt for at forstå koden. Kildekode i sig selv, kan have forskellig værdi som dokumentation for funktion. Test analyser, kan være af større betydning, f.eks. i forbindelse med alcometeret, at den er afprøvet med tilfældige kendte opløsninger (for producenten ukendte), og viser korrekt.

Jeg antager at det er produktansvar vi går efter - og at åben source blot er en mulighed for de identiteter hvor produktansvaret er svært at løfte!?

Problemet er, at så længe hardware og software kommer fra hver sin leverandør, så er det en ukontrolabel risiko at indgå garantier for meget andet end mediets læsbarhed.

Man kan garantere at et stykke software virker på et bestemt rent OS med et bestemt sæt sikkerhedsopdateringer på en bestemt type PC uden noget andet tilsluttet hardware. Men det er jo ikke særlig sjovt.

Når nogen yder nogen form for garantier på produkter der består af flere dele som fx. TV-oplevelsen, der ofte består af både en fordeler dåser, lange kabler, optage-maskine, TV og en kabel-TV/satellit forbindelsen, så skal man typisk selv verificere at det ikke er sammenspillet med en anden komponent i den samlede løsning der er årsag til problemet. Ellers skal man selv betale hele gildet.

I eksemplet med TV er det typisk relativt let* at isolere de enkelte elementer, og finde den defekte komponent, da hver leverandør har en fysisk adskillig kasse.

Når man pludselig har besøg af en trojansk hest på sin PC (10-100 (?) forskellige leverandøre i en kasse!) er det ret svært at afgøre hvem der har skylden.

Når man først har identificeret problemet, så kan produktansvaret bruges - men med mindre vi alene tror på at produktansvaret vil blive forfulgt af de store virksomheder - og dermed indirekte hjælpe de private, så tror jeg ikke det er så let som det lyder.

Men de fleste software defekter er nok uafhængige af omgivelserne, og vil nok også kunne gennemskues som værende sådan af flere - så de defekter kan vi måske komme til livs lidt hurtigere.

*) Jeg har 2 TV kanaler der mest bare er sne - men jeg er ikke sikker nok på det ikke kan være forsaget af noget andet, til at fejlmelde det til YouSee - så selv ikke her er det "let".

Produktansvar er ikke ansvaret for at enhver idiot kan betjene en motorsav, men ansvaret for at den ikke river armen af den kompetente bruger, fordi der blev sparet på materialer og sjusket med samlingen. Generelt holder man i produktansvarssager leverandøren op på de løfter der er givet og hvad en "ræsonabel person" ville læse disse som.

Enig.

Og i forlængelse af den bemærkning, så skal man huske at produktansvarsloven definerer en defekt på denne måde:

§ 5. Et produkt lider af en defekt, når det ikke frembyder den sikkerhed, som med rette kan forventes. Ved bedømmelsen heraf tages hensyn til alle omstændigheder, navnlig til: 1) produktets markedsføring, 2) den anvendelse af produktet, som med rimelighed kan forventes, og 3) tidspunktet, da produktet er bragt i omsætning.

Der er altså på ingen måde tale om, at en leverandør skal hænges op på hvadsomhelst. Dansk lovgivning er iøvrigt fyldt med den slags "bløde" formuleringer. Den konkrete udmøntning vil derfor afhænge af retspraksis.

Når man pludselig har besøg af en trojansk hest på sin PC (10-100 (?) forskellige leverandøre i en kasse!) er det ret svært at afgøre hvem der har skylden.

Som PC'ens operativsystem er idag, er det svært med produktansvar. Det skyldes i høj grad operativsystemet, at du har svært ved at lokalisere og finde den ansvarlige for problemer. Hvis alle programmer, og drivere, er isolerede godt og grundigt, og ikke har adgang til fælles harddisk, så er det meget nemt at sikre de ikke ødelægger noget for hinanden. Sådanne krav stilles til hardware, netop for at kunne have produktansvar - f.eks. har vi EMC love, der skal sikre at udstyr ikke ødelægger hinanden på grund af elektrisk støj. Hvis operativsystemer blev krævet at programmer og drivere var isolerede i forhold til hinanden, og ikke kunne ødelægge noget for hinanden, så vil det være langt nemmere at finde en eventuel fejl - og det vil være svært, og måske endog umuligt, for virus at udbrede sig til andre programmer.

Nogle, forsøger så den med, at det vil skrue udviklingen 30 år tilbage, at hvis programmer skal isoleres, vil de jo ikke kunne kommunikere, og hvordan skal man kunne hente en tekst fra diskette, eller gemme en tekst, så en anden tekstbehandling kan læse den. Naturligvis, så kan man stille masser af sådanne spørgsmål, som ofte afslører man ikke kan regne simple datalogiske forholdsregler ud - men går i "panik mode", og lukker for at bruge hovedet. I langt de fleste tilfælde, er relativt nemt at finde metoder og principper for kommunikation mellem isolerede programmer, således der ikke er problemer med sikkerhed, eller mulighed for at virus kan udbrede sig. Samtidigt, kan sådanne forholdsregler sikre, at det er forholdsvis nemt at se hvem der er "skyldig" når noget går galt, da fejlen ikke kan udbrede sig til andre programmer. Hvis eksempelvis en printerdriver går galt, kan vi naturligvis diskutere om det er printerdriveren, eller programmet som skriver ud - men det kan relativ nemt afklares ved at prøve at skrive ud på en anden printer, eller ved at prøve at skrive ud fra et andet program. Det kan brugerne godt finde ud af. Det er derfor oftest meget simpelt at se hvor progblemerne opstår, og hvem der er årsag. Idag, må vi dog sige, at det er næsten umuligt, da hvemsomhelst har adgang til andres data, lægger driver ind "for hinanden" osv. uden det er noget som brugeren har kontrol og styr over. Sådan noget, fungerer ikke. Hvis brugeren køber en facilitet, og ligger den ind - så ved brugeren også om den fungerer. Købes f.eks. en ny fonttype, så vil operativsystemet også skulle være indrettet, således at den ikke kan "forstyre" andre fonte, og det kun er den pågældende som giver kvaler, hvis noget er galt. Uanset, hvilke "features" du køber, og drivere, skal de være indstalleret i en isoleret boks, på samme måde som printer, fonte, og alt andet, og det selekteres så af bruger, f.eks. ved at selektere "font". Det er ikke muligt, eller lovligt at kunne lave en font, som indstallerer sig, og "forbedrer" system fonten, eller standard fonten. Brugeren, skal have kontrol over dette, men kan indstallere en ny font, og opsætte den til at være standard font - på samme måde, som printer kan indstalleres, og sættes til at være standard printer.

Brugeren, skal altså have styr på de ting som købes - og indstalleres det, kan det ikke bare "opgradere" en facilitet, eller "gøre noget bedre". Det kan øge antallet af features og selekteres af bruger, og endog opsættes som standard funktion af brugeren. Men, det kan ikke gøre dette "automatisk". I princippet, kan produktet naturligvis indeholde en vejledning til, hvordan produktet opsættes til at være standard printer, eller standard font, eller det kan stå i brugsanvisningen. Det vigtige er, at brugeren selv har gjort det, og indstalleret det sådan.

Det med at "overskrive" andres DLL'er, osv. og holde logbog, så det kan føres tilbage, er en metode der fungerer meget dårligt sammen med produktansvar.