Elektronisk Forpost Norge
Ved styret: styret@efn.no


Oslo, 15. september 2005


Moderniseringsdepartementet
e-post: postmottak@mod.dep.no
Postboks 8004 Dep
0030 Oslo



Svar på høringen om «Bruk av åpne standarder og åpen kildekode i offentlig sektor»

Elektronisk Forpost Norge (heretter EFN) mener Moderniseringsdepartementet under ledelse av Morten Meyer tok et stort skritt i riktig retning med IT-politikken. Spesielt eNorge 2009 inneholder politikk som løfter IT-spørsmålet inn i et borger- og samfunnsperspektiv. Endelig er det slutt på at staten fremmer gårsdagens løsninger ved å favorisere produkter fra enkeltaktører i markedet.

Planen inneholder gode analyser over IT-utviklingen. Vi er spesielt glade for fokuset på at IKT-verktøy og tjenester skal produseres etter prinsippet om universell utforming, slik at de kan benyttes av flest mulig brukergrupper. For å hindre nye klasseskiller i tilgangen på digital informasjon og eksklusjon av svake grupper, må prinsippet være at alle får muligheten til å omforme, utbedre, og tilpasse teknologien til sine behov.

I EFN er vi også opptatt av at veiskiltene på den elektroniske landevei er på et språk elevene forstår. Derfor et det et skritt i riktig retning når planen sier at statlige etater skal tilrettelegge for samiske tegn når IT-systemer/registre skiftes ut. Det er videre positivt med et enkelt og tydelig språk slik at offentlig informasjon er forståelig for alle. For vår del er fokuset på digital kompetanse og lærende nettverk det viktigste. Vi ser at regjeringen også vil følge med på utviklingen, og derunder utformingen av Digitale RestriksjonsMekanismer (DRM/Digital Rights Management).

Vi fokuserer ikke på hva som er ubetinget positivt av de fremlagte anbefalingene. Vi ønsker å rette fokus mot de steder hvor det framkommer forslag som etter vårt skjønn kan - og bør - forbedres.

Vi velger å benytte termen «produsenteid» programvare fremfor «proprietær» programvare. «Produsenteid» er et godt norsk ord, som markerer at programvaren faktisk er eid av en produsent. Det gjør begrepet umiddelbart lettere å forstå betydningen av.

Åpne standarder og åpen programvare

Vi vil understreke at selv om åpne formatstandarder for produksjon og utveksling av data og dokumenter er grunnleggende, vil optimal råderett over informasjonsbehandlingen i samfunnet realiseres gjennom at det også brukes åpen, det vil si ikke produsenteid, programvare. Hvorfor det er slik, er det redegjort nærmere for i denne høringsuttalelsen. Når det gjelder åpne standarder, ser vi behovet for at begrepet «standard» defineres slik at man er klar over hva det snakkes om.

Spørsmålene fra Departementet er svart på under respektive kapittelnummer. Vi gjentar spørsmålene først:

  1. Er rapportens anbefalinger svar på de utfordringer offentlig sektor står overfor, innen rammene for gruppens arbeid?

  2. Er det kommentarer til foreslått organisering av standardiseringsarbeidet i offentlig sektor, jf. kap. 3.9 og 3.10?

  3. Er det noen tiltak som dere mener bør prioriteres foran andre (jf. tiltaksoversikten i vedlegg 2)?

  4. Er tempoet i de foreslåtte endringene riktig?

Innholdsliste

ne standarder og åpen programvare 1

1 Gir anbefalingene svar på utfordringene innen offentlig sektor? 2

1.1 Betydningen av åpen programvarepolitikk 2

1.2 Konkurranse og behovet for veiledning 2

1.3 Eksklusjon av fri programvare i anbud 4

1.4 Om standardkrav til bruk av OpenDocument 6

1.5 Programvare på norsk 6

1.6 Sikkerhet 6

1.7 Hvorfor programvare med full endringsrett er sikrere 7

1.7.1Om innsyn, utbedring av feil og mangler og ansvaret for programvaren 8

1.8 EU Public Licence 10

2 Kommentarer til organisering 10

2.1 Kompetansesenter med åpen kildekode og åpne standarder. 10

3 Prioriteringen av tiltak 11

4 Tempo for gjennomføring 11


1 Gir anbefalingene svar på utfordringene innen offentlig sektor?

Rapporten har flere gode anbefalinger som samsvarer med utfordringene i offentlig sektor. Vi tar ikke tak i de gode tiltakene som er tatt inn allerede. Vi fokuserer på områder hvor vi mener det er rom for forbedring.

1.1 Betydningen av åpen programvarepolitikk

Produsenteid programvare basert på lukket kildekode innebærer at den er ulovlig for alle andre å endre enn produsentens/leverandørens egne ansatte. Ettersom åpen programvare bygger på en utviklingsmodell hvor det er både uinnskrenket innsyn og uinnskrenket rett til endringer i programkoden, mener vi at denne modellen på lang sikt vil styrke befolkningens innsikt i IKT-prosesser og styrke demokratiske rettigheter i sin alminnelighet.

Hva mer er, muligheten til at en lang rekke frittstående aktører kan gis betalte oppdrag med videreutvikling og vedlikeholdsoppgaver av datasystemene vil stimulere næringsutvikling og vekst i IKT-næringene. Et tilleggsmoment er at dette vil komme innenlandsk næringsliv til gode, da systemene basert på åpen kildekode ikke er bundet opp til utenlandske leverandører. En økende utbredelse av åpen programvare i det offentlige vil med stor sannsynlighet fungere som en motor og et forbilde for samfunnet som helhet.

