Öppen källkod i offentliga upphandlingar

Äntligen får myndigheterna kräva öppen källkod, istället för att bara hoppas på det

Fram till nyligen befann sig upphandlande myndigheter i en besvärlig situation. Den som utformade en anbudsinfordran var tvungen att hålla den teknikneutral och i princip godkänna alla anbud som uppfyllde de ställda kraven. Ett obligatoriskt krav på öppen källkod ansågs vara juridiskt känsligt, så för säkerhets skull formulerade man sig neutralt. Resultatet av denna försiktighet var paradoxalt. En förvaltning som av goda skäl ville satsa på öppen källkod fick i slutändan utvärdera anbud som även innehöll slutna produkter, och hamnade inte sällan precis där man egentligen inte ville hamna. Strävan efter digital suveränitet och upphandlingsreglerna drog åt olika håll.

Bundestagets vetenskapliga avdelning har nu löst detta dilemma.

Den 16 juli 2026 offentliggjordes ett utlåtande som klargör den avgörande frågan. Får offentliga upphandlare i en upphandling ställa krav på öppen källkodsprogramvara? Svaret från de vetenskapliga tjänsterna är entydigt. Det får de, och i många fall talar det till och med mer för än emot detta.

Vad som förändras ur ett förlåtelseperspektiv

Kärnan är lätt att förklara. Ett krav på öppen källkod i upphandlingsunderlaget är tillåtet, så länge det är sakligt motiverat, proportionerligt och motiveras på ett transparent sätt. Detta innebär dock inte fritt spelrum. En myndighet som kräver öppen källkod måste kunna förklara varför detta krav tjänar syftet. Om det saknas lämpliga erbjudanden med öppen källkod rekommenderar utlåtandet dessutom tillägget ”eller motsvarande”, så att konkurrensen förblir öppen.

Den viktiga skillnaden jämfört med den gamla praxisen ligger någon annanstans. Tidigare var upphandlingsenheten tvungen att hålla dörren öppen för alla tekniska anbud och hoppas att det rätta till slut skulle vinna. I framtiden får den från början ställa den önskade egenskapen som villkor, istället för att överlåta det åt slumpen beroende på hur anbudssituationen ser ut. Utlåtandet går till och med ett steg längre och anser att ett sådant krav under vissa omständigheter är nödvändigt, inte bara tillåtet.

Fyra skäl som motiverar krav på öppen källkod i upphandlingsannonser

I dokumentet anges flera skäl för att kräva öppen källkod, och dessa stämmer påfallande väl överens med vad vi känner till från IAM-projekt.

Den första är IT-säkerhet. Öppen källkod kan granskas, kontrolleras och vidareutvecklas oberoende, medan en sluten ”svart låda” förhindrar just detta. Särskilt inom identitetshantering, där en enda programvara styr åtkomsträttigheterna för tusentals konton, är spårbarhet ingen akademisk lyx.

Därtill kommer interoperabiliteten. Öppna standarder och dokumenterade gränssnitt underlättar anslutningen till befintliga system, vilket i växande myndighetslandskap med ett dussin källsystem ofta avgör om projektet blir en framgång eller ett evigt pågående arbete.

Den tredje punkten, beroendet av tillverkaren, väger tyngst. Den senaste rättspraxis från Europeiska unionens domstol kräver att offentliga upphandlare redan vid den första upphandlingen strategiskt överväger om ett upphandlingsbeslut kan leda till framtida, konkurrensbegränsande beroenden. Ett självförvållat leverantörsberoende räcker senare oftast inte som motivering för en direktupphandling utan konkurrens. Den egentliga skyldigheten ligger alltså i att undvika sådana beroenden redan från början. Det är precis vad öppen källkod åstadkommer, eftersom beroendet av en enskild tillverkare inte uppstår överhuvudtaget.

Då återstår den långsiktiga kostnadseffektiviteten, där licensavgiften bara är den synliga delen. Det som oftast blir dyrare är den post som inte finns med på någon faktura, nämligen den förlorade förhandlingskraften gentemot en leverantör som vet precis att man inte kan byta.

Den verkliga risken med en proprietär IAM-lösning är inte dagens licensavgift. Det är räkningen som kommer när avtalet måste förnyas och det inte längre finns något alternativ.

”Öppen källkod är en licensmodell, inte en teknik”

Varför detta berör oss särskilt inom IAM-området

Identitets- och åtkomsthantering (IAM) är ett utmärkt exempel på de beroendeförhållanden som utredningen tar upp. Ett IAM-system är placerat på en av de mest känsliga punkterna i hela infrastrukturen. Det vet vem som har vilka behörigheter, skapar konton enligt fastställda rutiner, stämmer av behörigheter genom avstämning och återkallar åtkomst så snart någon lämnar organisationen. Den som binder denna centrala knutpunkt till en sluten produkt gör sig beroende just där en senare övergång är särskilt betungande.

Vi ser ofta hos kunder inom högskolevärlden och förvaltningen att det egentliga hindret sällan är licensen. Det är kopplingarna och datalogiken bakom dem. Om reglerna för hur identiteter korreleras och behörigheter tilldelas finns i ett proprietärt format, har man bara begränsad kontroll över sin egen processmiljö. Med en öppen källkodsplattform som midPoint förblir denna logik insynbar och överförbar, vilket gör hela skillnaden när man byter tjänsteleverantör eller ska migrera ett system.

Att vara ärlig är en del av det. Öppen källkod löser inte alla problem, och den vanligaste orsaken till detta har inte mycket att göra med själva programvaran. Den heter personalbrist. Många organisationer måste fokusera på den kompetens som faktiskt finns internt, och att självständigt driva en öppen källkodsbaserad IAM-plattform ingår sällan i detta. Just därför har vi medvetet satsat på Managed Services och SaaS. På så sätt får ett universitet eller en myndighet fördelarna med en öppen, tillverkaroberoende lösning utan att behöva bygga upp ett eget driftsteam. Utlåtandet tvingar ingen att välja öppen källkod. Det tar bara bort tvånget att medvetet hamna i en lösning som man egentligen inte ville ha.

Från en neutral upphandling till tydliga krav

För upphandlande myndigheter förändras utgångsläget märkbart med detta utlåtande. Hittills har det varit den som krävt öppen källkod som stått under press att motivera sitt val. I framtiden kommer det snarare att vara den som medvetet binder en central komponent till en enda tillverkare, trots att alternativ med öppen källkod finns tillgängliga, som hamnar i en situation där man måste förklara sig. Ett tydligt formulerat krav anger, istället för en specifik produkt, de verifierbara egenskaper som behövs, till exempel offentliggjord källkod, dokumenterade gränssnitt och rätten till vidareutveckling av tredje part. På så sätt kan man säkerställa det önskade resultatet utan att stänga dörren för verklig konkurrens mellan leverantörer av öppen källkod.

Digital suveränitet har länge varit ett begrepp som bara förekom i vackra tal. Nu finns det en rättslig grund för att omsätta det i konkreta upphandlingstexter. Ramverket för detta fanns i princip redan, och utlåtandet gör det hållbart.

Vill ni inte vänta längre och undvika att er nästa upphandling återigen blir en neutral nödlösning? Kontakta oss då redan nu via kontaktformuläret. Vi visar er hur en juridiskt säker open source-kravspecifikation konkret ser ut i ert IAM-projekt, från kravspecifikationen till driften.