Myter om öppen källkod
Uppdaterad 2023-06-10, ändringslogg.
Sammanfattning | Workshopen den 2020-10-06 adresserade Daniel Melin (Skatteverket) ett antal myter om öppen källkod. Mycket av hans kunskap kommer från att ha arbetat med öppen programvara sedan 90-talet samt efter elva år på Kammarkollegiet där han arbetat med frågor kring upphandling och då bl.a. i relation till öppen programvara.
Frågor och myter som adresserades
Finns det support för öppen programvara?
Många tror att så inte är fallet, men det är osant menar Daniel. I grunden beror det på hur populär en programvara är, inte om det är en öppen programvara eller inte. Är en öppen programvara populär, välanvänd samt har ett aktivt community kring sig så finns det support.
Går det att upphandla öppen programvara?
Så fort någon säger LOU så springer alla iväg, men det grundläggande är att upphandla öppen programvara är enklare, inte svårare än proprietär programvara. Om något kostar noll kronor och tillhandahålls fritt behövs det inte upphandlas alls. Sen kan det behövas konsulter eller support-avtal - detta måste då upphandlas.
Går det att kräva att en öppen programvara ska användas inom ramen för en upphandling eller avrop?
Om det är en öppen programvara, och därmed utan en kostnad knuten till licensen samt att det inte finns några andra hindrande regler eller krav (t.ex. en Linux-distribution som endast vissa återförsäljare får sälja), så får ni kräva att en specifik programvara ska användas. Om det däremot gäller programvara där en viss del utgörs av öppen programvara och viss del inte kan det vara problematiskt (t.ex. Open Core).
Kan jag som myndighetsanställd på min arbetstid skriva och publicera öppen programvara? Är det förenligt med anställningsavtalet som myndighetsanställd?
Det är såklart en sak om den anställde gör saker orelaterat till myndighetens uppdrag, t.ex. ett spel, men om det är något som myndigheten använder finns det inget hinder. Om programvaran sen kan vara till glädje för nån annan är det bra. Det kan vara en resa för HR att förstå sammanhanget.
Myndigheter är skyldiga att avskriva öppen programvara vars utveckling de har finansierat och kan därmed inte dela med andra.
Daniel drog här en anekdot om hur en myndighet hade uppdragit åt en konsult att utveckla en modul till en öppen programvara. När sedan en annan myndighet kom och önskade en kopia på modulen sa konsulten ja, men den ursprungliga myndigheten ansåg modulen vara deras och hade ett ekonomiskt värde i böckerna och därför inte kunde spridas till andra. Detta är sant i den materiella världen, men inte den immateriella världen. Att sprida öppen programvara innebär inte att förlora något, snarare kan du få ett mervärde om andra jobbar vidare med programvaran. I detta fall löste det sig med att modulen licensierades som en öppen programvara.
Myndigheter ska vara försiktiga med att ta in öppen programvara med vissa licenser.
Daniel har inte upplevt att detta skulle vara problematiskt. För företag som säljer något som innehåller öppen programvara då behövs kontroll eftersom licensvillkor triggas genom distribution. Om en myndighet använder en öppen programvaran triggas normalt inga licensvillkor.
Vilken licens ska jag använda när jag släpper en öppen programvara?
Generellt är moderna licenser bättre än äldre licenser. Om ni utvecklat nånting som ni ska släppa, använd en modern variant som tar hänsyn till problematiken med patent, t.ex. GPLv3-familen, MPL 2 eller Apache 2. Vid osäkerhet, utgå från att AGPLv3 är lämplig, det är en modern licens som i hög grad säkerställer att programvaran fortsätter vara öppen.