Sunne og levedyktige norske bedrifter som Trolltech, Systems in Motion, Linpro og flere andre har allerede med stort hell benyttet de kommersielle og varig lønnsomme muligheter som åpner seg for utvikling, systemtilpasning, integrasjoner og brukerstøtte. Det er overhodet ikke tvilsomt at programvare basert på åpen kildekode kan danne grunnlaget for en permanent verdiskapning, og vi vil sterkt oppfordre til at det offentlige går foran i å velge åpne løsninger.

1.2 Konkurranse og behovet for veiledning

I kapittel 6.8 kommer flere oppsiktsvekkende uttalelser om åpen kildekode og forholdet til produsenteid programvare.

Kap. 6.8 Behov for veiledning om bruk av åpen kildekode, side 31.

«Like konkurransevilkår krever at den enkelte virksomhet stiller de samme behov
og krav til bruk av åpen kildekode programvare, som til bruk av kommersiell
programvare. Selv om reduserte lisenskostnader i utgangspunktet gjør bruk
av åpen kildekode programvare fordelaktig, kan eksempelvis migrasjonskostnader
i gitte situasjoner gjøre den dyrere.»

Det er i beste fall unyansert å skrive at migrasjonskostnader i gitte situasjoner gjør åpen kildekode dyrere. Dette fordi det også er minst like riktig å si at at produsenteid programvare blir dyrere i gitte situasjoner. Faktum er at det påløper kostnader ved migrering uavhengig om programvaren er åpen eller produsenteid. Arbeidsomfanget forbundet med selve migreringen blir fort den samme. Lisensavgiften for produsenteid programvare kommer ikke sjelden som et kostbart tillegg, noe som mange unnlater å ta med i beregningene når det blir spørsmål om kostnadene ved integrasjon.

Vi kan bruke sak-arkivsystem som et eksempel. Dersom kommunen velger å bruke OpenOffice forventer selger at det betales ekstra for integrasjon. Tilpasningen kan ta to månedsverk til f.eks. en sum av 300.000 kroner. Leverandøren av fagsystemet tar ikke ekstra betalt for å integrere med Microsoft Office selv om den prosessen vil kreve to måneder. Kommunen slipper også å betale for ny integrasjon når Microsoft kommer med en ny Office-utgave. Denne situasjonen kan fort føre til at innkjøper i kommunen, gjerne en person med økonomibakgrunn og uten spesielle kunnskaper om andre typer programvare enn Microsofts, på sviktende grunnlag slår fast at åpen kildekode faller dyrere. Anbefalingen går da gjerne ut å at det fortsettes med programvare fra Microsoft. Noen er også i den tro at man slipper opplæring med ny utgave av Microsoft Office-programmene, hvilket ikke er korrekt.

Vi har satt opp et eksempel med Kongsberg kommune. Denne kommunen har 800 kontordatamaskiner og vurderer å velge en annen kontorpakke en den de bruker i dag. Britt-Inger Kolseth undersøkte på oppdrag fra rådmannen hva Microsoft Office kostet (februar/mars 2005). Tallene er rett fra informasjonsdirektøren i Microsoft. For 800 administrative datamaskiner ville det koste 3,96 millioner kroner over 5 år. Da er det iberegnet en oppgradering av kontorpakken. Her er to aktuelle eksempler:

Aktivitet

Kostnader over 5 år

Fortsette med dagens sak-arkivsystem. Microsoft Office-lisenser for 800 kontordatamaskiner i fem år (3,96 mill). En Office-oppgradering er regnet inn. Kurs for 1000 ansatte a kroner 1000.

4 060 000

Beholde dagens sak-arkivsystem. Betale for integrering med OpenOffice for kroner 300.000. I tillegg gis et årlig bidrag på kroner 50.000 til oversetting. Kurs for 1000 ansatte a kroner 1000.

550 000

Antall ganger kommunen må betale mer ved ikke å bruke 250.000 på integrasjon.

7,38

*) Brukerundersøkelser viser at det ikke krever mer innsats å lære OpenOffie enn ved en ny utgave av Microsoft Office.

Poengene er som følger:

  1. Ved integrasjon i et fagsystem må man utføre samme arbeidsmengde uavhengig om programvaren er produsenteid eller fri. Opplæringskostnadene til ny utgave av kontorprogrammene er marginale og først og fremst de samme, uavhengig av om man bruker OpenOffice eller MS Office.

  2. Det oppstår en prisforskjell hvis selger av fagsystemet ikke tar betalt for integrasjon med kontorpakken fra en leverandør, hvorpå kunden får en ekstra regning ved bruk av en annen kontorpakke.

  3. Lisenskostnadene for produsenteid programvare er ofte mange ganger høyere enn kostnadene for integrasjon for standardsystemer i offentlig virksomhet.

