Hvorfor er åpen kildekode viktig for offentlig sektor?

Åpen kildekode kan gi store fordeler med tanke på at løsninger kan gjenbrukes, og videreutvikles i fellesskap. Videre gir åpenheten større innsyn og kontroll for offentligheten. Denne etterprøvbarheten er vesentlig for ansvarlig utvikling av løsninger med komponenter av kunstig intelligens i offentlig sektor, og i det geopolitiske situasjonsbildet vi befinner oss i. Bruk av åpen kildekode åpner også for mer rettferdig konkurranse ved at tilbydere kan bygge videre på det som allerede eksisterer.

Mange offentlige virksomheter ønsker å bruke mer åpen kildekode, men diskusjonen blir ofte knyttet til risiko og sikkerhet. Samtidig er realiteten at de fleste digitale løsninger allerede er bygget på åpen kildekode gjennom leverandørene. Moderne web- og skyløsninger er ofte avhengige av hundrevis eller tusenvis av åpne komponenter fra tjenester som npmjs.com. Dersom én av disse inneholder sårbarheter eller blir kompromittert, kan det påvirke store deler av løsningen. Utfordringer knyttet til programvareforsyningskjeden er derfor ikke noe man møter først når man velger å utvikle eller dele åpen kildekode, det er allerede en del av dagens digitale infrastruktur. Spørsmålet er derfor ikke om man bruker åpen kildekode, men hvordan man forvalter den på en ansvarlig måte.

En ansvarlig forvaltning av åpen kildekode stopper ikke ved egen bruk. Når offentlig sektor er avhengig av disse komponentene i stor skala, er det også et felles ansvar å bidra tilbake gjennom finansiering, deling, vedlikehold og aktiv deltakelse i miljøene som utvikler og forvalter teknologien.

Hva sier EU? EU løfter åpen kildekode fram som et virkemiddel for interoperabilitet, digital suverenitet og bedre gjenbruk i offentlig sektor. Med føringer gjennom blant annet Interoperable Europe Act, EU Open Source Strategy og relaterte initiativer blir det viktigere å jobbe systematisk med både bruk, deling og bidrag tilbake.

Hva mener vi med åpen kildekode?

Åpen kildekode er programvare som gir tilgang til å fritt bruke, lese og dele kildekoden til programvaren. Dette brukes som betegnelse ettersom mange kommersielle programvareleverandører holder kildekoden sin hemmelig. Når kildekoden som offentlig sektor bruker i sine løsninger er åpen, har myndigheter, befolkning og leverandører innsyn i hvordan programvaren fungerer.

Når en har innsyn og rett til å gjøre endringer, kan en rette feil og gjøre forbedringer eller få noen andre til å gjøre dette for seg. Den forbedrede programvaren kan deles tilbake til offentligheten, og ideen er at det på denne måten vokser frem et «økosystem» av kvalitetssikret programvare som en fellesressurs.

Anebfalinger: bruke, dele og bidra

Arbeidsgruppen anbefaler tre grep som kan styrke offentlig sektors handlingsrom og redusere sårbarhet over tid.

Figur: Tre anbefalinger for åpen kildekode i offentlig sektor.

Bruke: Åpen kildekode som foretrukket valg

Ved nye anskaffelser og utviklingsløp bør åpen kildekode velges der det er mulig og gir ønsket kvalitet. Dette gjelder både løsninger dere bygger selv og løsninger dere kjøper.

Gevinsten er særlig økt endringsevne: åpne løsninger og åpne standarder gjør det lettere å bytte komponenter og leverandører uten å starte på nytt.

Dele: Åpent som standard

Programvare utviklet for offentlige midler bør som hovedregel publiseres med åpen lisens. Målet er å åpne så mye som mulig innenfor det som er forsvarlig.

Åpen deling gir mer innsyn, bedre etterprøvbarhet og bedre grunnlag for gjenbruk på tvers av virksomheter.

Bidra: Sikre den digitale grunnmuren

Offentlig sektor er avhengig av åpne prosjekter som ofte vedlikeholdes av små miljøer. Når kritiske prosjekter svekkes, øker risikoen for mange tjenester samtidig.

Bidrag kan være kode, dokumentasjon, testing og deltakelse i fagmiljø, men finansiering er ofte særlig viktig for å sikre vedlikehold og sikkerhetsoppdateringer over tid.

Hva får dere igjen?

Mer kontroll over livsløpet

