Hoppa till innehåll
Checklistor
Anskaffning

Anskaffning

Syfte: Stöd för beställare, kravställare och systemägare när öppen programvara övervägs eller väljs.

Vad checklistan täcker — och inte: Den listar bara det som är specifikt för öppen programvara. Generella upphandlingskrav — informationssäkerhet, it-säkerhet, drift, arkitektur, TCO, diarieföring, utsedd systemägare etc. — förutsätts hanteras enligt era ordinarie processer och tas inte upp här.

När man upphandlar öppen programvara gäller andra spelregler än vid traditionell programvaruanskaffning: själva programvaran är fritt tillgänglig och det är tjänsterna runt den (implementation, support, underhåll, utbildning) som upphandlas. Kravställare/beställare kan därför namnge specifik öppen programvara direkt i underlaget; konkurrensen sker på tjänsterna istället för på produktvalet, vilket motverkar leverantörs­inlåsning.

Detta är uttryckligen tillåtet enligt Kammarkollegiets vägledning för avrop från Programvaror och tjänster, sektion 3.3 “Programvara med öppen källkod”:

Kund får ställa ett obligatoriskt krav på specifik namngiven Programvara som i sin helhet är licensierad med en eller flera licenser godkända av Open Source Initiative (OSI), är gratis och fri för alla leverantörer att nyttja (det krävs ex. ingen återförsäljarstatus).

Kund får ställa obligatoriska krav på standarder om standarden uppfyller kraven på en öppen standard enligt SOU 2009:86.

A. Förberedelse – behov och krav

  • SKA: Öppen programvara är övervägd som förstahandsval. Vid annat val finns dokumenterad motivering — gäller både när proprietär programvara väljs i stället och när öppen programvara inte är lämplig/möjlig (avstegsbeslut). Lämpliga grunder: funktionella, tekniska, säkerhetsmässiga eller ekonomiska skäl.
  • BÖR: Diggs Svenskt ramverk för digital samverkan och Interoperabilitetsförordningen (EU) 2024/903 är konsulterade för öppna standarder och interoperabilitet.

B. Grundläggande utvärdering av kandidatprojekt

Det projekt som väljs bör ha genomgått en grundläggande utvärdering — särskilt med avseende på projekthälsa (är det aktivt och välskött?), säkerhet (visar projektet goda säkerhetsförmågor?) och licensvillkoren (är de förenliga med era ändamål?). Punkterna nedan är utgångspunkter, inte en uttömmande granskning.

  • SKA: Projektet uppdateras regelbundet (incheckningar/kodändringar, utgåvor, ärenden).
  • SKA: Det finns en tydlig huvudaktör/organisation bakom projektet.
  • SKA: Felrapporter och förbättringsförslag hanteras inom rimlig tid.
  • SKA: Licensen är identifierad, OSI-godkänd och förenlig med hur organisationen avser att använda programvaran (drift, förändring, ev. egen publicering). Se Licensval och licenskompatibilitet.
  • SKA: Projektet visar upp goda säkerhetsförmågor. Exempel (inte alla behövs): dokumenterad säkerhetshantering (filen SECURITY.md, sårbarhetspolicy), redovisad SBOM (sammansättning), releasesignaturer (äkthet), tydligt stödfönster (hur länge säkerhetsuppdateras), eller en hälsobedömning som OpenSSF Scorecard eller motsvarande.
  • SKA: Programvarans “as is”-villkor och organisationens kvalitets- och riskansvar är förstådda. Öppen programvara levereras utan garantier; ansvaret för drift och kvalitet vilar på den som använder den.
  • BÖR: Det finns en aktiv gemenskap/community kring projektet.
  • BÖR: Det framgår hur man bidrar (filen CONTRIBUTING.md, governance, kodgranskning).

C. Ytterligare stöd

Användning av öppen programvara