Rådet må være at man ved anskaffelser tar med i vurderingen flere alternative løsninger, og søker å finne fremgangsmåter for å komme i mål. Bruk av åpen kildekode stopper fort opp dersom den innkjøpsansvarlige økonomen feilaktig tror at at ting er vanskelig fordi leverandøren må utføre migrering. Innkjøper får et inntrykk av at det blir kostbart med integrasjon. De tror det blir billigere med dagens silo-løsning. Fremfor å se på de økonomiske realiteter velges den dyreste løsningen, uavhengig av om den åpne kildekodeløsningen har samme funksjonalitet og er vel så brukervennlig. Videre må det poengteres at potensielle problemer med lisensbetingelser er svært mye mindre med åpen kildekode enn for lukket kildekode.

Med dette som utgangspunkt er også tiltakene mangelfulle i forhold til hva som rapportens hovedhensikt: Ã… legge grunnlaget for en praktisk politikk som sikrer teknisk interoperabilitet (samvirke) i utveksling av elektronisk informasjon innen og med offentlig sektor. Her kan det skytes inn at det er en feiloppfatning at hensyn til interoperabilitet kan tale mot bruk av åpen kildekode. Dette vil være tilfellet bare dersom systemer man ønsker å kommunisere med anvender produsenteide formater som ikke kan behandles av åpen programvare. Med henvisning til anbefalingen fra arbeidsgruppen under 3.5 hvor det tas til orde for at bruk av åpne standarder gjøres obligatorisk vil vi også hevde at en naturlig konsekvens av denne erkjennelsen er at programvare med åpen kildekode foretrekkes hvis overhodet mulig.

Forslag til tiltak:

-- Samle leverandører av fagsystemer i samarbeide med KS for å gi en samlet oppfordring til at de støtter OpenDocument-standarden som anbefales av EU. Om dette ikke blir fulgt opp, bør regjeringen stramme inn slik de gjør i andre sammenhenger. Først er ordningen frivillig. Om det ikke går, strammer regjeringen inn.

-- Kildekoden for programmer som utførerer samfunnskritiske tjenester, som for eksempel valgavvikling, skatteberegning og rettspleie, skal være tilgjengelig slik at innbyggerne kan kontrollere om sikkerhetshensyn og rettssikkerhet er ivaretatt.

-- Kildekoden til programvare som er en del av infrastrukturen som styrer og opererer samfunnskritiske systemer skal være åpen for inspeksjon, distribusjon, og endring av det offentlige selv. Dette er et krav som ikke kan avvikes ved avtale.

1.3 Eksklusjon av fri programvare i anbud

Dokumentet sier for lite om konkurransesituasjonen. Dessverre viser dokument etter dokument at IKT-etater i mange norske kommuner har favorisert Microsoft-programmer ved anbud. Vedlagt er noen få eksempler på hvordan offentlig sektor på denne måten har kommet i skade for å hindre fri programvare.

I tillegg har det enkelte ganger blitt hevdet at fri programvare ikke lar seg bruke, og denne påstanden fremmes da uten å ha evaluert den frie programvaren. De som evaluerer finner ut at fri programvare er rimeligere og har like god funksjonalitet som programvaren fra Microsoft.

Argumenter fremmet av programvareprodusenter til fordel for egne systemer medfører altfor ofte at brukeren ender opp med programvare som kun kan kjøres på en bestemt plattform. Åpne kildekodeløsninger kan som oftest brukes på tvers av en rekke programvareplattformer uavhengig av enkeltprodusenter. Dette sikrer interoperabilitet og muliggjør den frie konkurranse vi i vårt samfunn alle bør ha som mål å oppmuntre.

I tilfeller hvor enkeltprodusenter velger å bare levere på egen plattform, vanskeliggjør dette teknisk interoperabilitet. Bruken av åpne standarder og åpen kildekode har dyptgripende økonomiske konsekvenser. En utredning av Teknologirådet i Danmark (oktober 2002) viser en samfunnsmessig gevinst på 3,7 milliarder ved å gå over til åpen kildekode. Dette skyldes både lavere pris på programvaren grunnet konkurranse samt lavere driftskostnader, hvor samfunnet kan tilby borgerne bedre IT-tjenester for pengene.

Et godt eksempel på en åpen standard er GSM for mobiltelefoni. Det at man valgte denne standarden sparte Norge for 2 milliarder ved utbygning framfor det tysk-franske forslaget til mobilstandard. GSM åpner arenaen for en mangfold av leverandører når det gjelder apparater, tjenester og operatører.

En helt ny undersøkelse fra Storbritannia (BECTA 2005) viser at åpen kildekode på 15 skoler har redusert levetidskostnadene til 56% av tilsvarende løsninger med produsenteid programvare. I videregående skole var kostnadene med åpen kildekode 76% av løsninger med produsenteid programvare. Kostnadene med innkjøpt hjelp og standard driftsstøtte var også lavere når åpen kildekode ble tatt i bruk. Pengene som ble spart ble brukt på mer utstyr, og resultatet ble påviselig bedre IT-tjenester på skolene.

BECTA = British Educational Communications and Technology Agency

http://www.becta.org.uk/corporate/press_out.cfm?id=4681

Siemens Business Systems gjennomførte en større brukerundersøkelse med vanlige brukere i 2003. Selskapet skriver:

Det tar to dagers kurs å lære Linux med kontorprogrammer. Det er det samme som de fleste foretak budsjetterer ved overgang til ny utgave av Windows og MS Office. Det tar en dag å gjøre brukerne kjent med Linux på skrivebordet, og en dag med introduksjon i kontorpakken OpenOffice. [...]