Digitale løsninger i offentlig sektor har ofte lang levetid – gjerne 10–20 år – og det er gjennom hele denne livssyklusen, ikke bare ved anskaffelsen, at kostnadene og risikoen faktisk påløper.

Med proprietær programvare er du prisgitt leverandørens valg gjennom hele løpet: når produktet videreutvikles, når det avvikles («end of life»), hvilke priser som gjelder ved fornyelse, og om du i det hele tatt får migrert dataene dine ut når avtalen tar slutt. Blir leverandøren kjøpt opp, endrer strategi eller går konkurs, kan en kritisk tjeneste stå uten vedlikehold over natten.

Åpen kildekode flytter kontrollen over livssyklusen til virksomheten selv. Selv om en leverandør trekker seg, finnes koden fortsatt, og en annen aktør kan ta over vedlikehold, feilretting og videreutvikling. Det betyr ikke at åpen kildekode er kostnadsfri – vedlikehold, sikkerhet og oppgradering av avhengigheter må finansieres uansett – men kostnaden blir synlig og styrbar i stedet for skjult i lisens- og avtalevilkår du ikke rår over.

I praksis bør virksomheten vurdere hele livsløpet allerede ved valg av løsning: ikke bare innkjøps- og utviklingskostnad, men også vedlikehold, kompetanse, migrering inn og ut, og hva en avvikling vil koste. For mange løsninger gir åpen kildekode bedre ressursutnyttelse over tid, selv om det sjelden gir lavere kostnad på dag én.

Mindre leverandørinnlåsing

Portabilitet handler om muligheten til å flytte løsninger, data og kompetanse mellom leverandører og plattformer uten å starte på nytt. Interoperabilitet handler om at systemer kan samhandle på tvers av virksomheter og forvaltningsnivåer. Begge deler svekkes når løsninger bygges lukket, og styrkes når de bygges åpent.

Når kildekoden er åpen og bygget på åpne standarder, reduseres innelåsingen til én leverandør. Du kan bytte leverandør, ta deler av forvaltningen inn selv, eller la flere aktører konkurrere om videreutvikling og drift. Det gir både bedre forhandlingsposisjon og lavere risiko for at løsningen blir en blindvei.

Bedre gjenbruk på tvers

Mange offentlige virksomheter har overlappende behov, men løser dem hver for seg. Resultatet er at samme funksjonalitet utvikles, betales for og vedlikeholdes mange ganger parallelt. Åpen kildekode gjør det mulig å erstatte dette med gjenbruk: én virksomhet kan bygge en løsning åpent, og andre kan ta den i bruk eller bygge videre på den.

Gevinsten er størst når gjenbruk tenkes inn fra starten. En løsning som er publisert åpent, men uten dokumentasjon, lisens eller tydelig forvaltning, er teknisk tilgjengelig, men i praksis vanskelig å gjenbruke. Reell nyttiggjøring krever at andre kan finne løsningen, forstå hva den gjør, vurdere om den passer, og ta den i bruk uten å måtte kontakte utviklerne.

Gjenbruk er ikke bare god ressursbruk for den enkelte virksomhet; det er en samfunnsgevinst. Når flere bidrar til og bruker samme løsning, vokser det fram et felles økosystem av kvalitetssikret programvare som blir bedre og sikrere for alle som er avhengige av den.

Mer etterprøvbare digitale tjenester

Åpen kildekode blir mer og mer vesentlig sett i lys av KI-drevet utvikling. En åpen kodebase er nærmest en forutsetning både for å gjøre det som lages etterprøvbart, forklarbart og for å kunne bruke KI-verktøy til kontinuerlig utvikling og forbedring. Dette fordi det er viktig med åpenhet og sporbarhet for hva KI-programvare som hjelper utvikleren med koding, testing, og dokumentasjon faktisk gjør, og fordi velregulert tilgang og definerte prosesser som åpen kildekode legger til rette for gir økt forklarbarhet rundt dette.

Sterkere digital beredskap

Åpen kildekode kan redusere sårbarhet ved at virksomheten ikke er like bundet til lukkede løsninger, enkeltleverandører eller utilgjengelig kompetanse. Det gir større handlefrihet ved teknologiske, økonomiske eller geopolitiske endringer.

Før dere starter: få kontroll på rammene

Før dere går til praktiske valg om bruk, deling og bidrag, bør virksomheten ha kontroll på noen grunnleggende rammer:

• Sikkerhet og sårbarheter: etabler rutiner for å oppdage, håndtere og følge opp sårbarheter og eksponerte hemmeligheter.
• Lisenser og rettigheter: avklar lisensvalg tidlig, og ha oversikt over plikter knyttet til komponentene dere bruker.
• Dokumentasjon og forvaltning: sørg for minimumsnivå for README, lisens, kontaktpunkt og enkel forvaltningsbeskrivelse.
• Roller og ansvar: gjør det tydelig hvem som eier koden, godkjenner endringer og følger opp feil, bidrag og sikkerhet.
• Kostnader over tid: planlegg for drift, vedlikehold, sikkerhetsoppdateringer og kompetanse, ikke bare oppstart.

Når disse rammene er på plass, blir det enklere å gå fra ambisjon til praktisk gjennomføring.

(Norstella - leverandørperspektiv)

Operativ veiledning

Åpen kildekode er ikke et prosjekt med start og slutt, men en arbeidsform som modnes over tid. Dere trenger ikke gjøre alt samtidig. Start med ett avgrenset område, for eksempel én løsning eller ett repository.

Etter at rammene over er avklart, er et praktisk utgangspunkt å jobbe i tre spor:

• Bruke: få oversikt over avhengigheter, lisenser og sårbarheter i det dere allerede er avhengige av. (mer om lisenstyper)
• Dele: velg én konkret kandidat for publisering, og avklar lisens, dokumentasjon og forvaltningsansvar.
• Bidra: avklar hvordan virksomheten kan bidra tilbake på en realistisk måte, for eksempel med kode, dokumentasjon, testing eller finansiering.

Lær underveis, og bruk erfaringer fra andre offentlige virksomheter som allerede har delt kode og praksis åpent.

For mange virksomheter er det nyttig å starte i liten skala:

• Velg ett system eller én tjeneste dere kjenner godt.
• Kartlegg hvilke åpne komponenter dere faktisk bruker i dag.
• Avklar hva som eventuelt kan deles trygt uten at dere åpner alt på én gang.
• Sett av navngitt ansvar for oppfølging av sikkerhet, lisens og publisering.

Minimumskrav

Bruk sjekklisten under for å sikre at dere har det viktigste på plass for bruk, deling og bidrag.

Start med noen enkle grunnkrav før dere går videre til de mer konkrete punktene:

• Håndter lisenser tidlig: avklar lisensvalg for egne leveranser og etabler en enkel rutine for tredjepartslisenser.
• Sett en minimumsstandard for dokumentasjon: sørg for README, lisensfil, kontaktpunkt og kort beskrivelse av forvaltning.
• Bygg sikkerhet inn i prosessen: bruk skanning av avhengigheter og hemmeligheter, og avklar hvordan sårbarheter håndteres.
• Plasser ansvaret tydelig: navngi hvem som eier koden, hvem som godkjenner endringer, og hvem som følger opp bidrag og feil.

Når dere vurderer å ta i bruk et åpent prosjekt, er det også nyttig å se etter noen grunnleggende kjennetegn: tydelig lisens, aktivt vedlikehold, god dokumentasjon, åpen styring og en viss stabilitet i kode og videreutvikling.

Når dere skal bruke åpen kildekode

• Har dere oversikt over hvilke åpne komponenter, avhengigheter og lisenser løsningen bygger på?
• Er prosjektet aktivt vedlikeholdt, og finnes det nok dokumentasjon og støtte til å ta det i bruk forsvarlig?
• Har dere rutiner for å oppdage og følge opp sårbarheter, oppgraderinger og lisensutfordringer?

Praktisk råd: start med å lage en enkel oversikt over hvilke åpne biblioteker og rammeverk dere allerede er avhengige av. Da blir det lettere å prioritere hva som må følges tettest opp.

Når dere skal dele kode

• Hva er formålet med å dele koden: transparens, gjenbruk, samarbeid eller videreutvikling?
• Kan koden publiseres forsvarlig, eller inneholder den hemmeligheter, sensitiv informasjon eller forhold som må skjermes?
• Er lisens, README, kontaktpunkt og forvaltningsansvar på plass før publisering?
• Er repository og historikk sanert for nøkler, passord, personopplysninger og sensitiv konfigurasjon?
• Finnes en enkel kanal for å melde sårbarheter og feil?

Praktisk råd: velg ett repository som pilot. Få på plass minimumspakken (lisens, README, kontaktpunkt og enkel forvaltningsbeskrivelse), og bruk læringen derfra før dere åpner flere.

Når dere skal bidra tilbake