Linux-løsninger fra de største Linux-distributørene vil føre til besparelser på 20-30% i administrative kostnader, 50% på maskinvaren, og 80% i lisenskostnader. Dette er konklusjonen etter omfattende tester med Linux i vanlig bruk.[...]

Linux er spesielt sterk på sentralisert drift, fortalte selskapets talsperson. Dette blir viktigere ettersom ansatte vil jobbe fra flere forskjellige steder i bedrifter. [...]

Talspersonen fra Siemens sa også: «Vi så ikke på Linux på skrivebordet som et større marked. Vi tok feil.»

Linker om konkurransesituasjonen:

http://developer.skolelinux.no/~knuty/2005-05-02-om-IBM-anbud-UDE.pdf

http://developer.skolelinux.no/~knuty/2005-06-13-fra-Nittedal-til-Stiftelsen-SLX-Debian-Labs.pdf

ftp://ftp.skolelinux.no/skolelinux/press/2005-09-02-agderposten-anbud.jpg

http://developer.skolelinux.no/artikler/2005-09-02-agderposten-anbud.html

Linker med evalueringer:

http://developer.skolelinux.no/rapporter/rapport_trondheim.pdf

http://europa.eu.int/idabc/en/document/3803

http://europa.eu.int/idabc/en/document/4105/469

http://www.newsforge.com/article.pl?sid=03/08/13/1424212

Forslag til tiltak:

IT-staber og rådmenn som gjør offentlig IT-innkjøp trenger hjelp til å følge forskriftene for offentlige anskaffelser. På den måten kan man sikre at markedet virker. Siden dette hittil ikke har blitt fulgt opp, bør kommuner som er underlagt fylkesmannens administrasjon grunnet budsjettunderskudd bli fulgt opp i sine IT-anbud.

Det er helt avgjørende at skattepengene brukes for å sikre gode tjenester til borgerne, og at man unngår unødige kutt i f.eks. skolen fordi IT-staben har valgt den mest kostbare og minst hensiktsmessige IT-løsningen. Derfor bør man følge ekstra nøye opp kommuner hvor budsjettet er flyttet til fylkesmannen grunnet underskudd.

1.4 Om standardkrav til bruk av OpenDocument

Punkt 3.5 åpner for unntak under punktet om kontorstøtteverktøy. Forslaget fra dokumentet er: «Bruk av åpne IT-standarder gjøres obligatorisk men det gis anledning til unntak. Unntak må begrunnes».

Konkurransesituasjonen i dag viser dessverre at det unntaket har vært hovedregelen. Ved anskaffelser har det til og med vært forutsatt at det brukes produsenteide dokumentformat fra enkeltleverandører som holder konkurrenter ute. Selv om det kan finnes argumenter for å beholde dagens produsent av kontorprogram, er dette kortsiktig og påfører virksomheten betydelige ekstrakostnader. Vi viser til evaluering gjort av Justisdepartementet i Finland, og eksemplet viser hvor lite det koster å støtte en annen kontorpakke enn den nåværende markedslederens:

http://europa.eu.int/idabc/en/document/4105/469

Departementet må passe seg for å sementere dagens situasjon, hvor IT-avdelinger ikke har regnet på hva fortsatt kjøp av de dyreste løsningene koster skattebetalerne. Kravet må være at fagsystemer må støtte åpne standarder, og at virksomheten står fritt til å velge kontorverktøy såfremt det er tilrettelagt for en eller flere åpne dokumentstandarder. Vi begrunner dette med følgende:

Mange oppfatter kontorverktøy som selve limet i samvirket mellom saksbehandler og fagapplikasjon. Ved anbud tvinges kommuner å velge fagsystemer som bare støtter kontorprogram fra en spesifikk leverandør, selv om det eksisterer bedre og dertil rimeligere alternativ. Uten et reelt alternativ som baserer seg på åpne standarder vil det offentlige gå glipp av lavere priser. Myndighetene vil hemme konkurransen i markedet dersom man velger å subsidiere leverandører som svekker konkurransen og fortrenger alternativene.

Forslag til tiltak:

-- OpenDocument 1.0 og nyere versjoner av standarden skal inngå som en del av NOARK. På den måten sikrer man at leverandører av fagsystemer støtter åpne dokumentstandarder.

http://www.riksarkivet.no/arkivverket/lover/elarkiv/noark-4.html

1.5 Programvare på norsk

I brev til Moderniseringsdepartementet skriver «OpenOffice-stiftelsen» at oversettelse til norsk koster 2,6 til 3 millioner kroner for hver hovedversjon. Her fortjener det å understrekes at etter en slik oversettelse kan alle som bruker norsk anvende de aktuelle kontorprogrammene. Vedlikeholdskostnader ved oppgradering av hver hovedversjon av den produsenteide kontorpakken koster rundt 1 million kroner i året. For dette beløpet er det mulig å tilby hele Norges befolkning et komplett kontorstøtteverktøy.

Forslag til tiltak:

-- Regjeringer bør samle aktører i kommuner og markedet for å bidra til en stabil og trygg oversetting og kvalitetssikring av fri programvare på norsk.

1.6 Sikkerhet

Behandlingen av sikkerhetsspørsmålet i politikk-dokumentet er dessverre faglig svak. Vi skal her argumentere hvorfor det er uakseptabelt at det offentlige bruker produsenteid programvare med dagens avtalevilkår i samfunnskritiske IT-systemer. Vi har også eksempler på situasjoner hvor samfunnet tar stor risiko ved knytte sine IT-systemer til en bestemt leverandør. Dette fordi dataleverandøren har lagt inn produktsperrer mot konkurrerende programsystemer. Vårt poeng illustreres i denne artikkelen fra IT-avisen (fra 9. sept. 2005):

Nødhjelp bare til Windows-brukere -- Mac- og Linux-brukere utestenges

Etter at orkanen Katrina herjet over New Orleans i USA har kritikken haglet mot US Federal Emergency Management Agency (FEMA). Begrunnelsen for kritikken ble sterkere etter at det kom frem at FEMA hindret Mac- og Linux-brukere fra å søke om støtte.

Organisasjonen hadde nemlig laget en nettløsning som bare fungerer på Windows og Internet Explorer 6. Eneste løsningen for andre er Opera, som etter brukerens konfigurering kan «forkle» seg selv som Internet Explorer 6. Vi finner at dette er en merkelig og skremmende situasjon, at sentrale og i det ovennevnte tilfellet livsviktige funksjoner skal bindes så sterkt opp mot en bestemt programvareleverandør at brukere av andre systemer forhindres fra tilgang.

Vil bruke Linux

En rekke av de som jobber med nødhjelp i området er misfornøyde med at de tvinges til å bruke Windows. De fremhever blant annet at de er nødt til å bruke penger på Windows-lisenser for overhodet å kunne hjelpe folk med å søke om støtte.

Samtidig klager de på at det tar altfor lang tid å sette opp, patche og konfigurere arbeidsstasjoner med Windows XP, sammenliknet med for eksempel Linux. Det viser seg også at en rekke av maskinene som har blitt donert i katastrofeområdet ikke har kapasitet til å kjøre det svært ressurskrevende Windows XP.

Kilde: http://www.itavisen.no/showArticle.php?articleId=1307047

Vår analyse:

Moderne katastrofearbeid er helt avhengig av mobilt IT-utstyr, derunder bærbare PC-er for å koordinere redningsaksjoner. Den omtalte katastrofen i New Orleans i USA i september 2005 berørte millioner. Et betydelig antall mennesker har mistet livet. Presidenten satte inn 40-50.000 soldater fra Nasjonalgarden for å delta i arbeidet med å redde liv.

For å redde liv trenger redningsmannskapet presis informasjon for å ta gode beslutninger. Nyhetsmedier er utilstrekkelige som informasjonskanal. Nasjonalgarden i USA har en god og fullt mobil IT-infrastruktur. Mye av utstyret i det amerikanske forsvaret kjører på andre plattformer enn Windows XP eller tilsvarende fra Microsoft. Deltagere i f.eks. Nasjonalgarden forventer å kunne bruke utstyret i operasjoner, også i redningsaksjonen som igangsettes etter orkaner som Katrina. Ã… ha rett informasjon er en forutsetning for effektivt å redde liv. Det vil jo være uheldig om liv går tapt som en følge av at enkeltprodusenter av web-servere stenger konkurrerende systemer ute.

Det er mye man ikke får gjort noe med under en gigantisk redningsaksjon som den vi her henviser til. Men de aller fleste gjør sitt beste. Hva kan vi si om Microsoft når de stenger ute konkurrerende systemer som kan redde liv - at de gjør sitt beste? Er det riktig av det offentlige å velge IT-systemer som i verste fall legger hindringer i veien i ekstremsituasjoner når man har behov for katastrofehjelp og livredding, og som i hverdagen generelt låser brukerne til å måtte bruke programvare fra en enkelt programvareleverandør?

Forslag til tiltak:

-- Regjeringer må raskest mulig flytte nett-applikasjoner til løsninger som følger åpne standarder for å unngå å sette liv og helse i fare. Ettersom også Norge berøres av internasjonale hendelser er vi helt avhengig av å følge åpne standarder som en naturlig del av arbeidet med sårbarhet.

1.7 Hvorfor programvare med full endringsrett er sikrere

Flere hevder feilaktig[2] at Windows fremstår som sikrere, og begrunner denne påstandene med at Windows og Microsoft er mest utbredt. Dette er en flertallsmisforståelse (majoritetsmisforståelse). For det første finnes det flere grunnleggende forskjeller i sikkerhetsdesignet mellom Windows og f.eks. Linux. For det annet er det uvisst hvilke av disse operativsystemene som er mest utbredt som tjenersystem (server-OS). På Internett viser målinger at Linux har større utbredelse enn Windows. Dermed kan det argumentet neppe brukes for å hevde at Linux er like usikkert som Windows er.

Her er det verd å legge merke til at et operativsystem som regnes som et av de aller sikreste i dag nettopp er basert på fullstendig åpen kildekode - OpenBSD [3]. En rask gjennomgang av sikkerhetshull i databasen til US-CERT [4] viser OpenBSD med færre (og mindre alvorlige) sikkerhetshull enn Linux, som igjen viser færre og mindre alvorlige sikkerhetshull enn Windows.

Ã…rsaken til at OpenBSD er så overlegent sikkert er flerdelt: For det første gjør utviklerne av det åpne systemet noe som forlagsbransjen har gjort i uminnelig tid og som er en sørgelig mangelvare i programvareindustrien: korrekturlesing. Mens forleggere korrekturleser i flere ledd før de gir ut en bok, håndteres feil i programvare i all vesentlighet reaktivt. Feil blir oppdaget ved testing og deretter rettet. En slik reaktiv holdning til feil, som er situasjonen i all produsenteid programvare, fører til mindre sikre programmer.