• Hva er målet med å bidra tilbake: redusere risiko, styrke kvalitet, bygge kompetanse eller støtte kritiske avhengigheter?
• Hvilke bidragsformer er realistiske for dere: kode, feilretting, dokumentasjon, testing, finansiering eller deltakelse i fagmiljø?

Praktisk råd: vurder aktivt hvordan virksomheten kan bidra tilbake til prosjekter dere er avhengige av. Bidrag kan være kode, dokumentasjon og testing, men finansiering er ofte et særlig viktig bidrag for å sikre vedlikehold, sikkerhetsoppdateringer og videre utvikling over tid.

Hvor modne er dere?

Vi kan skille mellom ulike grader av modenhet for åpen kildekode. Det finnes flere modeller for beskrivelse av modenhet, én slik modell er skissert av OSPO alliance (Referanse).

Modellen skisserer fem nivåer av modenhet: bruk, tillit, kultur, engasjement og strategi.

På det laveste nivået har vi altså bruk av åpen kildekode i en organisasjon, hvor man har tilstrekkelig kompetanse til å ta i bruk, men hovedsakelig er konsument.

I neste nivå er det en økt bevissthet og kontrollerte rammer, slik som sikkerhet, håndtering av avhengigheter, juridiske og økonomiske forhold.

På kulturnivået er en god praksis internalisert i organisasjonen, og det er utviklet en intern kultur der åpen kildekode er en naturlig del av arbeidsprosessen.

På de to øverste nivåene går vi til engasjement, hvor organisasjonen er aktiv bidragsyter, enten ved å dele aktivt egne prosjekter, eller som bidragsyter i eksterne prosjekter.

På det øverste nivået er åpen kildekode bevisst brukt som virkemiddel for å nå organisasjonens overordnede mål. Her er åpen kildekode ikke bare et teknisk valg, men også et strategisk valg forankret i øverste ledelse.

Åpen kildekode og åpne standarder utfyller hverandre: standardene legger til rette for at systemer kan snakke sammen, mens åpen kildekode gir innsyn i hvordan samhandlingen faktisk er implementert. For offentlig sektor, der tjenester ofte må utveksle data på tvers av etater, kommuner og forvaltningsnivåer, er dette en forutsetning for å unngå at hver virksomhet bygger sine egne, inkompatible siloer. (oppdatere tekst Digdir) (bør bli mer handlingsrettet?)

Status - og hvordan kan du bidra?

All informasjon på disse sidene er arbeidsdokumenter som er under arbeid. Vi tar gjerne imot tilbakemeldinger fra alle som er engasjerte i tematikken ☺️. Send tilbakemeldinger oss via diskusjonssiden på github eller på epost. Det er også lov å åpne en pull-request mot repoet. Arbeidsgruppen vil vurdere eventuelle bidrag.

Relevante kilder

EU og offentlig sektor

• Interoperable Europe Act - relevant for interoperabilitet, grensekryssende digitale tjenester og offentlig sektors samhandling.
• European Commission Open Source Software Strategy 2020-2023 - relevant for “Think Open”, deling, gjenbruk, aktiv deltakelse og støtte til kritiske åpne prosjekter.
• OSOR Handbook: Open Source Software in Public Administration - praktisk referanse for offentlig sektor, med tema som anskaffelser, kataloger, lisensiering, finansiering, styring og OSPO.
• OSOR Public Procurement of Open Source Software - relevant for anskaffelser av åpne løsninger og tjenester rundt åpen kildekode.

Praktisk publisering og styring

• Retningslinjer for åpen kildekode i NAV - norsk offentlig eksempel på hvordan en stor virksomhet organiserer publisering, eierskap og praktisk arbeid med åpen kildekode.
• GOV.UK: Making source code open and reusable - kort offentlig veiledning om å gjøre kildekode åpen og gjenbrukbar.
• NHS Service Manual: Make new source code open - tydelig offentlig sektor-prinsipp om at ny kildekode bør gjøres åpen og gjenbrukbar med passende lisens, med mindre det finnes god grunn til å la være.
• OSPO Alliance Good Governance Initiative - relevant for modenhet, roller, policy og styring.

Sikkerhet og lisens

• OpenSSF Scorecard - verktøy for vurdering av sikkerhetspraksis i åpne prosjekter.
• OpenSSF Best Practices Badge - selvdeklarering og beste praksis for FLOSS-prosjekter.
• REUSE Specification - standardisert metode for maskinlesbar og ryddig lisens- og opphavsrettsinformasjon i repositories.