I OpenBSD korrekturleses koden jevnlig. Feil blir rettet proaktivt. Ikke sjelden blir feil i andre operativsystemer rapportert inn til Bugtraq [5] med notisen at denne feilen allerede er rettet i tidligere utgaver av OpenBSD. Et annet viktig moment er at OpenBSD har full åpenhet rundt alle sikkerhetshull som blir funnet. Dette nødvendiggjør en rask håndtering av sikkerhetshullene.

Ã…pen kildekode skaper altså betingelser for utvikling av et system som kan tilby en uovertruffen grad av datasikkerhet.

2. http://www.theregister.co.uk/security/security_report_windows_vs_linux/

3. http://www.openbsd.org/

4.

http://www.kb.cert.org/vuls/bymetric?searchview&query=linux&searchorder=4&count=10000

http://www.kb.cert.org/vuls/bymetric?searchview&query=microsoft&searchorder=4&count=10000

http://www.kb.cert.org/vuls/bymetric?searchview&query=openbsd&searchorder=4&count=10000

5. http://www.securityfocus.com/

6. http://www.hmsetatene.no/etater/dbe/publikasjoner/dbafile3241.html

1.7.1 Om innsyn, utbedring av feil og mangler og ansvaret for programvaren

Realistisk bedømt vil det bli svært vanskelig til direkte umulig å ivareta den digitale sikkerheten for befolkningen ved å unnlate å satse på åpne standarder. Skal man sikre etterprøvbarhet samt muligheten til å utbedre feil og mangler ved en byggekonstruksjon, er det en grunnleggende forutsetning å gi full tilgang til denne konstruksjonen. I programvare er «byggekonstruksjonen» selve kildekoden. Som et illustrerende eksempel viser vi til en parallell som finnes i gjeldende forskrifter for elektriske anlegg - forsyningsanlegg (av 18. august 1994)[6]:

§ 15 Mangelfull utførelse

Finner Elektrisitetstilsynet at et elektrisk anlegg som er undergitt tilsyn, eller en enkelt del av anlegget ikke utføres på forsvarlig måte eller i samsvar med gjeldende forskrifter, har Elektrisitetstilsynet rett til å forby fortsettelse av arbeidet og å forlange det omgjort, fornyet og utbedret.

§ 16 Mangelfullt vedlikehold

Når et elektrisk anlegg som er undergitt tilsyn, for noen del er slett eller mangelfullt vedlikeholdt eller for øvrig er i en slik tilstand at det etter Elektrisitetstilsynets mening frembyr fare for menneskeliv eller for skade på eiendom, kan Elektrisitetstilsynet gi pålegg om straks å stanse driften, sette anlegget i forsvarlig stand eller fjerne det.

Etter hva vi kan se er følgende ansvarslinjer klarlagt fra Stortinget:

1. Det er virksomheten med ansvar for driften som er ansvarlig for sikkerheten.

2. Det er opp til eksterne tilsynsmyndigheter å vurdere om sikkerheten er god nok i forhold til sårbarheten.

Etter vår mening har det offentlige hittil i stor grad brukt leverandører av programvare som ikke garanterer for kvaliteten. Man har da i beste fall innsynsrett i deler av systemene, men på grunn av et programvareselskaps eiendomsrett over koden har ingen andre noen endringsrett. Samtidig har man fullt operatøransvar for datasystemene. Hvordan skal man da kunne utbedre feil og mangler når man som operatør og ansvarlig for driften er fratatt enhver mulighet til å på lovlig vis endre systemene? Svaret er at noen slik mulighet ikke eksisterer med produsenteid programvare. Man har heller ingen sanksjonsmuligheter mot bestemte leverandører når det oppdages sikkerhetsbrister. Videre er man med slik programvare uunngåelig prisgitt leverandørenes til enhver tid eksisterende kompetanse og beredvillighet for å utbedre sikkerhetsbrister og forhindre systemfeil.

Dersom det offentlige skal ha muligheten til å best mulig sikre seg mot mangelfull utførelse og vedlikehold, er det ikke tilstrekkelig med innsyn i koden. Dette er et i særdeleshet viktig moment. Man må ha full og uinnskrenket endrings- og bruksrett til byggekonstruksjonene (kildekoden), og man må kunne holde sine anlegg i forsvarlig stand, eller også fjerne disse hvis det viser seg umulig. Sårbarhetsutvalget slår fast at det er etaten som er ansvarlig for driften, dermed er det naturlig at den aktuelle etat eller organisasjon selv når som helst må kunne utbedre feil i anleggene også ut fra pålegg som måtte komme. Pålegg kan komme som et resultat av feil i f.eks. skatteberegningen, på grunn av mangelfull sikkerhet, direkte feil, eller etter pålegg fra tilsyn som f.eks. Datatilsynet.

Frihet til på et hvilket som helst tidspunkt å rette feil i alle deler av kildekoden vi gi kontrollen tilbake til etaten(e) som har operatøransvaret for datasystemene. Det blir følgelig enklere å stille garantier ved behov for feilretting, noe som står i sterk kontrast til situasjonen hvor de tradisjonelt mest brukte programleverandører ikke gir garantier i det hele tatt. Et viktig fortrinn er at full tilgang til prosessen og kildekoden i alle ledd der sensitiv informasjon blir behandlet, også gir innsyn og muligheten til å etterprøve rettslige beslutninger.

Det er avgjørende å være oppmerksom på at garantiene ikke vil kunne ivaretas ved bare innsyn i kildekode. En årsak til dette er at for kompilert kildekode lar det seg aldri gjøre å verifisere at den kildekoden man får innsyn i, gjerne bestemt av leverandøren, faktisk er den som brukes i de kjørbare systemene. Det eneste som ivaretar alle krav til sikkerhet er fullt innsyn og ikke minst uinnskrenket endringsrett i kildekoden som benyttes. Den kan ikke aksepteres at en leverandør av et dataprogram begrenser hva de som bruker, har operatøransvar, eller blir berørt av systemet kan få lov til å gjøre med dette programmet.

Rapporten er beklagelig svak på sårbarhet. Man har også fremmet uriktige påstander om hva som må til for å redusere sårbarhet i samfunnskritiske IT-systemer. Til 3.11 «Konsekvenser for sikkerhet» ønsker vi å presisere at bruk av åpne standarder er en faktor som i stor grad fremmer datasikkerheten. Det blir derfor misvisende å konstatere at åpne standarder ikke er noen sikkerhetsrisiko, når det er dokumenterbart at åpne standarder i realiteten kan sies å være en forutsetning for å oppnå best mulig sikkerhet.

Forslag til tiltak:

-- Kildekoden til programmer som utfører samfunnskritiske tjenester som for eksempel valgavvikling, skatteberegning og rettspleie, skal være tilgjengelig, slik at publikum kan kontrollere om sikkerhetshensyn og rettssikkerhet er ivaretatt.

-- Kildekoden til programvare som er en del av infrastrukturen som styrer og opererer samfunnskritiske systemer skal være åpen for inspeksjon, distribusjon, og endring av det offentlige selv. Dette er et krav som ikke kan avvikes ved avtale.

1.8 EU Public Licence

Også internasjonalt øker forståelsen for betydningen av disse tingene. Et eksempel på det, er at EU-kommisjonen i disse dager utarbeider en EU Public Licence (EUPL). Hensikten med lisensen er å gi juridisk sikkerhet i europeisk lovgivning for å beskytte rettighetene til eier og bruker av programvaren. Det gjøres betydelig arbeide med utkastet til EUPL slik at den ikke diskriminerer annen fri og åpen programvare.

http://europa.eu.int/idabc/en/document/4420

Forslag til tiltak:

-- Det offentlige legger opp til å bruke EUPL i den programvaren de lager selv. Samtidig bør denne lisensen legges til grunn ved fremtidig innkjøp av programvare. Når det gjelder systemer som gjør autmatisk saksbehandling, effektiviserer, eller inngår i samfunnskritisk teknologi, eller prosesser, må programvaren være EUPL (når denne lisensen er klar).

2 Kommentarer til organisering

EFN mener at det offentlige i for liten grad har gjort nødvendige grep for å følge opp anbefalingene fra Sårbarhetsutvalget. Borgerne mangler innsyn i automatiske rutiner for saksbehandling. Det offentlige velger systemer som i sine avtaler (programlisenser) fratar brukerne enhver mulighet til å utbedre feil og mangler i systemene. På den måten er det offentlige prisgitt leverandørens vilje til å å utbedre feil, og man står i stor fare om leverandør skulle gå konkurs eller av andre årsaker ikke gir tilgang til å ende systemene. En avtale om kun å se på kildekoden er helt uinteressant om det ikke følger med en avtale med full endringsrett. Det offentlige må selv kunne rette defekt programvare, og ta i bruk den rettede programvaren i virksomheten. Videre må det pålegges offentlige kontorer å dele feilrettinger med de andre som bruker den aktuelle programvaren.

Etter hva vi kan se er følgende ansvarslinjer klarlagt fra Stortinget:

1. Det er virksomheten med ansvar for driften som er ansvarlig for sikkerheten.

2. Det er opp til eksterne tilsynsmyndigheter å vurdere om sikkerheten er god nok i forhold til sårbarheten.

Forslag til tiltak:

-- Det offentlige må styrke arbeidet med IT-sikkerheten slik at ansvarlige organer også distribuerer feilrettinger i samfunnskritiske systemer. Det samme gjelder for fagsystemer som utfører automatisk saksbehandling hvor borgerne skal ha innsyn i de regler og rutiner som utføres ved f.eks. skatteberegning på Internett, ved gjennomføring av valg, og redningsaksjoner.

-- Dette skal gjelde uavhengig av hvilken programleverandør, og de lisenser de måtte ha. Klarer ikke leverandøren å levere i henhold til kravene til åpenhet, så må myndighetene bytte ut slike systemer.

2.1Kompetansesenter med åpen kildekode og åpne standarder.

Vi mener dokumentet i for liten grad legger trøkk bak gjennomføring av den foreslåtte opplæringen. EU-organet IDABC har i en rekke sammenheng vist hvordan andre land som Tyskland, England, Nederland osv. har etablert kompetansessentre for åpen programvare. Dette er gjort for å gi råd til brukere av slik programvare i det offentlige. Det offentlige har allerede brukt mye mer midler på rådgivning knyttet til bruk av produsenteid programvare, spesielt fra en leverandør, noe rapportene fra kommunene selv viser. Her har man mye å ta igjen, og ved å etablere fast rådgivning, vil man kunne få en bedre oversikt over alle de som konkurrerer med hverandre om å levere gode åpne kildekodeløsninger.

ForslForslag til tiltak:

Etabler kompetansesenter for åpne kildekodeløsninger, og åpne standarder for å følge opp arbeidet med opplæring av det offentlige i innkjøp og bruk av slik programvare.

3 Prioriteringen av tiltak

EFN mener at det offentlige i for liten grad har gjort nødvendige grep for å følge opp anbefalingene fra Sårbarhetsutvalget. Borgerne mangler innsyn i automatiske rutiner for saksbehandling. Det offentlige velger systemer som i sine avtaler (programlisenser) fratar brukerne enhver mulighet til å utbedre feil og mangler i systemene. På den måten er det offentlige prisgitt leverandørens vilje til å å utbedre feil, og man står i stor fare om leverandør skulle gå konkurs eller av andre årsaker ikke gir tilgang til å ende systemene. En avtale om kun å se på kildekoden er helt uinteressant om det ikke følger med en avtale med full endringsrett. Det offentlige må selv kunne rette defekt programvare, og ta i bruk den rettede/endrede programvaren i virksomheten. Videre må det pålegges offentlige kontorer å dele feilrettinger med de andre som bruker den aktuelle programvaren.

Etter hva vi kan se er følgende ansvarslinjer klarlagt fra Stortinget:

1. Det er virksomheten med ansvar for driften som er ansvarlig for sikkerheten.

2. Det er opp til eksterne tilsynsmyndigheter å vurdere om sikkerheten er god nok i forhold til sårbarheten.

Forslag til tiltak:

-- Det offentlige må styrke arbeidet med IT-sikkerheten slik at ansvarlige organer også distribuerer feilrettinger i samfunnskritiske systemer. Det samme gjelder for fagsystemer som utfører automatisk saksbehandling hvor borgerne skal ha innsyn i de regler og rutiner som utføres ved f.eks. skatteberegning på Internett, ved gjennomføring av valg, og redningsaksjoner.

Dette skal gjelde uavhengig av hvilken programleverandør, og de lisenser de måtte ha. Klarer ikke leverandøren å levere i henhold til kravene til åpenhet, så må myndighetene bytte ut slike systemer.

Vi mener at tiltak som handler om markedssituasjonen må opp. Norge har et handelsunderskudd på 23 milliarder kroner på import av IT-tjenester. Dette er store beløp, og det offentlige er en betydelig innkjøper av IT-tjenester og utstyr. Her har det offentlige et særskilt ansvar for å bygge kompetanse i landet på samme måte som vi gjorde det ved oljeutbyggingen i Nordsjøen. Derfør bør Departementet løfte opp tiltak som stiller krav til åpne standarder, men også åpen kildekode på en rekke områder som berører personvern, datasikkerhet, og retten til å utbedre feil og mangler. Her er EU-kommisjonen i gang med EU Public Licence €“ noe som kan være et godt rammeverk for slike prioriteringer.

Det politiske Norge har mer og mer sett disse poengene. F.eks. skriver Sosialistisk Venstreparti om behovet for å styrke opplæring, og kompetanse på nye IT-muligheter på en måte som styrker konkurransen i programvaremarkedet. Vi siterer:

SV vil styrke offentlige innkjøperes kompetanse om åpen kildekode, og opprette et drifts-, brukerstøtte- og opplæringsorgan for bruk av åpen programvare i skolen.

Norges markedsmakt som innkjøper av programvare skal brukes til å påvirke IT-næringen til å velge bedre og åpnere løsninger. Dette krever økt IKT-kompetanse i offentlig sektor. SV vil derfor opprette program for etter- og videreutdanning for å bedre ansatte i offentlig sektors IKT-kompetanse, og for å sikre reelt frie valg av programvare ved innkjøp.

4 Tempo for gjennomføring

Tregheten i det offentlige er betydelig. Dette gjelder både kompetansesituasjonen og markedssituasjonen. Her mener vi tempoet må opp, og tiltakene som berører dette må prioriteres først. I tillegg bør man som andre land i EU laget kompetansesentre med åpen kildekode og åpne standarder. Dette er gjort i Nederland, Tyskland, England og en rekke andre land som vi kan sammenligne oss med.

Vi mener også at sikkerhetsspørsmålet er viktig, både når det gjelder personvern, innsyn og at datasystemene er sikre mot datainnbrudd og feil. I mange år har det offentlige godtatt ufordelaktige avtalevilkår knyttet til dataprogrammene, som blant annet fraskriver leverandøren for ethvert ansvar. Det er helt på det rene at det offentlige selv er ansvarlig for bruken av IT-systemene, og må stå for feilretting og utbedringer om noe går galt. Tiltak knyttet til dette er nærmest fraværende, og man må spørre om kompetansen om slike spørsmål har vært god nok hos de Departementet har engasjert til å skrive et dokument som ellers inneholder mange gode forslag og prioriteringer.

Skrevet av Per Inge Østmoen og Knut Yrvin

Styret i EFN 15.09.2005


Høringssvar fra EFN 15.09.2005 12 av 12