Analys av DIGG:s policy för utveckling av programvara...Utfärdare: Björn Lundell Analys av DIGG:s policy för utveckling av programvara Sammanfattning Denna sammanfattning presenterar

Utfärdare: Björn Lundell Analys av DIGG:s policy för utveckling av programvara

Analys av DIGG:s policy för utveckling av programvara

Professor Björn Lundell, Ph.D. Software Systems Research Group

Högskolan i Skövde [email protected]

Förord

Denna rapport presenterar en analys av DIGG:s policy för utveckling av programvara1 (Dnr. 2019-136). Den analys som redovisas i rapporten har genomförts av Dr. Björn Lundell, professor i datavetenskap vid Högskolan i Skövde, inom ramen för ett oberoende uppdrag. Av dessa skäl ska rapportens innehåll, med alla eventuella felaktigheter och brister, inte uppfattas som något ställningstagande från DIGG.

Rapporten har utvecklats inom ramen för en analys som genomförts på uppdrag av DIGG utifrån ett av DIGG identifierat behov av att sakkunniggranska den policy för utveckling av programvara som publicerades den 5 maj 2019. Rapportens innehåll är tänkt att kunna utgöra ett stöd för både DIGG och andra myndigheter som i sin myndighetsutövning, på ett eller annat sätt, har behov av att förhålla sig till programvara, vilket inkluderar såväl användning, anskaffning och utveckling (samt vidareutveckling) av programvara.

De värderingar, ställningstaganden och rekommendationer som redovisas i rapporten tillskrivs författaren och ska inte uppfattas som något beslut av någon myndighet. I sammanhanget ska betonas att författaren har en lång bakgrund och erfarenhet av socio-teknisk forskning inom området datavetenskap, med betydande fokus på öppen programvara, öppna standarder och andra former av öppenhet från de senaste decenniernas forskning. Även om författaren bedrivit forskning i samverkan med juridisk expertis och från denna publicerat resultat som redovisar en rad juridiska utmaningar som relaterar öppen programvara i vetenskapliga fora, ska denna rapport inte uppfattas som en juridisk vägledning. Den analys som redovisas i denna rapport har berikats och influerats av erfarenheter från flera studier som genomförts i samverkan med flera personer inom ramen för flera forskningsprojekt som involverar internationell och nationell samverkan, däribland tidigare studier som genomförts inom ramen för tidigare uppdrag av andra myndigheter i Sverige. Utifrån detta vill författaren passa på och tacka alla personer som, på olika sätt, bidragit till att berika författarens erfarenheter och insikter som influerat viktiga utgångspunkter för den analys som redovisas i rapporten.

Alla värderingar, ställningstaganden och rekommendationer som redovisas i rapporten har utvecklats utifrån författarens erfarenhet och uppfattning av underliggande utgångspunkter och behov av att kunna bedriva en tillitsfull och god förvaltning under den myndighets-utövning som genomförs inom en politiskt styrd organisation. Detta inkluderar alla typer av myndigheter, såväl stora som små, samt oavsett huruvida en myndighet betraktas som IT-intensiv och oavsett huruvida en myndighet bedriver egen utveckling av programvara. Även om de värderingar, ställningstaganden och rekommendationer som redovisas i rapporten presenteras som rekommendationer till myndigheter ska rapportens användning av begreppet ’myndighet’ tolkas inkluderande och rapportens rekommendationer riktar sig därmed till alla typer av myndigheter, vilket inkluderar såväl statligt styrda myndigheter, regioner som kommuner.

Version: 1.0 1 (96) 20 maj 2020

https://uppdrag.Av

mailto:[email protected]


Sammanfattning

Denna sammanfattning presenterar en översikt av resultat och rekommendationer från den analys som genomförts av DIGG:s policy för utveckling av programvara2 (Dnr. 2019-136).

Sammanfattningen riktar sig till företrädare för DIGG och andra myndigheter som har inflytande över beslut som påverkar den egna myndighetens (och andra organisationers) policys, strategier och praktik för anskaffning, utveckling, användning, förvaltning och tillgängliggörande av programvara.

DIGG:s policy hänvisar explicit till tre olika licenser för öppen programvara3: BSD 2-Clause, Apache och GPL. Det finns flera versioner av GPL som alla har olika effekter. Policyn innehåller en referens till GPL som kan uppfattas utgöra en inkluderande referens som omfattar alla versioner av licenser inom den familj av licenser som ibland, övergripande, refereras som GPL (eller som General Public License). Licenser inom GPL-familjen kan övergripande delas in i tre typer, som alla har olika effekter, när de används. Följande tre typer av licenser ur denna familj har alla olika egenskaper och effekter: LGPL (Lesser General Public License), GPL (General Public License) och AGPL (Affero General Public License). Dessutom har flera versioner av dessa licenser publicerats, däribland: LGPL version 2.1, LGPL version 3.0, GPL version 2.0, GPL version 3.0 och AGPL version 3.0.

Det finns många aspekter som en myndighet behöver beakta då en myndighet, på något sätt, har behov av att engagera sig med och förhålla sig till utveckling och anskaffning av programvara. Något förenklat kan DIGG:s policy sägas identifiera två olika principiella situationer för en myndighet som behöver fatta beslut avseende utveckling och anskaffning av programvara.

Den första principiella situationen där en policy kan ge viktig vägledning avser en situation då en myndighet har behov av att anskaffa eller bidra till vidareutveckling av ett redan etablerat programvaruprojekt som tillhandahåller öppen programvara. I denna situation behöver myndigheten ta ställning till en rad frågor som inkluderar analys av under vilka licenser och villkor som öppen programvara tillhandahålls av det etablerade programvaru-projektet. Denna analys behöver värdera olika möjligheter för att anskaffa och vidareutveckla en redan etablerade programvara, vilket inkluderar flera ställningstaganden avseende eventuell upphandling och utveckling. Det ska betonas att såväl upphandling som utveckling kan (helt eller delvis) genomföras i en myndighets egen regi, men även (helt eller delvis) i extern regi. Exempelvis kan en myndighet upphandla vidareutveckling av förbättringar eller anpassningar av en redan etablerad öppen programvara som genomförs av externa parter.

Den andra principiella situationen där en policy kan ge betydelsefull vägledning avser en situation då en myndighet har behov av att etablera ett nytt programvaruprojekt som ska tillhandahålla öppen programvara för att tillgodose myndighetens behov. Även i denna situation behöver myndigheten ta ställning till en rad frågor som inkluderar hur programvaruprojektet ska styras, etableras och förvaltas, men också en lång rad frågor avseende under vilka villkor och licenser som öppen programvara kan och ska tillhandahållas från programvaruprojektet. Frågor att ta ställning till inkluderar i vilken utsträckning det vid etablering av nya programvaruprojekt är av vikt för en myndighet att skapa incitament för en god förvaltning och vidareutveckling av det nya projektet. Vidare är frågor om val av licens som skyddar samt stimulerar och ger incitament för fortsatt öppenhet nya och etablerade programvaruprojekt som tillhandahåller öppen programvara. Det kan noteras att den

Version: 1.0 2 (96) 20 maj 2020


organisation (Open Source Initiative4) som etablerat och förvaltat definitionen för öppen programvara nu rekommenderar att nya programvaruprojekt som ska tillhandahålla öppen programvara väljer en populär5 (välanvänd) licens för öppen programvara som innehåller goda patentklausuler. Det kan konstateras att patent som belastar programvara idag är ett betydligt större problem än det var under förra seklet då viktiga organisationer som i hög grad influerat hur individer och organisationer idag arbetar med programvaruutveckling etablera-des, som Free Software Foundation (etablerad 1984) och Open Source Initiative (etablerad 1998). Utifrån detta redovisar denna rapport rekommendationer som syftar till att vägleda en myndighet vid val av lämplig licens då ett nytt programvaruprojekt ska etableras där syftet är att tillhandahålla en öppen programvara. Relaterat överväganden avseende licenser identifieras ett antal frågeställningar som myndigheter behöver beakta för att kunna fatta informerade strategiska beslut.

Frågor om myndighetens överväganden avseende vikten av att skydda fortsatt öppenhet för myndighetens investeringar i nyutvecklad och vidareutvecklad programvara är relevant i både det första och andra principiella scenariot. I båda dessa situationer finns det, i många fall, starka skäl att inventera om det är (tekniskt och juridiskt) möjligt att återanvända redan existerande öppen programvara. Vidare behöver en analys göra av huruvida programvaran utvecklats av ett programvaruprojekt som har en god förvaltning och där distribuerad öppen programvara håller god kvalitet. Då en myndighet vidareutvecklar ett befintligt programvaru-projekt eller etablerar ett nytt programvaruprojekt finns det, i många fall, starka skäl att återanvända redan existerande komponenter (byggblock) av redan existerande öppen programvara. Det kan många gånger vara tekniskt och licensmässigt möjligt (och ofta lämpligt) att återanvända komponenter vid vidareutveckling av redan existerande program-varuprojekt och även vid nyutveckling och etablering av ett nytt programvaruprojekt.

Det ska betonas att det, i vissa scenarier beroende på behov, även kan finnas mycket starka skäl att avstå från att återanvända redan existerande öppen programvara. Ett scenario då en komponent inte kan (och inte ska) återanvändas uppstår då licensen (eller licenserna) för en etablerad komponent inte kan kombineras med den licens myndigheten planerar använda för det programvaruprojekt som ska etableras eller vidareutvecklas. Ett annat sådant, långt ifrån ovanligt, scenario uppstår då det för den redan existerande komponenten (den öppna programvara som myndigheten planerar återanvända som en komponent i ett nytt eller vidareutvecklat programvaruprojekt) saknas tillförlitliga uppgifter om huruvida myndigheten redan har (alternativt har möjlighet att anskaffa) alla nödvändiga rättigheter för att kunna återanvända och distribuera den öppna programvaran. Det kan tänkas att den komponent som är tänkt att inkluderas i ett programvaruprojekt som myndigheten planerar etablera eller vidareutveckla av juridiska skäl inte kan användas (exempelvis om komponenten implementerar en standard utan att ha anskaffat alla nödvändiga rättigheter för detta).

I händelse av att en komponent som en myndighet planerar återanvända, exempelvis, implementerar ett patentbelastat filformat under licensen BSD 2-Clause finns det mycket starka skäl för myndigheten att anskaffa alla nödvändiga licenser för detta filformat innan myndigheten börjar använda komponenten. Licensen BSD 2-Clause har varit föremål för mycket diskussion bland juridisk expertis (denna licens saknar exempelvis en explicit patentklausul, till skillnad från flera andra licenser, exempelvis LGPL 3.0-licensen). Rapporten redogör för dessa diskussioner, men sammanfattningsvis är det bland annat av detta skäl som rekommendationer från forskning inom området och rekommendationen från

Version: 1.0 3 (96) 20 maj 2020


denna analys avråder från att använda BSD-licensen då nya programvaruprojekt ska etableras, speciellt då filformat och standarder ska implementeras i öppen programvara6. Om ett val står mellan att använda MIT-licensen eller BSD 2-Clause för ett nytt programvaruprojekt, är rekommendationen från denna analys att MIT-licensen bör väljas istället för BSD 2-Clause. Det finns flera skäl för detta som redovisas i rapporten.

Forskning visar att det, för vissa standarder och vissa filformat, i praktiken kan visa sig vara omöjligt att inom rimlig tid anskaffa alla nödvändiga rättigheter för att använda en specifik standard respektive ett specifikt filformat i en öppen programvara och utifrån detta är det viktigt att genomföra en analys inför varje beslut om återanvändning av en komponent som implementerar en standard eller ett filformat som kan vara belastad med patent7, specifikt s.k. standardessentiella patent8. Det är viktigt att notera att denna utmaning inte på något sätt är unik för öppen programvara. Tidigare forskning visar att hinder för att använda patent-belastade standarder och filformat även påverkar möjligheten att implementera dessa i programvara som tillhandahålls under alla typer av villkor.

Utifrån olika utmaningar med patentbelastade standarder och filformat som ska implemen-teras i det programvaruprojekt som en myndighet planerar etablera, finns det mycket starka skäl att myndigheten först klargör att alla nödvändiga rättigheter anskaffats så att myndig-heten kan etablera det planerade programvaruprojektet som ska tillhandahålla öppen programvara. Vid en etablering av ett nytt programvaruprojekt som ska implementera denna typ av patentbelastade standarder finns det mycket starka skäl att rekommendera en myndighet att välja en licens ur familjen GPL för att på detta sätt säkerställa fortsatt öppenhet för det etablerade projektet som ska tillhandahålla öppen programvara.

Denna analys rekommenderar att en myndighet väljer LGPL-licensen vid implementation av standarder och filformat i öppen programvara. Detta rekommenderas både i en situation då ett nytt programvaruprojekt ska etableras och då en vidareutveckling av ett redan etablerat programvaruprojekt ska göras under förutsättning att detta är möjlighet utifrån de licensval som det etablerade projektet tidigare gjort. En etablering av ett programvaruprojekt som ska implementera en standard eller ett filformat kan, med fördel, utgöra en komponent (ett byggblock) i en större lösning. Genom LGPL-licensen skyddas fortsatt öppenhet för program-varan vid distribution vilket stimulerar en transparent tolkning av den tekniska specifikationen för standarden och filformatet. Licenser ur familjen GPL ger även bra skydd för de som vill använda en komponent genom att distribution endast kan ske om alla nödvändiga rättigheter har anskaffats9.

En förutsättning för att beslutsfattare inom myndigheter ska kunna fatta välinformerade beslut avseende vidareutveckling, nyutveckling och anskaffning av programvara ställer krav på kunskap om öppen programvara och underliggande incitament som olika intressenter utanför den egna myndigheten har. Det är viktigt att ha insikter om de motiv och incitament som olika aktörer har för att kunna fatta goda beslut då en myndighet behöver förhålla sig till och ibland engagera sig med olika programvaruprojekt, i ett landskap där olika aktörer agerar utifrån olika (ibland motstridiga) utgångspunkter och incitament.

Utifrån detta avser denna rapport redovisa ett antal rekommendationer som syftar till att vägleda en myndighet för val av lämplig licens då ett nytt programvaruprojekt ska etableras där syftet är att tillhandahålla en öppen programvara.

Version: 1.0 4 (96) 20 maj 2020


1. Introduktion

Betydelsen av programvara för samhällets digitalisering kan inte nog understrykas. Utöver traditionella IT-företag blir allt fler myndigheter och organisationer i olika branscher beroende av programvara och det finns många exempel på organisationer som under senaste decenniet i grunden transformerats. Exempelvis uppmärksammade Marc Andreesen programvaras betydelse för många branscher genom det budskap som kommunicerades i en artikel publicerad i The Wall Street Journal den 20 augusti 2011 där frasen ’software is eating the world’ myntades10 .

Öppen programvara11 är programvara som tillhandahålls under en licens12 som uppfyller definitionen13 för öppen programvara. Organisationen Open Source Initiative14 förvaltar definitionen som har etablerats för att precisera vad som konstituerar öppen programvara. Definitionen ligger till grund för att avgöra huruvida nya förslag på licenser för programvara ska erkännas som licenser för öppen programvara15. Det finns ett stort antal licenser16 för öppen programvara men endast ett fåtal17 av dessa används av en klar majoritet av alla programvaruprojekt som tillhandahåller öppen programvara som fått stor spridning. Öppen programvara utvecklas ofta i en öppen samverkan18 där intresserade individer och organisationer via internet och webben har möjlighet att engagera sig och bidra till utvecklingen. Programvaruprojekt som tillhandahåller öppen programvara, till skillnad från sluten programvara19, ger användaren rätt att undersöka, använda, kopiera, vidareutveckla och distribuera programvaran utan restriktioner.

Under de senaste decennierna har uppfattningar om öppen programvara utvecklats från att betraktas med viss skepsis till att under det senaste decenniet betraktas som en självklarhet av alltfler individer och organisationer20. Redan 2010 rapporterade exempelvis Gartner att öppen programvara är ofrånkomligt för flertalet IT-organisationer21. Betydelsen av öppen program-vara har gått från att vara en angelägenhet för några få utvecklare till att bli den dominerande modellen för utveckling av programvara som används av de mest innovativa företagen22. För många ledande IT-företag är det numera en självklarhet att använda och vara engagerad med öppen programvara och i maj 2014 hävdade exempelvis en ledande företrädare för Samsung att det idag inte går att utveckla innovativa produkter och tjänster utan att använda öppen programvara23 . I många branscher som exempelvis fordonsbranschen är det idag vanligt att företag tillhandahåller produkter, däribland bussar24 och personbilar25 , som innehåller öppen programvara under licenser som ställer krav på att företaget som tillhandahåller produkten ger kunden ett erbjudande om att restriktionsfritt, samt i princip kostnadsfritt26, kunna ta del av källkoden för den distribuerade öppna programvaran.

Inom offentlig sektor har många myndigheter i olika länder under lång tid använt öppen programvara. Långt innan 1990-talet fanns det en tradition av att fritt dela programvara mellan olika organisationer och många av de teknologier som ligger till grund för internet och webben är resultatet av detta. Det ska nämnas att flera licenser för öppen programvara utvecklades innan ett kraftfullt internet fanns tillgängligt och av detta skäl skedde distribution av programvara ofta via flygpost där programvaran tillhandahölls via magnetband eller disketter.

Europeiska Kommissionen publicerade redan 2001 en studie om öppen programvara inom offentlig sektor. Studien redovisar utgångspunkter för öppen programvara27 , samt en analys av hur öppen programvara används i Frankrike, Spanien, Tyskland, Italien, Belgien och

Version: 1.0 5 (96) 20 maj 2020


Sverige28. Vidare redovisas en analys av marknaden för öppen programvara och utmaningar kring offentlig upphandling av programvara29 samt en översikt av 100 programvaruprojekt, där flera än idag är aktiva och tillhandahåller öppen programvara30. Därefter har myndigheter i Sverige, successivt, visat ett allt större intresse för användning av och engagemang med öppen programvara. Under 2020 publicerar EU ett antal rapporter från olika EU-länder31 som redovisar nationella policys för myndigheters användning av öppen programvara, där rapporten från Sverige redovisar ett antal exempel på hur myndigheter i Sverige använder och är engagerade med öppen programvara32.

Fortsättningsvis innehåller rapporten en redovisning av öppen programvara och dess ekosystem (sektion 2) följt av en genomgång av förutsättningar och initiativ för en hållbar digitalisering (sektion 3). Vidare behandlas hur myndigheter kan engagera sig med öppen programvara som del av sitt strategiska arbete med anskaffning och utveckling av programvara (sektion 4). Därefter redovisas en analys av innehållet i nuvarande policy med förslag till rekommendationer för hur myndigheter kan arbeta med en vidareutvecklad policy (sektion 5). Avslutningsvis behandlar rapporten hur öppen programvara påverkar ett antal relaterade utmaningar med rekommendationer för hur myndigheter kan och bör adressera dessa utmaningar (sektion 6).

Rapporten är strukturerad för att kunna läsas på olika sätt. De inledande delsektionerna i sektion 2, 3, 4 och 5 ger en översikt av innehållet i respektive sektion (d.v.s. sektion 2.1, sektion 3.1, sektion 4.1 och sektion 5.1). Specifikt presenterar sektion 5.1 en översikt av det förslag på rekommenderade licenser för en vidareutvecklad policy som redovisas från genomförd analys. De olika delsektionerna i sektion 6 presenterar ett antal rekommendationer som behandlar öppen programvara i relation till ett antal relaterade utmaningar som en myndighet har att förhålla sig till för att utveckla en hållbar digitalisering. Specifikt behandlar sektion 6 rekommendationer avseende öppen programvara relaterat följande: standarder (delsektion 6.1), patentbelastade standarder (delsektion 6.2), EU:s interoperabilitetsramverk (delsektion 6.3), programvara som tillhandahålls genom lokal installation och drift (delsektion 6.4), programvara som tillhandahålls som tjänst (delsektion 6.5), forskning (delsektion 6.6) och kompetensutveckling (delsektion 6.7).

För en läsare som önskar ta del av en översiktlig redovisning av rekommendationerna från denna analys rekommenderas att ta del av rapportens förord, sektion 1 följt av den inledande översikten i respektive delsektion (delsektionerna 2.1, 3.1, 4.1 och 5.1) samt de delsektioner i sektion 6 som behandlar de relaterade utmaningar som är speciellt relevanta för läsaren.

För en läsare som önskar få en djupare förståelse av öppen programvara rekommenderas särskilt sektion 2. Därutöver rekommenderas en läsare som vill få en djupare bild av de utgångspunkter som ligger till grund för de ställningstaganden och rekommendationer som redovisas att ta del av hela innehållet i rapporten.

Version: 1.0 6 (96) 20 maj 2020


2. Öppen programvara och dess ekosystem

2.1 Översikt

Öppen programvara skapar förutsättningar för en förtroendefull förvaltning. Förtroendet för en myndighet ställer krav på en god och långsiktigt hållbar hantering av de data som upprättas och förvaltas inom myndigheten, vilket förutsätter att myndigheten har kontroll över de system och den programvara som används för denna förvaltning.

För att en myndighet ska ha kontroll över sin förvaltning är det nödvändigt att agera utifrån en genomtänkt strategi som ger en god förvaltning av data i filer och andra digitala artefakter (exempelvis innehåll i en databas) där innehållet i en fil (eller annan typ av digital representa-tion) organiseras och representeras i ett lämpligt format33 som har implementerats i öppen programvara34. Genom detta möjliggörs en långsiktigt hållbar tolkning och återanvändning av myndighetens data. När myndighetens data hanteras och finns representerade i öppna standarder som är implementerade i öppen programvara möjliggörs en transparent35 och långsiktigt god förvaltning av myndighetens information och handlingar. En sådan förvaltning möjliggör tolkning och återanvändning av data, såväl inom som utanför den egna myndig-heten, under hela den tidsperiod som myndigheten har ett förvaltningsansvar. Av dessa skäl behöver myndigheten, under hela denna tidsperiod, ha tillgång till programvara36 som korrekt kan tolka och återanvända data i de digitala representationer som myndigheten använder för att kunna upprätthålla en god förvaltning.

Öppen programvara är ett begrepp som ibland sammanblandas med andra öppenhets-begrepp. För att positionera öppen programvara i förhållande till öppen standard och öppet innehåll preciseras inledningsvis dessa begrepp med en illustration och exemplifiering av hur dessa förhåller sig till varandra genom en öppenhetskub37 (se tabell 1). Det finns många möjligheter och hinder som på olika sätt påverkar och skapar förutsättningar för en hållbar digitalisering38 . En utgångspunkt för en god förvaltning av en myndighets information förutsätter möjlighet att kunna använda och återanvända de data som myndigheten själv upprättar och har ansvar att förvalta. Detta förutsätter att data förvaltas i filer (eller andra representationer) som är representerade i filformat som kan (och har39) implementerats i öppen programvara.

En öppen programvara40 är en programvara som tillhandahålls under en licens41 som uppfyller definitionen för öppen programvara42 . Ett fåtal populära licenser för öppen programvara används av en mycket stor andel av de programvaruprojekt som tillhandahåller öppen programvara.

En öppen standard är en standard som tillhandahålls under villkor som uppfyller definitionen av öppen standard enligt EU:s Interoperabilitetsramverk version 1.043. Standarder som uppfyller denna definition kan implementeras av programvaruprojekt som tillhandahåller såväl öppen programvara som sluten programvara44 . Kammarkollegiet har publicerat en väg-ledning som presenterar ett antal öppna standarder som uppfyller denna definition av öppen standard45. Öppna standarder som uppfyller definitionen i Kammarkollegiets vägledning är konkurrensneutrala, möjliggör interoperabilitet46 och kan implementeras i såväl öppen som sluten programvara. En myndighet som genomför en offentlig upphandling kan referera till öppna standarder för att formulera obligatoriska krav i förfrågningsunderlaget. Det finns ett stort antal standarder där vissa av dessa preciserar en teknisk specifikation av ett filformat.

Version: 1.0 7 (96) 20 maj 2020


Ett filformat som tillhandahålls under villkor som uppfyller definitionen av öppen standard enligt EU:s Interoperabilitetsramverk version 1.047 är ett öppet filformat. Det ska noteras att EU:s Interoperabilitetsramverk i senare versioner, både version 2 och version 3, saknar en definition av öppen standard (och båda dessa versioner presenterar istället begreppet öppen specifikation (eng. open specification) med en definition som hindrar interoperabilitet48

genom att denna definition hindrar implementation i öppen programvara49 .

Ett öppet innehåll är ett innehåll som tillhandahålls under villkor som uppfyller den definition av öppet innehåll som etablerats50 genom ett projekt av organisationen Open Knowledge Foundation51. Om en myndighet tillhandahåller data som öppet innehåll kan detta fritt användas, modifieras och delas (på motsvarande sätt som öppen programvara fritt kan användas, modifieras och delas). Det finns ett antal licenser som en myndighet kan använda för att tillhandahålla öppet innehåll som uppfyller definitionen, däribland följande tre: CC0, CC-BY 4.0 och CC-BY-SA 4.052 .

# Standard Programvara Innehåll Illustrativt exempel

1 öppen öppen öppen PDF/A-1 standarden (ISO 19005-1:2005) är implementerad i den öppna programvaran LibreOffice 6 som användas för att skapa och tillhandahålla PDF-filer som öppet innehåll under CC-BY-SA 4.0.

2 öppen öppen sluten PDF/A-1 standarden (ISO 19005-1:2005) är implementerad i den öppna programvaran LibreOffice 6 som användas för att skapa och tillhandahålla PDF-filer som slutet innehåll under traditionell användning av upphovsrätt.

3 öppen sluten öppen PDF/A-1 standarden (ISO 19005-1:2005) är implementerad i den slutna programvaran MS Office 2016 som användas för att skapa och tillhandahålla PDF-filer som öppet innehåll under CC-BY-SA 4.0.

4 öppen sluten sluten PDF/A-1 standarden (ISO 19005-1:2005) är implementerad i den slutna programvaran MS Office 2016 som användas för att skapa och tillhandahålla PDF-filer som slutet innehåll under traditionell användning av upphovsrätt.

5 sluten öppen öppen N/A53

6 sluten öppen sluten N/A54

7 sluten sluten öppen PDF/A-2 standarden (ISO 19005-2:2011) är implementerad i den slutna programvaran callas pdfaPilot 7 som användas för att skapa och tillhandahålla PDF-filer som öppet innehåll under CC-BY-SA 4.0.

8 sluten sluten sluten PDF/A-3 standarden (ISO 19005-3:2012) är implementerad i den slutna programvaran MS Office 365 som användas för att skapa och tillhandahålla PDF-filer som slutet innehåll under traditionell användning av upphovsrätt.

Tabell 1: Åtta kombinationer av hur standarder, programvara och innehåll tillhandahålls.

Version: 1.0 8 (96) 20 maj 2020


2.2. Öppen programvara och relaterade begrepp

Genom åren har olika individer och organisationer utvecklat ett stort antal licenser55 som används för att tillhandahålla programvara under olika villkor och av dessa har ett antal erkänts som licenser för öppen programvara (eng. Open Source Software56) av organisationen Open Source Initiative57. Organisationen har en kommitté med sakkunniga som granskar föreslagna licenser i en öppen process utifrån definitionen av öppen programvara58 och under förutsättning att en föreslagen licens uppfyller definitionen erkänns denna som en ny licens för öppen programvara59 . Kring gruppen som etablerade organisationen bakom öppen programvara fanns tidigt personer som såg mycket stor potential för innovation och nya former för samverkan långt utöver utveckling av programvara60. ”

I vissa sammanhang används även det relaterade begreppet fri programvara för att betona de friheter (i betydelsen free speech, inte ’fri’ som i ’gratis’) som en användare av fri program-vara61 (eng. Free Software) har62. Med fri programvara betonas de friheter63 en användare har att använda, kopiera, distribuera, undersöka och vidareutveckla programvaran64 . Begreppet fri programvara och den underliggande ideologi som ligger till grund för organisationen Free Software Foundation65 har haft stor betydelse för framväxten och användningen av de licenser som idag är vanliga för en stor mängd betydelsefull fri och öppen programvara. Historiskt har det funnits en del spänningar mellan företrädare för fri respektive öppen programvara, där det finns flera starka personligheter som motiverats av delvis olika utgångspunkter och övertygelser för sina respektive ageranden. I praktiken är det dock så att nästan all programvara som idag erkänns som öppen programvara också är fri programvara och omvänt.

Ytterligare ett relaterat begrepp som ibland används är libre software, vilket framför allt används i länder där romanska språk talas, för att betona den avsedda betydelsen av ’free speech’ och därigenom uttrycka sig inkluderande om både öppen programvara och fri programvara66 . Begreppet libre software har sitt ursprung i en kommentar på en nyhetsgrupp av en spansktalande person som använde ordet libre67 i betydelsen ’frihet’ (på svenska) under en diskussion om en översättning av GPL-licensen68. På engelska förkortas ofta öppen programvara med OSS69 och fri programvara med FS70, men ibland används även förkortningen FOSS då intentionen är att uttrycka sig inkluderande och använda en term som inkluderar unionen av alla programvara som uppfyller (minst en) av kriterierna för öppen programvara eller fri programvara. Förkortningen FLOSS förekommer också då alla tre begreppen inkluderas71.

Nära förknippat med fri programvara är idén om att tillhandahålla programvara under villkor med copyleft72 (vilket har beskrivits som en lek med ord73 , copyleft istället för copyright). Idén med copyleft74 är centralt för utvecklingen av fri programvara som tillhandahålls under licensen GPL (GNU General Public License), vilket är en av fyra klassiska licenser som erkänts som licenser för öppen programvara75. Denna licens och dess copylefteffekt utvecklades utifrån de idéer som Richard Stallman lanserade genom etableringen av GNU-projektet. En licens som har en effekt av copyleft är utformad så att när programvara tillhandahålls under villkor med copyleft skyddas fortsatt öppenhet för programvaran. Betydelsen av den effekt som uppnås av GPL-licensens copyleft har, av flera bedömare76, uppfattats som en innovation inom området för licensiering av programvara.

Upphovsrättsskyddad programvara som tillhandahålls under villkor och licenser som inte uppfyller definitionen för öppen programvara refereras i denna rapport som sluten program-

Version: 1.0 9 (96) 20 maj 2020


vara. På svenska används även begreppet öppen källkod som synonym till öppen programvara77 . Då individer och organisationer utvecklar och tillhandahåller programvara som öppen programvara används upphovsrätten78, något förenklat uttryckt, omvänt för att ge användaren möjlighet att fritt använda, förbättra och vidaredistribuera programvaran (i flera led). Karakteristiskt för öppen programvara är att dess licenser innebär att programvaran kan användas utan att först behöva fråga om lov, men att licensen ställer krav på ett tillerkännande av dess upphovsrättsinnehavare79 och för vissa licenser, specifikt licenser av typen copyleft, även ställer krav på att distribution av öppen programvara skyddar fortsatt öppenhet genom krav på att distributionen måste ske under samma öppna licens.

Då en individ eller organisation kontrollerar all upphovsrätt för en öppen programvara finns möjlighet för upphovsrättsinnehavaren att byta licens på programvaran och tillhandahålla nya versioner av programvaran under andra villkor, däribland under någon annan licens för öppen programvara men även under någon annan licens som sluten programvara. Under förutsättning att en öppen programvara tillhandahålls under vissa licenser, specifikt licenser av typen permissive, kan en användare även stänga en öppen programvara och använda samt vidaredistribuera programvaran som del av en sluten programvara.

I Sverige och flertalet andra jurisdiktioner gäller upphovsrätt80 för all programvara, för såväl öppen som sluten programvara, från tidpunkten då verket skapas och under hela tidsperioden fram till 70 år efter upphovsrättsinnehavarens död. Den (eller de) som innehar upphovsrätten för en programvara har möjlighet att välja under vilka villkor programvaran ska tillhandahållas, däribland kan upphovsrättsinnehavaren välja att tillhandahålla programvaran under (en eller flera) licenser för öppen programvara. Upphovsrättsinnehavaren har även rätt att byta licens och tillhandahålla nya versioner av programvaran under (en eller flera) andra licenser, däribland under licenser för såväl öppen som sluten programvara. I vissa länder, exempelvis USA, kan en utvecklare av programvara välja att avsäga sig upphovsrätten till utvecklad programvara och istället tillhandahålla denna som s.k. public domain vilket inte uppfyller definitionen för öppen programvara81. Däremot är det i Sverige (och flertalet andra Europeiska länder) inte möjligt att avsäga sig upphovsrätten. Öppen programvara är skyddad av upphovsrätt, medan programvara som i USA tillhandahålls som s.k. public domain inte är det. Programvara under public domain är inte öppen programvara82. Eftersom rättsläget är oklart för public domain i många jurisdiktioner undviker många organisationer och program-varuprojekt att använda denna typ av programvara.

Begreppet proprietär programvara, som kan ge associationer till kontroll och ägande83 , används i andra sammanhang i en betydelse som är snarlik denna rapports användning av begreppet sluten programvara. Men då upphovsrättsinnehavaren har viss kontroll på all programvara betonas istället effekten av hur upphovsrätten används genom att använda de två begreppen öppen programvara och sluten programvara som varandras motsatser. Denna användning av begreppet sluten programvara är i linje med tidigare forskning84 .

Sammanfattningsvis utgörs öppen programvara av all upphovsrättsskyddad programvara som uppfyller definitionen för öppen programvara85 , medan sluten programvara utgörs av all annan upphovsrättsskyddad programvara som inte uppfyller definitionen för öppen programvara. Därutöver finns programvara som i vissa jurisdiktioner, exempelvis USA, tillhandahålls utan upphovsrättsskydd som s.k. public domain.

Version: 1.0 10 (96) 20 maj 2020


2.3. Öppen programvara och dess evolution

Evolutionen av öppen programvara har en historia som går tillbaka långt innan begreppet Open Source Software först myntades86. Det finns en lång tradition av att fritt dela källkoden för programvara som utvecklats inom olika organisationer87. Denna tradition var utmärkande för den tidiga utvecklingen av programvara och teknologier för internet som bedrevs inom akademi och forskningslabb och där den tidiga utvecklingen av operativsystemet Unix utgör ett illustrativt exempel88.

Den 27 september 1983 kommunicerade Richard Stallman sin plan på att utveckla ett komplett programvarusystem (kallat GNU) via en artikel som publicerades på en nyhetsgrupp på Usenet89 . Stallmans initiala idé var att utveckla GNU så att det skulle bli kompatibelt med operativsystemet UNIX som vid tidpunkten hade många användare. Tanken vara att GNU skulle innehålla en operativsystemskärna och alla nödvändiga systemprogram så att program utvecklade för UNIX skulle kunna användas på ett komplett GNU-system.

Den plan som ursprungligen kommunicerades ledde inte till detta, men väl till utvecklingen av GPL-licensen och tillblivelsen av organisationen Free Software Foundation som före-språkar fri programvara90. Detaljer om Stallmans ursprungliga kommunikation och hur de ursprungliga idéer som kommunicerades utvecklade sig har senare återpublicerats på GNU-projektets webbplats91.

Mångtydigheten i begreppet ’fri’ på engelska var det huvudsakliga skälet till att en grupp inflytelserika utvecklare introducerade ett nytt begrepp för att undvika missförstånd avseende vad som avses med fri programvara och utifrån detta myntade begreppet Open Source Software92.

Organisationen Open Source Initiative etablerades 1998 och samma år lanserade organisationen sin webbplats93. Definitionen av öppen programvara har utgjort en viktig utgångspunkt94 för organisationens verksamhet95. Definitionen av öppen programvara, som har sin utgångspunkt i ett policydokument från programvaruprojektet Debian96 , preciserar ett antal rättigheter som en programvarulicens måste ge användaren för att programvara som tillhandahålls under licensen ska utgöra öppen programvara97. Metaforer som katedralen och basaren användes för att kommunicera tidiga idéer bakom öppen programvara98 . I januari 1999 tillkännagav Open Source Initiative att de söker kvalificerade personer till organisationens styrelse99. Genom åren har organisationen granskat förslag på nya licenser och versioner av tidigare erkända licenser för öppen programvara. Successivt har organisationen publicerat information om de licenser för öppen programvara som erkänts av organisationen. Exempelvis presenterades 12 erkända licenser för öppen programvara på den lista som publicerades på organisationens webbplats den 15 augusti 2000100 . Av dessa presenterades fyra licenser (GPL, LGPL, BSD och MIT) som de klassiska licenserna för öppen programvara101. Successivt har antalet erkända licenser utökats och idag har organisationen erkänt fler än 90 licenser för öppen programvara som presenteras på organisationens webbplats102.

Bland de licenser som den 15 augusti 2000 presenterades och erkändes103 som licenser för öppen programvara finns de fyra klassiska licenserna som fortfarande används av många programvaruprojekt, däribland GPL-licensen104 (version 2105 , publicerad i juni 1991), LGPL-licensen106 (version 2.1, publicerad i februari 1999), BSD-licensen107 (som efter att en företrädare för University of California den 22 juli 1999 beslöt att ta bort en av de

Version: 1.0 11 (96) 20 maj 2020


ursprungligen fyra klausulerna i licensen108 så att licensen efter detta istället totalt innehåller totalt 3 klausuler109 vilken senare har kommit att refereras som ”BSD 3-Clause”) och MIT-licensen110 (en licens vars ursprung111 går tillbaka till Athena-projektet som på 1980-talet bland annat utvecklade fönstersystemet X, vars version 6 tillhandahölls 1985 och vars version 11 tillhandahölls 1987, därav refereras MIT-licensen ibland också som X11-licensen, även om dagens MIT-licens som erkänns som öppen programvara har en annan utformning än de tidiga X-licenserna).

Redan innan begreppet öppen programvara etablerades fanns det företag som tillhandahöll kommersiell support för fri programvara. Exempelvis etablerades redan 1989 företaget Cygnos112 i USA, vars affärsidé var113 att tillhandahålla kommersiell support för fri program-vara med fokus på utvecklingsverktyg. Det var få företag som under början av 1990-talet fokuserade på fri programvara114 . I Sverige etablerades 1992 företaget Signum Support AB115

som sedan starten utvecklade produkter och konsultverksamhet inom fri programvara och operativsystemet Linux.

Utvecklingen av betydelsefull öppen programvara för webben drevs på genom att IBM träffade avtal med en grupp utvecklare, the Apache Group, i april 1998116 . Genom åren har ett stort antal olika nyttor med öppen programvara identifierats bland individer och organisa-tioner där licenser för öppen programvara spelar en central roll för flera av dessa. Exempelvis utvecklade Brian Behlendorf117 ett resonemang om olika nyttor med öppen programvara under en inbjuden presentation på en internationell konferens118 och uppmärksammade i samman-hanget bland annat licensens roll för att befria licenstagaren från ett antal skyldigheter gentemot licensgivaren av öppen programvara på ett sätt som skapar en relation av ömsesidig nytta snarare än ett beroende av upphovsrättsinnehavaren119 .

2.4. Öppen programvara och dess licenser

Programvaruprojekt kan tillhandahålla programvara under en lång rad olika villkor och licenser. Ett antal av dessa licenser uppfyller definitionen för öppen programvara och presenteras120 som licenser för öppen programvara av organisationen Open Source Initiative121 .

Bland flertalet ledande juridiska experter finns det konsensus om att licenser som används av många programvaruprojekt som tillhandahåller öppen programvara kan delas in i en av de två övergripande typerna: permissive och copyleft. Tabell 2 presenterar de fyra klassiska licenserna (GPL, LGPL, BSD och MIT) som användes innan MPL-licensen (version 1.1) tillhandahölls och ett antal andra licenser som den 15 augusti 2000 utgjorde erkända licenser för öppen programvara. För respektive licens presenteras de historiska länkarna till respektive licens (se första kolumnen i tabell 2) och dess kortnamn enligt SPDX122 med länkar till respektive licens så som Open Source Initiative (OSI) refererade dessa runt årsskiftet 2019/2020 (se andra kolumnen i tabell 2). Vissa av de licenser som OSI presenterade den 15 augusti 2000 har även långt senare presenterats som populära och rekommenderade licenser för nya programvaruprojekt och dessa är markerade med fet stil i tabell 2. Det ska noteras att ett antal licenser har ersatts av nya versioner och att vissa licenser i tabellen inte längre rekommenderas (se tredje kolumnen i tabell 2).

Version: 1.0 12 (96) 20 maj 2020


Licens för öppen programvara Kortnamn Kommentar

GNU General Public License (GPL)123 GPL-2.0124 GPL-2.0 publicerades i juni 1991.

GPL-3.0125 GPL-3.0 publicerades den 29 juni 2007.

GNU Library or ‘Lesser’ Public License (LGPL)126

LGPL-2.1127 LGPL-2.1 publicerades i februari 1999. LGPL-2.0 var aktuell när OSI etablerades men LGPL-2.0 rekommenderas inte längre128 av FSF.

LGPL-3.0129 LGPL-3.0 publicerades den 29 juni 2007.

BSD license130 BSD-3-Clause131 BSD-3-Clause publicerades den 22 juli 1999132 och var initialt refererad av OSI. BSD-2-Clause användes 29 april 1999133, men var initialt ej refererad av OSI.

MIT license (sometimes called the ‘X Consortium license’)134

MIT135 Licensen var publicerad när OSI etablerades.

Artistic license136 Artistic-1.0137 Artistic-1.0 har ersatts138 av Artistic-2.0139 .

Mozilla Public License (MPL)140 MPL-1.0141 MPL-1.0 har ersatts142 av MPL-1.1143, som båda har ersatts144 av MPL-2.0145 .

Qt Public License (QPL) QPL-1.0146

IBM Public License147 IPL-1.0148

MITRE Collaborative Virtual Workspace License (CVW License)149

Saknas. CVW-licensen är av OSI markerad som avvecklad150. MITRE rekommenderar ej och använder inte längre denna licens151 .

Ricoh Source Code Public License152 RSCPL153

Python license154 Python155 Licensen för Python 0.9.9 till 1.2156 har vidareutvecklats i flera versioner157 .

zlib/libpng license158 Zlib159

Tabell 2: Ett antal erkända licenser för öppen programvara

Utöver de populära licenser som markeras med fet stil i tabell 2 har även Apache 2.0160 och CDDL 1.0161 erkänts av OSI som licenser för öppen programvara och runt årsskiftet 2019/2020 ingick även Apache 2.0 bland de licenser som OSI presenterade som populära licenser. Även den numera inaktuella162 Apache 1.1163 har erkänts av OSI, däremot har Apache 1.0164 aldrig erkänts som en licens för öppen programvara.

Under början av 2000-talet har det publicerats och gjorts ett antal uttalanden om effekterna av att använda olika licenser för öppen programvara, speciellt GPL, från individer och organisationer som haft (och har) incitament att bevaka sina egna affärsintressen. Exempelvis har en ledande företrädare för sluten programvara karaktäriserat öppen programvara som ej tillgänglig för kommersiella företag165 .

En central utgångspunkt för copyleft som idé är att stärka tillväxten av öppen programvara så att en vidareutvecklad öppen programvara förblir en öppen programvara166 . Då individer och organisationer utvecklar och vidareutvecklar öppen programvara inom ett programvaruprojekt under en licens med copyleft uppnås effekten att den programvara som distribueras från projektet måste tillhandahållas som öppen programvara under samma licens. Genom copyleft uppstår en snöbollseffekt som leder till en ständigt ökande mängd öppen programvara allt

Version: 1.0 13 (96) 20 maj 2020


eftersom programvaruprojektet vidareutvecklas och ny programvara tillförs projektet under samma licens. Då en organisation engagerar sig med och bidrar till ett programvaruprojekt som tillhandahåller öppen programvara under en licens av typen copyleft bidrar organisa-tionen till att skydda fortsatt öppenhet för projektet, samtidigt som licensen också förhindrar att programvara från programvaruprojektet kan tillhandahållas som sluten programvara.

Det finns en hel del tidigare forskning som analyserat olika effekter av att använda licenser av typen copyleft för att utveckla och tillhandahålla öppen programvara167 . Figur 1 presenterar exempel på licenser för öppen programvara som kategoriserats utifrån typer av licenser som baseras på tidigare forskning168 . Bland licenser som innehåller en explicit patentlicensklausul återfinns exempelvis GPL 3.0169 och Apache 2.0170 , medan både BSD 3-Clause och GPL 2.0 saknar en explicit patentlicensklausul.

Figur 1: Exempel på olika typer av licenser för öppen programvara (baserat på tidigare forskning171)

Genom åren har olika programvaruprojekt tillhandahållit öppen programvara under ett antal olika licenser och även om det idag finns ett stort antal licenser för öppen programvara är det värt att notera att en överväldigande majoritet av alla etablerade programvaruprojekt med många intressenter tillhandahålls under ett litet antal licenser för öppen programvara.

Av ett antal orsaker har olika licensers popularitet förändrats över tid och genom åren har ett antal analyser genomförts för att mäta popularitet för olika licenser. I tabell 3 presenteras en översikt av vissa resultat från ett antal av de analyser som genomförts genom åren. Då ny programvara som tillhandahålls som öppen programvara hela tiden utvecklas och vidareutvecklas i olika programvaruprojekt kan det konstateras att den totala mängden programvara hela tiden ökar. Detta innebär att även om den procentuella andelen programvara som tillhandahålls under en viss licens exempelvis har minskat från ett år till ett annat behöver detta inte nödvändigtvis innebära att den totala mängden programvara under denna licens har minskat.

Relaterat översikten i tabell 3 är kan det vidare konstateras att öppen programvara från ett programvaruprojekt som tillhandahålls under en licens av typen copyleft behåller samma licens då programvaran distribueras för användning i andra organisationer. Detta till skillnad från öppen programvara som tillhandahålls under en licens av typen permissive som kan distribueras under en annan licens för användning i andra organisationer.

Version: 1.0 14 (96) 20 maj 2020


Licens (SPDX172)

Exempel på programvaruprojekt

Ett programvaruprojekt för att utveckla och tillhandahålla …

GPL-2.0 Linux kernel173 en operativsystemskärna174 .

GPL-2.0 MariaDB Server175 ett databashanteringssystem176 .

GPL-3.0 GIMP177 ett generellt bildbehandlingsprogram178 .

GPL-3.0 GNU Compiler Collection en programvarusvit av kompilatorer179 .

LGPL-2.1 FFMPEG180 en programvarusvit för kodning och avkodning av video och ljud181 .

LGPL-2.1 VLC MediaPlayer en mediaspelare182 .

LGPL-3.0 PeaZip en filhanterare och arkiveringsprogram183 .

LGPL-3.0 OpenNN ett programvarubibliotek som implementerar neuronnät184 .

AGPL-3.0 NextCloud en programvarusvit för distribuerad filhantering185 .

AGPL-3.0 Koha en programvara för administration av folkbibliotek186 .

BSD-2-Clause Nginx en webbserver187 .

BSD-3-Clause Contiki-NG188 ett operativsystem för sakernas internet (IoT)189 .

MIT X-Road190 en lösning för att möjliggöra interoperabilitet mellan organisationer på nationell och internationell nivå191 .

MIT Bouncy Castle ett kryptobibliotek192 .

Apache-2.0 Apache PDFBox193 ett Java-bibliotek för att kunna skapa och behandla PDF-filer194 .

Apache-2.0 OpenStack en molnplattform (IaaS)195 .

Tabell 3: Licenser för öppen programvara och exempel på projekt som använder respektive licens

För etablerade programvaruprojekt med många utvecklare som bidragit till öppen program-vara som används i många olika sammanhang är det ofta önskvärt att aldrig byta licens då det kan få en rad oönskade konsekvenser för projektets intressenter. För öppen programvara som fått stor spridning kan det i praktiken vara mycket svårt och i vissa fall till och med omöjligt196

för ett programvaruprojekt att byta licens. Endast om alla upphovsrättsinnehavare för ett programvaruprojekt är överens om att byta licens kan ett projekt byta licens, vilket i praktiken är omöjligt för många etablerade programvaruprojekt som har utvecklats under lång tid.

Den uppsättning licenser för öppen programvara som organisationer har att förhålla sig till har genom åren karaktäriserats på en rad olika sätt, där det är tydligt att det bland olika intressenter och forskare uttryckts vitt skilda uppfattningar avseende de effekter som följer av att använda specifika licenser i olika scenarier. Speciellt finns det betydande skillnader mellan olika kategorier av intressenter avseende huruvida de effekter som följer av att använda licenser med copyleft är lämpliga respektive olämpliga att använda i olika situationer och sammanhang. Forskning visar att beroende på vilken roll en viss intressent har i det större ekosystemet för programvara kan olika erfarenheter starkt ha präglat de uppfattningar som råder197.

Av vissa företrädare för telekomindustrin har exempelvis GPL-licensen karaktäriserats som riskfylld, med ord som att den kan ’förgifta’ utvecklingen genom effekten av copyleft198 . Andra studier som undersökt uppfattningar från små företag lyfter tvärtemot fram denna

Version: 1.0 15 (96) 20 maj 2020


licens som ett viktigt skydd för fortsatt öppenhet för de investeringar i form av tid som ett mindre företag gör genom att bidra till ett programvaruprojekt som tillhandahålls under GPL. Det finns även exempel på större IT-företag som föredrar GPL-licensen av kommersiella skäl199. Att öppen programvara som tillhandahålls under andra licenser (av typen permissive) kan stängas av intressenter som styr och kontrollerar upphovsrätten för programvaruprojektet har beskrivits som ett hinder som avskräcker intressenter från att engagera sig med programvaruprojektet som implementerar IT-standarder och att implementationer av IT-standarder som tillhandahålls under en licens från GPL-familjen därför föredras av konkurrensskäl av många intressenter eftersom det skyddar fortsatt öppenhet för redan gjorda investeringar200.

Ett stort antal programvaruprojekt som utvecklats under flera decennier används idag av många individer och organisationer som tillhandahåller öppen programvara under olika licenser, däribland GPL som används av Linux-projektet201 . Genom åren har ledande företrädare för flera organisationer uttryckts starka uppfattningar om olika (önskade och oönskade) effekter av användning av olika licenser för att utveckla och tillhandahålla öppen programvara. Exempelvis har effekten av att Linux-projektets användning av GPL-licensen karaktäriserats som ’cancer’202 av en ledande företrädare för ett globalt IT-företag under en intervju för Chicago Sun Times203.

2.5. Organisationer och intressenter för öppen programvara och dess projekt

Under 1980 och 1990-talet etablerades ett antal programvaruprojekt där individer och andra intressenter engagerade sig kring projektens mål, i många fall som informellt organiserade gemenskaper, för att utveckla och tillhandahålla öppen programvara. Styrning, organisering och engagemang med många programvaruprojekt som växte fram under 2000-talets första decennium kan, i många fall, karaktäriseras av idédrivna och löst sammanhållna gemenskaper som hålls samman av engagerade individer som, utifrån en heterogen mängd olika (altruis-tiska, idealistiska och kommersiella) utgångspunkter och drivkrafter, utvecklar och till-handahåller öppen programvara. Denna typ av projekt refereras ibland som communitydrivna projekt. Det finns omfattande forskning som analyserat drivkrafter och organisation av communities utifrån olika utgångspunkter och studier som visar att det är en heterogen samling motiv som ligger till grund för olika intressenters engagemang med olika projekt204.

Successivt, då allt fler kommersiella aktörer engagerat sig i utveckling av öppen programvara har det vuxit fram nya former för att organisera och ge stöd till utveckling av olika programvaruprojekt. Ett antal olika stiftelser och andra typer av ’neutrala’ organisationer har etablerats med syfte att ge olika former av stöd till olika programvaruprojekt så att projekten kan fokusera på den tekniska utvecklingen av öppen programvara.

Därutöver har ett antal kommersiella aktörer tagit initiativ för att driva utveckling och förvaltning av programvaruprojekt som tillhandahåller öppen programvara. Ett antal program-varuprojekt av denna typ, där en enskild kommersiell aktör dominerar och styr utvecklingen av öppen programvara, har fått stor spridning.

Ett stort antal programvaruprojekt bedriver utveckling inom ramen för olika stiftelser som etablerats för att ge stöd till en god förvaltning av olika projekt. Viktiga utgångspunkter och motiv till varför flera programvaruprojekt förvaltas inom ramen för en stiftelse inkluderar behov av att etablera en, i förhållande till olika kommersiella aktörer, mer neutral organisation

Version: 1.0 16 (96) 20 maj 2020


som kan erbjuda olika former av administrativt och juridiskt stöd till den tekniska utvecklingen som bedrivs inom ramen för specifika projekt.

Stiftelsen Linux Foundation (LF) etablerades den 22 januari 2007 för att främja utvecklingen kring Linux genom en sammanslagning205 av de två icke-kommersiella konsortierna Open Source Development Labs (OSDL) som etablerades 2000 och Free Standards Group (FSG) som etablerades 1998. Båda organisationerna var, med lite olika fokus, engagerade med att driva på utvecklingen kring Linux där OSDL etablerades206 för att ge stöd till utvecklingen av viktiga projekt medan FSG etablerades207 utifrån en vision om ett standardiserat och portabelt Linux som undviker fragmentering av utvecklingen208 . Stiftelsen har ett omfattande stöd från många företag och utöver Linux tillhandahålls stöd till ett stort antal programvaruprojekt som tillhandahåller inflytelserik öppen programvara209 .

Stiftelsen Apache Software Foundation (ASF) etablerades den 30 juni 1999210 för att ge stöd till ett antal programvaruprojekt som initierats av The Apache Group211 . Redan 1996 etableras Apache HTTP Server Project212 och vid tidpunkten för etableringen av ASF hade ytterligare fem programvaruprojekt etablerats. Namnet Apache, A PAtCHy server, har sitt ursprung i det faktum att existerande programkod (NCSA httpd 1.3) vidareutvecklades213 . Genom åren har ett stort antal programvaruprojekt etablerats som förvaltas inom ramen för ASF214. Under början av 2020 har 7000 utvecklare bidragit till över 350 programvaruprojekt inom ramen för ASF215 .

Den öppna plattformen eclipse.org etablerades i november 2001216 genom ett initiativ av IBM och ett antal andra organisationer som tillhandahåller utvecklingsverktyg som utifrån detta inledde en öppen samverkan217 . I januari 2004 etablerades stiftelsen Eclipse Foundation218 . En undersökning som presenteras i juni 2011 rapporterar hur individer och organisationer är engagerade med Eclipse och visar att nästan 1000 utvecklare bidrar till över 200 program-varuprojekt219 . Undersökningen visar att drygt 170 företag var engagerade med Eclipse. Under början av 2020 finns drygt 375 projekt och drygt 300 organisationer var engagerade inom Eclipse Foundation220 . Drygt 1600 utvecklare har bidragit till projekten och stiftelsen har etablerat 14 olika industrial working groups som fokuserar på utveckling inom olika områden221 .

Den 23 januari 1998 tillkännagav företaget Netscape Communications att källkoden till programvaran Netscape Communicator ska släppas fri222 och att organisationen mozilla.org etableras223. Utifrån detta lanseras visionen för mozilla.org224. Stiftelsen Mozilla Foundation etablerades 2003225 utifrån en vision om ett öppet Internet och en öppen webb. Stiftelsen engagerar ett stort antal frivilliga och det helägda bolaget Mozilla Corporation har genom åren bidragit till ett antal viktiga projekt, där webbläsaren Firefox utgör ett välkänt exempel.

Dessutom finns ett stort antal stiftelser som organiserar olika programvaruprojekt och initiativ som driver på utvecklingen av öppen programvara. Bland stiftelser och andra typer av icke-kommersiella organisationer organiseras välkända programvaruprojekt som tillhandahåller öppen programvara, där exempelvis följande kan nämnas: Document Foundation226

(etablerad kring kontorssviten LibreOffice), GNOME Foundation227 (etablerad kring plattformen GNOME), KDE Free Qt Foundation228 (etablerad kring KDE projektet), MariaDB Foundation229 (etablerad kring databashanteringssystemet MariaDB), Open Source Geospatial Foundation230 (etablerad kring projekt inom GIS-området), Open Stack Foundation231 (etablerad kring molnplattformen OpenStack), Perl Foundation232 (etablerad kring programmeringsspråket Perl), Python Software Foundation233 (etablerad kring

Version: 1.0 17 (96) 20 maj 2020

https://mozilla.org

https://eclipse.org


programmeringsspråket Python), VideoLAN234 (etablerad kring mediaspelaren VLC och relaterade projekt), Xiph.Org Foundation235 (etablering kring initiativ för att skapa öppna multimediaformat och öppna programvaruprojekt). Flera av dessa organisationer rymmer engagerade individer, företag och andra typer av organisationer.

Därutöver finns ett stort antal organisationer som ger olika typer av stöd, som exempelvis organisationen Open Innovation Network236 som etablerat en defensiv patentpool för att skydda Linuxsystemet från juridiska hot.

Version: 1.0 18 (96) 20 maj 2020

https://Xiph.Org


3. Programvara för en hållbar digitalisering

3.1. Översikt

Baserat på en analys genomförd i tidigare forskning237 presenteras (i Figur 2) en konceptuell modell av hur samverkan kring viss specifik teknologi, över tid, upphör att vara unik och ge unika konkurrensfördelar för enskilda företag, till att blir allmänt använda och fortsatt vara viktiga för många företag i en bransch och successivt därefter bli allmänt tillgängliga. Över tid förändras således förutsättningarna för företag och andra organisationer att samverka kring teknologi och programvaruprojekt, vilket innebär en successiv förflyttning nedåt och åt höger i figuren för en specifik teknologi och ett specifikt programvaruprojekt.

Figur 2: En konceptualisering av teknologins livscykel

Konceptualiseringen i Figur 2 ska betraktas kontextuellt utifrån specifika förutsättningar som specifika organisationer har i sitt förhållande till en viss teknologi. Exempelvis kan ett företag befinna sig på den mellersta nivån, medan ett annat företag kan befinna sig på den nivå som finns längst ned i figuren, för ett och samma programvaruprojekt beroende på de olika företagens specifika verksamhet.

Även om en myndighet inte drivs av kommersiella mål är det viktigt att beakta och förstå de underliggande incitament som ger förutsättningar för olika individers och organisationers agerande. Exempelvis kan det ha en avgörande betydelse för vilka anbud som en myndighet får från potentiella anbudsgivare i en offentlig upphandling om det som ska upphandlas finns långt upp eller långt ned i Figur 2 för olika potentiella anbudsgivare.

Version: 1.0 19 (96) 20 maj 2020


Även om det finns avgörande skillnader mellan förutsättningarna för myndigheters och företags verksamheter, där företag exempelvis har kommersiella drivkrafter, är det för en myndighet viktigt att vara medveten om incitament för olika aktörer att vara engagerade med specifika programvaruprojekt inför beslut avseende hur en myndighet väljer att agera i förhållande till specifika programvaruprojekt.

3.2. Förutsättningar och utmaningar för en hållbar digitalisering

Inom offentlig sektor har det genom åren tagits många initiativ som vuxit fram utifrån en rad olika motiv, där vikten av innovativa och kostnadseffektiva organisationer i flera fall betonats utifrån ett behov av att upprätthålla medborgares tillit till en god förvaltning. Redan under tidigt 2000-tal identifierades flera initiativ, som på olika sätt relaterar användning och engagemang med öppen programvara i olika länder.

Under det estländska ordförandeskapet inom EU under hösten 2017 betonade minister-deklarationen betydelsen av att använda öppen programvara och öppna standarder vid utveckling och vidareutveckling av IKT-system för att undvika inlåsningseffekter238.

I enskilda länder har det exempelvis tagits politiska beslut för att höja kompetensen kring öppen programvara239 och det har fattats beslut om att offentliga organisationer ska använda öppna standarder och öppen programvara240 , där de strategiska initiativen som tagits av regeringen i Nederländerna är ett välkänt tidigt exempel241 inom EU.

Under senare år har begrepp som digital suveränitet och datasuveränitet lyfts fram som väsentliga utgångspunkter för den pågående digitaliseringen av offentlig sektor, såväl internationellt242 som av en myndighet i Sverige243 . Exempelvis har den svenska regeringen under 2019 initierat en utredning244 om säker och kostnadseffektiv it-drift för den offentliga förvaltningen som bland annat ska analysera hur it-upphandling kan ’medföra ovälkomna och långdragna konsekvenser i form av inlåsningseffekter, leverantörsberoende, oförutsedda kostnader och obalanserade avtalsvillkor’.

En innovativ och hållbar digitalisering av offentlig sektor möjliggörs av digital suveränitet och datasuveränitet, vilket förutsätter att myndigheter har kontroll på de digitala artefakter som upprättas och förvaltas med hjälp av de system och den programvara som används. Forskning visar att många svenska myndigheter använder strategier och genomför projekt på olämpliga sätt som leder till olika former av problematiska inlåsningseffekter245 som ger oönskade tekniska, juridiska, ekonomiska och samhälleliga konsekvenser. Oönskade inlåsningseffekter och standarder som tillhandahålls under FRAND-villkor246 skapar hinder för en hållbar digitalisering247 . Det finns flera studier som visar att användning av slutna standarder och slutna filformat hindrar en god långsiktig förvaltning av digitala artefakter som även skapar hinder för interoperabilitet248. För att möjliggöra interoperabilitet har exempelvis en organisation som utvecklar standarder för internet (IETF) för länge sedan etablerat en process där det ställs krav på interoperabilitet mellan olika (oberoende) programvaror som implementerar tekniska specifikationer för nya förslag på standarder249 .

Genom åren har juridiska utmaningar och tvister blivit ett växande problem för många organisationer som arbetar med programvara och digitalisering. Såväl stora som små organisationer behöver lägga allt större resurser på att hantera juridiska tvister och under senaste åren har flera uppmärksammade rättsfall som relaterar programvara och standarder250

behandlats och diskuterats i olika länder. För de många småföretag som arbetar med

Version: 1.0 20 (96) 20 maj 2020


programvara och digitalisering kan aktiviteter från företrädare för organisationer som innehar patent251 som belastar252 standarder och patent (speciellt aktiviteter från aktörer253 som har som affärsidé att tillhandahålla patentlicenser) leda till juridiska tvister som skapar betydande hinder för vidare utveckling av programvara. Även för stora företag kan denna typ av juridiska oklarheter och tvister skapa betydande problem för en hållbar digitalisering. Bland forskare och företrädare för många organisationer som arbetar med digitaliseringsprojekt finns idag en utbredd uppfattning att juridiska tvister relaterat patent som belastar standarder och programvara idag är ett betydande problem. Under en diskussion bland experter inom området framkom exempelvis uppgifter om att globala IT-företag idag behöver spendera mer resurser på tvister än vad de spenderar på forskning och utveckling254 .

Flera statliga utredningar presenterar, medvetet eller omedvetet, argument och förslag som – vid eventuellt genomförande – i grunden påverkar förutsättningarna för en hållbar digitalisering och därigenom också en enskild myndighets möjlighet att långsiktigt upprätthålla förutsättningar för en lämplig behandling och förvaltning av myndighetens egna digitala artefakter.

Exempelvis redovisar Digitaliseringsrättsutredningen att myndigheters användning av programvara som tjänst kan innebära att en myndighet blir bunden av otydliga och olämpliga avtalsvillkor i komplicerade it-avtal som är ’mer komplicerade än tjänsterna ifråga’255. Vidare identifierar utredningen risker för inlåsning256 och uppmärksammar risker som en myndighet utsätts för då myndigheten saknar tillgång till alla avtalsvillkor som relaterar användning av en specifik programvara som tjänst som tillhandahålls av en extern leverantör257 . Däremot saknar utredningen en analys av flera, mycket problematiska, former av inlåsningseffekter som relaterar användning av programvara som tjänst för att förvalta en myndighets handlingar. Det förefaller som utredningen underskattar de risker som en myndighet exponeras för relaterat möjligheten till långsiktig förvaltning och återanvändning av uppgifter i de handlingar som myndigheten upprättar och behandlar med hjälp av en specifik programvara som tjänst258 . För en myndighet är det centralt att kunna återanvända uppgifter i upprättade handlingar även efter en tidpunkt då myndigheten avslutat användningen av en specifik tjänst. För en myndighet kan det i flera scenarion vara mycket olämpligt, oavsett hur avtalsvillkoren i det aktuella it-avtalet har utformats, att agera utifrån en föreställning om att den egna myndigheten kommer att få stöd av den leverantör som är på väg att förlora en kund259 . Detta blir, självklart, än mer problematiskt i en situation då leverantören inte längre finns kvar på marknaden. I händelse av att myndigheten dessutom saknar tillgång till alla versioner av den kompletta källkoden för den programvara som leverantören tidigare har tillhandahållit som tjänst för driften innebär detta att myndigheten, i värsta fall, kommer att förlora tillgång till sin egen information.

Vidare har en annan utredning presenterat generella argument som hävdar att standardiser-ing260 bidrar till interoperabilitet, men utan att redovisa några detaljer om de utmaningar som är förknippade med detta. Ett stort antal utredningar har identifierat och betonat betydelsen av standarder, exempelvis med en betoning på internationella standarder, gemensamma standarder261, förvaltningsgemensamma standarder262, väletablerade standarder263 , men i flera fall används begreppen utan att precisera vad som avses.

I några fall har dock utredningar, som exempelvis slutbetänkandet från E-delegationen264 , betonat vikten av att myndigheter använder och ställer krav på användning av öppna standarder vilket skapar förutsättningar för att myndigheter kan medverka till etablering och

Version: 1.0 21 (96) 20 maj 2020


upprätthållande av en hållbar digitalisering. Som ett (av flera) mål i den nationella upphandlingsstrategin presenteras vikten av ’en mångfald av leverantörer och en väl fungerande konkurrens’. För att uppnå detta mål rekommenderas en myndighet ’att i möjligaste mån använda sig av öppna standarder’ även om strategin samtidigt också hänvisar till internationella standarder utifrån, vad som förefaller vara, en föreställning om att alla internationella standarder gynnar konkurrensen265. Tidigare forskning visar att det finns internationella standarder som också är slutna standarder och denna typ av standarder har effekten av att skapa konkurrenshinder och hindra implementation i öppen programvara genom att myndigheten saknar möjlighet att anskaffa alla nödvändiga rättigheter för att kunna använda slutna standarder266 .

Att statsförvaltningen ’i hög grad är inlåst till vissa leverantörer och att öppna standarder inte är en prioriterad fråga’ lyfts också fram av utredningen om en gemensam statlig molntjänst267, som även redovisar att det, alternativt, för statsförvaltningen ’i det närmaste [är] omöjligt att dra nytta av öppna standarder p.g.a. inlåsningen till vissa leverantörer’. Vidare lyfter utred-ningen fram den breda acceptans som finns för visionen om att de molntjänster som tillhanda-hålls till myndigheter ska baseras på öppen programvara och öppna standarder268.

Regeringens strategi för standardisering använder dock begreppet öppna standarder269 utan att precisera vad som avses. Det framgår dock av sammanhanget att strategin använder begreppet öppna standarder i en betydelse som inkluderar patentbelastade slutna standarder som tillhandahålls under FRAND-villkor270. Strategin förordar och förefaller vara baserad på en föreställning om att standarder som tillhandahålls under FRAND-villkor kan utgöra någon form av lösning inom digitaliseringsområdet271 . Detta trots att många intressenter redovisat juridisk osäkerhet avseende FRAND-villkor272 och resultat från tidigare publicerad forskning som visar att patentbelastade IT-standarder som tillhandahålls under FRAND-villkor skapar hinder för konkurrens genom att potentiella anbudsgivare i en offentlig upphandling, i praktiken, exkluderas från att kunna lämna anbud273. Denna forskning visar vidare att denna typ av patentbelastade standarder hindrar användning av öppen programvara274 .

3.3. Politiska initiativ relaterat öppen programvara i Sverige

Genom åren har olika företrädare för flera regeringar och politiska partier givit uttryck för ett flertal initiativ som behandlat öppen programvara och dess roll inom offentlig sektor i Sverige.

Exempelvis ger regeringens proposition (Prop. 2004/05:175) uttryck för bedömningen att användningen av öppen programvara bör främjas och att utvecklingen inom området löpande bör följas upp, med följande formulering275:

’Regeringens bedömning: Användningen av öppna standarder och öppna programvaror bör främjas och utvecklingen på området för öppna programvaror och öppen källkod bör löpande följas upp. Myndigheternas användningsområden för sådana produkter bör utvärderas. För- och nackdelar för offentlig förvaltning med att använda öppna programvaror samt lämpliga handlingslinjer för Sverige inför arbetet inom EU angående användning av öppna programvaror bör utredas.’

Version: 1.0 22 (96) 20 maj 2020


Samma proposition uppmärksammar specifikt276 att offentliga organisationers användning av öppen programvara, i kombination med öppna standarder, möjliggör interoperabilitet och stimulerar konkurrensen inom området:

’Användningen av öppna programvaror och öppna standarder ökar möjligheterna att integrera olika datasystem med varandra. Möjligheten att underlätta integrering av nya system genom att använda öppna standarder bör vara av intresse för den offentliga sektorn överlag. En ökad användning av öppna programvaror och öppna standarder bör därför också främja konkurrensen på programvaruområdet.’

Vidare betonar samma proposition277 att öppna programvaror och öppna standarder är en förutsättning för offentliga organisationers möjlighet att upprätthålla en god förvaltning av ärenden i scenarios där det ställs krav på långa livscykler för de digitala handlingar som upprättas, förvaltas och arkiveras inom olika offentliga organisationer:

’Ett ytterligare argument för användning av öppna programvaror är att arkivering, som i princip skall kunna ske för all framtid, fordrar öppna programvaror och öppna standarder för att kunna genomföras i praktiken. Därigenom kan öppna programvaror och öppna standarder bli viktiga för att kunna genomföra elektronisk ärendehantering fullt ut i förvaltningarna.’

Regeringens direktiv till E-delegationen278 (Dir. 2009:19) betonade vikten av att använda öppna standarder och öppen programvara på följande sätt:

’Den offentliga förvaltningens e-tjänster bör i så stor utsträckning som möjligt bygga på öppna standarder samt använda sig av programvara som bygger på öppen källkod och lösningar som stegvis frigör förvaltningen från beroendet av enskilda plattformar och lösningar.’

Utifrån detta direktiv presenterade E-delegationen, i sin första publikation (SOU 2009:86), en konkurrensneutral definition av begreppet öppen standard279 som innebär att standarder som uppfyller denna definition280 kan implementeras i såväl sluten som öppen programvara. Därutöver har E-delegationen också preciserat följande krav281 på att förvaltnings-gemensamma specifikationer ska bygga på öppna standarder för att möjliggöra användning av öppen programvara:

’De förvaltningsgemensamma specifikationer som tas fram ska vara grunden för olika delar av förvaltningens upphandlingar av e-tjänster för arkiv och diarium, likväl som att ligga till grund för internt utvecklade och driftade tjänster. Specifikationerna ska bygga på öppna standards och också ge utrymme för tillämpningar av öppen källkod, allt för att skapa ökad innovation inom området och säkra att de olika systemlösningarna är förvaltningsbara under hela livscykeln.’

Regeringens strategi för en digitalt samverkande statsförvaltning betonar betydelsen av öppna standarder som möjliggör användning av programvara som undviker oönskade beroenden av enskilda tekniker och lösningar vid utveckling av digitala tjänster. Även om strategin saknar en explicit hänvisning till öppen programvara är det uppenbart att denna typ av programvara möjliggör utveckling av återanvändbara lösningar som kan undvika inlåsning282:

’Digitala tjänster bör i så stor utsträckning som möjligt bygga på öppna standarder och använda programvara som frigör statsförvaltningen från beroendet av enskilda tekniker och lösningar.’

Version: 1.0 23 (96) 20 maj 2020


Regeringens skrivelse till Riksdagen (Skr. 2017/18:47) lyfter fram betydelsen av att proaktivt använda offentlig upphandling och vikten av ’medveten användning’ av lösningar i öppen programvara som verktyg för att främja utveckling och digitalt drivna innovationer283:

’Offentlig upphandling bör i större utsträckning användas som ett proaktivt verktyg för att främja utveckling och användning digitalt drivna innovationer. Innovations-upphandling och innovationspartnerskap är i sammanhanget viktiga verktyg liksom medveten användning av lösningar i öppen källkod, standarder och testbäddar.’

Betydelsen av öppen programvara betonas också i regeringens strategi för standardisering som antogs i juli 2018. Strategin betonar att regeringen ’ska verka för’ att myndigheter vid upphandlingar ska hänvisa till it-standarder som bygger på öppen programvara284. Av strategin framgår dock inte exakt vad som avses. En möjlig tolkning är att myndigheter, i de upphandlingar som genomförs, i ökad utsträckning ska referera it-standarder som är implementerade285 i öppen programvara (d.v.s. att det för en teknisk specifikation av en it-standard existerar en implementation i öppen programvara). En annan möjlig tolkning är att myndigheter, i de upphandlingar som genomförs, i ökad utsträckning ska referera till it-standarder som har utvecklats genom ett programvaruprojekt286 som tillhandahåller öppen programvara (d.v.s. där en implementation driver utvecklingen av en teknisk specifikation av standarden).

Regeringens direktiv till en pågående utredning om säker och kostnadseffektiv it-drift i den offentliga förvaltningen (Dir. 2019:64) betonar vikten av en väl genomförd offentlig upphandling som en nyckelfaktor för att en myndighet ska kunna genomföra en lyckad anskaffning av it-drift och pekar samtidigt på risker för inlåsning och oönskade leverantörs-beroenden som kan bli följden av en ’icke-strategisk’ upphandling:

’Rätt använt är offentlig upphandling och avtalsförvaltning nyckelfaktorer som ger en myndighet goda förutsättningar att ta del av marknadens it-driftstjänster på ett kostnadseffektivt och juridiskt hållbart sätt (se t.ex. Nationella upphandlings-strategin). På motsatt sätt kan tex. en icke strategisk upphandling av it-drift medföra ovälkomna och långdragna konsekvenser i form av inlåsningseffekter, leverantörs-beroende, oförutsedda kostnader och obalanserade avtalsvillkor.’

Direktivet till denna utredning förefaller vara baserat på en föreställning om att en myndighets utkontraktering av it-drift – i enlighet med gällande regelverk – i praktiken kan föregås av en strategiskt genomförd upphandling som undviker oönskade inlåsningseffekter, något som baserat på analys av ett stort antal projekt genomförda inom ett stort antal myndigheter i praktiken visat sig vara ogenomförbart då en myndighet anskaffar programvara som tjänst287.

Regeringens direktiv till en annan pågående utredning om att etablera en förvaltnings-gemensam digital infrastruktur för informationsutbyte288 omfattar att myndigheterna ska åter-använda och utveckla byggblock för informationsutbyte mellan myndigheter. Genomförandet av utredningen innebär, rimligen, att myndigheterna ska etablera programvaruprojekt som utvecklar ett antal byggblock i vilka öppna standarder implementeras. Programvaruprojektet som utvecklar byggblocken etableras och publiceras (lämpligen på) en öppen plattform289 och där stabila versioner av utvecklade byggblock om möjligt tillhandahålls som öppen programvara290:

’Myndigheterna ska i så stor utsträckning som möjligt återanvända redan utvecklade nationella och EU-gemensamma byggblock för informationsutbyte, under förut-sättningar att de kan tillgodose den offentliga förvaltningens behov av ett säkert och

Version: 1.0 24 (96) 20 maj 2020


effektivt elektroniskt informationsutbyte. De byggblock som tas fram inom ramen för infrastrukturen ska i så stor utsträckning som möjligt bygga på öppna standarder och om möjligt använda programvara som frigör statsförvaltningen från beroendet av enskilda tekniska lösningar. Vidare ska framtagna byggblock i möjligaste mån publiceras som öppen källkod.’

3.4. Initiativ för öppen programvara inom offentlig sektor

Det finns ett stort antal internationella initiativ och exempel på policys och strategier som presenterats och införts inom offentlig sektor på olika nivåer i olika länder.

För att framgångsrikt kunna införa en policy för öppen programvara rekommenderar EU-studier att införandet genomförs med en förankring på gräsrotsnivå291. Detta kan uppnås genom att successivt försöka undanröja olika, formella och informella, hinder för anskaffning och upphandling av öppen programvara. Genom att ställa krav på interoperabilitet genom öppna standarder292, istället för kompatibilitet med dominerande sluten programvara293, ges möjlighet att anskaffa och använda öppen programvara.

Öppen programvara som tillhandahålls av programvaruprojekt utgör en allmännyttig resurs som individer och organisationer kan använda och vidareutveckla för nya innovativa syften utan traditionella juridiska hinder294 . Detta stimulerar innovation295 och återanvändning av olika komponenter (byggblock) av öppen programvara som kan ge betydande nyttor, exempelvis i form av ökad kostnadseffektivitet och möjlighet att undvika problematisk och kostnadsdrivande teknisk och juridisk inlåsning.

I Sverige har det genom åren tagits ett antal nationella initiativ, både från regering och regeringskansli, som på olika sätt påverkat förutsättningarna för användning och engagemang med öppen programvara inom offentlig sektor. Vidare har ett antal förslag presenterats från enskilda ledamöter i Sveriges Riksdag och dessa har, på olika sätt, berört kompetens och förutsättningar för användning och nyttjande av öppen programvara inom offentlig sektor. Tabell 4 presenterar ett antal motioner som relaterar öppen programvara som behandlats i Sveriges Riksdag.

Utöver DIGG:s policy finns det även tidigare exempel bland enskilda Svenska myndigheter som utvecklat egna riktlinjer som preciserar hur den egna myndigheten ska förhålla till användning av och engagemang med öppen programvara296. Därutöver har enskilda myndigheter tagit olika initiativ till mer informell samverkan som på olika sätt påverkar förutsättningarna för användning av öppen programvara, både bland stora IT-intensiva myndigheter (exempelvis arbetet inom eSam) och samverkan mellan enskilda kommuner (exempelvis nätverket Kivos och föreningen Sambruk).

Ett stort antal organisationer inom offentlig sektor har lång erfarenhet från anskaffning och utveckling av programvara som tillhandahålls under olika villkor. Under senare år har allt fler myndigheter valt att anskaffa programvara som tjänst, i många fall utan att först ha genomfört en gedigen analys av de avtalsvillkor myndigheten blir bundna av.

Version: 1.0 25 (96) 20 maj 2020


Motionär(er) Motion, datum Sammanfattning av förslag & motiv

Karl Sigfrid (m) 2008/09:Fi254 2 okt. 2008

Föreslår ’en övergång till öppen källkod inom den offentliga sektorn [och] att myndigheters egenproducerade kod börtillgängliggöras som öppen källkod. […] Öppen källkod bidrar även till tjänsteutveckling och bättre konkurrens.’

Lage Rahm, Jan Lindholm, Mehmet Kaplan, Per Bolund, Max Andersson (alla mp)

2009/10:K318, 2 okt. 2009

’statliga myndigheter och företag ska åläggas att upprätta handlingsplaner för en övergång till fri programvara.’

Lars Ohly, Marianne Berg, Jacob Johnson, Hans Linde, Elina Linna, Lena Olsson, Alice Åström, Ulla Andersson (alla v)

2009/10:Fi261 6 okt. 2009

’Vi skapar också ett nytt anslag för stöd till fri programvara med 10 miljoner kronor 2010 […] vi föreslår att en utredning tillsätts som sammanställer erfarenheter av att gå över till öppna standarder och fri programvara, och som utifrån detta lägger fram förslag till rekommendationer för myndigheter’

Thomas Östros (s), Sonia Karlsson (s), Monica Green (s), Hans Hoff (s), Agneta Gille (s), Tommy Ternemar (s), Jörgen Hellman (s), Christina Zedell (s), Mats Pertoft (mp), Ulla Andersson (v)

2009/10:Fi11 4 apr. 2010

’Vi ser exempelvis att Danmark, Nederländerna och Norge har börjat gå över till att använda fri programvara, dvs. program med öppen källkod, i statliga myndigheter. Det finns liknande exempel även i Sverige och vi föreslår att en utredning tillsätts som sammanställer erfarenheter av att gå över till öppna standarder och fri programvara och som utifrån detta lägger fram förslag till rekommendationer för myndigheter.’

Lena Hallengren (s), Désirée Liljevall (s), Peter Pedersen (v), Kent Persson (v), Karin Svensson Smith (mp), Per Bolund (mp)

2009/10:T6 21 apr. 2010

’För IT-användare är det väsentligt att programmen är möjliga att ta del av, använda och utveckla. Öppen mjukvara innebär att det står användaren fritt att ändra i mjukvaran, vilket gör att t.ex. statliga myndigheter och andra fritt kan anpassa den efter behov. Öppen standard är när det finns en enighet om att använda sig av samma teknikstandard. Vi anser att statliga myndigheter bör pröva möjligheten att i större utsträckning använda sig av öppen källkod.’

Ulrika Carlsson (c), Ola Johansson (c)

2010/11:T522 26 okt. 2010

Föreslår att ’ett nationellt kompetenscenter för öppen källkod och öppna standarder etableras.’

Monica Green (s) 2010/11:Fi249 25 okt. 2010

Föreslår att ’utveckla möjligheterna till öppna källkoder och fri programvara. […] I Norge har de etablerat ett kompetenscenter som heter Friprog. Sverige skulle ha stor nytta av att utveckla ett motsvarande center.’

Maria Ferm, Mehmet Kaplan, Jonas Eriksson, Agneta Börjesson, Bodil Ceballos, Tina Ehn, Annika Lillemets, Peter Rådberg, Mats Pertoft (alla mp)

2013/14:N441 2 okt. 2013

’När stat, kommun och landsting köper ny programvara bör det alltid övervägas om det kan utvecklas som öppen källkod. [… ] Öppna standarder är en viktig grund för innovation. Digitala bibliotek och andra institutioner som syftar till att göra information och handlingar tillgängliga för allmänheten bör använda öppna format och öppna standarder.’

Monica Green (s) 2013/14:Fi292 3 okt. 2013

Föreslår att ’utveckla möjligheterna till öppna källkoder och fri programvara. […] Öppna program och öppen standard är viktiga inslag för att effektivisera den offentliga förvaltningen’

Mattias Bäckström Johansson (sd)

2016/17:127 27 sep. 2016

Föreslår ’en övergång till öppen källkod och öppna standarder inom den offentliga sektorn’

Mattias Bäckström Johansson (sd)

2018/19:117 18 okt. 2018

Föreslår ’en övergång till öppen källkod och öppna standarder inom den offentliga sektorn’

Tabell 4: Motioner som relaterar öppen programvara

Version: 1.0 26 (96) 20 maj 2020


Studier av ett stort antal projekt som genomförts inom myndigheter i Sverige visar att det finns en problematisk praktik vid upphandling och utveckling av IT-system som skapar hinder för användning av öppen programvara. Genomförd analys av ett stort antal obligatoriska krav som olika myndigheter i Sverige formulerat i genomförda projekt visar att det finns en utbredd praktik inom offentlig sektor som, medvetet eller omedvetet, hindrar anskaffning och användning av öppen programvara297 . Forskningsresultat redovisar att för flera av de projekt som genomförts av svenska myndigheter visar analyser att många myndigheter är298

omedvetna om flera olika typer av problematisk inlåsning och att många myndigheter saknar strategier för att kunna förvalta sin egen information.

Det finns också flera exempel på att myndigheter under lång tid har anskaffat och använt öppen programvara inom sina respektive myndigheter. Redan 2004 rapporteras299 betydande kostnadseffektivitet utifrån anskaffning och införande av öppen programvara inom en svensk myndighet:

’Tidigare hade vi 140-150 servrar som kostade 140 miljoner kronor. Sedan jul kör vi lika många maskiner med Red Hats Linux och det kostar 4,5 miljoner kronor, säger Lars-Göran Berglund, IT-chef på PPM.’

Stockholms läns landsting var tidigt ute med att egenutveckla öppen programvara som tillhandahölls via en öppen plattform. Exempelvis offentliggjordes i maj 2005 att programmen WebCare och ListOn tillhandahölls under GPL300 och samma år publicerade Carelink301 även en rapport som redogör för möjligheterna med att utveckla och tillhandahålla öppen program-vara i samverkan mellan olika organisationer inom sektorn för vård- och omsorg302. Sedan den 1 januari 2008 ingår verksamheten inom Carelink i Sjukvårdsrådgivningen SVR AB303 och under 2010 framgick av uppgifter på Carelinks webbplats att verksamheten ’finns numera inom Inera AB’304.

På uppdrag av Näringsdepartementet presenterades i mars 2016 en utredning som redovisar en analys av hur öppen programvara används inom svensk statsförvaltning305 . Utredningen redovisar att öppen programvara ’dominerar’ i datacentermiljön och konstaterar att använd-ningen av ’öppen programvara inom offentlig sektor är mycket utbredd och ökar för varje år’.

EU har tagit initiativ till att under 2020 presentera en redovisning av svenska myndigheters användning av öppen programvara som en av flera rapporter från alla EU-länder306. Dessa översikter redovisar policys, lagstiftning och initiativ som på olika sätt ger förutsättningar för användning av öppen programvara307.

Version: 1.0 27 (96) 20 maj 2020


4. Policy, strategi och praktik för anskaffning & utveckling av programvara

4.1. Översikt

Det finns många sätt som en myndighet kan förhålla sig till och engagera sig med olika programvaruprojekt som utvecklar och förvaltar öppen programvara. Baserat på tidigare publicerad forskning308 presenteras en konceptuell modell (se Figur 3) som illustrerar olika typer av relationer mellan en myndighets interna arbete med programvara (längst ned i figuren) och ett programvaruprojekt som tillhandahåller öppen programvara på en öppen plattform (längst upp i figuren).

Figur 3: En modell för hur myndigheter kan engagera sig med öppen programvara

Totalt finns fem (principiella) relationer (markerade med 1-5 längs pilarna i Figur 3) som illustrerar förhållandet mellan en organisations interna arbete med programvara (blåmarkerad del av Figur 3) och arbete med öppen programvara som bedrivs i en öppen samverkan på en öppen plattform (gulmarkerad del av Figur 3). Modellen är inte begränsad till att enbart avse myndigheter (organisationen längst ned i figuren kan även avse utveckling som sker internt inom ett företag eller en annan typ av organisation).

Det ska noteras att en myndighet (eller annan typ av organisation som finns längst ned i figuren), i allmänhet, har relationer till ett mycket stort antal programvaruprojekt. När en myndighet anskaffar öppen programvara (exempelvis genom en offentlig upphandling) för användning inom sin egen organisation utgör detta ett exempel som illustrerar relation 2 i figuren.

Då en myndighet återanvänder komponenter (byggblock) av öppen programvara från redan etablerade programvaruprojekt (som finns på en öppen plattform) i sin egen interna utvecklingsprocess illustrerar detta ett exempel på relation 3 i figuren.

Version: 1.0 28 (96) 20 maj 2020


I situationer då en myndighet rapporterar brister i en öppen programvara eller lämnar bidrag till programvaruprojektet (på den öppna plattform) där utvecklingen bedrivs utgör detta ett exempel som illustrerar relation 4 i figuren. Om myndigheten, exempelvis, lämnar kommentarer utifrån egen användning av den anskaffade öppna programvaran på öppna forum som används av programvaruutvecklingsprojektet utgör detta ett exempel som illustrerar relation 4a, medan en process där en myndighet öppnar upp en redan existerande (sluten) programvara i syfte att etablera detta som ett programvaruprojekt på en öppen plattform utgör ett exempel som illustrerar relation 4b.

Då en myndighet tar ett strategiskt initiativ för att etablera ett nytt, eller engagerar sig med ett befintligt, programvaruprojekt som utvecklas och förvaltas på en öppen plattform utgör detta exempel som illustrerar relation 5 i figuren.

4.2. Ramavtal för upphandling av öppen programvara inom offentlig sektor

Bland myndigheter finns det en lång tradition av att anskaffa produkter och tjänster genom offentlig upphandling och i Sverige har myndigheter under lång tid haft möjlighet att upphandla öppen programvara genom avrop på olika ramavtal.

Redan 2002 presenterade Statskontoret en uppdragsbeskrivning som redovisade ett identifierat behov av att utreda möjligheten att etablera ett ramavtal för öppen programvara309. Detta motiverades av en identifierad brist på konkurrens på programvarumarknaden och pågående initiativ inom EU310 .

Under Statskontorets arbete med att etablera ett ramavtal som möjliggör upphandling av öppen programvara genomfördes en förstudie och specifika analyser. Exempelvis publicerade Statskontoret redan 2003 en rapport som redovisar en analys av stöd för interoperabilitet mellan olika ordbehandlingsprogram genom användning av ett XML-baserat filformat. Rapporten identifierar stora brister vid försök att utväxla dokument skapade i XML-baserade format och redovisar att användning av det slutna filformatet ”.doc” ger det minst bristfälliga stödet för interoperabilitet311 . Det kan noteras att kompatibilitet med ett slutet filformat utgjorde en utgångspunkt för analysen312.

Under perioden från den 23 november 2003 till den 22 november 2006 fanns det möjlighet för myndigheter att avropa öppen programvara från sex ramavtalsleverantörer på ramavtalet Programvaror och tjänster 2004 som etablerats av den ramavtalsansvariga myndigheten Statskontoret313. Svensk fackpress rapporterade i februari 2004 att Statskontoret fattat beslut314

om att öppen programvara ska kunna upphandlas på alla kommande ramavtal: ’Statskontoret har bestämt att öppen källkod ska finnas med som alternativ i alla framtida upphandlingar. Den nya policyn börjar gälla snarast. Därmed har öppen källkod chans till ett rejält genombrott i den offentliga sektorn.’

Den nya policyn började gälla315 med ramavtalen Programvaror och tjänster 2004: ’Linux och öppen källkod blir ett fullfjädrat alternativ när Statskontoret inom kort tar ett principbeslut om att alla framtida ramavtalsupphandlingar inom staten ska innehålla både öppna och etablerade alternativ.’

Den 1 januari 2006 etablerades en ny myndighet, Verva, som fick uppgiften att agera som en central förvaltningsmyndighet för en sammanhållen statlig förvaltning316. Myndighetens uppdrag inkluderade att arbeta för goda villkor för anskaffning och användning av IT inom

Version: 1.0 29 (96) 20 maj 2020


offentlig förvaltning samt ’beakta intresset av innovationer och teknikneutrala lösningar’317. Inom Vervas uppdrag låg att ta över Statskontorets roll för att etablera ett nytt ramavtal som ersätter det tidigare etablerade ramavtalet Programvaror och tjänster 2004 som ’upphör att gälla i slutet av 2006’318.

Från den 19 september 2007 fram till den 31 mars 2011319 fanns det möjlighet för myndigheter att avropa öppen programvara från fem ramavtalsleverantörer på ramavtalet Öppna programvaror och tjänster 2007 som etablerats av den, vid tidpunkten för etableringen, ramavtalsansvariga myndigheten Verva (Verket för förvaltningsutveckling)320 .

Den 19 juni 2006 redovisade Verva resultat från en analys av förutsättningar och pågående utveckling inom programvaruområdet där syftet var att identifiera behov inom offentlig sektor321. Analysen redovisar322 bland annat att försäljningen ’via ramavtalen på området öppen programvara har hitintills inte varit särskilt omfattande’ och att leverantörerna ’hävdar att marknaden fortfarande är relativt omogen inom detta område’.

Verva redovisade den 30 mars 2007 en analys av de rättsliga konsekvenserna av en ökad användning av öppen programvara. Analysen är utvecklad inom ramen för it-standardiserings-utredningen323 och förordar att en myndighet använder licenser för öppen programvara som har en effekt av copyleft för att därigenom möjliggöra återanvändning och säkerställa ’att det ursprungliga programmet och alla senare ändringar som distribueras kan utnyttjas enligt samma generösa licensvillkor’324 . Den 19 december 2008 presenterade Verva resultat från en genomförd enkätundersökning som analyserat myndigheters attityd till och användning av öppen programvara, där undersökningen visar att ’flera myndigheter efterfrågat en nationell policy som tydliggör regeringens viljeinriktning vad gäller användning av öppen programvara’325 . Utifrån undersökningen identifierar Verva att många myndigheter ser ett behov av stöd och det efterfrågas en ’klar viljeinriktning’ från regeringen326:

’Över en tredjedel av myndigheterna ser ett behov av stöd i anskaffning och användning av öppen programvara. Nästan alla dessa myndigheter har ett behov av stöd i form av erfarenhetsutbyte och närmare två tredjedelar önskar en vägledning. Närmare hälften av myndigheterna efterfrågar en nationell policy med en klar viljeinriktning från regeringen.’

Kammarkollegiet presenterade under våren 2010 en förstudie som analyserat behov av nya ramavtal inom området programvara, där analysen inkluderat dialog med leverantörer och kunder, som redovisar ett identifierat behov av att ramavtalen främjar öppen programvara327:

’Ramavtalen bör fortsättningsvis även främja öppen programvaras utveckling och nyttjande, detta i linje med E-delegationens betänkande.’

Den 28 januari 2011 fattade Kammarkollegiet beslut328 (Dnr. 93-36-10) om att tilldela ramavtal till fem leverantörer för ramavtalet Öppna programvaror 2010. Från den 1 april 2011329 till den 31 mars 2015330 fanns det möjlighet att avropa öppen programvara på detta ramavtal.

Kammarkollegiet presenterade den 5 februari 2014 förstudien Programvaror och tjänster 2013 som redovisar en analys av erfarenheter och identifierade framtida behov för nya ramavtal331 . Denna förstudie föreslår ’att Statens inköpscentral genomför fyra upphandlingar. Kontorsstöd, Informationsförsörjning, Grundläggande it samt Systemutveckling’. För att undvika diskriminering av öppen programvara i en upphandling betonas vikten av öppna standarder och utifrån detta rekommenderar förstudien att kommande ramavtal endast tillåter

Version: 1.0 30 (96) 20 maj 2020


att obligatoriska krav på standarder får referera till öppna standarder enligt den definition som finns i EU:s interoperabilitetsramverk version 1.0332 (EIF 1.0)333:

’Kommande upphandlingar bör, i likhet med den brittiska modellen framhålla vikten av öppna standarder för att hjälpa kunderna att skapa öppnare it-system och att uppfylla SOU 2009:86. Att ställa obligatoriska krav på standarder i sina avrop bör endast vara tillåtet om standarden uppfyller kraven på en öppen standard enligt SOU 2009:86. Med en öppen standard avses en standard som uppfyller de fyra kriterier som interoperabilitetsramverket EIF 1.0 anger.’

Under 2015 presenterade Kammarkollegiet ramavtalet Programvaror och tjänster 2014 som består av fyra ramavtalsområden: Systemutveckling, Kontorsstöd, Grundläggande IT och Informationsförsörjning. Ramavtalet inkluderar öppen programvara men omfattar även programvara som tillhandahålls under andra villkor, däribland sluten programvara och programvara som tillhandahålls som tjänst (SaaS).

Avropsreglerna för samtliga ramavtalsområden i ramavtalet Programvaror och tjänster 2014 föreskriver att obligatoriska krav334 på standarder endast får referera till öppna standarder enligt den definition som finns i EU:s interoperabilitetsramverk version 1.0335 (EIF 1.0)336. För att ge stöd till myndigheter och leverantörer som avser formulera obligatoriska krav på IT-standarder då ramavtalet används tar Kammarkollegiet initiativ till att utveckla en vägledning för öppna IT-standarder som uppfyller den konkurrensneutrala definitionen av öppen standard enligt EIF 1.0337. Initiala versioner av vägledningen publicerades under 2015 och den 7 mars 2016 publiceras såväl en svensk338 som en engelsk version339 av vägledningen för öppna IT-standarder utifrån ett stort internationellt intresse340 .

För ramavtalsområdet Systemutveckling341 tilldelades sju leverantörer ramavtal och från den 7 april 2015 till den 31 december 2018342 fanns det möjlighet att avropa öppen programvara inom detta ramavtalsområde. Detta omfattade programvaror och tjänster som används för systemutveckling och systemförvaltning. För ramavtalsområdet Kontorsstöd343 tilldelades sju leverantörer ramavtal och från den 6 maj 2015 till den 31 december 2018344 kunde öppen programvara avropas inom detta ramavtalsområde. Detta omfattade programvaror och tjänster som primärt ger stöd till användare vid offentlig sektor inom generella kontorsgöromål. För ramavtalsområdet Grundläggande IT345 tilldelades sex leverantörer ramavtal för och från den den 6 maj 2015 till den 31 december 2018346 kunde öppen programvara avropas inom detta ramavtalsområde. Detta omfattade primärt programvaror och tjänster som ger stöd till en it-avdelning avseende arbetet med drift, förvaltning, tillgångshantering och informations-säkerhet. För ramavtalsområdet Informationsförsörjning347 tilldelades sju leverantörer ramavtal och från den 10 november 2015 fanns möjlighet att avropa öppen programvara inom detta ramavtalsområde fram till348 den 30 november 2019349. Detta omfattade huvudsakliga kontaktstödjande-, verksamhetsstödjande- och infrastrukturella programvaror och tjänster.

Statens inköpscentral vid Kammarkollegiet presenterades den 9 juni 2017 en Förstudie-rapport inom Programvaror och tjänster som redovisar en analys genomförd för att ’samla information och kunskap om pågående utveckling inom området samt om vilka behov som myndigheterna har’350. Förstudien redovisar bland annat att inlåsningseffekter är ett utbredd problem för i princip alla myndigheter351:

’Inlåsningseffekter är ett problem för i princip alla myndigheter. Medvetenheten om inlåsningseffekter varierar precis som synen på hur allvarligt problemet är. Frågan

Version: 1.0 31 (96) 20 maj 2020


är inte bara kopplad till tekniska frågor utan i högsta grad även till kunskap och kostnader.’

Utifrån förstudien inleddes under hösten 2017 fem ramavtalsupphandlingar352 inom området Programvaror och tjänster för att ge myndigheter möjlighet att avropa programvara som tillhandahålls under olika villkor, däribland öppen programvara, sluten programvara samt programvara som tillhandahålls som tjänst (SaaS). Området programvaror och tjänster delades upp i följande fem ramavtalsområden: Systemutveckling, Informationsförsörjning, Vård Skola Omsorg, Licensförsörjning och Programvarulösningar. Under februari 2018 fattades tilldelningsbeslut, men då detta beslut överprövades ledde detta till en förlängning av tidigare ramavtal.

För ramavtalsområdet Systemutveckling tilldelades sex leverantörer ramavtal för perioden från den 8 maj 2019 till den 31 maj 2021 där området ’omfattar programvaror och tjänster som används för systemutveckling och systemförvaltning, exempelvis utvecklingsprojekt av kundanpassad programvara, förvaltning av kundanpassad programvara, app-utveckling, API-tjänster, PaaS och programvaror för systemutveckling’353 . För ramavtalsområdet Vård Skola Omsorg tilldelades sex leverantörer ramavtal för perioden från den 1 januari 2019 till den 1 januari 2021 där området omfattar ’programvaror och tjänster som primärt används inom sjukvård, tandvård, hälsovård, kommunal omsorg, förskola, grundskola, gymnasium, hög-skola och universitet’354 . För ramavtalsområdet Licensförsörjning tilldelades fem leverantörer ramavtal för perioden från den 18 februari 2019 till den 28 februari 2021 där området ’omfattar licenser, abonnemang och prenumeration av programvara och publika moln-tjänster’355. För ramavtalsområdet Programvarulösningar tilldelades sex leverantörer ram-avtal för perioden från den 18 februari 2019 till den 28 februari 2021 där området omfattar ’programvara, publik molntjänst och privat molntjänst som används när kunds behov täcker mer än ett av ramavtalen Licensförsörjning, Systemutveckling, Informationsförsörjning samt Vård Skola Omsorg’356 .

Efter att Kammarkollegiet den 4 oktober 2019 fattat tilldelningsbeslut meddelades den 15 oktober 2019 att ansökan om överprövning inkommit357 och för de tidigare ramavtalen inom ramavtalsområdet Informationsförsörjning som löpte ut den 30 november 2019 saknades den 17 april 2020 nya ramavtal inom detta ramavtalsområde358 .

Som för det tidigare ramavtalet Programvaror och tjänster 2014 föreskriver avropsreglerna samtliga fem ramavtalsområden (Systemutveckling, Informationsförsörjning, Vård Skola Omsorg, Licensförsörjning och Programvarulösningar) som utgör ramavtalen Programvaror och tjänster att obligatoriska krav359 på standarder endast får referera till öppna standarder enligt den definition som finns i EU:s interoperabilitetsramverk version 1.0360 (EIF 1.0)361 .

Avropsreglerna för ramavtalen Programvaror och tjänster preciserar för samtliga ramavtalsområden att en myndighet kan ställa krav på öppen programvara som enligt avropsreglernas allmänna villkor362 avser ’programvara som i sin helhet är licensierad med en eller flera licenser godkända av Open Source Initiative’. De allmänna villkoren reglerar dessutom följande avseende rättigheter mellan Ramavtalsleverantör och kund363:

’Ramavtalsleverantör garanterar att Kunds användning av och/eller förfogande av hela eller del av Kontraktsföremål i enlighet med Kontrakt inte gör intrång i tredje parts immateriella rättigheter.’

Version: 1.0 32 (96) 20 maj 2020


Vidare preciserar ramavtalets särskilda villkor för öppen programvara364 vad som gäller då en myndighet avropar att en leverantör ska tillhandahålla anpassad öppen programvara. För att reglera immateriella rättigheter mellan kund och ramavtalsleverantör då anpassad öppen programvara ska tillhandahållas preciserar ramavtalen två alternativ till hur avtalsvillkoren mellan kund och ramavtalsleverantör kan utformas.

Enligt det första alternativet365 (som också är det som gäller ifall inget alternativ avtalats) gäller bland annat följande då en myndighet avropar anpassad öppen programvara från en ramavtalsleverantör:

’Kund erhåller en vederlagsfri, icke-exklusiv och i tiden obegränsad nyttjanderätt till anpassningen inom Kunds verksamhet, inklusive en rätt att fritt kopiera och ändra (modifiera, vidareutveckla och korrigera) anpassningen. I det fall Kund anlitar tredje part för utförande av tjänster åt Kund har Kund rätt att upplåta motsvarande nyttjanderätt till sådan tredje part för sådant begränsat syfte.’

Om däremot det andra alternativet366 används för att tillhandahålla anpassad öppen program-vara gäller följande:

’Samtliga immateriella rättigheter, inklusive upphovsrätten, till anpassningen överlåts till Kund med full ägande- och förfoganderätt, inklusive rätten att fritt kopiera, ändra (modifiera, vidareutveckla och korrigera) samt upplåta eller överlåta anpassningen. Ramavtalsleverantör får inte utan Kunds medgivande på något sätt nyttja eller förfoga över anpassningen. Ramavtalsleverantör ska gentemot anlitad Konsulttjänstleverantör göra förbehåll för Kunds rättigheter till anpassningen.’

4.3. Kunskapsläget avseende öppen programvara inom offentlig sektor

En systematisk litteraturgenomgång av 24 relevanta tidskrifter och 7 publikationer från konferenser och workshops inom området för programvarusystem identifierade totalt 24289 studier som publicerats mellan 1998 och 2008. Denna studie fann att 1540 av dessa studier behandlar öppen programvara och att endast totalt 112 av dessa studier rapporterar erfaren-heter av organisationers anskaffning av öppen programvara367. Bland resultaten från denna litteraturgenomgång som publicerades 2011 rapporteras bland annat ett kompetensbehov inom den egna organisationen och ett behov av organisatorisk acceptans för användande av öppen programvara bland beslutsfattare och anställda inom organisationen368 .

En studie som analyserat användning av öppen programvara inom offentlig sektor i Storbritannien, Tyskland och Sverige i april 1999 har identifierat betydande skillnader mellan länderna. Studien visar att offentliga organisationer i Tyskland använder öppen programvara369

och Linux i en betydligt större utsträckning än i Sverige370.

Tidig forskning har identifierat lärande, grundat i teorin Legitimate Peripheral Participation371 av Lave & Wenger, som en förklaring och huvudsaklig drivkraft för individers och organisationers motiv för att engagera sig med öppen programvara372 . För öppen programvara saknas en strikt separation mellan kund och leverantör373 , som vid traditionell anskaffning då en myndighet exempelvis upphandlar sluten programvara. Alla individer och organisationer kan potentiellt påverka vidareutvecklingen av öppen programvara genom att engagera sig med och bidra till olika programvaruprojekt som är av strategisk betydelse för att tillgodose olika behov på såväl kort som lång sikt.

Version: 1.0 33 (96) 20 maj 2020


Genom åren har omfattande forskning publicerats inom olika discipliner som, direkt eller indirekt, analyserat en rad tekniska, ekonomiska, juridiska, sociala och samhälleliga aspekter som relaterar öppen programvara. Det finns en omfattande forskning, både ämnesspecifik och interdisciplinär, som i stor utsträckning bedrivs inom området programvaruutveckling (eng. Software Engineering) där också en akademisk ämnesgrupp inom området öppen program-vara (eng. Open Source Systems) etablerats inom Information Federation for Information Processing (IFIP Working Group 2.13). som organiserar den internationella vetenskapliga konferensen Open Source Systems (OSS). Därutöver finns internationella vetenskapliga konferenser, exempelvis International Symposium on Open Collaboration (OpenSym), som behandlas öppen programvara och andra former av öppenhet etablerad inom ramen för Association for Computing Machinery (ACM). Båda dessa internationella event har arrangerats i Sverige.

När den femte internationella konferensen OSS 2009 arrangerades i Skövde374 och när det femtonde internationella symposiet OpenSym 2019 arrangerades i Skövde375 så var det första gången dessa två event arrangerades i Norden.

Version: 1.0 34 (96) 20 maj 2020


5. Vidareutveckling av DIGG:s policy för utveckling av programvara

5.1. Översikt

Detta avsnitt behandlar de licenser som refereras i DIGG:s policy (Figur 4) och presenterar förslag på vilka licenser för öppen programvara som bör rekommenderas i en reviderad version av policyn (Figur 5). Denna kategorisering av licenser i två dimensioner (där den ena dimensionen avser huruvida en licens har eller saknar en explicit klausul som adresserar patent och den andra dimensionen avser huruvida en licens har eller saknar en effekt av copyleft) baseras på tidigare forskning376 .

Figur 4: Licenser för öppen programvara som rekommenderas i DIGG:s policy

Figur 5: Förslag på rekommenderade licenser till en vidareutvecklad policy

5.2. Kategorisering och effekter av licenser som refereras i nuvarande policy

Utformningen av DIGG:s policy för utveckling av programvara ger stöd till myndigheter på flera sätt, där två principiellt olika situationer kan urskiljas. Den första avser en situation då en myndighet engagerar sig med redan befintliga programvaruprojekt som tillhandahåller öppen programvara och den andra avser en situation då en myndighet tar initiativ till att etablera ett nytt programvaruprojekt.

Version: 1.0 35 (96) 20 maj 2020


DIGG:s policy ger stöd till DIGG och andra myndigheter i en situation då en myndighet engagerar sig med redan befintliga programvaruprojekt som tillhandahåller öppen programvara. I dessa situationer rekommenderas att myndigheten accepterar ’redan beslutade licensval förutsatt att valet innebär en licens som finns upptagen på opensource.org’. Med andra ord, policyn preciserar att denna rekommendation förutsätter att programvara från ett befintligt programvaruprojektet tillhandahålls med en licens som är erkänd av organisationen Open Source Initiative377 . Formuleringen av denna rekommendation är mångtydig och bör preciseras, speciellt för situationer då policyn ska tillämpas för etablerade projekt som tillhandahåller öppen programvara under fler än en licens.

Dessutom ger DIGG:s policy stöd till DIGG och andra myndigheter i en situation då en myndighet tar initiativ till etablering av ett nytt programvaruprojekt som planerar att tillhandahålla öppen programvara. I denna situation presenterar policyn följande rekommen-dation: ’I det fall då DIGG tar initiativ till, eller äger ett projekt skall licensformerna Apache eller BSD ”2-clause” användas i första hand.’ Denna formulering kan, eventuellt, uppfattas som att policyn rekommenderar att den myndighet som tillämpar policyn inför etablering av ett nytt programvaruprojekt i första hand ska ställa krav på att exakt en av (de två rekommenderade) licenserna ’Apache’ och ’BSD 2-Clause’ ska väljas.

Då en myndighet tillämpar policyn för ett programvaruprojekt som tillhandahåller program-vara under fler än en licens (då minst en av dessa licenser är erkänd som en licens för öppen programvara) är det oklart vad som avses. En möjlig tolkning av uttrycket ’en licens’ i denna formulering är att policyn rekommenderar den myndighet som tillämpar policyn att endast engagera sig med befintliga programvaruprojekt som tillhandahåller programvara med exakt en licens som erkänts av Open Source Initiative. En alternativ möjlig tolkning av uttrycket ’en licens’ är att policyn rekommenderar den myndighet som tillämpar policyn att vid engage-mang med ett befintlig programvaruprojekt endast engagera sig och göra bidrag till program-varuprojektet under exakt en licens oavsett huruvida programvaruprojektet tillhandahåller programvara från programvaruprojektet under flera licenser där en delmängd (eller samtliga) av dessa licenser är erkända av Open Source Initiative. Av detta skäl bör policyns rekommen-dation preciseras för att klargöra hur en myndighet bör agera inför ett eventuellt engagemang med ett programvaruprojekt som tillhandahåller programvara under fler än en licens.

Det finns, principiellt, två scenarier att ta ställning till. Ett första scenario avser situationer då programvaruprojekt tillhandahåller öppen programvara under fler än en licens där samtliga utgör licenser för öppen programvara. I detta scenario finns goda skäl att rekommendera myndigheter att vid engagemang med programvaruprojektet tillhandahålla bidrag under samtliga licenser som det befintliga programvaruprojektet valt att använda. Ett andra scenario avser programvaruprojekt som tillhandahåller programvara under fler än en licens, men där endast en delmängd av dessa utgör licenser för öppen programvara. Ett exempel på detta andra scenario utgörs av ett etablerat programvaruprojekt som tillhandahålls under två olika licenser (en licens för öppen programvara, exempelvis GPL version 2.0, samt en licens för sluten programvara).

Då en myndighet tillämpar policyn inför ett eventuellt engagemang med ett redan befintligt programvaruprojekt ges dessutom följande rekommendation: ’Endast om befintliga val är så olämpliga att DIGG inte skulle kunna stödja projektet ska krav ställas på att projektet byter licensform’. Vad som avses med ’olämpliga’ och vad som avses med ’licensform’ skulle behöva preciseras. Exempelvis, avser policyn att alla licenser som är erkända av Open Source

Version: 1.0 36 (96) 20 maj 2020

https://opensource.org


Initiative är lämpliga, medan programvara som tillhandahålls under andra villkor per definition är olämpliga? Vidare, avser ’licensform’ samtliga (eller endast vissa) av licenser som erkänts av Open Source Initiative?

I sammanhanget är det viktigt att påpeka att det för många befintliga programvaruprojekt som har många intressenter, speciellt de projekt som etablerats för länge sedan, i praktiken kan vara svårt (och för vissa projekt kanske helt orealistiskt) att förvänta sig att det ska vara möjligt att övertyga företrädare för dessa redan väletablerade befintliga programvaruprojekt att ändra villkor och byta licensform för den programvara som tillhandahålls från dessa projekt.

Då DIGG ’tar initiativ till’ eller ’äger’ ett projekt säger policyn att Apache eller BSD 2-clause ska ’användas i första hand’ utifrån följande formulering:

’Valet av Apache resp. BSD-licenser följer av att dessa licenser innebär väldigt få restriktioner och även medger fri kommersiell användning.’

Denna formulering är olycklig och skulle behöva förtydligas. Formuleringen kan missuppfattas och eventuellt ge intryck av att andra licenser för öppen programvara inte medger användning av programvara för kommersiella syften. Att öppen programvara skulle vara en motsats till programvara som används för kommersiella syften är en miss-uppfattning378. Vidare kan formuleringen ’väldigt få restriktioner’ ge intrycket av att dessa två licenser har likartade egenskaper, men som framgår av Figur 4 är det väsentliga skillnader mellan dessa två licenser.

Vidare presenterar policyn följande rekommendation till en myndighet som ’tar initiativ till’ att etablera ett nytt programvaruprojekt som planerar att tillhandahålla öppen programvara:

’I de fall där syftet med publiceringen inte är öppen spridning utan snarare att skapa en sluten krets av organisationen som tillsammans förvaltar programvaran ska GPL-licens väljas.’

Denna rekommendation (avseende publicering av programvara under ’GPL-licens’) motiveras med följande argument:

’Eftersom detta begränsar möjligheterna till återanvändning är detta ett undantagsfall som särskilt ska motiveras’

Formuleringen ’ska GPL-licens väljas’ skulle behöva preciseras. Avser formuleringen att exkludera LGPL och AGPL? Är rekommendationen oberoende av version? Exempelvis, avses en av GPL 2.0 och GPL 3.0? Eller avser formuleringen att någon licens ur hela GPL-familjen ska väljas?

Argumentet om GPL-licensens effekt (d.v.s. att detta val ’begränsar möjligheterna till återanvändning’) kan ifrågasättas utifrån tidigare forskningsresultat. Det är korrekt att programvara under, exempelvis GPL 2.0, inte kan återanvändas i ett programvaruprojekt som tillhandahålls under Apache 2.0 (men även det omvända gäller). Vidare kan, exempelvis, all programvara som tillhandahålls under GPL 2.0 återanvändas i andra programvaruprojekt som tillhandahålls under samma licens. Dessutom kan programvara som tillhandahålls under villkoren ’GPL 2.0 or later’ återanvändas i programvaruprojekt som utvecklas under såväl GPL 2.0 som GPL 3.0.

All öppen programvara, som exempelvis operativsystemet Linux, skyddas av upphovsrätten och dess licenser används för att upprätthålla normer som etablerats för att möjliggöra

Version: 1.0 37 (96) 20 maj 2020


användning, modifiering och vidaredistribution av programvara från dessa programvaru-projekt379 . I grunden är alla licenser för öppen programvara baserade på upphovsrätten som används utifrån ett antal principer som programvaruprojekt kan använda för att tillhandahålla programvara380 .

När ett programvaruprojekt tillhandahåller öppen programvara innebär detta att program-varans källkod måste vara tillgänglig under villkor som tillåter vidaredistribution utan kostnad och licensen måste tillåta att programvaran modifieras och distribueras vidare under samma villkor som det ursprungliga verket381 .

5.3. Analys av nuvarande policyns referens till BSD 2-Clause

BSD 2-Clause382 är en licens för öppen programvara som av SPDX (version 3.8383) presenteras med namnet BSD 2-Clause ”Simplified” License och med identifieraren BSD-2-Clause384.

Licensen har sitt ursprung från det arbete som sedan slutet av 1970-talet385 bedrevs av forskare vid University of California med operativsystemet Berkeley Software Distribution (BSD). Redan 1989 tillhandahöll Berkeley en distribution386 av både källkod och exekverbar version av programvaran under villkor som ställde krav på tillerkännande av upphovsrättsinnehava-ren387 (BSD 4-Clause) som tillät modifiering och vidaredistribution av källkoden. Detta ledde till att programvaran fritt distribuerades vidare via internet388 . Eftersom den ursprungliga BSD-licensen (BSD 4-Clause) är en licens som, utöver att ställa krav på tillerkännande till innehavare av upphovsrätt till programvaran, även ställer krav på tillerkännande till University of California i marknadsföringsmaterial relaterat programvaran389 har BSD 4-Clause inte erkänts som en licens för öppen programvara390. Genom åren har flera olika varianter av BSD-licenser presenterats, med olika effekter, vilket kan skapa förvirring391 . Det kan exempelvis noteras att BSD 2-Clause har stora likheter med BSD 3-Clause392 och båda dessa är licenser för öppen programvara. För dessa licenser är rätten att vidaredistribuera programvaran central eftersom andra rättigheter följer av denna rättighet393.

Programvara som tillhandahålls under BSD-2-Clause licensen tillåter användning, modifiering och vidaredistribution under samma licens. Däremot ställer inte denna licens några krav på att programvara behöver vidaredistribueras394. Vidare tillåter licensen att programvara kan stängas och tillhandahållas som sluten programvara vilket illustreras av hur Apple utvecklade Mac OS X395. BSD-2-Clause licensen saknar effekt av copyleft396 .

BSD-2-Clause licensen har stora likheter med MIT licensen. Det finns dock vissa skillnader mellan dessa båda licenser som relaterar hur patent kan påverka programvara som tillhandahålls under dessa licenser. Bland jurister som är specialiserade på öppen programvara har det presenterats olika uppfattningar avseende huruvida, och i så fall på vilket sätt och i vilken utsträckning, dessa licenser hanterar patent.

När programvara tillhandahålls under BSD-2-Clause ställer licensen krav på tillerkännande av upphovsrättsinnehavaren och licensen ger rätt att vidaredistribuera och använda (eng. ‘use’) programvaran, med eller utan modifiering, både som källkod och i exekverbar form397. Licensen är formulerad på ett sätt som endast använder ett (av totalt fem398 centrala) begrepp som är centralt utifrån ett perspektiv av patent och licensens tillämpbarhet avseende patent är långt ifrån självklar399. Licensen saknar en explicit patentklausul400, vilket finns i många andra licenser som utvecklats under senare år (se Figur 4). Bland jurister finns uppfattningen att

Version: 1.0 38 (96) 20 maj 2020


BSD-2-Clause troligen ger en implicit rättighet till patent401 och det finns även jurister som ger uttryck för uppfattningen att BSD 2-Clause (och alla övriga licenser i Figur 5) ger en rättighet till patent402 , men det finns också jurister som redovisar uppfattningen att licensen endast avser upphovsrätt och att rättigheter avseende patent helt saknas403 .

5.4. Analys av nuvarande policyns referens till Apache

Apache 2.0404 är en licens för öppen programvara som av SPDX (version 3.8405) presenteras med namnet Apache License 2.0 och med identifieraren Apache-2.0406.

Licensen har sitt ursprung från arbetet med programvaruprojektet Apache HTTP Server project som en grupp utvecklare etablerade för att skapa en webbserver407 genom en öppen samverkan över internet där programvarans källkod fritt kunde användas, kopieras, modifieras och vidaredistribueras408. Redan 1996 fanns källkoden för detta projekt fritt tillgänglig via internet och under 1999 tillhandahölls projektet under Apache 1.0 licensen409. Den 30 juni 1999 etablerades organisationen Apache Software Foundation (ASF) för att ge stöd till utveckling och förvaltning av de projekt som drivs inom ramen för organisationen410 , där bland annat frågor om vidareutveckling av licensen behandlas411 . Licensen (Apache 1.0) innehåller en klausul som orsakade att den aldrig erkänts som öppen programvara men klausulen togs bort då en ny version (Apache 1.1) publicerades av ASF under 2000412 . Detta ledde till att Apache 1.1, i början av 2001413erkändes som en licens för öppen programvara414

och under januari 2004 publicerade ASF en ny version (Apache 2.0) som också erkänns som en licens för öppen programvara415 . Till skillnad från Apache 1.1 innehåller Apache 2.0 en explicit patentklausul416.

Programvara som tillhandahålls under Apache 2.0 licensen tillåter användning, modifiering och vidaredistribution under samma licens. Vid vidaredistribution av modifierad källkod ställer licensen krav på att det vid distributionen tydligt anges att källkoden har modifierats417. Däremot ställs inga krav på att programvara under Apache 2.0 måste vidaredistribueras. Licensen saknar effekt av copyleft418.

Utöver rättigheter avseende upphovsrätt tillhandahåller rättighetsinnehavare som tillhanda-håller programvara under Apache 2.0 även en patentlicens419 som uttryckts i en specifik patentklausul420 . Licenstexten (Apache 2.0) innehåller explicita formuleringar avseende rättigheter som återfinns i USA:s patentlagstiftning421. Rättigheterna avseende patent avser endast de patent som kontrolleras av den som bidrar, ej till hela verket422. Apache 2.0 har även en klausul som möjliggör ett omgående återtagande423 av de rättigheter som licensgivaren tillhandahållit avseende patent424. I händelse av att en licensgivare som tillhandahåller öppen programvara under Apache 2.0 blir anklagad för patentintrång finns en klausul för att återta patentlicensen425.

Det ska noteras att programvara under Apache 2.0 inte kan kombineras med programvara under GPL 2.0426.

5.5. Analys av nuvarande policyns referens till GPL

GPL 2.0427 är en licens för öppen programvara som av organisationen Open Source Initiative (OSI) presenteras under namnet GNU General Public License version 2. Av SPDX (version 3.8428) presenteras licensen under två olika namn, GNU General Public License v2.0 only

Version: 1.0 39 (96) 20 maj 2020


samt GNU General Public License version 2 or later med tillhörande identifierare GPL-2.0-only samt GPL-2.0-or-later. Även om GPL-2.0 presenteras med två olika namn så är det endast en licens. Tillägget ”or later” utgör, i sig självt, en option som licensgivaren ger licenstagare. Om en licensgivare exempelvis väljer att tillhandahålla programvara under GPL-2.0-only förhindras att denna programvara kan kombineras med annan programvara som tillhandahålls under senare versioner (inklusive version 3429) av samma licens. Om en licensgivare däremot väljer att använda optionen ”or later” (d.v.s. väljer att tillhandahålla programvara under GPL-2.0-or-later) tillåts däremot att programvaran kan kombineras med annan programvara som tillhandahålls under senare versioner (version 3) av samma licens. Genom att använda optionen ”or later” ger licensgivaren alla licenstagare större möjligheter att återanvända programvaran i nya sammanhang.

GPL 3.0430 är en licens för öppen programvara som av organisationen Open Source Initiative (OSI) presenteras under namnet GNU General Public License version 3. Av SPDX (version 3.8431) presenteras licensen under två olika namn, GNU General Public License v3.0 only samt GNU General Public License version 3 or later med tillhörande identifierare GPL-3.0-only samt GPL-3.0-or-later. Om en licensgivare exempelvis väljer att tillhandahålla programvara under GPL-3.0-only förhindras att programvaran kan kombineras med programvara under (kommande) senare versioner432 av samma licens. Om en licensgivare däremot väljer att använda optionen ”or later” (d.v.s. väljer att använda GPL-3.0-or-later) tillåts däremot att tillhandahållen programvara kan kombineras med annan programvara som tillhandahålls under (kommande) senare versioner av samma licens.

LGPL 2.1433 är en licens för öppen programvara som av organisationen OSI presenteras under namnet GNU Lesser General Public License version 2.1. Av SPDX (version 3.8434) presenteras licensen under två olika namn, GNU Lesser General Public License v2.1 only samt GNU Lesser General Public License v2.1 or later med tillhörande identifierare LGPL-2.1-only samt LGPL-2.1-or-later. Optionen ”or later” för LGPL 2.1 fungerar på motsvarande sätt som för GPL 2.0.

LGPL 3.0435 är en licens för öppen programvara som av organisationen OSI presenteras under namnet GNU Lesser General Public License version 3.0. Av SPDX (version 3.8436) presenteras licensen under två olika namn, GNU Lesser General Public License v3.0 only samt GNU Lesser General Public License v3.0 or later med tillhörande identifierare LGPL-3.0-only samt LGPL-3.0-or-later. Optionen ”or later” för LGPL 3.0 fungerar på motsvarande sätt som för GPL 3.0.

AGPL 3.0437 är en licens för öppen programvara som av organisationen OSI presenteras under namnet GNU Affero General Public License version 3. Av SPDX (version 3.8438) presenteras licensen under två olika namn, GNU Affero General Public License v3.0 only samt GNU Affero General Public License v3.0 or later med tillhörande identifierare AGPL-3.0-only samt AGPL-3.0-or-later. Optionen ”or later” för AGPL 3.0 fungerar på motsvarande sätt som för GPL 3.0.

Det finns flera licenser i GPL-familjen (GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0 och AGPL 3.0) som rekommenderas för olika syften. Dessa licenser i GPL-familjen har olika effekt av copyleft.

Copyleft är centralt för alla licenser ur GPL-familjen och innebär en förpliktelse att, under vissa omständigheter, tillhandahålla källkoden för en programvara. Effekten av copyleft kan,

Version: 1.0 40 (96) 20 maj 2020

https://version3.Av


förenklat, sägas flytta rätten för ett verk från författaren till användaren439. Denna effekt aktiveras när ett derivat har skapats från ett upphovsrättsskyddat verk och när detta derivat har distribuerats440. Då programvara under GPL, i modifierad eller omodifierad form, inkluderas i programvara som vidaredistribueras innebär detta att hela verket behöver distribueras under GPL441 .

När en licensgivare tillhandahåller programvara under GPL 2.0 ges licenstagaren tillåtelse att modifiera och vidaredistribuera verket i sin ursprungliga form eller i modifierad form442. Detsamma gäller även för övriga licenser ur GPL-familjen. När programvara under GPL 2.0 distribueras vidare så ska detta ske under samma licens, eller en licens som är kompatibel med GPL 2.0443.

Inom GPL-familjen är LGPL en variant som jämfört med GPL har en mer begränsad effekt av copyleft444 . Om en modul av programvara tillhandahålls under LGPL är effekten av copyleft begränsad till modulen som dynamiskt kan anropas från programvara som tillhandahålls under annan licens445. Programvara under LGPL har annars stora likheter med GPL446 .

Flera moderna licenser för öppen programvara, däribland erkända licenser ur GPL-familjen (GPL 3.0, LGPL 3.0 och AGPL 3.0), är utformade med explicita patentklausuler som innebär att programvara som tillhandahålls under dessa licenser inte tillåter royalty för patent som kontrolleras av tredjepart447 . GPL-licenserna under version 2 (GPL 2.0 och LGPL 2.1) saknar däremot en explicit patentklausul448, medan licenserna under version 3 (GPL 3.0, LGPL 3.0 och AGPL 3.0) har en explicit patentklausul449 . Under GPL version 3 kan en licenstagare som initierar en patenttvist avseende programvaran förlora alla rättigheter att distribuera programvaran450 .

Även om GPL 2.0 och LGPL 2.1 saknar en explicit patentklausul har dessa licenser andra klausuler som hanterar rättigheten att vidaredistribuera programvara451, däribland en klausul som kallas Liberty or Death (sektion 7 i GPL 2.0 samt sektion 11 i LGPL 2.1), som hindrar distribution av programvaran om detta innebär ytterligare restriktioner för licenstagaren452.

GPL-licensen använder, på ett elegant sätt453 , kontraktsvillkor och upphovsrätten på ett inkluderande sätt som skyddar fortsatt öppenhet istället för att användas exkluderande gentemot individer och organisationer som har intresse av att engagera sig med ett program-varuprojekt. För en myndighet som engagerar sig med ett redan etablerat programvaruprojekt eller planerar etablera ett nytt programvaruprojekt med det långsiktiga målet att ge incitament för att såväl vidareutvecklad som nyutvecklad programvara ska förbli öppen programvara finns det i många scenarier mycket goda skäl att använda en (eller flera) licenser från GPL-familjen. Ett sådant val är även naturligt för många företag som tillhandahåller prenumera-tionstjänster kring öppen programvara. Exempelvis passar Red Hat:s affärsmodell, som baseras på att tillhandahålla tjänster genom prenumerationer, utmärkt för att utveckla och engagera sig med flera olika programvaruprojekt som tillhandahålls under GPL-licensen454. Många företag som tillhandahåller programvara tillsammans med hårdvara distribuerar ofta Linux (som tillhandahålls under licensen GPL 2.0) som en del av denna distribution455 .

Det är långt ifrån ovanligt att organisationer tillhandahåller programvara som tjänst456 till en eller flera andra organisationer. I ett sådant scenario anses det exempelvis, enligt bedömning av många ledande jurister som är specialiserade inom området öppen programvara, att någon distribution inte sker när programvaran som används på servern tillhandahålls under GPL 2.0 eller GPL 3.0. Däremot anses det att distribution faktiskt sker i ett alternativt scenario då en

Version: 1.0 41 (96) 20 maj 2020


programvara på en server istället tillhandahålls via webben under exempelvis AGPL 3.0457

AGPL 3.0 är en licens vars effekt av copyleft även aktiveras då programvara under licensen tillgängliggörs över ett nätverk, exempelvis om programvara under AGPL 3.0 tillhandahålls som en tjänst458. AGPL 3.0 är kompatibel med GPL 3.0 genom en specifik klausul459.

Frågor om vad som utgör en distribution i specifika scenarios har varit föremål för omfattande diskussion bland utvecklare och jurister specialiserade inom området och kanske speciellt relaterat situationer där programvara tillhandahålls som tjänst. I vissa scenarios, exempelvis då viss del av programvaran exekveras på klienten (exempelvis som ett skript i en webb-läsare), kan distribution mycket väl anses ha skett460 .

5.6. Önskade och oönskade effekter av refererade licenser i nuvarande policy

Presidenten för organisationen bakom öppen programvara (Open Source Initiative) har karaktäriserat licenser för öppen programvara som ett multilateralt samförstånd kring en organisations normer för programvaruprojekt461 .

Då en myndighet utvecklar och anskaffar programvara är det viktig att analysera de önskade och oönskade effekter som olika beslut kan ha på olika programvaruprojekt som myndigheten påverkar och påverkas av. Beslut avseende val av olika licenser är en viktig aspekt, men långt ifrån den enda, som behöver behandlas av en myndighet för att kunna upprätthålla en hållbar digitalisering. Inför strategiska beslut om förhållningssätt och val av licenser är det exempelvis viktigt att beakta betydelsen av myndighetens behov och möjligheter att kunna använda olika standarder som behöver implementeras i programvara för att möjliggöra behandling och långsiktig förvaltning av myndighetens egen information.

I litteraturen har flera olika kategoriseringar av licenser för öppen programvara presenterats, däribland distinktionen utifrån huruvida en licens har, respektive saknar, en effekt av copyleft. Detta refereras ofta som copyleft (som exempelvis inkluderar alla licenser ur GPL-familjen) och permissive (som exempelvis inkluderar licenserna BSD-2-Clause, MIT samt Apache 2.0). Ibland används även begreppet strong copyleft (där exempelvis GPL 2.0 och GPL 3.0 ingår) och weak copyleft (där exempelvis LGPL 2.1 och LGPL 3.0 ingår) för att skilja på vilken omfattning effekten av copyleft har.

En annan kategorisering delar in licenser för öppen programvara i tre kategorier, beroende på hur de är utformade: free-for-all462, keep-open463 och Share-alike464 .

Moderna licenser för öppen programvara, som exempelvis Apache 2.0 och GPL version 3 (LGPL 3.0, GPL 3.0 och AGPL 3.0), innehåller explicita klausuler avsedda att hantera patent. Dessa licenser är utvecklade under en tidsperiod då juridiska dispyter avseende patent som belastar programvara blivit mer vanliga465 . Även om andra licenser, som exempelvis MIT, saknar en explicit patentklausul finns det argument som talar för att licensen ändå inkluderar rättigheter avseende patent466 och även argument från en juridisk analys som dragit denna slutsats467. Vidare är MIT, till skillnad från exempelvis Apache 2.0, kompatibel med licenser under GPL-familjen version 2 vilket är ett skäl att beakta i en situation då utgångspunkten är att en licens som saknar copyleft ska väljas.

För en myndighet, ett företag eller en annan typ av organisation som fattat beslut om att bidra till ett redan etablerat, eller bidra till att etablera ett nytt, programvaruprojekt som tillhanda-håller öppen programvara innebär effekten av copyleft att de bidrag som görs till projektet

Version: 1.0 42 (96) 20 maj 2020


kommer att förbli öppet tillgängliga under villkor som hindrar andra aktörer att stänga projektet468. Utifrån dessa skäl bedöms licenser under GPL-familjen i många scenarier vara lämpliga för en organisation som planerar att etablera ett nytt, eller bidra till ett befintligt, programvaruprojekt som tillhandahåller öppen programvara. Om en myndighet, exempelvis, bidrar till ett programvaruprojekt som implementerar en IT-standard och väljer att tillhanda-hålla öppen programvara från projektet under LGPL så skyddas fortsatt öppenhet för den öppna programvara som implementerat standarden samtidigt som denna programvara kan användas i många olika scenarier469. Om myndigheten däremot väljer att tillhandahålla öppen programvara under GPL eller AGPL så bedöms kan detta dessutom bidra till ett öppet ekosystem kring den implementerade IT-standarden470 .

Då programvaruprojekt utvecklar och tillhandahåller öppen programvara är det vanligt att återanvända redan existerande komponenter (byggblock) av öppen programvara. En förutsättning för att kunna återanvända en viss komponent i ett specifikt programvaruprojekt är att licensen för komponenten och licensen för programvaruprojektet är förenliga. Exempelvis är det, av ett antal orsaker, omöjligt för ett programvaruprojekt som tillhandahålls under GPL 2.0 att återanvända en komponent som tillhandahålls under Apache 2.0 eftersom dessa två licenser är inkompatibla med varandra. Av detta skäl kan programvara som tillhandahålls under Apache 2.0 exempelvis inte återanvändas och förenas med programvaruprojektet som utvecklar kärnan i operativsystemet Linux (eftersom detta projekt endast tillhandahålls under GPL 2.0). Däremot anses, exempelvis, programvara som tillhandahålls under Apache 2.0 vara förenlig med programvara tillhandahållen under GPL 3.0471 , samt även omvänt (så att även en komponent som tillhandahålls under GPL 3.0 kan återanvändas av ett programvaruprojekt som tillhandahålls under Apache 2.0)472.

Det är dock inte alla licenser som är kompatibla i båda riktningarna (d.v.s. programvara under licens A är kompatibel med programvara under licens B, samt omvänt). Bara för att program-vara som tillhandahålls under licens A är kompatibel och kan förenas med programvara som tillhandahålls under licens B (så att exempelvis en komponent som tillhandahålls under A kan återanvändas av ett programvaruprojekt som tillhandahålls under licens B) kan det vara så att det omvända inte gäller (d.v.s. programvara under licens B kan vara inkompatibel med programvara under licens A)473 .

Om exempelvis en teknisk specifikation av en standard är belastad med ett (eller flera) essentiella patent (eng. ‘standard-essential patents’, SEPs474) kan detta innebära att licenser för dessa patent behöver anskaffas innan specifikationen kan implementeras och användas av programvara som tillhandahålls under en licens för öppen programvara475 .

Upphovsrättsinnehavaren har tre principiella rättigheter avseende programvara som följer av upphovsrättslagen: rätten att kopiera programvaran, rätten att modifiera programvaran och rätten att distribuera programvaran. För sluten programvara väljer upphovsrättsinnehavaren normalt att inte dela dessa rättigheter med tredje part476 . Villkoren för sluten programvara innehåller ofta restriktioner som hindrar användaren från att exempelvis modifiera och analysera källkoden genom s.k. dekompilering för att möjliggöra en detaljerad inspektion av programvarans funktion477.

Licenser för öppen programvara är väsentliga att förstå för tre kategorier av intressenter: utvecklare, jurister som ger vägledning till utvecklare samt alla andra478. Bland kategorin alla andra intressenter ryms alla individer och organisationer som, i ett eller annat sammanhang,

Version: 1.0 43 (96) 20 maj 2020


påverkar och är påverkade av projekt som som anskaffar, utvecklar och använder programvara för olika syften.

Erfarenheter visar att det finns starka skäl för en organisation att etablera en policy479 för öppen programvara som rekommenderar användning av erkända licenser som används av många individer och organisationer som är engagerade med olika etablerade programvaru-projekt. För att en myndighet framgångsrikt ska kunna engagera sig med olika initiativ och programvaruprojekt som utvecklar öppen programvara är det viktigt att förstå de underliggande incitament som påverkar hur olika intressenter agerar i förhållande till dessa projekt480 .

Det finns även organisationer som väljer att driva programvaruprojekt som initialt tillhanda-håller sluten programvara och med en tidsfördröjning tillhandahåller öppen programvara. Denna strategi kan dock få effekten att ett begränsat antal individer och organisationer, utöver de som redan är knutna till den organisation som leder projektet, har incitament att bidra till vidare utveckling av programvaruprojektet481 .

5.7. Förslag på referenser till licenser för en vidareutvecklad policy

Denna sektion redovisar en värdering och rekommendation för vidareutveckling av DIGG:s policy för utveckling av programvara.

Till en vidareutvecklad policy för utveckling av programvara föreslås licenser ur GPL-familjen som särskilt lämpliga för en myndighet som väljer att etablera ett nytt programvaru-projekt (se figur 5). Genom dess effekt av copyleft skyddas, i varierande grad (beroende på om LGPL, GPL eller AGPL används), fortsatt öppenhet för de programvaruprojekt som myndigheten engagerar sig med.

En myndighet kan mycket väl engagera sig med ett redan etablerat programvaruprojekt som tillhandahåller öppen programvara under Apache 2.0, men däremot anses denna licens mindre lämplig licens då en myndighet inför etablering av ett nytt programvaruprojekt står i begrepp att välja licens. Eftersom Apache 2.0 saknar en effekt av copyleft kan programvara som tillhandahålls under licensen stängas av en licenstagare, som istället kan välja att vidareutveckla programvaran och distribuera denna som sluten programvara och även välja att inte distribuera den vidareutvecklade programvaran alls. Det är heller inte möjligt att kombinera programvara som tillhandahålls under Apache 2.0 med annan programvara som tillhandahålls under GPL 2.0.

I kategorin av licenser som saknar effekt av copyleft och som även saknar en explicit patentklausul förordas MIT som en mer lämplig licens än BSD 2-Clause, även om ingen av dessa licenser rekomenderas då en myndighet ska etablera ett nytt programvaruprojekt.

MIT-licensen är en mycket enkel licens482 som också används av många programvaruprojekt. Denna licens uppskattas av många utvecklare. Enligt vissa bedömare har MIT också en bättre utformning för att (implicit) hantera patent483, men det ska betonas att det finns olika uppfattningar bland juridiska experter i detta avseende.

Vid etablering av ett nytt programvaruprojekt rekommenderas att en myndighet, istället för MIT och istället för BSD 2-Clause, överväger att istället använda LPGL-licensen för att skydda fortsatt öppenhet hos det etablerade projektet. Programvara under LGPL kan, liksom programvara under BSD och MIT, inkluderas i programvara som tillhandahålls under villkor

Version: 1.0 44 (96) 20 maj 2020


för såväl öppen programvara som sluten programvara. Då en myndighet vill etablera och stimulera evolution av ett öppet ekosystem kring ett nytt (eller etablerat) programvaruprojekt som tillhandahåller öppen programvara rekommenderas däremot GPL och AGPL.

Det kan konstateras att rekommendationerna från denna analys (se Figur 5), i stort, är i linje med rekommendationer för val av licenser till nya programvaruprojekt från den person (Bruce Perens) som etablerat definitionen av öppen programvara484.

Version: 1.0 45 (96) 20 maj 2020


6. Öppna frågor för vidare analys och diskussion

Under 1970-talet fanns det i USA tvivel avseende huruvida upphovsrätt och patent gäller för programvara485 . Under 1980-talet blev det klarlagt att upphovsrätt gäller för programvara486

och under 1990-talet blev det även klarlagt att patent påverkar programvara487 .

För att en myndighet ska kunna fatta välinformerade beslut om utveckling, upphandling och införande av programvara inom myndigheten är det viktigt att ha kunskap om licenser för såväl öppen som sluten programvara. Detta är viktigt alldeles oavsett om en myndighet väljer att utveckla eller anskaffa en programvara för lokal drift i egen regi (med egen personal eller med inhyrda konsulter), drift i samverkan med andra myndigheter, eller drift genom avtal med externa tjänsteleverantörer.

Tidigare forskning visar att det bland såväl myndigheter som leverantörer finns behov av ökad kunskap avseende olika typer av licenser och avtal som enskilda organisationer är bundna av som en konsekvens av att en myndighet anskaffar och använder olika typer av programvara. Detta gäller såväl licenser för öppen som sluten programvara. När det gäller licenser för öppen programvara används upphovsrätten på ett sätt som tillåter att programvaran används, modifieras och vidaredistribueras under givna villkor som gäller för respektive licens. Men om en organisation inte respekterar dessa villkor kan organisationen göra sig skyldig till intrång i upphovsrätten488 .

Efter att ett antal enskilda utvecklare identifierat upphovsrättsintrång från ett antal organisationer som, medvetet eller omedvetet, valt att använda öppen programvara från programvaruprojekt utan att respektera villkoren i tillhörande licens etablerades en organisation för att komma tillrätta med identifierade upphovsrättsintrång489. Organisationens mål var att åstadkomma effekten av att programvarans källkod ska tillhandahålls i enlighet med de villkor som gäller enligt licensen.

6.1. Öppen programvara och standarder

För organisationer som har behov av att behandla och representera data i format som möjliggör utbyte och återanvändning av information inom, samt mellan, olika system över långa livscykler är det viktigt att använda IT-standarder som korrekt och fullständigt har implementerats i programvara. Detta inkluderar scenarier där data behandlas, representeras och överförs inom, samt mellan, olika system som förvaltas inom en eller flera organisationer under villkor som lyder under en eller flera olika jurisdiktioner.

Om en myndighet endast använder IT-standarder som tillhandahålls under villkor som uppfyller definitionen av en öppen standard enligt EU:s interoperabilitetsramverk version 1.0490 (EIF 1.0), eller någon annan motsvarande definition, undviker myndigheten att skapa en situation som hindrar implementation och användning av dessa IT-standarder i programvaru-projekt som tillhandahåller öppen programvara. En vägledning som, baserat på en analys utifrån EIF 1.0, presenterar ett antal öppna standarder har publicerats av Statens inköpscentral vid Kammarkollegiet491. Myndigheter kan också bidra till en förbättrad standardisering genom att proaktivt bidra till programvaruprojekt som utvecklar referensimplementationer av öppna IT-standarder som tillhandahåller öppen programvara492.

För att möjliggöra interoperabilitet och undvika konkurrenshinder vid utveckling och anskaffning av programvara rekommenderas myndigheter, utifrån en studie som genomförts

Version: 1.0 46 (96) 20 maj 2020


på uppdrag av Konkurrensverket493 , att endast ställa krav på användning av öppna filformat och öppna standarder som uppfyller definitionen enligt EIF 1.0494. Baserat på samma studie rekommenderas även att en myndighet som vid utveckling och anskaffning av nya IT-system planerar ställa krav på användning av en sluten IT-standard (d.v.s. en IT-standard som ej uppfyller definitionen enligt EIF 1.0) identifierar alla risker för konkurrenshinder och diskriminering som individer och organisationer kommer att utsättas för utifrån myndighetens agerande495 .

Om en myndighet har behov av att referera en specifik IT-standard, exempelvis för att behandla och förvalta handlingar i filer som representeras i ett specifikt slutet filformat som inkommer till myndigheten, behöver myndigheten anskaffa alla nödvändiga rättigheter (inklusive alla patentlicenser för de standard-essentiella patent som belastar standarden) för att standarden ska kunna implementeras och användas i programvara som kan tillhandahållas under alla licenser för öppen programvara496. Då en myndighet genomför en upphandling och i upphandlingsdokumenten, exempelvis, ställer krav på en sluten IT-standard som myndig-heten själv saknar alla nödvändiga rättigheter till skapar myndigheten konkurrenshinder. Detta beror på att potentiella anbudsgivare inte likabehandlas eftersom det i praktiken saknas möjlighet att (under tidsperioden då anbud kan lämnas) anskaffa alla nödvändiga rättigheter för att kunna använda den slutna IT-standarden497 .

Då en myndighet planerar använda en IT-standard som ej uppfyller definitionen av öppen standard, enligt EIF 1.0, är det nödvändigt att initialt anskaffa alla nödvändiga rättigheter för att standarden ska kunna användas för implementation i öppen programvara498. Resultat från flera studier visar att det, i praktiken, kan vara omöjligt för en myndighet att anskaffa alla nödvändiga rättigheter som en följd av att rättighetsinnehavare är ovilliga att tillhandahålla licenser som möjliggör (laglig) användning av en specifik standard499.

Rekommendation till myndigheten: Av dessa skäl är det mycket viktigt att en myndighet som planerar använda en sluten standard eller ett slutet filformat först anskaffar alla nödvändiga rättigheter (inklusive alla nödvändiga patentlicenser) innan myndigheten börjar använda en programvara som implementerar standarden (eller filformatet). En förutsättning för att myndigheten ska kunna behandla uppgifter i handlingar som myndigheten representerar i dessa standarder och filformat är att dessa har implementerats i programvara som myndigheten har tillgång till under hela livscykeln för alla handlingar som myndigheten behöver förvalta.

6.2. Öppen programvara och patentbelastade standarder

För att en organisation strategiskt ska kunna engagera sig med programvaruprojekt som tillhandahåller öppen programvara är det viktigt att undvika användning av slutna standarder eftersom denna typ av standarder hindrar användning av öppen programvara500.

Eftersom varje myndighet behöver utbyta uppgifter med andra organisationer kan det i praktiken dock visa sig vara mycket svårt, speciellt på kort sikt501 , för en enskild myndighet att undvika att behöva befatta sig med uppgifter i handlingar som representeras i patentbelastade slutna standarder och slutna filformat. I praktiken kan en myndighet förväntas, exempelvis av företrädare för andra organisationer, behöva använda programvara som har implementerat olika slutna standarder och slutna filformat för att kunna behandla uppgifter som är representerade i handlingar som har upprättats utanför den egna

Version: 1.0 47 (96) 20 maj 2020


myndigheten. Om handlingar som upprättats utanför den egna organisationen inkommer till den egna myndigheten kan detta innebära en (underförstådd) förväntan (eller till och med ett krav) på att myndigheten ska kunna hantera och behandla uppgifter i dessa inkomna handlingar.

En enskild myndighet kan sakna möjlighet att ställa krav på att individer och organisationer utanför den egna myndigheten aldrig tillhandahåller uppgifter och handlingar som förutsätter användning av patentbelastade slutna standarder och slutna filformat. Däremot finns det självklart ingenting som hindrar att en enskild myndighet agerar proaktivt för att uppmuntra användning av öppna standarder och öppna filformat som kan implementeras i programvara under alla typer av licenser och därigenom långsiktigt bidra till en hållbar digitalisering som möjliggör konkurrens samt långsiktig förvaltning och återanvändning av uppgifter i olika handlingar.

Öppna standarder och öppna filformat som uppfyller definitionen enligt EIF 1.0 kan implementeras och användas i öppen programvara502. En förutsättning för att en standard och ett filformat ska kunna implementeras i öppen programvara är att det vid distribution av den öppna programvaran inte ställs några krav på ersättning (royalty) per exemplar. Om det finns patent som påverkar ett programvaruprojekt så behöver projektet inneha patenträttigheter som tillåter att öppen programvara (restriktionsfritt) kan vidaredistribueras503.

Flera studier har visat att patentbelastade IT-standarder, som tillhandahålls under s.k. FRAND-villkor, skapar hinder för användning och implementation i programvaruprojekt som tillhandahåller öppen programvara504. Trots detta finns det en senare publicerad studie505 som hävdar att det inte finns några tidigare studier som visar att FRAND-villkor för standarder kan innebära problem. Därutöver har officiell kommunikation från EU redovisat att patent-belastade standarder som tillhandahålls under FRAND-villkor kan hindra506 användning av öppen programvara.

Om en myndighet använder programvara som implementerar en patentbelastad sluten IT-standard behöver myndigheten anskaffa patentlicenser för att undvika risk för att bli anklagad för att ha gjort patentintrång507 . Studier visar att användning och implementation av slutna standarder i programvara kan leda till juridiska dispyter och det finns exempel på att användning av ett slutet filformat kan leda till att en domstol kan döma ut mycket stora skadestånd för patentintrång508.

Rekommendation till myndigheten: Av dessa skäl är det mycket viktigt att en myndighet som planerar använda en standard som behöver implementeras i programvara först anskaffar alla nödvändiga rättigheter (inklusive alla nödvändiga patentlicenser) för de standarder och filformat som myndigheten avser ställa krav på i de projekt som myndigheten genomför för att upphandla respektive utveckla programvara för att tillgodose myndighetens egna behov.

6.3. Öppen programvara och EU:s interoperabilitetsramverk

Den 18 november 2004, under en internationell konferens i Haag, presenterades EU:s definition av öppen standard av den ledande företrädaren509 för det projekt inom Europeiska Kommissionen som utvecklat EU:s interoperabilitetsramverk version 1.0510 (EIF 1.0). EU:s definition av öppen standard utgör en viktig utgångspunkt för EU:s och enskilda länders strategiska arbete med interoperabilitet. Denna definition har också påverkat enskilda organisationers agerande och nationell policy i flera länder. I Sverige valde exempelvis E-

Version: 1.0 48 (96) 20 maj 2020


delegationen att precisera innebörden av öppen standard genom att referera till EU:s definition av öppen standard i sin första publikation som publicerades den 19 november 2009511 . Senare har samma definition också använts av Statens inköpscentral vid Kammarkollegiet vid utformning av avtalsvillkor för de statliga ramavtalen för upphandling av programvara och tjänster i vilka det är tillåtet att formulera obligatoriska krav som refererar till standarder endast om dessa uppfyller definitionen av öppen standard512.

Den 15 juli 2008 presenterades ett utkast på version 2 av EU:s interoperabilitetsramverk och detta innehåller samma definition av öppen standard som publiceras i EIF 1.0513 . Den 22 september 2008 tillgängliggjordes detta utkast för att inhämta kommentarer från olika intressenter514 och under 2009 redovisade EU kommentarer från totalt 54 intressenter515. En analys av innehållet i dessa kommentarer visar att ett antal intressenter har lämnat kommentarer och rekommendationer som baseras på föreställningar och missförstånd relaterat villkor för hur standarder tillhandahålls och specifikt avseende relationen mellan standarder och öppen programvara516. Det finns även remissvar som innehåller direkta faktafel avseende ursprunget för olika definitioner517 .

Den 16 december 2010 presenterades EU:s interoperabilitetsramverk version 2518 (EIF 2.0) och denna saknar en definition av öppen standard. Istället har ett nytt begrepp introducerats, öppen specifikation, men detta begrepp introduceras med en definition som hindrar interoperabilitet. Definitionen av öppen specifikation enligt EIF 2.0 inkluderar dels standarder som uppfyller definitionen av öppen standard (enligt EIF 1.0) men även patentbelastade slutna standarder som ej uppfyller definitionen av öppen standard (enligt EIF 1.0). Resultat från flera studier visar att ett stort antal patentbelastade slutna standarder som uppfyller definitionen av öppen specifikation (enligt EIF 2.0) men inte uppfyller definitionen av öppen standard (enligt EIF 1.0) begränsar konkurrensen och hindrar implementation i öppen programvara519.

I februari 2016 presenterades ett utkast på version 3 av EU:s interoperabilitetsramverk520 med en inbjudan om att under perioden från den 6 april 2016 till 29 juni 2016 inhämta kommentarer från olika intressenter. EU sammanställde och redovisade kommentarerna den 17 oktober 2016521. Den 30 november 2017 publicerades EU:s interoperabilitetsramverk version 3522 (EIF 3.0). Både utkast till EIF 3.0 och den publicerade EIF 3.0 saknar en definition av öppen standard och presenterar istället begreppet öppen specifikation med en definition som inkluderar patentbelastade slutna standarder och som hindrar interoperabilitet.

Utifrån detta kan det konstateras att endast EIF 1.0 innehåller en definition av öppen standard som möjliggör interoperabilitet, medan detta saknas i både EIF 2.0 och EIF 3.0. Definitionen av öppen specifikation som finns i EIF 2.0 och definitionen av öppen specifikation som finns i EIF 3.0 skapar hinder för interoperabilitet. För en myndighet som har ambitionen att åstadkomma interoperabilitet är det endast EIF 1.0 som är relevant. Det finns flera exempelvis på formella ISO-standarder som uppfyller definitionen av öppen specifikation (enligt EIF 2.0 och EIF 3.0), men som ej uppfyller definitionen av öppen standard (enligt EIF 1.0)523.

För en myndighet är det mycket viktigt att inte blanda ihop begreppen formella standarder (exempelvis standarder från ISO och ITU-T) med öppna standarder enligt EIF 1.0524 . Det är vidare mycket viktigt att vara medveten om att det finns formella standarder som tillhandahålls under villkor som skapar konkurrenshinder525 och att det för formella standarder kan vara omöjligt att anskaffa alla nödvändiga rättigheter som möjliggör implementation av standarden i programvara526 .

Version: 1.0 49 (96) 20 maj 2020


Öppna standarder är konkurrensneutrala och en myndighet kan därför ställa krav på en öppen standard vid utveckling och upphandling av programvara utan att skapa konkurrenshinder. En standard som uppfyller EU:s definition av öppen standard, enligt EU:s interoperabilitets-ramverk version 1.0, kan implementeras i såväl öppen som sluten programvara.

Rekommendation till myndigheten: Av dessa skäl är det mycket viktigt att en myndighet som har ambitionen att möjliggöra interoperabilitet för att etablera en långsiktigt hållbar förvaltning av digitala handlingar genom upphandling och utveckling av programvara endast refererar till standarder och filformat som uppfyller definitionen av öppen standard enligt EIF 1.0. Eftersom endast öppna standarder kan implementeras i öppen programvara behöver en myndighet först anskaffa alla nödvändiga rättigheter (inklusive alla nödvändiga patentlicenser) för de standarder och filformat som myndigheten avser ställa krav på i de projekt som myndigheten genomför för att upphandla respektive utveckla programvara för att tillgodose myndighetens egna behov. Av samma skäl är det dessutom mycket viktigt att en myndighet som har ambitionen att möjliggöra interoperabilitet undviker att referera till en specifikation som ej uppfyller definitionen av öppen standard enligt EIF 1.0 även om denna specifikation uppfyller definitionen av öppen specifikation enligt EIF 2.0 eller uppfyller definitionen av öppen specifikation enligt EIF 3.0.

6.4. Öppen programvara tillhandahållen genom lokal installation

Programvaruprojekt som utvecklar, förvaltar och tillhandahåller öppen programvara kan vara organiserade på flera olika sätt (se figur 1 för en översikt) där projekten engagerar individer som representerar olika organisationer, däribland företag, myndigheter samt andra typer av intressenter. Individer, företag, myndigheter och andra typer av organisationer kan bidra till utvecklingen av öppen programvara i ett enskilt programvaruprojekt på många olika sätt.

Oavsett huruvida en myndighet har, eller saknar, strategiskt inflytande över ett specifikt programvaruprojekts vidare utveckling och förvaltning kan myndigheten anskaffa öppen programvara från projektet för lokal installation och drift inom den egna myndigheten. Lokal drift av öppen programvara för användning inom en myndighet kan hanteras av personal från den egna myndigheten, i samverkan med personal från andra myndigheter, eller av personal från externa organisationer som engagerats av myndigheten.

En myndighets anskaffning av öppen programvara för lokal installation och användning kan genomföras inom ramen för en offentlig upphandling och beroende på behov även inkludera anpassning av programvaran från ett, i förhållande till myndigheten, externt förvaltat programvaruprojekt. Anskaffning av öppen programvara för lokal drift inom en myndighet kan omfatta vidareutveckling av befintlig, samt utveckling av ny, programvara som genomförs på olika sätt. Exempelvis kan olika konstellationer av myndighetens egen personal, personal från andra myndigheter, samt personal från externa organisationer som engagerats av myndigheten vara involverade i olika former av samverkan.

När en myndighet anskaffar, eller själv bedriver, utveckling av en öppen programvara kan den sammantagna arbetsinsatsen som ligger bakom utvecklingen av källkoden för det första exemplaret av programvaran vara mycket stor. Däremot kan kostnaden för att tillhandahålla källkoden för exemplar två av samma programvara (i princip) vara lika med noll under förutsättning att programvaran tillhandahålls under någon licens för öppen programvara. Utifrån detta kan en myndighet, i många scenarier, ha mycket att vinna på en öppen

Version: 1.0 50 (96) 20 maj 2020


samverkan med andra myndigheter och andra externa intressenter för att utveckla och förvalta olika komponenter (byggblock) av öppen programvara. Enskilda byggblock av öppen programvara kan, i flera scenarier för en myndighet, vara av stor strategisk betydelse för flera myndigheter och andra intressenter utifrån ett syfte av stärkt kostnadseffektivitet och full kontroll på den programvara som en specifik organisation är beroende av.

Rekommendation till myndigheten: Av dessa skäl kan det, i vissa scenarier, vara av stor vikt för en myndighet att endast använda öppen programvara som är lokalt installerad och som används med lokal drift inom den egna myndigheten. För en myndighet är det mycket viktigt att ha tillgång till öppen programvara som kan användas, inom den egna myndigheten, för att behandla och förvalta alla uppgifter i de handlingar som inkommit till, upprättats inom samt behöver återanvändas av den egna myndigheten. Detta förutsätter tillgång till öppen programvara under hela den tidsperiod som omfattar livscykeln för respektive handling och att programvaran kan användas av myndigheten under hela denna tid för att juridiskt och tekniskt korrekt kunna tolka (både för att läsa och för att skriva) filer i de filformat som används för att representera de handlingar som myndigheten behöver förvalta.

6.5. Öppen programvara tillhandahållen som tjänst

Vissa programvaruprojekt som tillhandahåller öppen programvara har specifika erbjudanden om drift av programvaran som en tjänst. För en myndighet kan det, i vissa scenarier, vara relevant att anskaffa och använda programvara som en extern organisation tillhandahåller som en tjänst. I princip kan den externa organisationen vara vilken annan organisation som helst, såväl andra svenska myndigheter som externa (svenska och internationella) företag. Olika former av myndighetssamverkan kan också vara relevanta där myndigheter, företag och andra intressenter kan samverka för att vidareutveckla och tillhandahålla öppen programvara som en tjänst till flera organisationer.

Om en myndighet är beroende av att använda programvara som tillhandahålls som tjänst av någon extern organisation som träffas av utländsk lagstiftning, vare sig det är öppen eller sluten programvara, saknar myndigheten full kontroll på den programvara som används. Även om en myndighet har avtal med de leverantörer som tillhandahåller den specifika programvara som tjänst som myndigheten är beroende av kan det tänkas att villkoren för användning kan komma att förändras527 på ett sätt som är ogynnsamt528 för myndigheten.

I händelse av att öppen programvara tillhandahålls som tjänst där behandling av data sker andra länder innebär detta att en myndighets användning av tjänsten kan påverkas och träffas av utländsk lagstiftning, potentiellt flera andra jurisdiktioner, beroende hur avtalsvillkoren för tjänsten utformats529 . Exempelvis behöver en myndighet beakta frågor om upphovsrätt (under olika jurisdiktioner) och under vilken lagstiftning som eventuella tvister avseende program-varan kan komma att avgöras.

Då öppen programvara tillhandahålls som tjänst kan det tänkas, beroende på under vilka licenser programvaran tillhandahålls, att det inte sker någon extern distribution av program-varan530. Bland individer och organisationer som bidrar till och är engagerade med olika programvaruprojekt som tillhandahåller öppen programvara är det inte så uppskattat, även om det kan vara tillåtet utifrån de licenser som används, om exempelvis en större organisation drar nytta av utvecklingen inom ett projekt och tillhandahåller programvaran som tjänst utan att på något sätt bidra tillbaka till själva projektet531.

Version: 1.0 51 (96) 20 maj 2020


För organisationer som är engagerade med och bidrar till ett programvaruprojekt som tillhandahåller öppen programvara, samt för en myndighet som har behov av att använda programvara från projektet, kan det för flera parter finnas ömsesidiga intressen att tillse så att myndigheten har tillgång till en komplett och fullt funktionell lokalt installerad öppen programvara och samtidigt också har tillgång till att använda samma programvara som tjänst. För en myndighet kan det i vissa scenarier vara mycket väsentligt att med mycket kort varsel, oavsett orsak, ha möjlighet att kunna ersätta användning av öppen programvara som tillhandahålls som en tjänst och istället använda en (identisk) öppen programvara som är lokalt installerad för användning med lokal drift532 .

Innan en myndighet anskaffar och börjar använda en öppen programvara som tillhandahålls som tjänst är det mycket viktigt att myndigheten försäkrar sig om att det finns juridisk533 , teknisk534 och ekonomisk535 möjlighet att med annan öppen programvara kunna behandla och återanvända alla uppgifter i de handlingar som myndigheten kommer att upprätta och förvalta med hjälp av tjänsten536 .

I händelse av att myndigheten saknar tillgång till detaljerad information om exakt hur en programvara som tillhandahålls som tjänst representerar handlingar finns stora risker för problematisk inlåsning genom att myndigheten saknar möjlighet att granska huruvida de handlingar som kommer att upprättas vid användning av tjänsten kommer att kunna förvaltas oberoende av tjänsten537 . Det finns flera möjliga orsaker till detta. En möjlig orsak utgörs av att myndigheten saknar tillgång till (och saknar möjlighet att ta del av) den kompletta källkoden för den programvara538 som är identisk med den programvara som tillhandahålls som tjänst. Utan tillgång till programvarans källkod saknas möjlighet att granska hur filformaten har implementerats i den programvara som har tillhandahållits539 (och som tillhandahålls) som tjänst under hela den tidsperiod då myndigheten använt tjänsten. En annan möjlig orsak utgörs av att den tekniska specifikation som ligger till grund för implementationen av specifikationen i programvaran saknas, eller att specifikationen ej är tillgänglig (och ej kan tillgängliggöras) för myndigheten. Detta innebär att myndigheten saknar möjlighet att kunna avgöra huruvida (och i så fall exakt hur) programvaran följer någon tillgänglig teknisk specifikation för att representera uppgifter i de handlingar som upprättas vid användning av tjänsten. I båda dessa fall hindras vidare förvaltning av handlingar som upprättas med hjälp av den programvara som myndigheten använt (som en tjänst) i en framtida situation då myndigheten avvecklat användning av tjänsten. I en sådan situation kommer myndigheten inte kunna förvalta dessa handlingar oberoende av tjänsten. Det ska poängteras att denna rekommendation inte är unik för öppen programvara som tillhandahålls som tjänst. Rekommendationen är än viktigare540 att beakta för en myndighet som står inför beslut om att anskaffa och börja använda sluten programvara som tjänst, speciellt i situationer då myndighetens användning av tjänsten träffas av utländsk lagstiftning.

Rekommendation till myndigheten: Av dessa skäl kan det, i vissa scenarier, för en myndighet vara relevant att använda öppen programvara som tillhandahålls som tjänst av någon extern organisation som den egna myndigheten har lämpliga avtal med. Innan en myndighet accepterar avtal med en extern organisation förutsätts att den egna myndigheten har tillgång till alla avtalsvillkor541 för tjänsten samt att myndigheten har genomfört en juridisk, teknisk, ekonomisk och samhällelig analys av alla dessa avtalsvillkor542 som resulterat i slutsatsen att det är lämpligt att myndigheten accepterar avtalsvillkoren. Samtidigt kan det vara mycket viktigt för en myndighet, beroende på hur strategisk användningen av programvaran är för

Version: 1.0 52 (96) 20 maj 2020


myndigheten543, att tillse att den egna myndigheten dessutom kontinuerligt har tillgång till den kompletta källkoden för programvaran och en lokalt installerad (identisk och fullt funktionell kopia på tillhandahållen) öppen programvara som kan tas i drift med kort544

varsel. Detta förutsätter tillgång till all öppen programvara som har använts under hela den tidsperiod som täcker hela livscykeln för respektive handling och att programvaran kan användas av myndigheten under hela denna tid för att juridiskt och tekniskt korrekt kunna tolka (både för att läsa och för att skriva) filer i de filformat som används för att representera de handlingar som myndigheten behöver förvalta. För myndigheter som använder öppen programvara, samt för organisationer som tillhandahåller denna programvara, som utvecklas inom programvaruprojekt kan det vara av mycket stor strategisk betydelse för myndigheten att vara engagerad med projektet för att upprätthålla kunskap och kompetens kring den programvara som är betydelsefull för den egna myndigheten.

6.6. Öppen programvara och forskning

Ett vetenskapligt förhållningssätt och användning av vetenskapliga metoder för att utveckla kunskap karaktäriseras av en systematisk process där data, källor, hypoteser och material finns publikt tillgängliga för återanvändning och kritisk granskning av andra forskare på sätt som har betydande likheter med processer för att utveckla öppen programvara545. Forskare har identifierat flera fördelar med en öppen ansats för den vetenskapliga processen, däribland en snabbare process, stärkt kostnadseffektivitet och förbättrad transparens546 .

För utvecklingen inom datavetenskap och relaterade områden har idéer som ligger till grund för fri och öppen programvara genom åren haft stor betydelse, där transparent tillgång till en programvaras källkod under villkor som möjliggör återanvändning och vidareutveckling varit viktig för kunskapsutvecklingen inom många områden547 . Inom flera vetenskapsområden, som exempelvis GIS-området548, astronomi549 och många andra områden, har öppen programvara haft stor betydelse för kunskapsutveckling och kommit att utgöra viktiga inslag i den vetenskapliga metoden.

Ett stort antal forskare använder och utvecklar öppen programvara som en naturlig del av forskningsprocessen. Utöver banbrytande innovationer som webben (ett resultat från CERN550) finns det flera exempel på betydelsefull forskning där öppen programvara haft stor betydelse för forskning och innovation, exempelvis har arbetet med White Rabbit551 haft en avgörande betydelse för viktiga upptäckter inom fysikens område552 vilket lett till flera betydelsefulla tillämpningar, som en sidoeffekt, inom helt andra områden som exempelvis i finansbranschen och inom meteorologin.

I Sverige har exempelvis SMHI länge varit aktiva i flera programvaruprojekt, däribland det internationella samverkansprojektet Pytroll som utvecklar öppen programvara som tillhandahålls under GPL 3.0 och LGPL 3.0 för att behandla satellitdata553. Ett annat programvaruprojekt från vilket SMHI tillhandahåller öppen programvara (under LGPL) är HYPE (HYdrological Predictions for the Environment)554.

I många länder finns det bland olika intressenter en förväntan på att resultat från forskning ska bli allmänt tillgängliga och speciellt då forskning genomförs inom ramen för forsknings-projekt som till 100 % finansieras av skattemedel555 . Incitament och traditioner för hur data och resultat hanteras varierar mellan olika forskningsområden, men inom flera områden är det långt ifrån ovanligt att forskare regelbundet publicerar resultat under villkor som möjliggör att

Version: 1.0 53 (96) 20 maj 2020


resultat publicerade i vetenskapliga tidskrifter delas som öppet innehåll556 . Bland forskare som utvecklar programvara förekommer också, som en naturlig del av den vetenskapliga metoden eller som del av själva resultaten från ett forskningsprojekt, att den programvara som utvecklas under genomförandet av ett forskningsprojekt tillhandahålls som öppen programvara. Flera finansiärer av forskning ställer krav på att ett forskningsprojekt ska ha en plan för hur de forskningsprojekt som finansieras kommer att hantera de forskningsdata som upprättas, behandlas och förvaltas under genomförandet av, samt efter avslut av, projektet. En sådan plan bör lämpligen557 inkludera strategier för långsiktig förvaltning och val av licenser för etablerade programvaruprojekt som tillhandahåller öppen programvara under, samt efter, genomförande av ett forskningsprojekt.

För ett forskningsprojekt och dess intressenter, speciellt om projektet involverar organisa-tioner som drivs av kommersiella intressen, är det mycket viktigt att tidigt komma överens om hur data och programvara ska hanteras under och efter genomförandet av projektet. Forskningsprojekt kan exempelvis föreskriva en policy som säger att all ny programvara som utvecklas inom ramen för ett projekt ska tillhandahållas under ’GPL 3.0 or later’ och att alla resultat som publiceras ska tillhandahållas under ’CC-BY-SA 4.0’ för att stimulera återanvändning och ett öppet ekosystem kring de resultat som utvecklas under genomförandet av forskningsprojektet.

För organisationer som bedriver forskning, som exempelvis CERN, är det mycket viktigt att ha en genomtänkt strategi för licensering av de resultat som utvecklas från genomförd forskning558 . Utifrån analyser har GPL 3.0 kommit att bli den standardlicens som används vid utveckling av programvara som tillhandahålls från programvaruprojekt som leds av CERN. I speciella fall, som exempelvis vid utveckling av programvarubibliotek, kan CERN istället använda licensen LGPL 3.0 som alternativ för att möjliggöra snabb spridning av dessa bibliotek559. För en organisation som bidrar till successiv kunskapsutveckling är dessa licenser ett lämpligt val560. Även från EU har användning av licenser med en effekt av copyleft rekommenderats som en lämplig strategi för att skydda fortsatt öppenhet och hindra att resultat från forskningen stängs561 . Som ett undantag möjliggör CERN:s policy att Apache 2.0 används då externa intressenter hindrar användning av copyleft (under GPL 3.0 eller LGPL 3.0) och i situationer då CERN saknar behov av att ha fortsatt kontroll över möjligheterna att vidareförädla öppen programvara som utvecklas inom ramen för ett programvaruprojekt562 . Utöver programvara har CERN tagit initiativ till att utveckla hårdvara i en öppen samverkan563 och har som en del av detta arbete utvecklat specifika licenser som är anpassade för tillhandahållande av öppen hårdvara564.

Rekommendation till myndigheten: En myndighet som, direkt eller indirekt, har inflytande på vilken programvara som används under genomförande av ett forskningsprojekt rekommenderas agera proaktivt för att ställa krav på att alla data och handlingar som behandlas under genomförandet av ett forskningsprojekt upprättas och förvaltas i öppna filformat och öppna standarder (se rad #1, rad #2, rad #3 och rad #4 i tabell 1). Om ett forskningsprojekt agerar utifrån detta krav minimeras risken för att data och handlingar som upprättats under genomförandet av forskningsprojektet inte kan förvaltas och återanvändas efter att projektet har avslutats. På motsvarande sätt bör en myndighet som har inflytande på hur ett forskningsprojekt genomförs ställa krav på att alla handlingar som upprättats inom ramen för ett forskningsprojekt är representerade i ett (eller flera) öppna filformat innan projektet avslutas och att det för samtliga dessa öppna filformat existerar öppen programvara

Version: 1.0 54 (96) 20 maj 2020


som kan användas för att tolka (både för att läsa och för att skriva) filer i samtliga dessa öppna filformat (se rad #1 och rad #2 i tabell 1). Om en myndighet och ett forskningsprojekt agerar för att långsiktigt förvalta all öppen programvara som behövs för att kunna tolka de data och handlingar som upprättats under genomförandet av projektet finns möjlighet att i framtiden återanvända data. Utifrån detta ställs det krav på att alla projekt endast agerar utifrån rad #1 och rad #2 i tabell 1. Det ska noteras att dessa rekommendationer inte innebär att det ställs krav på öppet innehåll (d.v.s. denna rekommendation ställer inte något krav enligt rad #1 i tabell 1). Det är viktigt att alla myndigheter, även myndigheter som själva inte aktivt deltar i forskningsprojekt, upprättar och förvaltar uppgifter i handlingar som representeras i öppna filformat för att möjliggöra återanvändning och förvaltning av uppgifter i dessa handlingar. Det ska betonas att slutna filformat aldrig bör användas av en myndighet som tillhandahåller data och andra handlingar (d.v.s. en myndighet bör alltid undvika rad #5, rad #6, rad #7 och rad #8 i tabell 1).

6.7. Öppen programvara och kompetensutveckling

Programvaruprojekt som tillhandahåller öppen programvara har visat sig kunna fungera bra för utveckla öppen programvara i såväl små som stora samverkansprojekt565 . Då individer och organisationer engagerar sig med programvaruprojekt som utvecklar och tillhandahåller öppen programvara från en kunskapsintensiv öppen samverkan som bedrivs på en öppen plattform skapas värden i form av producerad öppen programvara och relaterade digitala handlingar som kan användas, återanvändas och vidareförädlas av alla intresserade individer och organisationer566.

Att regelbundet studera och engagera sig med programvaruprojekt som tillhandahåller öppen programvara är ett utmärkt sätt för individer och organisationer att systematiskt och långsiktigt arbeta med sin kompetensförsörjning. Organisationen av dessa projekt erbjuder unika möjligheter och ett system för kompetensutveckling567.

Resultat från en forskningsstudie visar att många professionella programmerare i svenska organisationer sätter stort värde på möjligheten att vidareutveckla sin egen kompetens genom att engagera sig med olika programvaruprojekt som tillhandahåller öppen programvara och därigenom kunna ta del av hur andra utvecklare löser problem, samtidigt som det finns möjlighet att genom egna bidrag till projektet också kunna påverka och ha inflytande på projektets vidare utveckling568.

Rekommendation till myndigheten: En myndighet som, direkt eller indirekt, har inflytande på den långsiktiga kompetensförsörjningen inom viktiga områden för myndighetens verksamhet rekommenderas stimulera kunskapsutveckling och organisatoriskt lärande genom att uppmuntra att personal som utvecklar programvara ges möjlighet att vara engagerade med programvaruprojekt som tillhandahåller öppen programvara. Då en myndighet är aktiv inom strategiskt viktiga programvaruprojekt ges unika möjligheter till strategisk omvärlds-bevakning vilket bidrar till att berika myndighetens personal och skapa en intellektuellt stimulerande arbetsmiljö för myndighetens personal. Genom detta vidgar också en myndighet sitt informella kontaktnät vilket långsiktigt berikar verksamheten.

Version: 1.0 55 (96) 20 maj 2020


Referenser

Aliprandi, S. (2011) Interoperability And Open Standards: The Key To True Openness And Innovation, International Free and Open Source Software Law Review, Vol. 3(1): 5-24.

Alspaugh, T. A., Scacchi, W. & Asuncion, H. U. (2010) Software Licenses in Context: The Challenge of Heterogeneously-Licensed Systems, Journal of the Association of Information Systems, Vol. 11(11): 730-755.

Altsitsiadis, E. (2014) Round Table Report: Patent non-aggression pacts: a way forward for technological innovation?, Rapporteur: Dr. Efthymios Altsitsiadis, Speakers: Mirko Boehm, Carlo Piana, Clara Neppel, Moderator: Graham Taylor, OpenForum Academy, 19 February 2014, Silken Berlaymont Hotel, Brussels.

Andreesen, M. (2011) Why Software Is Eating The World, The Wall Street Journal, 20 August.

Anthes, G. (2016) Open Source Software No Longer Optional, Communications of the ACM, Vol. 59(8): 15-17.

Ayala, C. P., Cruzes, D. S., Hauge, O. & Conradi, R. (2011) Five Facts on the Adoption of Open Source Software, IEEE Software, Vol. 28(2): 95-99.

Baron, J., Pohlmann, T. & Blind, K. (2016) Essential patents and standard dynamics, Research Policy, Vol. 45(9): 1762-1773.

Behlendorf, B. (2009) How Open Source Can Still Save the World, In Boldyreff, C. et al. (Eds.) Open Source Ecosystems: Diverse Communities Interacting, IFIP Advances in Information and Communication Technology, Vol. 299, Springer, Berlin, p. 2.

Benkler, Y. (2006) The Wealth of Networks: How Social Production Transforms Markets and Freedom, Yale University Press, New Haven, ISBN-13: 978-0-300-11056-2.

Blind, K. & Böhm, M. (2019) The Relationship Between Open Source Software and Standard Setting, Thumm, N. (Ed.) EUR 29867 EN, JRC (Joint Research Centre) Science for Policy Report, Publications Office of the European Union, Luxembourg, 2019, ISBN 978-92-76-11593-9.

Boehm, M. (2019) The emergence of governance norms in volunteer-driven open source communities, Journal of Open Law, Technology, & Society, Vol. 11(1): 3-39.

Boldyreff, C., Crowston, K., Lundell, B. & Wasserman, A. I. (2009) (Eds.) (2019) Open Source Ecosystems: Diverse Communities Interacting, IFIP Advances in Information and Communication Technology, Vol. 299, Springer, Berlin.

Bretthauer, D. (2002) Open Source Software: A History, Information Technology and Libraries, Vol. 21(1): 3-10.

Brock, A. (2013) Understanding Commercial Agreements With Open Source Companies, In Coughlan, S. (Ed.) Thoughts on Open Innovation: Essays on Open Innovation from leading thinkers in the field, An OpenForum Academy publication, OpenForum Europe, ISBN: 978-1-304-01551-8, pp. 119-139.

Brooks, R. G. & Geradin, D. (2011) Interpreting and Enforcing the Voluntary FRAND Commitment, International Journal of IT Standards and Standardization Research, Vol. 9(1), pp. 1-23.

Bruce, G. L., Wittgreffe, J. P., Potter, J. M. M. & Robson, P. (2005) The potential for open source software in telecommunications operational support systems, BT Technology Journal, Vol. 23(3): 79-95.

Version: 1.0 56 (96) 20 maj 2020


Butler, S., Gamalielsson, J., Lundell, B., Brax, C. Sjöberg, J., Mattsson, A., Gustavsson, T., Feist, J. & Lönroth, E. (2019) On Company Contributions to Community Open Source Software Projects, IEEE Transactions on Software Engineering.

Butler, S., Gamalielsson, J., Lundell, B., Brax, C., Mattsson, A., Gustavsson, T., Feist, J. & Lönroth, E. (2020) Maintaining Interoperability in Open Source Software: A Case Study of the Apache PDFBox Project, Journal of Systems and Software, Vol. 159.

Byttner, K.-J. (2004) Linux ett måste - öppen källkod ska ingå i statens upphandlingar, Computer Sweden, 2 februari.

Carelink (2005) Collaborating Through Open Source Software: Legal concerns affecting contracting entities, Carelink.

Cassel, D. (2020) Why Bruce Perens Is Proposing ‘Coherent Open Source’, The New Stack, 5 February.

CERN (2012) Open Source Software Licence at CERN: Recommendations from the OSL Task Force, Final Report OSL-2012, Open Source Licence Task Force, CERN, 20 April.

CERN (2020) Licensing the Web, CERN, 15 February.

Chapin, L. (1992) The Internet Standards Process, RFC 1310, Internet Activities Board, March. https://tools.ietf.org/pdf/rfc1310

Chicago (2001) Microsoft CEO takes launch break with the Sun-Times, Chicago Sun Times, 1 juni.

Cockroach (2019) Why We’re Relicensing CockroachDB, Cockroach Labs, 4 June.

Cohn, A. G. & Spiegel, G. (2011) Effective Open Source Development Business Practices, The Computer & Internet Lawyer, Vol. 28(1): 1-17.

Contreras, J. L. (2016) Patents and Internet Standards, Centre for International Governance Innovation and Chatham House, Paper Series No. 29, April.

Copyleft (2019) Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide, copyleft.org, Accessed: 19 June.

Cygnos (2006) Marketing Cygnus Support – Free Software history, Last update 27 September,

Daimler (2018) Licence Agreement: Supplement, EvoBus – A Daimler Company, Daimler AG, Stuttgart, 27 July.

Daimler (2019) Licence Agreement: C-Class 205, Supplement, Mercedes-Benz, Stuttgart, 27 July.

David, P. A. & Shapiro, J. S. (2008) Community-based production of open-source software: What do we know about the developers who participate?, Information Economics and Policy, Vol. 20(4): 364-298.

DeBrie, E. & Goeschel, D. (2016) Open Source Software Licenses: Legal Implications and Practical Guidance, The Nebraska Lawyer, March/April, pp. 7-13.

DiBona, C., Ockman, S. & Stone, M. (1999) Introduction, In DiBona, C. et al. (Eds.) Opensources: Voices from the Open Source Revolution, O’Reilly & Associates, ISBN: 1-56592-582-3, pp. 8-15.

DIGG (2019) Policy for utveckling av programvara, Myndigheten för Digital förvaltning (Agency for Digital Government), Dnr. 2019-136, 8 maj.

Donnelly, F. P. (2010) Evaluating open source GIS for libraries, Library Hi Tech, Vol. 28(1): 131-151.

Version: 1.0 57 (96) 20 maj 2020

https://tools.ietf.org/pdf/rfc1310


EC (2001a) Study into the use of Open Source Software in the Public Sector: Part 1 – OSS Fact sheet, European Commission, June.

EC (2001b) Study into the use of Open Source Software in the Public Sector: Part 2 – Use of Open Source in Europe, European Commission, June.

EC (2001c) Study into the use of Open Source Software in the Public Sector: Part 3 – The Open Source Market Structure, European Commission, June.

EC (2001d) Annex: OSS Alphabetical list and Software identification, European Commission, June. http://web.archive.org/web/20050414053339/http://europa.eu.int/idabc/servlets/Doc?id=2009

EC (2003) Expert Group Report on Strategic Use and Adaptation of Intellectual Property Rights Systems in Information and Communications Technologies-based Research, European Commission, Luxembourg, ISBN 92-894-6001-6.

EC (2004) European Interoperability Framework for pan-European eGovernment Services, Version 1.0, European Commission, ISBN 92-894-8389-X. https://ec.europa.eu/idabc/servlets/Docd552.pdf

EC (2008) Draft document as basis for EIF 2.0, European Interoperability Framework for pan-European eGovernment Services, Draft for Public Comments – as basis for EIF 2.0 – 15/07/2008, European Commission.

EC (2010) European Interoperability Framework (EIF) for European public services, COM(2010) 744 final, Annex 2 to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions ‘Towards interoperability for European public services’, European Commission, 16 December.

EC (2012) Implementing FRAND standards in Open Source: Business as usual or mission impossible?, European Commission, 22 November.

EC (2013a) Against lock-in: building open ICT systems by making better use of standards in public procurement, COM(2013) 455 final, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions, European Commission, 25 June.

EC (2013b) Guide for the procurement of standards-based ICT – Elements of Good Practice, SWD(2013) 224 final, Accompanying the document: ‘Against lock-in: building open ICT systems by making better use of standards in public procurement’, COM(2013) 455 final, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions, European Commission, 25 June.

EC (2014) Competition policy brief: Standard-essential patents, Issue 8, European Commission, ISBN 978-92-79-35553-0, June.

EC (2016) European Interoperability Framework (EIF) for European Public Services, EIF Revision, Draft Intermediate Release, February, European Commission.

EC (2017a) European Interoperability Framework - Implementation Strategy, COM(2017) 134 final, ANNEX 2, Annex to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions, SWD(2017) 112 final, SWD(2017) 113 final, European Commission, 23 March.

EC (2017b) Setting out the EU approach to Standard Essential Patents, COM(2017) 712 final, Communication from the Commission to the European Parliament, the Council and the European Economic and Social Committee, European Commission, 29 November.

EC (2020a) Open Source Software Policies: Country Intelligence Reports, European Commission Open Source Observatory (OSOR), 8 April.

Version: 1.0 58 (96) 20 maj 2020

https://ec.europa.eu/idabc/servlets/Docd552.pdf

http://web.archive.org/web/20050414053339/http://europa.eu.int/idabc/servlets/Doc?id=2009


EC (2020b) Open Source Software Country Intelligence Report – Sweden 2020, DG DIGIT, European Commission, February.

Eclipse (2011) The Open Source Developer Report 2011: Eclipse Community Survey, The Eclipse Foundation, San Francisco, June.

Engelfriet, A. (2010) Choosing an Open Source License, IEEE Software, Vol. 27(1): 48-49.

Ensmenger, N. L. (2004) Open Source’s Lessons for Historians, IEEE Annals of the History of Computing, Vol. 26(4): 102-104.

EU (2012) Guide for the procurement of standards-based ICT: Elements of Good Practice, European Economics, D2 – Overview of Procurement Practices, Final Report, Study for the EU, Action 23, 1 March.

EU (2017) Tallinn Declaration on eGovernment, EU2017.EE, 6 October.

Fitzgerald, A. & Bassett, G. (2003) Legal Issues Relating to Free and Open Source Software, In Fitzgerald, A. & Bassett, G. (Eds.) Essays in Technology Policy and Law Volume 1, Queensland University of Technology School of Law, ISBN 0-9751394-0-1, pp. 11-36.

Fitzgerald, B. (2006) The Transformation of Open Source Software, MIS Quarterly, Vol. 30(3): 587-598.

FLOSS (2002a) Free/Libre and Open Source Software: Survey and Study, Final Report, Part 0: Table of Contents and Executive Summary, International Institute of Infonomics, University of Maastricht and Berlecon Research GmbH, June.

FLOSS (2002b) Use of Open Source Software in Firms and Public Institutions Evidence from Germany, Sweden and UK, FLOSS Final Report – Part 1, Free/Libre Open Source Software: Survey and Study, Berlecon Research, Berlin, July.

FLOSS (2002c) Open Source Software in the Public Sector: Policy within the European Union, FLOSS Final Report – Part 2b, Free/Libre Open Source Software: Survey and Study, Berlecon Research, Berlin, June.

FLOSS (2002d) Basics of Open Source Software Markets and Business Models, FLOSS Final Report – Part 3, Free/Libre Open Source Software: Survey and Study, Berlecon Research, Berlin, July.

FLOSSPOLS (2005) Open Standards and Interoperability Report: An Economic Basis for Open Standards, Deliverable D4, MERIT, University of Maastricht, flosspols.org http://flosspols.merit.unu.edu/deliverables/FLOSSPOLS-D04-openstandards-v6.pdf

Fogel, K. (2019) Producing Open Source Software: How to Run a Successful Free Software Project, 2nd Ed., Version: 2.3168, O’Reilly Media, https://producingoss.com/

Fontana, R., Kuhn, B. M., Moglen, E., Norwood, M., Ravicher, D. B., Sandler, K., Vasile, J. & Williamson, A. (2008) A Legal Issues Primer for Open Source and Free Software Projects, Version 1.5.1, 3 March, Software Freedom Law Center, New York.

Fontana, R. E. (2010) Open Source License Enforcement and Compliance, The Computer & Internet Lawyer, Vol. 27(4): 1-15.

Försäkringskassan (2018) Riktlinjer för öppen källkod, Dnr. 15918-2018, Försäkringskassan, 17 December.

Försäkringskassan (2019) Vitbok – Molntjänster i samhällsbärande verksamhet – risker, lämplighet och vägen framåt, Dnr. 013428-2019, Version 1.0, 18 november.

Version: 1.0 59 (96) 20 maj 2020

https://producingoss.com/

http://flosspols.merit.unu.edu/deliverables/FLOSSPOLS-D04-openstandards-v6.pdf

https://EU2017.EE


FSF (2020a) Definitionen av fri programvara, Free Software Foundation, senast uppdaterad 2 maj 2017. https://www.gnu.org/philosophy/free-sw.sv.html

FSF (2020b) What is free software?, Free Software Foundation, senast uppdaterad 30 juli 2019. https://www.gnu.org/philosophy/free-sw.sv.html

FSG (2005) The Imperative for Linux Standards: A Recommendation for the Future, A White Paper Prepared by the Free Standards Group, Free Standards Group, 1 August.

GAIA-X (2019) Project GAIA-X: A Federated Data Infrastructure as the Cradle of a Vibrant European Ecosystem, Federal Ministry for Economic Affairs and Energy (BMWi) & Federal Ministry of Education and Research, Berlin, October 2019.

Gaff, B. M. & Ploussios, G. J. (2012) Open Source Software, Computer, Vol. 45(6): 9-11.

Gartner (2010) What Every IT Practitioner Needs to Know About OSS, Gartner, 5 October.

Gamalielsson, J. & Lundell, B. (2014) Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?, The Journal of Systems and Software, Vol. 89(1): 128-145.

Gamalielsson, J. & Lundell, B. (2017) On licensing and other conditions for contributing to widely used open source projects: an exploratory analysis. In Proceedings of the 13th International Symposium on Open Collaboration (OpenSym ’17). ACM, New York, Article 9, 14p.

Ghosh, R. A. (2003) Open Source as a training system and US/EU differences, In Expert Group Report on Strategic Use and Adaptation of Intellectual Property Rights Systems in Information and Communications Technologies-based Research, European Commission, Luxembourg, ISBN 92-894-6001-6, pp. 61-73.

Ghosh, R. A. (2010) Open Source Software: Economics, Innovation, Law and Policy, In Yu, P. K. (Ed.) The WIPO Journal, Vol. 2(1), World Intellectual Property Organisation, pp. 82-92.

González-Barahona, J. M. (2004) Quo vadis, libre software?, v0.8.1, September. https://web.archive.org/web/20041207003919/http://sinetgy.org/jgb/articulos/libre-software-origin/

Greenstein, S. & Nagle, F. (2014) Digital dark matter and the economic contribution of Apache, Research Policy, Vol. 43: 623-631.

Grodsten Kennedy, J. (2011) Updating the Mozilla Public License: An Analysis of the Key Terms and Provisions in MPL 2.0, The Computer & Internet Lawyer, Vol. 28(6): 18-30.

Haapanen, A. (2015) Free and Open Source Software & the Mystery of Software Patent Licenses, International Free and Open Source Software Law Review, Vol. 7(1): 19-28.

Haapanen, A. (2017) Free and Open Source Software Licensing and the Mystery of Licensor’s Patents, Ph.D. dissertation, University of Helsinki. Law Review.

Haff, G. (2019) The mysterious history of the MIT License, opensource.com, 26 April. https://opensource.com/article/19/4/history-mit-license

Hahn, E. N. (2014) An Overview of Open-Source Software Licenses and the Value of Open-Source Software to Public Health Initiatives, Johns Hopkins APL Technical Digest, Vol. 32(4): 690-698.

Held, B. (2004) Interoperability: The EU perspective, In Open Standards and Libre software in Government, The Hague, 18 November.

Ilardi, T. J. (2011) Client Counseling for Common OSS License Problems, The Computer & Internet Lawyer, Vol. 31(12): 1-18.

Version: 1.0 60 (96) 20 maj 2020

https://opensource.com/article/19/4/history-mit-license

https://web.archive.org/web/20041207003919/http://sinetgy.org/jgb/articulos/libre-software-origin/

https://www.gnu.org/philosophy/free-sw.sv.html

https://www.gnu.org/philosophy/free-sw.sv.html


James, P. J. C. (2003) Open Source Software: An Australian Perspective, In Fitzgerald, A. & Bassett, G. (Eds.) Essays in Technology Policy and Law Volume 1, Queensland University of Technology School of Law, ISBN 0-9751394-0-1, pp. 63-88.

Kammarkollegiet (2010) Förstudie: Programvaror 2010, Förstudierapport FS: 2010:01, Dnr. 93-10-14, Kammarkollegiet.

Kammarkollegiet (2011) Beslut avseende avtal för IKT-produkter och tjänster, Dnr. 93-36-10, Kammarkollegiet, 28 januari.

Kammarkollegiet (2014a) Förstudie: Programvaror och tjänster 2013, Dnr. 96-40-2013, Kammarkollegiet, 5 februari.

Kammarkollegiet (2014b) Bilaga: Avropsregler Programvaror och tjänster 2014 - Grundläggande it, Dnr. 96-34-2014, Kammarkollegiet, 24 september.

Kammarkollegiet (2016) Öppna standarder: Programvaror och tjänster 2014, Dnr 96-38-2014, Kammarkollegiet, 7 mars.

Kammarkollegiet (2017a) Förstudierapport inom Programvaror och tjänster, Dnr 23.2-1111-2017, Kammarkollegiet, 9 juni.

Kammarkollegiet (2017b) Bilaga: Kravkatalog Programvaror & tjänster, Dnr 23.3-5559-17, Kammarkollegiet, 15 november.

Kammarkollegiet (2018a) Bilaga: Allmänna villkor Programvaror & tjänster, Dnr 23.3-6188-17, Kammarkollegiet, 22 januari.

Kammarkollegiet (2018b) Bilaga: Särskilda villkor för Öppen källkod Programvaror & tjänster, Dnr 23.3-6188-17, Kammarkollegiet, 22 januari.

Kapitsaki, G. M., Tselikas, N. D. & Foukarakis, I. E. (2015) An insight into license tools for open source software systems, Journal of Systems and Software, Vol. 102: 72-87.

Kappos, D. J. (2017) Comment – Open Source Software and Standards Development Organizations: Symbiotic Functions in the Innovation Equation, The Columbia Science & Technology Law Review, Vol. XVIII, Spring, pp. 259-267.

Kesan, J. (2011) The Fallacy of OSS Discrimination by FRAND Licensing: An Empirical Analysis, Illinois Public Law and Legal Theory, Research Papers Series No. 10-14.

King, R. (2014) Open Source ‘Eating’ Software World: Samsung, The Wall Street Journal: CIO Journal, 5 May.

Laurent, A. M. St. (2004) Understanding Open Source and Free Software Licensing, O’Reilly Media, Sebastopol, ISBN: 0596005814.

Lerner, J & Tirole, J. (2005) The Scope of Open Source Licensing, The Journal of Law, Economics, & Organization, Vol. 21(1): 20-56.

Lindberg, V. (2008) Intellectual Property and Open Source: A Practical Guide to Protecting Code, O’Reilly Media, Sebastopol, ISBN: 978-0-596-51796-0.

Lindberg, V. (2019) Comment – OSS and FRAND: Complementary Models for Innovation and Development, The Columbia Science & Technology Law Review, Vol. XX, Spring.

Lundell, B., Lings, B. & Lindqvist, E. (2010) Open Source in Swedish Companies: Where are We?, Information Systems Journal, Vol. 20(6): 519-535.

Version: 1.0 61 (96) 20 maj 2020


Lundell, B. & Gamalielsson, J. (2017) On the potential for improved standardisation through use of open source work practices in different standardisation organisations: How can open source-projects contribute to development of IT-standards?, In Blind, K. & Jakobs, K. (Eds.), Digitalisation: Challenge and Opportunity for Standardisation: Proceedings of the 22nd EURAS Annual Standardisation Conference, EURAS Contributions to Standardisation Research, Vol. 12. Verlag Mainz, Aachen, ISBN 978-3-95886-172-5, pp. T137-T155.

Lundell, B. & Gamalielsson, J. (2018) Sustainable digitalisation through different dimensions of openness: how can lock-in, interoperability, and long-term maintenance of IT systems be addressed?, In OpenSym ‘18, ACM, New York, ISBN 978-1-4503-5936-8.

Lundell, B., Gamalielsson, J. & Katz, A. (2015) On implementation of Open Standards in software: To what extent can ISO standards be implemented in open source software?, International Journal of Standardization Research, Vol. 13(1): 47-73.

Lundell, B., Gamalielsson, J. & Katz, A. (2018) On Challenges for Implementing ISO Standards in Software: Can Both Open and Closed Standards Be Implemented in Open Source Software?, In Jakobs, K. (Ed.) Corporate and Global Standardization Initiatives in Contemporary Society, IGI Global, Hershey, pp. 219-251.

Lundell, B., Gamalielsson, J. & Katz, A. (2019) Implementing IT Standards in Software: challenges and recommendations for organisations planning software development covering IT standards, European Journal of Law and Technology, Vol. 10(2).

Lundell, B., Gamalielsson, J. & Tengblad, S. (2016) IT-standarder, inlåsning och konkurrens: En analys av policy och praktik inom svensk förvaltning, Uppdragsforskningsrapport 2016:2, Konkurrensverket, ISSN: 1652-8089.

Lundell, B., Gamalielsson, J., Tengblad, S., Hooshyar Yousefi, B., Fischer, T., Johansson, G., Rodung, R., Mattsson, A., Oppmark, J., Gustavsson, T., Feist, J., Landemoo, S. & Lönroth, E. (2017) Addressing lock-in, interoperability, and long-term maintenance challenges through Open Source: How can companies strategically use Open Source?, In Balaguer et al. (Eds.) The 13th International Conference on Open Source Systems (OSS 2017), IFIP AICT 496, Springer, pp. 80-88.

McGowan, D. (2001) Legal Implications of Open-Source Software, Illinois Law Review, Vol. 2001(1): 241-304.

McHugh, J. (1998) For the love of hacking, Forbes, 10 August, pp. 94-101.

McKusick, K. (1999) Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable, In DiBona, C. et al. (Eds.) Opensources: Voices from the Open Source Revolution, O’Reilly & Associates, ISBN: 1-56592-582-3, pp. 21-27.

Merges, R. P. & Kuhn, J. M. (2009) An Estoppel Doctrine for Patented Standards, California Law Review, Vol. 97(1): 1-50.

Meeker, H. (2020) Open (Source) for Business: A Practical Guide to Open Source Software Licensing, Third edition, Kindle Direct Publishing Platform, Seattle, ISBN-13: 979-8618201773.

Michaelson, J. (2004) There’s no such thing as a free (software) lunch, Queue, Vol. 2(3): 40-47.

Murray, G. F. (2009) Categorization of Open Source Licenses: More Than Just Semantics, The Computer & Internet Lawyer, Vol. 26(1): 1-11.

Nadan, C. H. (2009) Closing the Loophole: Open Source Licensing & the Implied Patent License, The Computer & Internet Lawyer, Vol. 26(8): 1-6.

Nemiah, V. (2014) License and Registration, Please: Using Copyright “Conditions” to Protect Free/Open Source Software, Journal of Intellectual Property & Entertainment Law, Vol. 3(2): 358-390.

Version: 1.0 62 (96) 20 maj 2020


Netherlands (2007) The Netherlands in Open Connection: An action plan for the use of Open Standards and Open Source Software in the public and semi-public sector, The Ministry of Economic Affairs, The Hague, November.

Netscape (1998) Netscape Announces Plans to Make Next-Generation Communicator Source Code Available Free on the Net, Netscape Communications Corporation, 22 January.

Nilsen, V. & Anelli, G. (2016) Knowledge transfer at CERN, Technological Forecasting & Social Change, Vol. 112: 113-120.

Nowogrodzki, A. (2019) How to support open-source software and stay sane, Nature, Vol. 571: 133-134.

NPS (2016) Open IT-standards, National Procurement Services, Kammarkollegiet, Dnr 96-38-2014, 7 March. https://www.avropa.se/globalassets/dokument/open-it-standards.pdf

OECD (2019) Measuring the Digital Transformation: A Roadmap for the Future, OECD Publishing, Paris, ISBN 978-92-64-31199-2, March.

OKF (2020a) Open Definition 2.1, Open Knowledge Foundation, 27 January. http://opendefinition.org/od/2.1/en/

OKF (2020b) Open Definition: Conformant Licences, Open Knowledge Foundation, 27 January. https://opendefinition.org/licenses/

O’Reilly, T. (1999) Lessons from Open-Source Software Development, Communications of the ACM, Vol. 42(4): 32-37.

O’Reilly, T. (2005) The Open Source Paradigm Shift, In Wynants, M. and Cornelis, J. (Eds.) How Open is the Future?, VUB Brussels University Press, Brussels, ISBN 90-5487-378-7, pp. 85-109.

OSD (2020a) The Open Source Definition, Open Source Initiative, https://opensource.org/osd

OSD (2020b) The Open Source Definition: Annotated, Open Source Initiative, https://opensource.org/ osd-annotated

OSDL (2000) Industry Leaders Including HP, Intel, IBM AND NEC Forming Open Source Development Lab For Linux, Open Source Development Lab, 30 August.

OSI (1998a) Introduction to Open Source, Open Source Initiative, 5 December. http://web.archive.org/web/19981205141453/http://www.opensource.org/intro.html

OSI (1998b) History of the Open Source effort, Open Source Initiative, 6 December. https://web.archive.org/web/19981206185148/http://www.opensource.org/history.html

OSI (1999) Open Source Initiative: the Future is Here, Open Source Initiative, 17 January. http://web.archive.org/web/19990117101010/http://opensource.org/

OSI (2000) The Approved Licenses, Open Source Initiative, 15 August. http://web.archive.org/web/20000815055529/http://www.opensource.org/licenses/

OSL (2020a) Open Source Initiative: Licenses, Open Source Initiative, 27 januari. www.opensource.org/licences

OSL (2020b) Open Source Initiative: Licenses by Name, Open Source Initiative, 27 januari. https://opensource.org/licenses/alphabetical

OSL (2020c) Open Source Initiative: Licenses by Category, Open Source Initiative, 27 januari. https:// opensource.org/licenses/category

Version: 1.0 63 (96) 20 maj 2020

https://opensource.org/licenses/category

https://opensource.org/licenses/category

https://opensource.org/licenses/alphabetical

http://web.archive.org/web/20000815055529/http://www.opensource.org/licenses/

http://web.archive.org/web/19990117101010/http://opensource.org/

https://web.archive.org/web/19981206185148/http://www.opensource.org/history.html

http://web.archive.org/web/19981205141453/http://www.opensource.org/intro.html

https://opensource.org/osd-annotated

https://opensource.org/osd-annotated

https://opensource.org/osd

https://opendefinition.org/licenses/

http://opendefinition.org/od/2.1/en/

https://www.avropa.se/globalassets/dokument/open-it-standards.pdf

www.opensource.org/licences


OSR (2020) Open Source Initiative: Open Standards Requirement for Software, Open Source Initiative, 27 januari. https://opensource.org/osr

Othman, H. (2017) Open Source Licenses, Cordemeyer & Slager / Advocaten B. V., February.

Perens, B. (1999) The Open Source Definition, In DiBona, C. et al. (Eds.) Open Sources: Voices from the Open Source Revolution, O’Reilly & Associates, ISBN: 1-56592-582-3, pp. 79-86.

Peterson, C. (2018a) How I coined the term ‘open source’, Open Source Yearbook 2018, OpenSource.com, pp. 10-12.

Peterson, S. K. (2018b) Why so little love for the patent grant in the MIT License?, 23 March, OpenSource.com, https://opensource.com/article/18/3/patent-grant-mit-license

Phipps, S. (2017) Public Domain Is Not Open Source, Meshed Insights, 16 March.

Phipps, S. (2018) Open Source: The Third Decade, FOSDEM, Brussels, 3 February.

Piana, C. (2013) A discussion of the different software licensing regimes, In Legal aspects of free and open source software, European Parliament’s Committee on Legal Affairs, Directorate General for Internal Policies, European Parliament, 9 July, pp. 30-49.

Ramböll (2016) Internationell utblick öppen programvara inom statsförvaltningen, Version 1.0, mars.

Raymond, E. (1999) The Cathedral and the Bazaar, Knowledge, Technology, & Policy, Vol. 12(3): 23-49.

Regeringen (2005) Regeringens proposition 2004/05:175 – Från IT-politik för samhället till politik för IT-samhället, Prop. 2004/05:175, Stockholm, 30 juni.

Regeringen (2006) Förbättrad samordning av utvecklingen av standarder och grundfunktioner inom IT-området, Kommittédirektiv, Dir. 2006:36, Stockholm, 6 april.

Regeringen (2008) Standardiseringens betydelse i en globaliserad värld, Regeringens skrivelse 2007/08:140, Skr. 2007/08:140, 17 april.

Regeringen (2009) Delegation för e-förvaltning, Dir 2009:19, Regeringen, 26 mars.

Regeringen (2017) Hur Sverige blir bäst i världen på att använda digitaliseringens möjligheter – en skrivelse om politikens inriktning, Regeringens skrivelse 2017/18:47, Skr. 2017/18:47, 16 november.

Regeringen (2018) Regeringens strategi för standardisering, Bilaga till regeringsbeslut UD2018/12345/HI, 26 juli.

Regeringen (2019a) Säker och kostnadseffektiv it-drift för den offentliga förvaltningen, Kommittédirektiv, Dir. 2019:64, Infrastrukturdepartementet, Regeringen, 26 september.

Regeringen (2019b) Uppdrag att etablera en förvaltningsgemensam digital infrastruktur för informationsutbyte, Regeringen, Infrastrukturdepartementet, Dnr. I2019/03306/DF, I2019/01036/DF (delvis), I2019/01361/DF (delvis), I2019/02220/DF, 11 december.

Regeringskansliet (2012) Med medborgaren i centrum – Regeringens strategi för en digitalt samverkande statsförvaltning, Näringsdepartementet, Regeringskansliet, N2012.37, Dnr. N2012/6402/ ITP.

Regeringskansliet (2016) Nationella upphandlingsstrategin, Regeringskansliet, Finansdepartementet.

Regeringskansliet (2019) Regeringens strategi för standardisering, Regeringskansliet.

Riksrevisionen (2016) Den offentliga förvaltningens digitalisering – En enklare, öppnare och effektivare förvaltning?, RIR 2016:14, Riksrevisionen, Dnr.: 3.1.1-2015-0903, 21 juni.

Version: 1.0 64 (96) 20 maj 2020

https://opensource.com/article/18/3/patent-grant-mit-license

https://opensource.org/osr

https://OpenSource.com

https://OpenSource.com


Robles, G., Gamalielsson, J. & Lundell, B. (2019) Setting Up Government 3.0 Solutions Based on Open Source Software: The Case of X-Road, In Lindgren, I. et al., (Eds.) Electronic Government, Springer, Cham, pp. 69-81.

Rosen, L. (2005) Open Source Licensing: Software Freedom and Intellectual Property Law, Prentice-Hall, Upper Saddle River, ISBN 0-13-148787-6.

Scacchi, W. & Alspaugh, T. A. (2012) Understanding the role of licenses and evolution in open architecture software ecosystems, Journal of Systems and Software, Vol. 85(7): 1479-1494.

Sinclair, A. (2010) Licence Profile: BSD, International Free and Open Source Software Law Review, Vol. 2(1): 1-6.

Sinclair, A. (2010) Licence Profile: Apache License, Version 2.0, International Free and Open Source Software Law Review, Vol. 2(2): 107-114.

Smith, P. M. & Chang, W. R. (2016) The Evolution of Business Models Using Open Source Software, Milbank Intellectual Property Year in Review 2011, pp. 35-48.

SMHI (2020) Ten years of international collaboration on open source code, SMHI, 13 januari. https://www.smhi.se/en/research/research-news/ten-years-of-international-collaboration-on-open-source-code-1.156251

SOU (2007) Den osynliga infrastrukturen - om förbättrad samordning av offentlig IT-standardisering, Betänkande av IT-standardiseringsutredningen, SOU 2007:47, Stockholm, ISBN 978-91-38-22765-7, ISSN 0375-250X.

SOU (2009) Strategi för myndigheternas arbete med e-förvaltning, Betänkande av E-delegationen, Statens Offentliga Utredningar, SOU 2009:86, Stockholm, ISBN 978-91-38-23302-3.

SOU (2011) Så enkelt som möjligt för så många som möjligt – vägen till effektivare e-förvaltning, Betänkande från E-delegationen, Statens Offentliga Utredningar, SOU 2011:67, Stockholm, ISBN 978-91-38-23636-9.

SOU (2015a) En förvaltning som håller ihop, Slutbetänkande från E-delegationen, Statens Offentliga Utredningar, SOU 2015:66, Stockholm, ISBN 978-91-38-24322-0.

SOU (2015b) Digitaliseringens transformerande kraft – vägval för framtiden, Slutbetänkande av Digitaliseringskommissionen, Statens Offentliga Utredningar, SOU 2015:91, Stockholm, ISBN 978-91-38-24365-7.

SOU (2017) reboot – omstart för den digitala förvaltningen, Slutbetänkande av Utredningen om effektiv styrning av nationella digitala tjänster, Statens Offentliga Utredningar, SOU 2017:114, Stockholm, ISBN 978-91-38-24745-7.

SOU (2018) Juridik som stöd för förvaltningens digitalisering, Betänkande av Digitaliseringsrättsutredningen, Statens Offentliga Utredningar, SOU 2018:25, Stockholm, ISBN ISBN 978-91-38-24780-8.

SPDX (2020) SPDX License List, Version: 3.8, SPDX Workgroup a Linux Foundation Project, Linux Foundation, 9 February.

Statskontoret (2002) Uppdragsbeskrivning – öppen programvara, Statskontoret, 12 juli.

Statskontoret (2003a) Öppen programvara, Statskontoret 8:3, Statskontoret, Stockholm.

Statskontoret (2003b) Interoperability Test and XML Evaluation of StarOffice Writer 6.0 and Office Word 2003 Beta 2, Dnr. 2003/122, Statskontoret, The Swedish Agency for Public Management, 16 July, Revised: 8 September.

Version: 1.0 65 (96) 20 maj 2020

https://www.smhi.se/en/research/research-news/ten-years-of-international-collaboration-on-open-source-code-1.156251

https://www.smhi.se/en/research/research-news/ten-years-of-international-collaboration-on-open-source-code-1.156251


Statskontoret (2004) Vägledning: Programvaror och tjänster 2004 – Öppna programvaror, Statskontoret.

Svorc, J. & Katz, A. (2020) Breathe In, Breathe Out: How open hardware licensing can help save the world, Journal of Open Law, Technology, & Society, Vol. 11(1): 49-56.

UK (2015) Open Standards Principles, Updated 7 Sept., HM Government, U.K. Gov.

Välimäki, M. & Oksanen, V. (2005) Patents on Compatibility Standards and Open Source – Do Patent Law Exceptions and Royalty-Free Requirements Make Sense?, SCRIPT-ed, Vol. 2(3): 397-406.

Webbink, M. (2003) Licensing and Open Source, In Fitzgerald, A. & Bassett, G. (Eds.) Legal Issues Relating to Free and Open Source Software, Essays in Technology Policy and Law Volume 1, Queensland University of Technology School of Law, ISBN 0-9751394-0-1, pp. 1-10.

Webbink, M. (2009) Packaging Open Source, International Free and Open Source Software Law Review, Vol. 1(2): 83-98.

Verva (2006) Förstudie: Programvaror och tjänster 2006, Verket för förvaltningsutveckling, 2008:18, Dnr. 2006/49, 19 juni.

Verva (2007a) Rättsliga konsekvenser av ökad användning av öppna programvaror, Verket för förvaltningsutveckling, 2008:18, Dnr 2006/404, 30 mars, ändrad 14 augusti.

Verva (2007b) Programvaror och tjänster 2004, Öppna, Dnr 2003/382-3, Verva. http://web.archive.org/web/20071026045936/http://www.avropa.nu/templates/ ramavtalsomrade____2553.aspx

Verva (2008) Statens användning av öppen programvara: En kartläggning av myndigheternas inställning till och användning av öppen programvara, Verket för förvaltningsutveckling, 2008:18, Dnr. 2008/155, 19 december.

Williams, S (2002) Free as in Freedom Richard Stallman’s Crusadeα for Free Software, O’Reilly & Associates, Sebastopol, 12 February.

Woelfle, M., Olliaro, P. & Todd, M. (2011) Open science is a research accelerator, Nature Chemistry, Vol. 3: 745-748.

Ye, Y. & Kishida, K. (2003) Toward an Understanding of the Motivation of Open Source Software Developers, In Proceedings of the 25th International Conference on Software Engineering, IEEE Computer Society, Washington, 978-0-7695-1877-0, pp. 419-429.

Version: 1.0 66 (96) 20 maj 2020

http://web.archive.org/web/20071026045936/http://www.avropa.nu/templates/ramavtalsomrade____2553.aspx

http://web.archive.org/web/20071026045936/http://www.avropa.nu/templates/ramavtalsomrade____2553.aspx

1 (DIGG, 2019) 2 DIGG:s policy för utveckling av programvara (Dnr. 2019:136) refereras fortsättningsvis i denna rapport som

DIGG:s policy (DIGG, 2019). 3 DIGG:s policy använder begreppet öppen källkod som synonym för det engelska begreppet open source software

(OSI, 2020). Denna rapport använder begreppet öppen programvara som synonym för öppen källkod. 4 Open Source Initiative (OSI, 2020). 5 Totalt 10 erkända licenser för öppen programvara listas under rubriken “Popular Licences” (OSL, 2020a) 6 Se exempelvis Lundell et al. (2019) 7 ‘A patent is a form of governmental grant that gives its owner the exclusive right to practise (i.e., make, use and

sell) a claimed invention throughout the issuing country. Patent protection in most countries lasts for a period of 20 years from the date a patent application is filed. Patents may cover any system, device, product feature, process or improvement, so long as it is useful, novel and not obvious in view of existing technologies.’ (Contreras, 2016, p. 2)

8 ‘A standard-essential patent (SEP) is a patent that is necessarily infringed by any implementation of a standard. The effect of SEPs on the technological and commercial success of technology standards is subject to lively debates.’ (Baron et al., 2016, p. 1762)

9 Det finns klausuler i licenser ur familjen GPL (refereras ofta som ’liberty or death’) som, förenklat, uttrycker att programvaran vid en distribution inte kan begränsa de rättigheter som ursprungligen anskaffats av den som distribuerar programvaran, se vidare Lundell et al. (2019).

10 (Andreesen, 2011) 11 Denna rapport använder begreppet öppen programvara som en svensk översättning av open source software. På

svenska förekommer även begreppet öppen källkod som en svensk översättning till open source software. Redan den 12 juli 2002 användes begreppet öppen programvara av Statskontoret då ett PM utfärdades som redovisar en uppdragsbeskrivning för en förstudie ’Uppdragsbeskrivning – öppen programvara’ (Statskontoret, 2002). Förstudien presenterar en omfattande analys och redogör för att öppen programvara ’ger användaren frihet att använda, kopiera, distribuera, undersöka, ändra och förbättra programvaran’ (Statskontoret, 2003a).

12 Programvara kan tillhandahållas under en eller flera erkända licenser för öppen programvara. Då programvara tillhandahålls under två eller flera erkända licenser för öppen programvara ger detta användaren möjlighet att välja under vilken av dessa licenser den öppna programvaran ska användas.

13 Definitionen för öppen programvara (eng. Open Source Definition) etablerades av en av de personer, Bruce Perens, som tog initiativ till att etablera organisationen Open Source Initiative (OSI, 2020a, 2020b).

14 (OSI, 2020) 15 (OSL, 2020) 16 Den 2 januari 2020 var fler än 90 licenser erkända som licenser för öppen programvara av organisationen Open

Source Initiative (http://web.archive.org/web/20200102121751/https://opensource.org/licenses/alphabetical) 17 Forskning visar att programvaruprojekt som tillhandahåller programvara som fått stor spridning tillhandahålls under

ett fåtal erkända licenser för öppen programvara. 18 Många välkända programvaruprojekt utvecklar, förvaltar och tillhandahåller öppen programvara i en öppen

samverkan på en webbaserad plattform, som exempelvis plattformen GitHub. 19 Denna rapport använder begreppet sluten programvara för att beteckna all programvara som inte uppfyller

definitionen för öppen programvara (OSD, 2020a). Rapporten använder således begreppen öppen programvara och sluten programvara som varandras motsatser (och utifrån detta kategoriseras därmed alla programvaror i endast en av dessa två kategorier). På svenska förekommer även begreppet proprietär programvara vilket utgör en mycket stor delmängd av all sluten programvara. Därutöver tillkommer viss programvara som tillhandahålls under villkor som inte uppfyller definitionen för öppen programvara. I vissa jurisdiktioner (exempelvis USA) kan programvara tillhandahållas som s.k. public domain vilket skapar juridisk osäkerhet då programvara används och distribueras mellan olika jurisdiktioner (eftersom det i vissa andra jurisdiktioner, som exempelvis i Sverige, saknas möjligt att avsäga sig upphovsrätten till ett verk). Att programvara som tillhandahålls som public domain inte uppfyller definitionen för öppen programvara har exempelvis klargjorts av ledande företrädare för organisationen Open Source Initiative (Phipps, 2017).

20 Exempelvis har en ledande företrädare för den organisation (Open Source Initiative) som står bakom definitionen av öppen programvara hävdat att öppen programvara, istället för proprietär (sluten) programvara, sedan ett antal år tillbaka blivit norm: ‘Allison Randal, president of the Open Source Initiative [...] says the open source community essentially declared victory in 2010, by which time she says the tide of opinion had flowed overwhelmingly from proprietary software to OSS.’ (Anthes, 2016, p. 15, 16)

http://web.archive.org/web/20200102121751/https://opensource.org/licenses/alphabetical

21 ‘Open-source software (OSS) is unavoidable. For most mainstream IT organizations, it’s not a question of if, but when, where, how and why to leverage OSS technology.’ (Gartner, 2010)

22 ‘In the past two decades, open source software has emerged from something that a few hackers in European and American universities tinkered with, to a leading model for software development used by the biggest and most innovative companies in the world. The value of free software is estimated at over $40 billion in terms of the effort put in to develop it. But, unlike proprietary software, sold per copy for licence fees, this is all available, to everyone, at no charge.’ (Ghosh, 2010, p. 82)

23 ‘ “Today you can’t build a product without using open source software,” said Ibrahim Haddad, head of the open source innovation group at Samsung Research America, a subsidiary of Samsung Electronics. Open source software has become so pervasive that it’s “eating” the software world, he said, tweaking a popular Silicon Valley maxim. Mr. Haddad spoke Monday at the Open Business Conference in San Francisco.’ (King, 2014)

24 ‘This supplement describes all models and all standard and optional equipment of your vehicle available at the time of publication of this license agreement. Country-specific deviations are possible. Please note that not all licenses might be relevant for your vehicle.’ (Daimler, 2018, p. 3)

25 ‘Components of the software used in the vehicle may be free and open source software licensed under the terms of license of the GNU General Public License, Version 2 (GPLv2), GNU Lesser General Public License, Version 2.1 (LGPLv2.1) or GNU Library General Public License, Version 2 (LGPLv2). Upon request, we will supply the source code of the components licensed under the GPLv2, LGPL v2.1 and LGPLv2 on a data medium (please specify the designation of your vehicle). Please direct your request to the following address within three years after vehicle delivery: Mercedes-Benz AG, HPC: CAC, Customer Service, 70546 Stuttgart, Germany’ (Daimler, 2019, p. 5)

26 Ett företag som distribuerar produkter med öppen programvara under licensen GPL version 2.0 behöver tillhandahålla ett erbjudande till kunden om att få ta del av den maskinläsbara kompletta källkoden (för en liten kostnad som endast täcker den direkta kostnaden för att distribuera källkoden) för det program som distribueras med produkten till kunden, se vidare licenstexten: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

27 (EC, 2001a) 28 (EC, 2001b) 29 (EC, 2001c) 30 (EC, 2001d) 31 Under 2020 publiceras, successivt, 28 rapporter som redovisar olika EU-länders policy och strategiska engagemang

med öppen programvara (EC, 2020a), se vidare: https://joinup.ec.europa.eu/collection/open-source-observatory-osor/open-source-software-country-intelligence

32 (EC, 2020b) 33 Frågan av vad som är utgör ett ”lämpligt format” inkluderar såväl tekniska som juridiska överväganden. En

förutsättning för att ett filformat ska vara lämpligt är att formatet tillhandahålls under villkor som uppfyller definitionen av en öppen standard enligt EU:s interoperabilitetsramverk version 1.0 (EC, 2004). Dessa filformat refereras som öppna filformat. Exempelvis presenterar Lundell et al. (2019) för en uppsättning frågor som är viktiga att beakta innan en myndighet börjar använda ett system (eller en tjänst) för att upprätta och behandla data som myndigheten behöver förvalta.

34 En myndighet behöver ha tillgång till (minst) en öppen programvara som kan tolka filer (både för att kunna läsa och för att kunna skriva filer) i alla de filformat som myndigheten använder för att förvalta sin egen information. Detta innebär inte nödvändigtvis att myndigheten endast kan använda öppen programvara, men om myndigheten förvaltar data i filformat för vilket det saknas en öppen programvara riskerar myndigheten att inte kunna förvalta sin egen information.

35 Genom att källkoden för öppen programvara finns tillgänglig under villkor som möjliggör att myndighetens egen personal (alternativt med stöd av externa experter som myndigheten anlitar) kan inspektera programvarans funktion för att exakt kunna tolka hur ett öppet filformat och en öppen standard har implementerats i den öppna programvaran. Genom att villkoren för öppen programvara ger en myndighet möjlighet att inspektera, använda, modifiera och distribuera programvaran ges förutsättningar att, enskilt eller i samverkan med andra organisationer, långsiktigt upprätthålla tillgång till öppen programvara och därigenom skapa förutsättningar för en långsiktigt hållbar förvaltning.

36 Forskning visar att att sluten programvara mycket sällan finns tillgänglig längre tid än ett decennium (Lundell et al.,2011). Även om långt ifrån alla programvaruprojekt som tillhandahåller öppen programvara har varit aktiva längre tid än ett decennium finns det flera exempel på programvaruprojekt som tillhandahåller öppen programvara som har aktiva i flera decennier.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

https://joinup.ec.europa.eu/collection/open-source-observatory

37 Tabell 1 är baserad på öppenhetskuben (eng. openness cube), se vidare Lundell & Gamalielsson (2018). 38 Se exempelvis de frågeställningar som behandlades under konferensen “Hållbar digitalisering: Möjligheter och

hinder” som arrangerades för första gången den 19 augusti 2019 (https://www.his.se/hd2019/). 39 Det ska poängteras att detta inte innebär att en myndighet enbart måste använda öppen programvara. För en god

förvaltning är det däremot mycket väsentligt att det för varje representation av data (vare sig detta sker internt eller externt) som myndigheten använder existerar en öppen programvara som kan användas för att tolka och återanvända de data som myndigheten har ansvar för att förvalta. Även om en representation av data sker i en databas eller en extern tjänst (som myndigheten eventuellt saknar kontroll över) behöver myndigheten säkerställa att myndighetens egen information (alla data och alla metadata) kan förvaltas över hela tidsperioden som myndigheten har ett förvaltningsansvar för dessa data. Då en myndighet, i allmänhet, saknar inflytande över hur den exakta funktionen kommer att utvecklas över tid för den programvara som tjänst och den slutna programvara som myndigheten eventuellt använder är det viktigt att genomföra migrering och konvertering av myndighetens egen data för att säkerställa myndighetens möjlighet att långsiktigt kunna förvalta sin egen information.

40 Denna rapport använder begreppet öppen programvara som en svensk översättning av open source software. På svenska förekommer även begreppet öppen källkod som en svensk översättning till open source software. Redan den 12 juli 2002 användes begreppet öppen programvara av Statskontoret då ett PM utfärdades som redovisar en uppdragsbeskrivning för en förstudie ’Uppdragsbeskrivning – öppen programvara’ (Statskontoret, 2002). Förstudien presenterar en omfattande analys och redogör för att öppen programvara ’ger ger användaren frihet att använda, kopiera, distribuera, undersöka, ändra och förbättra programvaran’ (Statskontoret, 2003a).

41 Programvara kan tillhandahållas under en eller flera erkända licenser för öppen programvara. Då programvara tillhandahålls under två eller flera erkända licenser för öppen programvara ger detta användaren möjlighet att välja under vilken av dessa licenser den öppna programvaran ska användas.

42 Definitionen för öppen programvara (eng. Open Source Definition) etablerades av en av de personer, Bruce Perens, som tog initiativ till att etablera organisationen Open Source Initiative (OSI, 2020a, 2020b).

43 (EC, 2004) 44 Organisationen Open Source Initiative har formulerat ett krav på att en öppen standard inte får hindra någon från att

implementera en öppen standard i öppen programvara, detta krav är formulerat som ”Open Standards Requirement for Software” (OSR, 2020). Detta krav på att en öppen standard ska kunna implementeras i öppen programvara uppfylls av EU:s definition av öppen standard (EC, 2004) och ett antal andra definitioner av öppen standard, exempelvis den som används i Storbritannien (UK, 2015). Däremot uppfyller inte EU:s definition av öppen specifikation (eng. open specification) som presenteras i EU:s interoperabilitetsramverk version 2 och definitionen av öppen specifikation som presenteras i EU:s interoperabilitetsramverk version 3 detta krav på att en standard ska kunna implementeras i öppen programvara. Forskning visar att standarder som uppfyller denna definition av ’open specification’ hindrar interoperabilitet och inte kan implementeras i öppen programvara (Lundell et al., 2019). I flera EU-länder rekommenderas användning av standarder som inte kan implementeras i öppen programvara och det finns flera, mycket problematiska, missuppfattningar om möjligheten att använda flera patentbelastade standarder (som uppfyller definitionen av ”open specification”) eftersom det inte är möjligt att anskaffa alla nödvändiga rättigheter för många standarder vilket hindrar implementation i öppen programvara (Lundell et al., 2019).

45 För att möjliggöra konkurrens i en offentlig upphandling ställer Kammarkollegiet krav på att myndigheter som formulerar obligatoriska krav som refererar till standarder i en offentlig upphandling endast får referera till öppna standarder enligt den definition som presenteras i EU:s interoperabilitetsramverk version 1.0 (EC, 2004). I Nederländerna har det ställs krav på öppna standarder enligt samma definition (Netherlands, 2007) och i Sverige har E-delegationens första publikation preciserat innebörden av öppen standard med en referens till samma definition (SOU 2009:86). För att ge stöd till myndigheter har Kammarkollegiet publicerat en vägledning som presenterar definitionen och listar ett antal öppna standarder som uppfyller definitionen (NPS, 2016). En standard som uppfyller EU:s definition (EC, 2004) kan implementeras i ett programvaruprojekt som tillhandahåller såväl öppen programvara som sluten programvara. Det ska nämnas att begreppet ”öppen standard” också har definierats på andra sätt och ett antal andra definitioner är utformade på ett sätt så att standarder som uppfyller dessa hindrar implementation i öppen programvara.

46 ‘interoperability is the intentional design of a technology product or system, which allows it to cooperate with other products or systems without restriction or difficulty, thus producing a reliable outcome and resource optimization. The main goal of an interoperable system is to facilitate interaction between different software applications and to enable sharing and re-use of information among non-homogenous systems.’ (Aliprandi, 2011, p. 6)

47 (EC, 2004)

https://www.his.se/hd2019/

48 ‘interoperability is the intentional design of a technology product or system, which allows it to cooperate with other products or systems without restriction or difficulty, thus producing a reliable outcome and resource optimization. The main goal of an interoperable system is to facilitate interaction between different software applications and to enable sharing and re-use of information among non-homogenous systems.’ (Aliprandi, 2011, p. 6)

49 EU:s interoperabilitetsramverk version 1.0 (EC, 2004) definierar begreppet öppen standard på ett sätt som möjliggör implementation i öppen programvara, men i senare versioner (både version 2 och version 3) av EU:s interoperabilitetsramverk används istället begreppet öppen specifikation (eng. open specification) med en definition som innebär att patentbelastade standarder uppfyller denna definition vilket hindar implementation i öppen programvara. Forskning visar att denna typ av patentbelastade standarder hindrar interoperabilitet och kan även hindra implementation i både öppen och sluten programvara (Lundell et al., 2019).

50 Arbetet med att utveckla en definition för öppet innehåll har influerats av det tidigare arbetet med att utveckla definitionen för öppen programvara. Bakgrunden till denna definition beskrivs på följande sätt: ’The Open Definition was initially derived from the Open Source Definition, which in turn was derived from the original Debian Free Software Guidelines, and the Debian Social Contract of which they are a part, which were created by Bruce Perens and the Debian Developers. Bruce later used the same text in creating the Open Source Definition. This definition is substantially derivative of those documents and retains their essential principles. Richard Stallman was the first to push the ideals of software freedom which we continue.’ (OKF, 2020a)

51 (OKF, 2020b) 52 (Lundell & Gamalielsson, 2018) 53 Forskning visar att slutna standarder som tillhandahålls under s.k. RAND-villkor inte kan implementeras av

programvaruprojekt som planerar tillhandahålla öppen programvara (Lundell et al., 2015, 2018, 2019). 54 Forskning visar att slutna standarder som tillhandahålls under s.k. RAND-villkor inte kan implementeras av

programvaruprojekt som planerar tillhandahålla öppen programvara (Lundell et al., 2015, 2018, 2019). 55 ‘Copyright holders can permit other people to copy or modify their software. That permission (called a “license”)

can be as simple as a perpetual, unconditional and universal grant of permission to do any of the acts that are exclusive to the copyright holder.’ (Fontana et al., 2008, p. 3)

56 Begreppet myntades under ett möte den 5 februari 1998 av Christine Peterson: ‘I am the originator of the term “open source software” and came up with it while executive director at Foresight Institute. Not a software developer like the rest, I thank Linux programmer Todd Anderson for supporting the term and proposing it to the group.’ (Peterson, 2018a, p. 10)

57 (OSI, 2020) 58 (OSD, 2020a, 2020b) 59 (OSL, 2020) 60 ‘Rather than thinking of open source only as a set of software licenses and associated software development

practices, we do better to think of it as a field of scientific and economic inquiry, one with many historical precedents, and part of a broader social and economic story. We must understand the impact of such factors as standards and their effect on commoditization, system architecture and network effects, and the development practices associated with software as a service. We must study these factors when they appear in proprietary software as well as when they appear in traditional open-source projects. We must understand the ways in which the means by which software is deployed changes the way in which it is created and used. We must also see how the same principles that led to early source code sharing may impact other fields of collaborative activity. Only when we stop measuring open source by what activities are excluded from the definition, and begin to study its fellow travelers on the road to the future, will we understand its true impact and be fully prepared to embrace the new paradigm.’ (O’Reilly, 2005, p. 107-108)

61 Begreppet fri programvara är en svensk översättning (FSF, 2020a) av det engelska begreppet free software (FSF, 2020b).

62 (FSF, 2020a) 63 Definitionen av fri programvara preciseras i fyra friheter som utgår ifrån användarens friheter (i betydelsen

’yttrandefrihet’ och ska inte associeras med kostnadsfri eller gratis). En programvara definieras som fri programvara om programmets användare har följande fyra friheter: ‘The freedom to run the program as you wish, for any purpose (freedom 0). The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. The freedom to redistribute copies so you can help others (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.’ (FSF, 2020b)

https://projects.We

64 (FSF, 2020a) 65 (FSF, 2020a) 66 (González-Barahona, 2004) 67 Begreppet libre software används framför allt i länder där romanska språk talas istället för open source software

och free software, där ordet ’libre’ (på Spanska och Franska), ordet ’livre’ (på Portugisiska) samt ordet ’libero’ (på Italienska) har en betydelse som ’free speech’ (istället för ’free beer’ (González-Barahona, 2004).

68 (González-Barahona, 2004) 69 På engelska används ofta OSS som en förkortning för “Open Source Software” (OSI, 2020). 70 På engelska används ofta FS som en förkortning för “Free Software” (FSF, 2020b). 71 Förkortningen ”FLOSS” har sitt ursprung i namnet på ett EU-projekt (’the FLOSS project’) som analyserat öppen

programvara och under genomförandet bland annat undersökt användning av öppen programvara i Sverige, Tyskland och England (FLOSS, 2002a).

72 ‘About the time Stallman was pondering the ethical, political, and legal issues associated with free software, a California hacker named Don Hopkins mailed him a manual for the 68000 microprocessor. Hopkins, a Unix hacker and fellow science-fiction buff, had borrowed the manual from Stallman a while earlier. As a display of gratitude, Hopkins decorated the return envelope with a number of stickers obtained at a local science-fiction convention. One sticker in particular caught Stallman’s eye. It read, “Copyleft (L), All Rights Reversed.” Following the release of the first version of GPL, Stallman paid tribute to the sticker, nicknaming the free software license “Copyleft.” Over time, the nickname and its shorthand symbol, a backwards “C,” would become an official Free Software Foundation synonym for the GPL.’ (Williams, 2002, p. 80)

73 ‘Collaboration and sharing is at the hart of open source development. The developers I have met – and I have met many – are in the main a beautifully idiosyncratic, highly intelligent and interesting group of people of free thinkers. Their inability to accept the parameters of current thinking seems to me to be key to the creativity they demonstrate in the technical solutions they develop. Combined with their idealism, it forms the basis of the thinking that allows them to challenge the logic of laws, such as IP and in particular copyright. Copyleft, developed as part of this free thinking, is a play on the legal term copyright and a great example of this.’ (Brock, 2013, p. 119)

74 ‘Copyleft licenses are conditional licenses. One of the conditions you must satisfy before distributing copylefted software is that any changes you make to that software be likewise released under the copylefted license. A copyleft license ensures that all modified versions of your project remain free in the same way. Such licenses are said to keep code “forever free”.’ (Fontana et al., 2008, p. 4)

75 (OSI, 2000) 76 Idén att använda copyright på detta ’omvända’ sätt (för att skydda ett verks fortsatta öppenhet) har, av vissa,

karaktäriserats som ett ‘legal hack’. 77 Exempelvis föreslår standardiseringsutredningen att de två begreppen öppen programvara och öppen källkod är

synonyma med det engelska begreppet Open Source Software: ”För utredningens vidkommande förstås öppen programvara och öppen källkod som synonymt med det engelska Open Source Software. Vi gör alltså ingen distinktion mellan de båda uttrycken, men vi använder för enkelhetens skull genomgående begreppet öppen programvara. Utredningen ansluter sig därmed till Statskontorets definition från 2003 av öppen programvara som en programvara där källkoden är fritt tillgänglig och där programmet fritt kan användas, förändras, förbättras, kopieras och distribueras av alla.” (SOU, 2007)

78 ‘A software copyright is the exclusive legal right to control the rules for copying, modifying, and distributing a work of software. A person (or company, foundation, trust, or other legal entity) who has these exclusive legal rights is called a “copyright holder”. Legal rules prohibit non-copyright holders from copying, modifying or distributing copyrighted works without permission from the copyright holder.’ (Fontana et al., 2008, p. 3)

79 För flertalet individer och organisationer som bidrar till öppen programvara är detta tillerkännande mycket viktigt och vikten av att respektera upphovsrättsinnehavarens ideella rätt, så som framgår av respektive licens, kan inte nog understrykas.

80 “Software code is protected as expression in the form of a literary text under copyright law. Copyright law will protect the expression of an idea or facts but not the idea or facts themselves.” (Fitzgerald & Bassett, 2003, p. 11)

81 ‘Note that “open source” software is not the same thing as public domain software. Rather, the author or owner of public domain software has abandoned his or her copyright and has contributed material without retaining any right to control how the work is used, reproduced, modified, or distributed. In contrast, open source licensors retain copyright and may impose terms and conditions on the use, copying, modification, and/or distribution of their software.’ (Murray, 2009, p. 5)

82 ‘Whatever open source software is it is not “Public Domain.” ’ (Ilardi, 2011, p. 1) 83 På svenska används ibland begreppet proprietär programvara som en översättning av engelskans ‘proprietary

software’. Då all programvara (i Sverige) skyddas av upphovsrätt använder denna rapport begreppet öppen programvara för all programvara som uppfyller definitionen av öppen programvara, medan begreppet sluten programvara används för alla annan programvara (där upphovsrätten används på traditionellt sätt för att hindra användning och vidaredistribution).

84 ‘in order to contrast open source software and open source licenses from other kinds, I suggest we talk about “closed source” software or “trade secret” source code, with associated “royalty” or “fee”–based licensing.’ (Murray, 2009, p. 5)

85 (OSD, 2020a, 2020b) 86 ‘In the thirty years from 1970 to 2000, open source software (OSS) began as an assumption without a name or a

clear alternative. It has evolved into a sophisticated movement that has produced some of the most stable and widely used software packages ever produced.’ (Bretthauer, 2002, p. 3)

87 ‘In the first decades of electronic computing, even software developed internally was often freely distributed (in both meanings of the word) by user groups such as SHARE (IBM) and the Univac Scientific Exchange (USE).’ (Ensmenger, 2004, p. 102)

88 ‘Many efforts were dedicated to build an operating system that could be deployed on multiple hardware platforms. The most prominent example was Unix, which developed at the AT&T Laboratories and was published in 1969. Commercial users had to pay high license fees for using Unix, whereas academic institutions could use the software for a nominal charge. Consequently, Unix was the basis for the development of the Internet technologies. Many of these technologies were developed at universities and computer companies research laboratories, where Unix was deployed. Sharing the source code among software developers was commonplace. This tendency was reinforced by the emergence of computer networks like the Usenet that was started in 1979 to link the Unix community.’ (FLOSS, 2002d, p. 12)

89 Vid den tidpunkt då Stallman postade nyheten på Usenet (den 27 september 1983, på nyhetsgruppen net.unix-wizards) var detta ett välanvänt socialt medium. För vidare information om Usenet, se exempelvis Wikipedia: https://en.wikipedia.org/wiki/Usenet

90 (FSF, 2002a, 2002b) 91 http://www.gnu.org/gnu/initial-announcement.html 92 ‘At these meetings, we discussed the need for a new term due to the confusion factor. The argument was as follows:

those new to the term “free software” assume it is referring to the price. Old-timers must then launch into an explanation, usually given as follows: “We mean free as in freedom, not free as in beer.” At this point, a discussion on software has turned into one about the price of an alcoholic beverage. The problem was not that explaining the meaning is impossible – the problem was that the name for an important idea should not be so confusing to newcomers. A clearer term was needed. No political issues were raised regarding the free software term; the issue was its lack of clarity to those new to the concept.’ (Peterson, 2018a, p. 11)

93 (OSI, 1998) 94 ‘The Open Source Definition is a bill of rights for the computer user. It defines certain rights that a software license

must grant you to be certified as Open Source.’ (Perens, 1999, p. 79) 95 (OSD, 2000a, 2000b) 96 ‘The Open Source Definition started life as a policy document of the Debian GNU/Linux Distribution.’ (Perens,

1999, p. 80) 97 ‘Note that the Open Source Definition is not itself a software license. It is a specification of what is permissible in a

software license for that software to be referred to as Open Source.’ (Perens, 1999, p. 81) 98 ‘Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and

the fix obvious to someone. Or, less formally,”Given enough eyeballs, all bugs are shallow.” I dub this: “Linus’s Law.” ’ (Raymond, 1999, p. 29)

99 ‘There is now an organization dedicated to managing and promoting the Open Source trademark for the good of the community, the Open Source Initiative. You can read our launch announcement, and our Open Letter to AOL. We are seeking qualified board members for this organization.’ (OSI, 1999)

100 (OSL, 2000) 101 (OSI, 2000) 102 (OSL, 2020) 103 (OSI, 2000)

http://www.gnu.org/gnu/initial-announcement.html

https://en.wikipedia.org/wiki/Usenet

104 Licensen identifieras ‘GPL-2.0’ (SPDX, 2019), se vidare: https://opensource.org/licenses/GPL-2.0 105 Det finns även en tidigare version av GPL (GNU General Public License, Version 1) som publicerades i februari

1989, men denna version har aldrig erkänts som öppen programvara. Detta kan tyckas vara naturligt som en konsekvens av att GPL version 2 etablerades redan 1991 vilket var flera år innan begreppet öppen programvara lanserades genom organisationen Open Source Initiative. För information om version 1 av GPL-licensen, se vidare: https://www.gnu.org/licenses/old-licenses/gpl-1.0.txt

106 Licensen identifieras ‘LGPL-2.1’ (SPDX, 2019), se vidare: https://opensource.org/licenses/LGPL-2.1 107 Licensen identifieras ‘BSD-3-Clause’ (SPDX, 2019), se vidare: https://opensource.org/licenses/BSD-3-Clause 108 Den ursprungliga BSD-licensen, som hade fyra klausuer och identifieras ‘BSD-4-Clause’ (SPDX, 2019), har aldrig

erkänts som en licens för öppen programvara. Denna licens (d.v.s. BSD-3-Clause) refereras ibland som “Original License” och även som “Old License” utifrån det faktum att detta är det ursprungliga versionen av BSD-licensen som övriga versioner härstammar från, se vidare: https://directory.fsf.org/wiki/License:BSD-4-Clause

109 Denna licens (d.v.s. BSD-3-Clause) refereras ibland som “the New BSD License” och även som “the Modified BSD License” utifrån det faktum att den härstammar från den BSD-licens (med totalt 4 klausuler) som ursprungligen användes av University of California, se vidare: https://opensource.org/licenses/BSD-3-Clause

110 Licensen identifieras ‘MIT’ (SPDX, 2019), se vidare: https://opensource.org/licenses/MIT 111 En analys av ursprunget till MIT-licensen hävdar att licensen utvecklades på 1980-talet: ‘there’s a good argument to

be made that the MIT License, also called the X Consortium or X11 License at the time, crystallized with X11 in 1987, and that’s the best date to use. You could argue it was created in 1985 with possible adjustments over the next couple of years’ (Haff, 2019)

112 ‘When we started, “open source” had not been invented. “Free software” was known to a small but growing community, largely from universities and startup computer companies. The GNU C compiler reliably compiled itself, and produced good quality code, on the DEC Vax and the Motorola 68000. The Linux kernel had not been created. Berkeley Unix was still largely unfree (though I had made it compile with GCC in 1989, eliminating their big dependency on the unfree Portable C Compiler). GNU C++ was limping but unreliable. The GNU Lesser Public License did not exist.’ (Cygnos, 2006)

113 ‘Cygnus Support was a small company founded to support and improve free software. We started with three people -- Michael Tiemann, David Vinayak Wallace, and John Gilmore. […] It grew to employ more than 120 people, with annual revenues over $20,000,000, ten years later. It was merged into Red Hat Software as Red Hat’s second acquisition, in a time when Red Hat’s revenues were much smaller, but its market capitalization was much greater (due to the tech and Linux stock market bubbles). The company was sold for about $600 million, making all of its early employees into millionaires.’ (Cygnos, 2006)

114 ‘Part of our marketing strategy was to stand out from the crowd. There was nobody else selling support for free software -- except for a couple of guys in Scandinavia with a knockoff they called Signum Support -- but there was definitely a small crowd of vendors of compilers for embedded systems. We helped to kill most of them off, by selling our often superior product for much lower prices, and without the crazy $10,000 per seat “software license” restrictions.’ (Cygnos, 2006)

115 Enligt årsredovisningen för 1998 är Signum Support AB ett svenskt IT-företag som har sin kärnkompetens ”inom fri programvara och främst operativsystemet Linux”. Under 1999 bytte företaget namn till Cendio Systems AB.

116 ‘IBM’s INTELLECTUAL property lawyers had never drafted a deal quite like this one. In April software engineer Yen-Ping Shan was describing a partnership IBM was proposing with something called the Apache Group. IBM, all $100 billion worth of it, was courting this loose confederation of 20 programmers. “Loose” is an understatement. The programmers, scattered from Palo Alto to Munich, were not incorporated and had no formal business arrangements. IBM wanted to use the Apache Group’s software as the cornerstone of WebSphere, an Internet commerce package IBM planned to release in June. This was a weird partnership deal because no money was involved.’ (McHugh, 1998, p. 95)

117 Brian Behlendorf är en ledande utvecklare av Apache HTTP Server Project (http://httpd.apache.org), en av grundarna till ‘The Apache Group’ och till organisationen Apache Software Foundation (https://www.apache.org/) samt en av grundarna till organisationen Open Source Initiative (https://opensource.org).

118 Den 5 juni 2009 gav Brian Behlendorf en inbjuden ‘keynote’ presentation på den internationella konferensen ’The Fifth International Conference on Open Source Systems’ som arrangerades den 3-6 juni 2009 i Skövde, Sverige. Se vidare Boldyreff et al. (2009) för den publikation som publicerats från konferensen.

119 ‘it is in the way Open Source licenses free the recipient from obligations to the creators, creating a relationship of mutual empowerment rather than one of dependency.’ (Behlendorf, 2009, p. 2)

https://opensource.org/

https://opensource.org/

https://www.apache.org/

http://httpd.apache.org/

https://opensource.org/licenses/MIT

https://opensource.org/licenses/BSD-3-Clause

https://directory.fsf.org/wiki/License:BSD-4-Clause

https://opensource.org/licenses/BSD-3-Clause

https://opensource.org/licenses/LGPL-2.1

https://www.gnu.org/licenses/old-licenses/gpl-1.0.txt

https://opensource.org/licenses/GPL-2.0

120

130

140

150

160

Samma år som organisationen Open Source Initiative (OSI, 2020a) bildades publicerades organisationen webbplats (OSI, 1998a). Genom åren har organisationen publicerat information om de licenser för öppen programvara som erkänts av organisationen. Exempelvis har information om licenser för öppen programvara publicerats sedan organisationen såg dagens ljus 1998 (OSI, 1998b) och har sedan den bildades 1998 har nya licenser successivt tillkommit varefter de erkänts av organisationen.

121 (OSL, 2020) 122 https://spdx.org/licenses/ 123 http://web.archive.org/web/20000815084248/http://www.opensource.org/licenses/gpl-license.html 124 http://web.archive.org/web/20200107070106/https://opensource.org/licenses/GPL-2.0 125 http://web.archive.org/web/20200229183759/https://opensource.org/licenses/GPL-3.0 126 http://web.archive.org/web/20000815084253/http://www.opensource.org/licenses/lgpl-license.html 127 http://web.archive.org/web/20200102055405/https://opensource.org/licenses/LGPL-2.1 128 ‘Please note that the GNU Library General Public License has been superseded by the GNU Lesser General Public

License.’ (http://web.archive.org/web/20191222194937/https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html) 129 http://web.archive.org/web/20191122002508/https://opensource.org/licenses/LGPL-3.0

http://web.archive.org/web/20000815084259/http://www.opensource.org/licenses/bsd-license.html 131 http://web.archive.org/web/20200108095339/https://opensource.org/licenses/bsd-3-clause 132 http://web.archive.org/web/20191224202055/https://www.gnu.org/software/cssc/manual/BSD-Code.html 133 https://web.archive.org/web/19990429093111/http://www.freebsd.org/copyright/freebsd-license.html 134 http://web.archive.org/web/20000815084303/http://www.opensource.org/licenses/mit-license.html 135 http://web.archive.org/web/20200115113909/https://opensource.org/licenses/MIT 136 http://web.archive.org/web/20000815084307/http://www.opensource.org/licenses/artistic-license.html 137 http://web.archive.org/web/20191206232125/https://opensource.org/licenses/Artistic-1.0 138 ‘This license has been superseded by the Artistic License, Version 2.0.’

(http://web.archive.org/web/20191206232125/https://opensource.org/licenses/Artistic-1.0) 139 http://web.archive.org/web/20191001194610/https://opensource.org/licenses/Artistic-2.0

http://web.archive.org/web/20000815055717/http://www.mozilla.org/MPL/MPL-1.0.html 141 http://web.archive.org/web/20191206232126/https://opensource.org/licenses/MPL-1.0 142 http://web.archive.org/web/20110531002619/https://opensource.org/licenses/MPL-1.1 143 http://web.archive.org/web/20020627100112/https://opensource.org/licenses/mozilla1.1.php 144 ‘This license has been superseded by the Mozilla Public License 2.0; please use the MPL 2.0 instead of 1.1.’ (http://

web.archive.org/web/20191206232126/https://opensource.org/licenses/MPL-1.1) 145 http://web.archive.org/web/20200229151333/https://opensource.org/licenses/MPL-2.0 146 http://web.archive.org/web/20191206232124/https://opensource.org/licenses/QPL-1.0 147 http://web.archive.org/web/20000815084249/http://www.research.ibm.com/jikes/license/license3.htm 148 http://web.archive.org/web/20191001151320/https://opensource.org/licenses/IPL-1.0 149 http://web.archive.org/web/20000815084249/http://cvw.mitre.org/cvw/licenses/source/license.html

http://web.archive.org/web/20191001222744/https://opensource.org/licenses/mitrepl 151 ‘MITRE has ceased to use or recommend this license’

(http://web.archive.org/web/20191001222744/https://opensource.org/licenses/mitrepl) 152 http://web.archive.org/web/20000815084248/http://www.risource.org/RPL/RPL-1.0A.shtml 153 http://web.archive.org/web/20191206232152/https://opensource.org/licenses/RSCPL 154 http://web.archive.org/web/20000815064926/http://www.python.org/doc/Copyright.html 155 http://web.archive.org/web/20200214224913/https://opensource.org/licenses/Python-2.0 156 ‘CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2’

(http://web.archive.org/web/20200115013911/https://docs.python.org/3/license.html#cwi-license-agreement-for-python-0-9-0-through-1-2)

157 http://web.archive.org/web/20200115013911/https://docs.python.org/3/license.html 158 http://web.archive.org/web/20000815084312/http://www.opensource.org/licenses/zlib-license.html 159 http://web.archive.org/web/20191206232124/https://opensource.org/licenses/Zlib

http://web.archive.org/web/20200117181040/https://opensource.org/licenses/Apache-2.0


http://web.archive.org/web/20191206232124/https://opensource.org/licenses/Zlib

http://web.archive.org/web/20000815084312/http://www.opensource.org/licenses/zlib-license.html

http://web.archive.org/web/20200115013911/https://docs.python.org/3/license.html

http://web.archive.org/web/20200115013911/https://docs.python.org/3/license.html#cwi-license-agreement-for-python-0-9-0-through-1-2

http://web.archive.org/web/20200115013911/https://docs.python.org/3/license.html#cwi-license-agreement-for-python-0-9-0-through-1-2

http://web.archive.org/web/20200214224913/https://opensource.org/licenses/Python-2.0

http://web.archive.org/web/20000815064926/http://www.python.org/doc/Copyright.html

http://web.archive.org/web/20191206232152/https://opensource.org/licenses/RSCPL

http://web.archive.org/web/20000815084248/http://www.risource.org/RPL/RPL-1.0A.shtml

http://web.archive.org/web/20191001222744/https://opensource.org/licenses/mitrepl

http://web.archive.org/web/20191001222744/https://opensource.org/licenses/mitrepl

http://web.archive.org/web/20000815084249/http://cvw.mitre.org/cvw/licenses/source/license.html

http://web.archive.org/web/20191001151320/https://opensource.org/licenses/IPL-1.0

http://web.archive.org/web/20000815084249/http://www.research.ibm.com/jikes/license/license3.htm

http://web.archive.org/web/20191206232124/https://opensource.org/licenses/QPL-1.0

http://web.archive.org/web/20200229151333/https://opensource.org/licenses/MPL-2.0



http://web.archive.org/web/20020627100112/https://opensource.org/licenses/mozilla1.1.php



http://web.archive.org/web/20000815055717/http://www.mozilla.org/MPL/MPL-1.0.html

http://web.archive.org/web/20191001194610/https://opensource.org/licenses/Artistic-2.0



http://web.archive.org/web/20000815084307/http://www.opensource.org/licenses/artistic-license.html

http://web.archive.org/web/20200115113909/https://opensource.org/licenses/MIT

http://web.archive.org/web/20000815084303/http://www.opensource.org/licenses/mit-license.html

https://web.archive.org/web/19990429093111/http://www.freebsd.org/copyright/freebsd-license.html

http://web.archive.org/web/20191224202055/https://www.gnu.org/software/cssc/manual/BSD-Code.html

http://web.archive.org/web/20200108095339/https://opensource.org/licenses/bsd-3-clause

http://web.archive.org/web/20000815084259/http://www.opensource.org/licenses/bsd-license.html

http://web.archive.org/web/20191122002508/https://opensource.org/licenses/LGPL-3.0

http://web.archive.org/web/20191222194937/https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

http://web.archive.org/web/20200102055405/https://opensource.org/licenses/LGPL-2.1

http://web.archive.org/web/20000815084253/http://www.opensource.org/licenses/lgpl-license.html

http://web.archive.org/web/20200229183759/https://opensource.org/licenses/GPL-3.0


http://web.archive.org/web/20000815084248/http://www.opensource.org/licenses/gpl-license.html

https://spdx.org/licenses/

https://spdx.org/licenses/

161 http://web.archive.org/web/20191206232228/https://opensource.org/licenses/CDDL-1.0 162 ‘This license has been superseded by the Apache License, Version 2.0’

(http://web.archive.org/web/20191206232125/https://opensource.org/licenses/Apache-1.1) 163 http://web.archive.org/web/20191206232125/https://opensource.org/licenses/Apache-1.1 164 http://web.archive.org/web/20190325115233/https://spdx.org/licenses/Apache-1.0.html 165 ‘Open source is not available to commercial companies. The way the license is written, if you use any open-source

software, you have to make the rest of your software open source.’ (Chicago, 2001) 166 Se exempelvis Alspaugh et al. (2010): ‘The primary goal of reciprocity in licenses is to increase the amount of

FOSS by encouraging developers to bring additional software into the FOSS commons, and to prevent improvements to OSS software from vanishing behind proprietary licenses.’ (p. 736)

167 Exempelvis finns forskning om copyleft som belyser vikten av att öppen programvara från etablerade programvaruprojekt inte kan tillhandahållas som sluten programvara (Alspaugh et al., 2010, p. 736)

168 (Lundell et al., 2019) 169 ‘This right is granted under section 11 GPLv3.’ (Othman, 2017, p. 48) 170 ‘The right to use patents is covered under section 3 of the License.’ (Othman, 2017, p. 47) 171 (Lundell et al., 2019) 172 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 173 https://www.kernel.org 174 http://web.archive.org/web/20200211093455/https://en.wikipedia.org/wiki/Linux_kernel 175 (Butler et al., 2019) 176 http://web.archive.org/web/20200224135455/https://en.wikipedia.org/wiki/MariaDB 177 https://www.gimp.org/ 178 http://web.archive.org/web/20200207111634/https://en.wikipedia.org/wiki/GIMP 179 http://web.archive.org/web/20200211045128/https://en.wikipedia.org/wiki/GNU_Compiler_Collection 180 (Scacchi & Alspaugh, 2012) 181 http://web.archive.org/web/20200205124616/https://en.wikipedia.org/wiki/FFmpeg 182 http://web.archive.org/web/20200119034818/https://en.wikipedia.org/wiki/VLC_media_player 183 http://web.archive.org/web/20200221002442/https://en.wikipedia.org/wiki/PeaZip 184 ‘Open Neural Networks Library’ (https://en.wikipedia.org/wiki/OpenNN) 185 http://web.archive.org/web/20200224114834/https://en.wikipedia.org/wiki/Nextcloud 186 http://web.archive.org/web/20190619234243/https://en.wikipedia.org/wiki/Koha_(software) 187 http://web.archive.org/web/20200205171211/https://en.wikipedia.org/wiki/Nginx 188 (Butler et al., 2019) 189 ‘Contiki-NG provides an operating system for small, low-powered devices [...] Contiki-NG was forked in 2017

from Contiki-OS, which was established as an OSS project in 2003. Contiki-OS remains an active OSS project, but has not released a version of the software since 2015. The Contiki-NG project is independent of company control and managed by its core developers.’ (Butler et al., 2019)

190 (Robles et al., 2019) 191 ‘X-Road comprises a data exchange layer solution which empowers different organizations to exchange data and

information over the Internet and ensures confidentiality, integrity and interoperability between data exchange parties.’ (Robles et al., 2019)

192 ‘Bouncy Castle is a widely used cryptographic library first released as an OSS project in 2000’ (Butler et al., 2019) 193 (Butler et al., 2020) 194 ‘The Apache PDFBox project develops a Java library and command line tools that can create and process PDF

files.’ (Butler et al., 2020) 195 ‘infrastructure-as-a-service (IaaS)’ (http://web.archive.org/web/20200216095230/https://en.wikipedia.org/wiki/

OpenStack) 196 Exempelvis finns det bland utvecklare för det etablerade och brett använda programvaruprojektet Linux kernel

(https://www.kernel.org/) bred konsensus om att det i praktiken skulle vara omöjligt att byta licens (från GPL version 2.0) för detta projekt som etablerades för många år sedan.

197 (Gamalielsson & Lundell, 2017)

https://www.kernel.org/

http://web.archive.org/web/20200216095230/https://en.wikipedia.org/wiki/OpenStack

http://web.archive.org/web/20200216095230/https://en.wikipedia.org/wiki/OpenStack

http://web.archive.org/web/20200205171211/https://en.wikipedia.org/wiki/Nginx

http://web.archive.org/web/20190619234243/https://en.wikipedia.org/wiki/Koha_(software)

http://web.archive.org/web/20200224114834/https://en.wikipedia.org/wiki/Nextcloud

https://en.wikipedia.org/wiki/OpenNN

http://web.archive.org/web/20200221002442/https://en.wikipedia.org/wiki/PeaZip

http://web.archive.org/web/20200119034818/https://en.wikipedia.org/wiki/VLC_media_player

http://web.archive.org/web/20200205124616/https://en.wikipedia.org/wiki/FFmpeg

http://web.archive.org/web/20200211045128/https://en.wikipedia.org/wiki/GNU_Compiler_Collection

http://web.archive.org/web/20200207111634/https://en.wikipedia.org/wiki/GIMP

https://www.gimp.org/

http://web.archive.org/web/20200224135455/https://en.wikipedia.org/wiki/MariaDB

http://web.archive.org/web/20200211093455/https://en.wikipedia.org/wiki/Linux_kernel



http://web.archive.org/web/20200212221532/https://spdx.org/licenses/

http://web.archive.org/web/20190325115233/https://spdx.org/licenses/Apache-1.0.html




198 ‘GPL licences can ‘poison’ an entire development, where any future application that incorporates the open source component has to give up rights, and itself must be freely available as open source. These risks are mitigated through the use of other licences, such as Apache v2.0, that are not ‘viral’ and can allow certain degrees of commercial exploitation while still satisfying the needs of the developer community.’ (Bruce et al., 2005, p. 79)

199 ‘Why does Red Hat use the GNU General Public Licence as its principle licencing option? Although some of our software code is licenced under other Open Source licences, we principally use the GPL. We do so because of the obligation imposed on derivative works, thus extending the Open Source community and preventing other parties from simply ripping off the open source efforts. I have to tell you that this has been one of my great challenges in the time that I have been at Red Hat, and it has been a period of enlightenment for me as well. For that I have to credit our engineers, because despite time and time again having had debates especially over the first few years about our business model and about whether we do not need to have some proprietary offerings, we have consistently come back to the position that if we are willing to be an Open Source company that it means being an Open Source company. We will not start to integrate proprietary works into what we offer in order to provide some monetary benefit to ourselves. This has been a challenge for us, but I think in terms of our own corporate identity and who we are, it has been important for us to stay true to that vision.’ (Webbink, 2003, p. 9)

200 ‘While permissive licences like the MIT licence do not provide any protection against such scenarios, reciprocal licensing terms have been mentioned repeatedly as a viable IPR regime that protects contributors from future competition based on their own investments. The risk of competitors creating commercial, proprietary derivative work is a relevant concern to those participants. An IPR regime based on reciprocal licences like the GPL is considered sufficient protection by those participants.’ (Blind & Böhm, 2019, p. 15)

201 https://www.kernel.org/ 202 ‘Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That’s the way that

the license works.’ (Chicago, 2001) 203 https://chicago.suntimes.com/ 204 ‘The results of this paper provide strong evidence that heterogeneity of motivation is a key feature of open-source

communities. How this heterogeneity is managed, accommodated, or resisted seem likely to be important influences on the stability, persistence, and outcomes of open-source development efforts. In particular, it suggests that communities that find ways of mobilizing individuals with quite different motivations to join and to persevere in their contributions as well as making effective use of each of the different motivational types may expect greater success in their efforts.’ (David & Shapiro, 2008, p. 396)

205 https://web.archive.org/web/20080408224303/http://linux-foundation.org/weblogs/press/2007/01/21/new-linux-foundation-launches-%E2%80%93-merger-of-open-source-development-labs-and-free-standards-group/

206 ‘Aug. 30, 2000 - Hewlett-Packard, Intel Corporation, IBM and NEC Corporation today announced the Open Source Development Lab, the industry’s first independent, non-profit lab for developers who are adding enterprise capabilities to Linux*. The four companies plan to provide significant equipment and funding to the lab over the next several years. Additional contributors and sponsors of the lab include Caldera, Dell, Linuxcare, LynuxWorks, Red Hat, SGI, SuSE, TurboLinux and VA Linux.’ (OSDL, 2000)

207 ‘We are a non-profit corporation organized to accelerate the use and acceptance of open source technologies through the application, development and promotion of standards.’ (http://web.archive.org/web/20000818000537/http://www.freestandards.org/news/2000/20000508.shtml)

208 ‘Even before Linux became an enterprise operating system, the Linux community was concerned about fragmentation and its effects on software developers. In response, the community determined that a binary standard for Linux was important, not only for success in challenging Microsoft Windows, but for guaranteeing a broad and deep availability of applications for the platform. Out of this concern, the community banded together to form the Free Standards Group, a standards body tasked with developing open, international standards that would deliver on the vision of portability within a competitive Linux distribution ecosystem.’ (FSG, 2005)

209 ‘The Linux Foundation has taken its experience and expertise supporting the Linux community to help establish, build, and sustain some of the most critical open source technologies. Its work today extends far beyond Linux, fostering innovation in every layer of the software stack. The Linux Foundation hosts projects spanning enterprise IT, embedded systems, consumer electronics, cloud, networking, and more. A few of these high-velocity projects that are helping redefine what’s possible include Hyperledger for cross-industry blockchain technologies; Automotive Grade Linux, the open software platform for automotive applications; the Open Network Automation Platform project (ONAP) for real-time, policy-driven software automation of virtual network functions; and Kubernetes, the Cloud Native Computing Foundation project for production-grade container orchestration.’ (http:// web.archive.org/web/20200307082247/https://www.linuxfoundation.org/about/)

http://web.archive.org/web/20200307082247/https://www.linuxfoundation.org/about/

http://web.archive.org/web/20200307082247/https://www.linuxfoundation.org/about/

http://web.archive.org/web/20000818000537/http://www.freestandards.org/news/2000/20000508.shtml

https://web.archive.org/web/20080408224303/http://linux-foundation.org/weblogs/press/2007/01/21/new-linux-foundation-launches-%E2%80%93-merger-of-open-source-development-labs-and-free-standards-group/

https://web.archive.org/web/20080408224303/http://linux-foundation.org/weblogs/press/2007/01/21/new-linux-foundation-launches-%E2%80%93-merger-of-open-source-development-labs-and-free-standards-group/

https://chicago.suntimes.com/


210 ‘The Apache Group today announced the creation of the Apache Software Foundation (ASF), to formally shepherd the development of the #1 Web server worldwide -- the Apache HTTP Server Project -- and other projects under the Apache umbrella. This international volunteer effort is dedicated to the support of open-source software projects based on the collaborative model of the Apache HTTP Server Project.’ (http://web.archive.org/web/20000621010723/http://www.apache.org/foundation/press/pr_1999_06_30.html)

211 ‘The Apache Group consists of server users --- people who run web servers for a living, and will, if it is feasible, attempt to give other server users what they want. We have no outside sponsors to please and no institutional agenda of our own to pursue; everyone is welcome to make suggestions to influence the direction we take.’ (http:// web.archive.org/web/19961028123412/http://www.apache.org/info.html)

212 ‘The Apache project has been organized in an attempt to answer some of the concerns regarding active development of a public domain HTTP server. The goal of this project is to provide a secure, efficient and extensible server which provides HTTP services in sync with the current HTTP standards.’ (http://web.archive.org/ web/19961028123412/http://www.apache.org/info.html)

213 ‘Apache is “A PAtCHy server”. It was based on some existing code and a series of “patch files”.’ (http://web.archive.org/web/19961028122409/http://www.apache.org/docs/FAQ.html)

214 ‘The Apache Software Foundation, which was founded to support the Apache HTTPd project, has since created a wide array of other open source projects that add additional unquantified value to the Internet ecosystem.’ (Greenstein & Nagle, 2014, p. 625)

215 http://web.archive.org/web/20200301101456/http://apache.org/ 216 http://web.archive.org/web/20200305070339/https://www.eclipse.org/org/ 217 ‘Industry leaders Borland, IBM, MERANT, QNX Software Systems, Rational Software, RedHat, SuSE,

TogetherSoft and Webgain 2 formed the initial eclipse.org Board of Stewards in November 2001.’ (http://web.archive.org/web/20021219074517/https://www.eclipse.org/org/)

218 http://web.archive.org/web/20200305070339/https://www.eclipse.org/org/ 219 (Eclipse, 2011) 220 http://web.archive.org/web/20200328235029/https://www.eclipse.org/ 221 http://web.archive.org/web/20200404171736/https://www.eclipse.org/org/workinggroups/explore.php 222 ‘Netscape plans to make Netscape Communicator 5.0 source code available for modification and redistribution

beginning later this quarter with the first developer release of the product. The company will handle free source distribution with a license which allows source code modification and redistribution and provides for free availability of source code versions, building on the heritage of the GNU Public License (GPL), familiar to developers on the Net. Netscape intends to create a special Web site service where all interested parties can download the source code, post their enhancements, take part in newsgroup discussions, and obtain and share Communicator-related information with others in the Internet community.’ (Netscape, 1998)

223 https://web.archive.org/web/19990831174207/http://home.netscape.com/newsref/pr/newsrelease577.html? cp=nws02flh1

224 http://web.archive.org/web/19990423143752/http://www.mozilla.org/mission.html 225 http://web.archive.org/web/20200219041024/https://foundation.mozilla.org/en/about/ 226 http://web.archive.org/web/20200216014331/https://www.documentfoundation.org/ 227 http://web.archive.org/web/20200204174442/https://www.gnome.org/foundation/ 228 http://web.archive.org/web/20200224153248/https://kde.org/community/whatiskde/kdefreeqtfoundation.php 229 http://web.archive.org/web/20200307165737/https://mariadb.org/about/#about-mariadb-foundation 230 http://web.archive.org/web/20200216104702/https://www.osgeo.org/ 231 http://web.archive.org/web/20200302021156/https://www.openstack.org/foundation/ 232 http://web.archive.org/web/20191229171333/https://www.perlfoundation.org/ 233 http://web.archive.org/web/20200215012503/https://www.python.org/psf/ 234 http://web.archive.org/web/20200220195411/https://www.videolan.org/videolan/ 235 http://web.archive.org/web/20200227225614/https://www.xiph.org/ 236 http://web.archive.org/web/20200225065539/https://www.openinventionnetwork.com/ 237 (Lundell & van der Linden, 2013) 238 ‘make more use of open source solutions and/or open standards when (re)building ICT systems and solutions

(among else, to avoid vendor lock-ins)’ (EU, 2017)

http://web.archive.org/web/20200225065539/https://www.openinventionnetwork.com/

http://web.archive.org/web/20200227225614/https://www.xiph.org/

http://web.archive.org/web/20200220195411/https://www.videolan.org/videolan/

http://web.archive.org/web/20200215012503/https://www.python.org/psf/

http://web.archive.org/web/20191229171333/https://www.perlfoundation.org/

http://web.archive.org/web/20200302021156/https://www.openstack.org/foundation/

http://web.archive.org/web/20200216104702/https://www.osgeo.org/

http://web.archive.org/web/20200307165737/https://mariadb.org/about/#about-mariadb-foundation

http://web.archive.org/web/20200224153248/https://kde.org/community/whatiskde/kdefreeqtfoundation.php

http://web.archive.org/web/20200204174442/https://www.gnome.org/foundation/

http://web.archive.org/web/20200216014331/https://www.documentfoundation.org/

http://web.archive.org/web/20200219041024/https://foundation.mozilla.org/en/about/

http://web.archive.org/web/19990423143752/http://www.mozilla.org/mission.html

https://web.archive.org/web/19990831174207/http://home.netscape.com/newsref/pr/newsrelease577.html?cp=nws02flh1

https://web.archive.org/web/19990831174207/http://home.netscape.com/newsref/pr/newsrelease577.html?cp=nws02flh1

http://web.archive.org/web/20200404171736/https://www.eclipse.org/org/workinggroups/explore.php

http://web.archive.org/web/20200328235029/https://www.eclipse.org/

http://web.archive.org/web/20200305070339/https://www.eclipse.org/org/



http://web.archive.org/web/20200301101456/http://apache.org/

http://web.archive.org/web/19961028122409/http://www.apache.org/docs/FAQ.html

http://web.archive.org/web/19961028123412/http://www.apache.org/info.html




http://web.archive.org/web/20000621010723/http://www.apache.org/foundation/press/pr_1999_06_30.html

239 Exempelvis etablerades den 15 augusti 2007 i Norge ett nationellt kompetenscenter för öppen programvara efter beslut av regeringen (http://web.archive.org/web/20070821065731/http://www.friprog.no/)

240 ‘an increasing number of government agencies and public administrations (traditionally the largest consumers of software) are mandating that open source be a priority option, even to the extent of requiring formal justification for not choosing an open source solution if one is available.’ (Fitzgerald, 2006, p. 592)

241 För en översikt av de initiativ som tagits i Nederländerna, se exempelvis Netherlands (2007). 242 Se exempelvis projekt GAIA-X för ett initiativ i Tyskland som uppmärksammar vikten av digital suveränitet och

datasuveränitet (GAIA-X, 2019). 243 Se exempelvis ”Försäkringskassans vitbok” som behandlar vikten av digital suveränitet och datasuveränitet för den

pågående digitaliseringen (Försäkringskassan, 2019). 244 ’Säker och kostnadseffektiv it-drift för den offentliga förvaltningen’ (Dir. 2019:64), se vidare:

https://www.regeringen.se/rattsliga-dokument/kommittedirektiv/2019/09/dir.-201964/ 245 (Lundell et al., 2016) 246 ‘Divergent views and litigation over FRAND licensing risk delaying the uptake of new technologies,

standardisation processes and the roll-out of IoT in Europe.’ (EC, 2017b) 247 ‘Many organisations are ‘locked’ into their ICT systems because detailed knowledge about how the system works is

available only to the provider, so that when they need to buy new components or licences only that provider can deliver.’ (EC, 2013b)

248 Se exempelvis Lundell et al. (2015, 2016, 2018, 2019) 249 ‘These procedures are explicitly aimed at developing and adopting generally-accepted practices. Thus, a candidate

for Internet standardization is implemented and tested for correct operation and interoperability by multiple, independent parties, and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard.’ (Chapin, 1992, s. 4)

250 Se exempelvis Lundell et al. (2019) för referenser till ett antal uppmärksammade juridiska utmaningar och rättsfall som relaterar patent som belastar IT-standarder.

251 ‘Patents are time-limited statutory monopolies designed to protect inventions and technological developments. In return for full disclosure of your idea, you are granted the ability to prevent anyone else from making, using, selling, offering for sale, or importing the invention. Patents last for a maximum of about 20 years, after which the invention becomes part of the public domain.’ (Lindberg, 2008, p. 4)

252 Det ska noteras att det i praktiken, även för experter, många gånger är mycket svårt att identifiera och avgöra huruvida ett specifikt patent faktiskt belastar en specifik standard och ett specifikt programvaruprojekt. Då en organisation hävdar att organisationen innehar ett (eller flera) patent som belastar en specifik standard (exempelvis genom att deklarera att de innehar patent som belastar standarden till en standardiseringsorganisation) visar forskning att det för många standarder i praktiken är helt omöjligt att (inom rimlig tid) klargöra huruvida det är möjligt att använda den specifika standarden utan att den organisation som planerar att använda standarden behöver ta en betydande juridisk risk (se exempelvis Lundell et al., 2015, 2019).

253 Frågor om patent som belastar programvara och standarder är ett område som analyserats och diskuterats under lång tid av företrädare för olika aktörer med olika intressen. Bland organisationer som innehar affärsintressen med patentportföljer som potentiellt kan ha stor påverkan på olika projekt där företag och myndigheter digitaliserar är det viktigt att uppmärksamma och vara medveten om aktiviteter från aktörer vars (i vissa fall dominerande) affärsidé är att tillhandahålla patentlicenser (s.k. ’non practicing entities’, ibland även kallade patenttroll).

254 ‘Suffice it to say that Apple and Google are for the first time spending more on litigation than on Research and Development. And this issue does not only apply to large corporations that make the everyday headlines but to smaller companies as well who often become victims of patent trolling when they become large enough to be lucrative targets for patent infringement lawsuits.’ (Altsitsiadis, 2014)

https://www.regeringen.se/rattsliga-dokument/kommittedirektiv/2019/09/dir.-201964/

http://web.archive.org/web/20070821065731/http://www.friprog.no/

255 ’Beroende på vilken tjänst och vilken leverantör det är fråga om kan standardavtalen vara mer eller mindre omfattande och svårtolkade. Det är inte ovanligt att standardavtalen är mer komplicerade än tjänsterna i fråga och det kan vara en grannlaga uppgift att granska samtliga avtalsdokument och kontrollera hur avtalsvillkoren förhåller sig dels till varandra, dels till det regelverk myndigheten har att efterleva. Inte desto mindre är avtalsgranskning och -förhandling av avgörande vikt för att säkerställa att en upphandlande myndighet inte accepterar villkor som står i strid med författningskrav eller som på annat sätt kan leda till kännbara framtida konsekvenser för myndigheten. Här bör myndigheten bl.a. uppmärksamma om avtalet innehåller olämpliga villkor om lagval och tvistelösning. Inte sällan hänvisas till amerikansk lag, om leverantören har sitt säte i USA, och att tvistelösning ska ske i amerikansk domstol eller skiljenämnd. Därtill kan avtalet innehålla villkor som ger främmande makts myndigheter, eller andra aktörer, omfattande möjligheter att ta del av den information som leverantören hanterar på uppdrag av myndigheten (se även kapitel 10.1.3). Vidare behöver myndigheten uppmärksamma villkor som ger leverantören möjlighet att ensidigt ändra avtalsvillkoren eller att självsvåldigt avgöra om det finns skäl att innehålla (suspendera) tjänsten eller avsluta avtalsförhållandet i förtid. Standardavtalen är därtill ofta avfattade på engelska och det kan vara påfallande komplicerat att tolka avtalsvillkoren i en svensk juridisk kontext.’ (SOU, 2018, p. 409)

256 ’Myndigheters arbete med it-avtal är starkt sammanlänkat med upphandlingsprocessen och i synnerhet beställarkompetensen. Det är i den inledande fasen av upphandlingsarbetet som myndigheten t.ex. kan formulera en kravspecifikation som minimerar risken för framtida inlåsningseffekter. Men för att fullt ut undvika inlåsnings-effekter till följd av leverantörens immateriella rättigheter behöver myndigheten dessutom formulera ändamålsenliga avtalsvillkor.’ (SOU, 2018, p. 431)

257 ’Å ena sidan kan ändamålsenligt utformade avtalsvillkor vid köp av it bidra till att en myndighet uppfyller kraven på bl.a. rättssäkerhet i verksamheten och samtidigt kan tillgodogöra sig kostnadseffektiva och innovativa lösningar i affärsmässigt gynnsamma relationer. Otydligt eller olämpligt formulerade avtalsvillkor, eller avsaknad av avtalsvillkor, kan å andra sidan resultera i bristande rättssäkerhet, inlåsningseffekter, oklara ansvarsförhållanden, kostnadsdrivande lösningar etc., vilket i sin tur kan leda till negativa konsekvenser för en myndighets förmåga att exempelvis bedriva ett effektivt digitaliseringsarbete.’ (SOU, 2018, p. 490)

258 (Lundell et al., 2016; Lundell et al., 2015, 2019) 259 ’Vi har fått förklarat för oss att det finns utmaningar i att formulera förutsebara avtalsvillkor, t.ex. sådana som leder

till att det inte uppstår s.k. inlåsningseffekter. Det kan exempelvis vara komplicerat att utforma tydliga avtalsvillkor som ålägger leverantören att samarbeta vid ett framtida leverantörsbyte. Exempel: Om det saknas avtalsvillkor som förbinder leverantören att samarbeta vid ett framtida leverantörsbyte eller att överföra myndighetens information i ett användbart format vid avtalets upphörande kan det leda till svårigheter när myndigheten vill byta leverantör.’ (SOU, 2018, p. 108)

260 ’Mjuk infrastruktur och standardisering utgör fundament för att uppnå interoperabilitet, dvs. att få system, organisationer eller verksamhetsprocesser att fungera tillsammans och kunna kommunicera med varandra genom att överenskomna regler följs.’ (SOU, 2015b, p. 154)

261 ’Tekniklösningar som används för kommunikation mellan köpare och säljare måste vanligtvis bygga på en någorlunda gemensam teknisk plattform. Rädsla för inlåsningseffekter i system utvecklade i frånvaro av gemensamma standarder kan minska incitamenten att investera i it-lösningar.’ (SOU, 2012, p. 70); ’För att kunna utveckla en effektiv e-förvaltning bör systemen bygga på gemensamma standarder och kunna hantera olika tekniska format. Det saknas gemensamma specifikationer och format för de offentliga aktörernas it-system.’ (Riksrevisionen, 2016, s. 7)

262 ’förvaltningsgemensamma standarder’ (SOU, 2017, p. 220-221) 263 ’Tekniska specifikationer 5 § Det ska finnas tekniska specifikationer för elektronisk identifiering, som löpande ska

anpassas till väletablerade standarder, utvecklingen i övrigt, samt de hot och risker som kan uppkomma på området.’ (SOU, 2017, p. 32)

264 ’I E-delegationens principer för digital samverkan slås fast att öppna standarder bör användas, bl.a. för att de kan användas fritt utan att ägaren av standarden sätter upp orimliga eller diskriminerande hinder, kostnader eller avtalsmässiga begränsningar.’ (SOU, 2015a, s. 73)

265 ’Hur kan målet uppnås? Genom att er myndighet medverkar till att förenkla företagens gränsöverskridande verksamhet, främja konkurrens mellan leverantörer och förhindra inlåsning till en viss leverantör, t.ex. genom att i era upphandlingar hänvisa till internationella standarder. Strävan bör vara att i möjligaste mån använda sig av öppna standarder.’ (Regeringskansliet, 2016, p. 15)

266 (Lundell et al., 2015, 2019)

267 ’Generellt framstår det också som att statsförvaltningen i hög grad är inlåst till vissa leverantörer och att öppna standarder inte är en prioriterad fråga alternativt att det är i det närmaste omöjligt att dra nytta av öppna standarder p.g.a. inlåsningen till vissa leverantörer.’ (SSC, 2016, p. 21)

268 ’Enligt visionen ska den statliga molntjänsten som utgångspunkt bygga på principen om leverantörsoberoende, öppna standarder och öppen källkod. Detta mottogs uteslutande positivt av de intervjuade myndigheterna.’ (SSC, 2016, p. 31)

269 ’Regeringen ska verka för att digitala tjänster i så stor utsträckning som möjligt bygger på öppna standarder’ (Regeringen, 2018, p. 24)

270 ‘In this new world of standards, one of the currently most contentious issues concerns the meaning of a commitment by the holder of patents “essential” to the practice of a standard to license such patents on “fair, reasonable, and nondiscriminatory (FRAND)” terms and conditions.’ (Brooks & Geradin, 2011, p. 1, 2)

271 ’Regeringen anser att FRAND-avtal kan utgöra en lösning för att säkerställa att en balans uppnås mellan rättighetsinnehavare och användare’ (Regeringen, 2018, p. 15)

272 ‘There is legal uncertainty around what is defined as “fair and reasonable” in FRAND-governed IPR policies of standards-developing organisations (SDOs). Precise licensing conditions have to be agreed with the IPR owner before use of the licensed technology.’ (EC, 2012)

273 (Lundell et al., 2015) 274 (Lundell et al., 2015; 2019) 275 (Regeringen, 2005, s. 209) 276 (Regeringen, 2005, s. 210-211) 277 (Regeringen, 2005, s. 210) 278 (Regeringen, 2009) 279 (SOU, 2009, s. 15) 280 E-delegationens strategi för myndigheternas arbete med e-förvaltning presenterar en konkurrensneutral definition

av ”öppen standard” (SOU, 2009) som är identisk med den definition av ”öppen standard” som presenteras i EU:s interoperabilitetsramverk version 1.0 (EC, 2004).

281 (SOU, 2011, s. 35) 282 (Regeringskansliet, 2012, s. 13) 283 (Regeringen, 2017, s. 17) 284 ’Regeringen ska verka för att myndigheter vid upphandlingar i ökad utsträckning hänvisar till att it- och digitala

standarder bygger på öppen källkod’ (Regeringen, 2018, p. 11; Regeringskansliet, 2019, p. 13) 285 Denna ansats för standardisering refereras ibland som specifikationsdriven standardisering eftersom det existerar

en teknisk specifikation av it-standarden innan det finns en implementation i ett programvaruprojekt som tillhandahåller öppen programvara. I detta fall utvecklas den tekniska specifikationen av it-standarden på traditionellt sätt inom ramen för en standardiseringsorganisation (Lundell & Gamalielsson, 2017)

286 Denna ansats för standardisering refereras ibland som implementationsdriven standardisering eftersom det existerar en implementation i öppen programvara innan det finns en dokumentation i en teknisk specifikationen av en it-standard (Lundell & Gamalielsson, 2017).

287 (Lundell et al., 2016; Lundell et al., 2019) 288 (Regeringen, 2019b) 289 Exempelvis på någon tillgänglig plattform där öppen programvara utvecklas och tillhandahålls, som exempelvis:

GitHub (https://github.com/), GitLab (https://about.gitlab.com/), Launchpad (https://launchpad.net/) eller någon annan plattform.

290 (Regeringen, 2019b, p. 4) 291 ‘As the adoption of these recommendations requires considerable political will at several levels, it is more likely

that governments will move towards the increased use of open source through a bottom-up process, as is already the case with several regional or provincial governments. This is typically achieved through the use of a simple of “leveling the playing field” for public tenders, which currently heavily favour dominant vendors of proprietary software through interoperability requirements.’ (FLOSS, 2002c, p. 29)

292 ‘The solution is to require interoperability, but with open standards rather than proprietary ones, making open source software solutions providers viable suppliers and also reducing public dependence and vendor lock-in.’ (FLOSS, 2002c, p. 29)

https://launchpad.net/

https://about.gitlab.com/

https://github.com/

293 ‘compatibility with proprietary technologies should be explicitly excluded from public procurement criteria and replaced by interoperability with products from multiple vendors’ (FLOSSPOLS, 2005, p. 3)

294 ‘Open source software is a public resource with low entry barriers. Unlike forms of intellectual property with restricted access for re-use (through patents, restrictive copyright licensing), open source software can both disseminate innovations in the fastest possible way, as well as provide for further development and innovation from any source without inefficient time delays or other costs.’ (Ghosh, 2003, p. 61)

295 ‘Open source innovation has become a ubiquitous element of digital innovation. Today, open source tools such as Apache servers, Linux operating systems and countless machine learning libraries underpin the functioning of the digital economy.’ (OECD, 2019, p. 156)

296 (Försäkringskassan, 2018) 297 (Lundell et al., 2016) 298 (Lundell et al., 2016) 299 (Byttner, 2004) 300 http://web.archive.org/web/20051222035610/http://forum.carelink.se/pages/newsbill.asp?

deptid=24&projid=39&pages=207 301 ‘Carelink is a national association in Sweden comprised of members representing county councils, regions,

municipalities, and private healthcare organisations. We promote the advancement of information technology (IT) as a means to support and enhance efficiency in care for patients and providers alike. Carelink was formed in 2000 by the Swedish Federation of County Councils, the Swedish Association of Local Authorities, the Association of Private Care Providers and Apoteket, the Swedish Pharmacy chain. Carelink currently has 67 members.’ (Carelink, 2005, p. 3)

302 (Carelink, 2005) 303 http://web.archive.org/web/20080211094214/http://www.carelink.se/ 304 http://web.archive.org/web/20100812091347/http://www.carelink.se/ 305 (Ramböll, 2016) 306 (EC, 2020b) 307 https://joinup.ec.europa.eu/collection/open-source-observatory-osor/open-source-software-country-intelligence 308 (Lundell et al., 2017) 309 ’Uppdraget avser en förstudie som ska behandla frågor om öppna system och användning av olika typer av öppna

datorprogram d.v.s. programvaror för vilka användaren får tillgång till källkoden. Operativsystemet Linux är ett exempel på programvara som upplåts med öppen källkod. Ibland används beteckningen Open Source. Många av de produkter som används på Internet baseras på öppen programvara.’ (Statskontoret, 2002)

310 ’Bakgrunden till förstudien är även de aktiviteter inom området som pågår i offentlig förvaltning i omvärlden liksom initiativ inom EU. Viktigt är vidare de kännbara effekter som förvaltningen drabbats av på senare tid genom att ett fåtal stora programtillverkare helt dominerar marknaden för kontorsstöds- och operativsystemprodukter. Den bristande konkurrensen har gett återverkningar på priser och licensvillkor. Det finns även problem med säkerhet och sårbarhet.’ (Statskontoret, 2002)

311 ‘Word 2003 does not support DTD:s, which is a reason why XML -documents created in StarOffice cannot be opened in Word 2003. The OpenOffice.org open source project says on their official website that one of the requirements that was set for the XML -format that StarOffice and OpenOffice 2 should implement, is that the subdocuments, i.e. the five XML - documents in the sxw-package, should be editable in external programs 3 . It can be assumed that a prerequisite for this is that the external programs support DTD :s, which Word 2003 does not do.’ (Statskontoret, 2003b, p. 10)

312 ‘In the short run, the success of a new XML -supporting word processor depends on its ability to handle the Microsoft doc-format which has almost become a word processing standard. Performing tests on open source alternatives to the Microsoft programs are therefore important to ensure that they are compatible to the formats used commonly today.’ (Statskontoret, 2003b, p. 4)

313 ’Giltighetstiden för ramavtalet är 2004-11-23 – 2006-11-22 med möjlighet till 12 månaders förlängning.’ (Statskontoret, 2004, s. 4)

314 (Byttner, 2004) 315 (Byttner, 2004) 316 ’Verket för förvaltningsutveckling (Verva) är en ny myndighet som startades den 1 januari 2006. Vervas instruktion

är att agera som en central förvaltningsmyndighet för utveckling av en sammanhållen statlig förvaltning.’ (Verva, 2008, p. 5)

https://joinup.ec.europa.eu/collection/open-source-observatory-osor/open-source-software-country-intelligence

http://web.archive.org/web/20100812091347/http://www.carelink.se/

http://web.archive.org/web/20080211094214/http://www.carelink.se/

http://web.archive.org/web/20051222035610/http://forum.carelink.se/pages/newsbill.asp?deptid=24&projid=39&pages=207

http://web.archive.org/web/20051222035610/http://forum.carelink.se/pages/newsbill.asp?deptid=24&projid=39&pages=207

https://OpenOffice.org

317 (Verva, 2008, p. 5) 318 (Verva, 2008, p. 5) 319 Den ursprungliga planen var att ramavtalet skulle gälla till den 31 mars 2010, men efter beslut av Kammarkollegiet

den 18 januari 2010 bestämdes om en förlängning vilket innebar att ramavtalet gällde till den 31 mars 20111. 320 (Verva, 2007b) 321 (Verva, 2006) 322 (Verva, 2006, p. 11) 323 ’IT-standardiseringsutredningen skall analysera de rättsliga konsekvenserna av en ökad användning av öppen

källkod. Denna rapport biträder utredningen i denna fråga. Rapporten är författad av Daniel Westman, Institutionen för rättsinformatik vid Stockholms Universitet, på uppdrag av Verva.’ (Verva, 2007a, p. 1)

324 ’Den som ändrar ett datorprogram på ett sätt som inte är helt okvalificerat får ett upphovsrättsligt skydd för sin bearbetning. Den som vill utnyttja ett bearbetat datorprogram kan alltså behöva ha tillstånd från flera rättighetshavare. Genom att licensiera ett program enligt en öppen licens med en copyleft-klausul säkerställs att det ursprungliga programmet och alla senare ändringar som distribueras kan utnyttjas enligt samma generösa licensvillkor.’ (Verva, 2007a, p. 3)

325 (Verva, 2008, p. 35) 326 (Verva, 2008, p. 7) 327 (Kammarkollegiet, 2010, s. 23) 328 (Kammarkollegiet, 2011) 329 http://web.archive.org/web/20110303202909/http://www.avropa.se/templates/ramavtalsomrade____2553.aspx 330 För detta ramavtal utnyttjades förlängningsoptionen så att avtalsperioden förlängdes från det ursprungliga

slutdatumet 31 mars 2013, först till 31 juli 2014 och därefter till 31 mars 2015, vilket innebar att ramavtalet var gällande under totalt fyra år. Se vidare: http://web.archive.org/web/20111020193522/http://www.avropa.se/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom/Programvaror-och-tjanster/Oppna-programvaror-2010; http://web.archive.org/web/20140124144923/http://www.avropa.se:80/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom1/Programvaror-och-licenser/Oppna-programvaror-2010/; http://web.archive.org/web/20140331235455/http://www.avropa.se:80/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom1/Programvaror-och-licenser/Oppna-programvaror-2010

331 (Kammarkollegiet, 2014a, s. 2) 332 (EC, 2004) 333 (Kammarkollegiet, 2014a, s. 43) 334 ’Kund får ställa obligatoriska krav på standarder endast om standarden uppfyller kraven på en öppen standard enligt

SOU 2009:86. Med en öppen standard avses en standard som uppfyller de fyra kriterier som interoperabilitetsramverket EIF 1.0 anger.’ (Kammarkollegiet, 2014b, s. 6)

335 (EC, 2004) 336 (Kammarkollegiet, 2014a, s. 43) 337 (EC, 2004) 338 (Kammarkollegiet, 2016) 339 (NPS, 2016) 340 ’Listan översattes därefter till engelska eftersom intresset från EU och andra länder var stort.’ (Kammarkollegiet,

2017a) 341 http://web.archive.org/web/20151005034737/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/

Programvaror-och-tjanster/systemutveckling/ 342 Då beslut om ramavtal fattades inom ramavtalsområdet Systemutveckling gällde dessa fram till den 30 april 2017,

se vidare: http://web.archive.org/web/20180608071618/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/systemutveckling/

343 http://web.archive.org/web/20160125143338/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/ Programvaror-och-tjanster/kontorsstod/

344 Då beslut om ramavtal fattades inom ramavtalsområdet Kontorsstöd gällde dessa fram till den 30 april 2017, se vidare: http://web.archive.org/web/20180607144916/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/kontorsstod/

345 http://web.archive.org/web/20160228034207/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/ Programvaror-och-tjanster/grundlaggande-it/

http://web.archive.org/web/20160228034207/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/grundlaggande-it/


http://web.archive.org/web/20180607144916/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/kontorsstod/




http://web.archive.org/web/20180608071618/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/systemutveckling/




http://web.archive.org/web/20140331235455/http://www.avropa.se:80/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom1/Programvaror-och-licenser/Oppna-programvaror-2010

http://web.archive.org/web/20140331235455/http://www.avropa.se:80/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom1/Programvaror-och-licenser/Oppna-programvaror-2010

http://web.archive.org/web/20140124144923/http://www.avropa.se:80/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom1/Programvaror-och-licenser/Oppna-programvaror-2010/

http://web.archive.org/web/20140124144923/http://www.avropa.se:80/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom1/Programvaror-och-licenser/Oppna-programvaror-2010/

http://web.archive.org/web/20111020193522/http://www.avropa.se/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom/Programvaror-och-tjanster/Oppna-programvaror-2010

http://web.archive.org/web/20111020193522/http://www.avropa.se/Hitta-ramavtal/Ramavtalsomraden/IT-och-telekom/Programvaror-och-tjanster/Oppna-programvaror-2010

http://web.archive.org/web/20110303202909/http://www.avropa.se/templates/ramavtalsomrade____2553.aspx

346 Då beslut om ramavtal fattades inom ramavtalsområdet Grundläggande IT gällde dessa fram till den 30 april 2017, se vidare: http://web.archive.org/web/20180608071612/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/grundlaggande-it/

347 http://web.archive.org/web/20160128172015/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/ Programvaror-och-tjanster/informationsforsorjning

348 Enligt det ursprungliga beslutet gällde ramavtalen för detta ramavtalsområde till den 30 november 2017 (se http://web.archive.org/web/20160128172015/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/ Programvaror-och-tjanster/informationsforsorjning). Ramavtalen för detta ramavtalsområde förlängdes initialt till den 1 juni 2019 (se http://web.archive.org/web/20180511011109/http://www.avropa.se/ramavtal/ramavtalsomraden/ it-och-telekom/Programvaror-och-tjanster/informationsforsorjning) och efter ytterligare en förlängning till den 30 november 2019 (se https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/ informationsforsorjning2/).

349 https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/ informationsforsorjning2/

350 (Kammarkollegiet, 2017a) 351 (Kammarkollegiet, 2017a, s. 17) 352 http://web.archive.org/web/20180610090856/http://www.avropa.se/Upphandlingar/programvaror-och-tjanster/ 353 http://web.archive.org/web/20191117204736/https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/

Programvaror-och-tjanster/systemutveckling/ 354 https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/vard-skola-omsorg/ 355 https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/licensforsorjning/ 356 https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/

programvarulosningar/ 357 https://www.avropa.se/Nyheter/2019/itu/programvaror-och-tjanster---informationsforsorjning-overprovad/ 358 https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/

informationsforsorjning2/ 359 ’Kund får ställa obligatoriska krav på standarder endast om standarden uppfyller kraven på en öppen standard enligt

SOU 2009:86. Med en öppen standard avses en standard som uppfyller de fyra kriterier som interoperabilitetsramverket EIF 1.0 anger.’ (Kammarkollegiet, 2017b, s. 4)

360 (EC, 2004) 361 (Kammarkollegiet, 2014a, s. 43) 362 (Kammarkollegiet, 2018a, s. 8) 363 (Kammarkollegiet, 2018a, s. 24) 364 (Kammarkollegiet, 2018b) 365 (Kammarkollegiet, 2018b, s. 6) 366 (Kammarkollegiet, 2018b, s. 7) 367 ‘we found 1,540 papers related to OSS. Of these, 112 contained empirical evidence on the practical implications of

organizational OSS adoption.’ (Ayala, 2011, p. 95) 368 ‘organizations need to ensure that their high-level managers and employees support the OSS adoption and that they

have the skills in-house to succeed.’ (Ayala, 2011, p. 96) 369 ‘especially Germany and Sweden were of interest, as desk research revealed that they show opposite extremes of

OSS usage’ (FLOSS, 2002b) 370 ‘in Germany 42,7% of Internet hosts were running Linux, while the same figure for Sweden was only 16,9%’

(FLOSS, 2002b) 371 ‘The essential idea of LPP is that learning is situated in social situations, and learning takes place when members of

a community of practice interact with each other in their daily practice.’ (Ye & Kishida, 2003, p. 419) 372 ‘This paper describes a conceptual framework to analyze the motivational issues in OSS. It argues that learning is

one of the major motivational forces that attract software developers and users to participate in OSS development and to become members of OSS communities.’ (Ye & Kishida, 2003, p. 419)

https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/informationsforsorjning2/


https://www.avropa.se/Nyheter/2019/itu/programvaror-och-tjanster---informationsforsorjning-overprovad/

https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/programvarulosningar/

https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/programvarulosningar/

https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/licensforsorjning/

https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/vard-skola-omsorg/

http://web.archive.org/web/20191117204736/https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/systemutveckling/

http://web.archive.org/web/20191117204736/https://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/systemutveckling/

http://web.archive.org/web/20180610090856/http://www.avropa.se/Upphandlingar/programvaror-och-tjanster/





http://web.archive.org/web/20180511011109/http://www.avropa.se/ramavtal/ramavtalsomraden/it-och-telekom/Programvaror-och-tjanster/informationsforsorjning









373 ‘The right to access and modify source code itself does not make OSS projects different from most “Closed Source Software” ones. All developers in a project in any software company would have the same access privilege. The fundamental difference is the role transformation of the people involved in a project. In Closed Source Software projects, developers and users are clearly defined and strictly separated. In OSS projects, there is no clear distinction between developers and users: all users are potential developers.’ (Ye & Kishida, 2003, p. 419)

374 http://web.archive.org/web/20100409073057/http://oss2009.org/ 375 http://web.archive.org/web/20200122013631/https://opensym.org/os2019/ 376 (Lundell et al., 2019) 377 (OSI, 2020) 378 ‘I hope that readers will choose their words carefully to clarify that both open and closed source software may be

used for commercial and non-commercial purposes and that any software –other than that contributed to the public domain–is proprietary to its owner.’ (Murray, 2009, p. 10)

379 ‘The components of the GNU/Linux OS are copyrighted, and the rights are held by identifiable persons and firms. Under the open-source model of software production, however, these rights are used to enforce norms of the open-source community: Code may be freely copied, modified, and distributed, but only if the modifications (derivative works) are distributed on these terms as well.’ (McGowan, 2001, p. 242)

380 ‘A FOSS license is at root a copyright license, which must be (a) perpetual (subject to termination for violation of its conditions), (b) royalty-free, (c) granting essentially unlimited rights to engage in non-public-facing use of the code (execution, copying, and modification per se), and (d) restricting public-facing use (typically distribution or making copies available) only in ways that are not customarily regarded as unduly burdensome to the exercise of software freedom.’ (Fontana, 2010, p. 1, 2)

381 ‘The source must be available for redistribution without restriction and without charge, and the license must permit the creation of modifications and derivative works, and must allow those derivatives to be redistributed under the same terms as the original work.’ (O’Reilly, 1999, p. 34)

382 http://web.archive.org/web/20200219073428/https://opensource.org/licenses/BSD-2-Clause 383 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 384 http://web.archive.org/web/20200305231132/https://spdx.org/licenses/BSD-2-Clause.html 385 ‘Early in 1977, [Bill] Joy put together the “Berkeley Software Distribution.” This first distribution included the

Pascal system, and, in an obscure subdirectory of the Pascal source, the editor ex. Over the next year, Joy, acting in the capacity of distribution secretary, sent out about thirty free copies of the system.’ (McKusick, 1999, p. 22)

386 ‘The BSD originated networking code and supporting utilities were released in June 1989 as Networking Release 1, the first freely-redistributable code from Berkeley.’ (McKusick, 1999, p. 22)

387 ‘The licensing terms were liberal. A licensee could release the code modified or unmodified in source or binary form with no accounting or royalties to Berkeley. The only requirements were that the copyright notices in the source file be left intact and that products that incorporated the code indicate in their documentation that the product contained code from the University of California and its contributors.’ (McKusick, 1999, p. 22)

388 ‘Although Berkeley charged a $1,000 fee to get a tape, anyone was free to get a copy from anyone who had already had received it. Indeed, several large sites put it up for anonymous ftp shortly after it was released. Given that it was so easily available, the CSRG [Computer Systems Research Group] was pleased that several hundred organizations purchased copies, since their fees helped fund further development.’ (McKusick, 1999, p. 22)

389 ‘The advertising clause (the third of four clauses) required you to acknowledge use of U.C. Berkeley code in your advertising of any product using that code.’ (https://web.archive.org/web/20091129081849/http://www.opensource.org/licenses/bsd-license.php)

390 https://web.archive.org/web/20091129081849/http://www.opensource.org/licenses/bsd-license.php 391 ‘BSD or Berkeley Software Distribution used narrowly, means the open source licensing model developed in the

late 1970s and early 1980s out of the University of California at Berkeley by Bill Joy (later a co-founder of Sun Microsystems) in their efforts at improving Unix. Unlike the GPL model of the Free Software Foundation, there is no express obligation to return improvements and derivative works back to the common pool on the same terms as the original open source licence, although that is part of the underlying philosophy of the licence. Used widely, BSD refers to a number of licences of a similar kind, including FreeBSD and Open BSD.’ (James, 2003, p. 86)

392 http://web.archive.org/web/20200108095339/https://opensource.org/licenses/bsd-3-clause

http://web.archive.org/web/20200108095339/https://opensource.org/licenses/bsd-3-clause

https://web.archive.org/web/20091129081849/http://www.opensource.org/licenses/bsd-license.php

https://web.archive.org/web/20091129081849/http://www.opensource.org/licenses/bsd-license.php

http://web.archive.org/web/20200305231132/https://spdx.org/licenses/BSD-2-Clause.html


http://web.archive.org/web/20200219073428/https://opensource.org/licenses/BSD-2-Clause

http://web.archive.org/web/20200122013631/https://opensym.org/os2019/

http://web.archive.org/web/20100409073057/http://oss2009.org/

393 ‘It is clear that the licensee has a right to distribute the work, and it would be hard to argue that the licensee does not also have a right to modify. However, one of the most significant rights under copyright law is entirely missing from this grant: the right to reproduce the work. Some right of reproduction could be read into the right to modify, as the type of work the licence covers is computer code, and it is impractical to suggest that the licensee may modify and distribute a computer software work but may not reproduce that software. The expressly granted right to use could bolster this position; with respect to software, use often requires some form of reproduction.’ (Sinclair, 2010, p. 3)

394 BSD-2-Clause ‘do not require source code distribution.’ (Fontana et al., 2008, p. 6) 395 ‘You can, if you like, take the entire NetBSD operating system, change one line of code, and then make the whole

thing proprietary and try to sell it as YourOS. For this reason, a variant of BSD is now the second most widely used desktop computer operating system. Apple took pieces of Mach, FreeBSD, and NetBSD, created Darwin, and then spun Darwin into Mac OS X. There are large pieces of OS X that are now closed source software, even though they are based on BSD. That’s one of the features of the BSD license: it leaves to folks like Steve Jobs and the crew over at Apple the decision of whether they want to share or not.’ (Michaelson, 2004, p. 42)

396 ‘Under the BSD there is no Copyleft principle; the BSD-licensed software can be incorporated with other software and distributed under proprietary terms without any violation of the license.’ (Grodsten Kennedy, 2011, p. 18)

397 ‘The BSD license grant simply provides that “[r]edistribution and use in source and binary forms, with or without modification, are permitted” provided certain conditions are met, such as including a copyright notice. While the word “use” is a patent term, and nothing in this grant excludes its applicability to patents, that result is not at all certain.’ (Nadan, 2009, p. 2)

398 ‘The exclusive rights of a patent holder as enumerated in 35 U.S.C. Sec. 271(a), i.e. the rights to make, use, sell, offer for sale and import’ (Haapanen, 2015, p. 20)

399 ‘Under the BSD license, in turn, redistribution and use of the software with or without modification is permitted subject to certain conditions. The BSD license therefore mentions only one of the five enumerated exclusive patent rights: “use.” ’ (Haapanen, 2015, p. 20)

400 (Välimäki & Oksanen, 2005, p. 400) 401 ‘there is probably an implied patent license granted under any patents a distributor has that reads on the software

distributed.’ (Ilardi, 2011, p. 6) 402 ‘Because there are only 81 licenses, it is possible to exhaustively review every open source license for evidence of a

patent grant. Having done so, I conclude that essentially every open source license includes a patent grant.’ (Lindberg, 2019, p. 258, 259)

403 (Kesan, 2011) 404 http://web.archive.org/web/20200117181040/https://opensource.org/licenses/Apache-2.0 405 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 406 http://web.archive.org/web/20200218181129/https://spdx.org/licenses/Apache-2.0.html 407 http://web.archive.org/web/19961028114216/https://www.apache.org/ 408 ‘This is liberated software. Not just (as in many cases) free of charge, but–much more important–free for any

programmer to modify, improve and share with other programmers. Its code was out there for anyone and everyone to see–and copy.’ (McHugh, 1998, p. 96)

409 http://web.archive.org/web/19990507045520/http://www.apache.org/LICENSE.txt 410 ‘The Apache Group today announced the creation of the Apache Software Foundation (ASF)’

(http://web.archive.org/web/20000621010723/http://www.apache.org/foundation/press/pr_1999_06_30.html) 411 ‘Apache software may be used by anyone, anywhere, for any purpose, including for inclusion in proprietary

derivative works, without any obligation to disclose source code.’ (Rosen, 2005, p. 91) 412 ‘Based upon the 1.0 version of the ASL, the 1.1 version was approved by the ASF in 2000. The primary change

from the 1.0 licence is in the 'advertising clause' (section 3 of the 1.0 licence); derived products are no longer required to include attribution in their advertising materials, but only in their documentation.’ (http://web.archive.org/web/20010608220653/http://www.apache.org/licenses/)

413 http://web.archive.org/web/20010124085100/http://www.opensource.org/licenses/ 414 http://web.archive.org/web/20010202163100/http://www.apache.org/LICENSE 415 http://web.archive.org/web/20060405113954/http://www.opensource.org/licenses/apache2.0.php

http://web.archive.org/web/20060405113954/http://www.opensource.org/licenses/apache2.0.php

http://web.archive.org/web/20010202163100/http://www.apache.org/LICENSE

http://web.archive.org/web/20010124085100/http://www.opensource.org/licenses/

http://web.archive.org/web/20010608220653/http://www.apache.org/licenses/

http://web.archive.org/web/20000621010723/http://www.apache.org/foundation/press/pr_1999_06_30.html

http://web.archive.org/web/19990507045520/http://www.apache.org/LICENSE.txt

http://web.archive.org/web/19961028114216/https://www.apache.org/

http://web.archive.org/web/20200218181129/https://spdx.org/licenses/Apache-2.0.html



416 ‘The 2.0 version of the Apache License was approved by the ASF in 2004. The goals of this license revision have been to reduce the number of frequently asked questions, to allow the license to be reusable without modification by any project (including non-ASF projects), to allow the license to be included by reference instead of listed in every file, to clarify the license on submission of contributions, to require a patent license on contributions that necessarily infringe the contributor’s own patents, and to move comments regarding Apache and other inherited attribution notices to a location outside the license terms (the NOTICE file).’ (http://web.archive.org/web/20040610190542/http://www.apache.org/licenses/)

417 ‘The Apache license was created by the Apache Software Foundation. Like the BSD and MIT licenses, the Apache license allows software to be used without any obligation to redistribute the source code of any of the derivative works. The main difference is that the Apache license provides a clause about patent licensing and termination. In addition to providing a patent clause, the Apache license requires that any modifications to the source code distributed under the license carry prominent notices that the files were changed.’ (Hahn, 2014, p. 693)

418 ‘As a permissive open source licence (an open source licence that features broad permissions and no “copyleft” provision), the Apache License, Version 2.0 [...] has similar legal effects to those of licences like the BSD License, MIT License and historic permission notices.’ (Sinclair, 2010, p. 107)

419 ‘The Apache License expressly grants both a copyright licence and a patent licence to licensees. This is somewhat unusual among permissive open source licences, which do not usually mention patents.’ (Sinclair, 2010b, p. 109)

420 ‘Apache 2.0 includes a specific grant of the usual copyright rights to reproduce, distribute, prepare derivative works, perform, and display (§ 2), as well as a specific grant of patent rights (§ 3). The grant of patent rights is also the typical grant to make, use, and display, etc. but attaches “only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.” ’ (Ilardi, 2011, p. 5)

421 ‘The patent licence grant of the Apache License, like the copyright licence grant, seems to be based on US statutory law. The licence includes the rights to make, use, sell, and import, which are the terms used in the US Patent Act.’ (Sinclair, 2010b, p. 109)

422 ‘The Apache License contains an express patent license grant in Section 3. Unlike GPLv3, the patent license only extends to those patents held by a contributor of code and that apply to that contributor’s contribution, not to the entire work.’ (Webbink, 2009, p. 90)

423 ‘The last sentence of the patent licence section is not actually part of the licence grant; it is a patent termination clause. If a licensee under the Apache License brings a patent claim alleging that a work under the Apache License infringes that licensee’s patent, the Apache License ceases with respect to that licensee. This is a simple and relatively strong clause, as it applies to any patent litigation claim with respect to code under the Apache License and does not offer any resolution period (the termination is effective immediately upon the filing of the patent litigation claim).’ (Sinclair, 2010b, p. 110)

424 ‘Some of them may have even more far-reaching termination clauses that try to affect the enforceability of other software patents as well. See e.g. the latest versions of Apache license and Open Software Licenses for that matter.’ (Välimäki & Oksanen, 2005, p. 400)

425 ‘In a peripheral way, use of the code or mere redistribution does affect one’s patents. If a party (“You”) is exercising the license, and if it brings a claim accusing the open source software being provided under the license, then it loses the benefit of the patent licenses granted to it, but it does not lose the copyright license. Different open source licenses implement variations on this theme. For example, the Apache defensive termination provision is triggered by a defensive patent counterclaim. If that sounds harsh, keep in mind that the claim must accuse the Apache software in order to trigger the termination.’ (Meeker, 2020, p. 206)

426 ‘Apache v2.0 is not compatible with GPLv2.0, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions.’ (Kapitsaki et al., 2015, p. 86)

427 http://web.archive.org/web/20200107070106/https://opensource.org/licenses/GPL-2.0 428 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 429 GPL version 3 är för närvarande den senaste versionen av licensen, men det ska noteras att om en licensgivare

tillhandahåller programvara under “GPL-2.0-or-later” så kommer denna kunna användas av annan programvara som tillhandahålls under alla senare versioner av licensen (d.v.s. GPL 3.0, GPL 4.0, GPL 5.0, etc.).

430 http://web.archive.org/web/20200117181040/https://opensource.org/licenses/Apache-2.0 431 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/





http://web.archive.org/web/20040610190542/http://www.apache.org/licenses/

432 För närvarande är version 3 av GNU General Public License den senaste versionen men om det (i framtiden) kommer att utvecklas senare versioner (version 4, version 5, etc.) så kommer programvara som tillhandahålls under GPL version 3 att kunna kombineras med programvara som i framtiden kommer att tillhandahållas under dessa senare versioner av licensen.

433 http://web.archive.org/web/20200117181040/https://opensource.org/licenses/Apache-2.0 434 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 435 http://web.archive.org/web/20200117181040/https://opensource.org/licenses/Apache-2.0 436 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 437 http://web.archive.org/web/20200117181040/https://opensource.org/licenses/Apache-2.0 438 http://web.archive.org/web/20200212221532/https://spdx.org/licenses/ 439 ‘While copyright is traditionally concerned with protecting an author’s right to exclude others from copying,

distributing, or modifying a work, copyleft seeks to strengthen the rights of users by prohibiting the imposition of limits on the right to copy, distribute, or modify a work.’ (DeBrie & Goeschel, 2016, p. 9)

440 ‘Importantly, the copyleft obligation to provide the source code for a program is only triggered once a derivative work of the copyleft work has been created, and the derivative work has been distributed. As such, the most important questions for a company wanting to avoid copyleft obligations are: (1) what constitutes a derivative work, and (2) what constitutes distribution?’ (DeBrie & Goeschel, 2016, p. 9)

441 ‘a proprietary product that includes any modified or unmodified GPL code may need to be distributed under the GPL as well if it is a derivative work, that is if it is, “based on” a GPL licensed program (GPLv2, § 2). For these reasons, the GPL often is referred to as a “strong copyleft” license.”’ (Ilardi, 2011, p. 2)

442 ‘GPLv2 permits licensees to make modifications of the work and to redistribute the work, either in its original form or as modified (GPLv2 refers to such derivative works as “works based on the Program”) so long as the distributed work continues to be covered by this license (section 2 of the license). That aspect of GPLv2 is fairly well understood.’ (Webbink, 2009, p. 87)

443 ‘What the GPLv2 licensor can, and does, say is, if you are going to include my work in a collective work, then the collective work must also be licensed under GPLv2. What that means is all works included in the collective work must either be under GPLv2 or under a license that is compatible with GPLv2.’ (Webbink, 2009, p. 87, 88)

444 ‘The LGPL generally mirrors the GPL, with the principal exception being its treatment of linking. Libraries distributed under LGPL are subject to mostly the same license considerations as in the GPL.’ (Ilardi, 2011, p. 3)

445 ‘A variant of the GPL, known as the lesser GPL (LGPL) allows greater flexibility in regard to the “mixing” requirement: in particular, programs are allowed to link with (or employ) other programs or routines that are not themselves available under an open source license. In other respects, though, the LGPL is similar to the GPL.’ (Lerner & Tirole, 2005, p. 23)

446 ‘The LGPLv2 mirrors the GPLv2 in its application to derivative works, collective works, and compilations. The difference arises in Sections 5 and 6 of LGPLv2 where it permits the use of LGPLv2-licensed code (typically, libraries) with code licensed under a different license, including a proprietary license. The one limitation imposed on such combinations is that the licensor of the entire work (including both the non-LGPLv2 code and LGPLv2 code) must provide the licensee with the source code for the LGPLv2-licensed code and permit the licensee to make modifications in that code AND not prohibit the licensee from reverse engineering the non-LGPLv2 code included in the entire work solely for purpose of debugging the modifications to the LGPLv2 licensed code. This provision does not grant the licensee the right to copy, otherwise modify, or redistribute the non-LGPLv2 code included in the entire work.’ (Webbink, 2009, p. 89)

447 ‘In short, the most popular open source have a built-in termination mechanism that does not allow the development of software that requires any kind of royalty payments for third party patents. In more technical wording, GPL and LGPL are incompatible with patent royalties: if there is a patent for some software invention and that patent is not licensed for free to everyone forever, it is not possible to develop free software for that invention.’ (Välimäki & Oksanen, 2005, p. 400)

448 ‘GPLv2 does not include an express patent license grant. Rather, in Section 6 the GPLv2 makes clear that no other restrictions can be imposed on recipients, which would include any restriction arising from a patent held by the distributing party. In section 7 the GPLv2 makes clear that, if conditions are imposed on the distributing party that would interfere with the rights granted under the license, the distributing party is not to redistribute the software. These provisions have been construed as granting an implied license from a GPLv2 distributing party under any patent claims of that distributing party that read on GPLv2 code they distribute and preventing such a distributing party from entering into any form of license agreement with respect to patent rights that would not extend to all downstream recipients.’ (Webbink, 2009, p. 88)







https://distributed.As

449 ‘This latest GPL seeks to clarify the terms of the GPLv2 but also adds additional terms. Despite some controversy, the new terms remain faithful to Richard Stallman’s and the FSF’s fundamental philosophies. Some changes that generally were hailed as improvements by commercial interests include the addition of private contractor language (§ 2), more flexibility in delivery of source code (§ 6), removal of vague GPLv2 patent license language (GPLv2 § 7), an explicit patent license (§ 11), and language meant to limit or eliminate private patent license agreements (§ 11). Other new terms include a new definition of “Corresponding source code” (§ 1, para. 3 & 4), anti-lockdown provisions for consumer products (§ 6), expanded compatibility provisions (§ 7), the patent “Knowing Reliance” obligation (§ 11 para. 5) and a more detailed termination provision (§ 8).’ (Ilardi, 2011, p. 4)

450 ‘if someone using software under the license initiates patent litigation against another party, claiming that the covered work infringes, the initiator automatically loses all the patent grants otherwise provided for that work by the license, and in the case of the GPL-3.0 loses their right to distribute under the license altogether.’ (Fogel, 2019, p. 160)

451 ‘By way of example, the express license grants under the GPLv2 concern only the exclusive rights of a copyright holder, namely copying, modification and distribution of the code. [Section 7 of the GPLv2] The exclusive rights of a patent holder as enumerated in 35 U.S.C. Sec. 271(a), i.e. the rights to make, use, sell, offer for sale and import, are not mentioned within the license grants of the GPLv2. On the other hand, the GPLv2 includes the so called Liberty or Death clause, which prohibits (also) patent holders from distributing code under the GPLv2 and simultaneously claiming patent royalties from the licensees. [Section 7 of the GPLv2]’ (Haapanen, 2015, p. 20)

452 ‘[“Liberty or Death”] states that if the recipient may not distribute the code under the terms of GPL without other restrictions, the recipient may not distribute the code at all. This provision would come into play if there were conflicts between the licensing terms for GPL and proprietary code, for instance, or between GPL and patent licenses or nondisclosure agreements.’ (Meeker, 2020, p. 49)

453 ‘The licenses, and the GNU GPL in particular, represent an elegant use of contractual terms and property rights to create social conditions in which software is produced on a model of openness rather than exclusion.’ (McGowan, 2001, p. 243)

454 ‘Red Hat, arguably the most successful open source company, employs the oldest open source business model: support services on a subscription basis. Red Hat’s Fedora Linux and Red Hat Enterprise Linux each include significant layers on top of the Linux kernel that add value to Linux for its users. But these additional layers do not depend on a purchase of a subscription from Red Hat; rather, they are free, just as Linux is. Instead of selling licenses to the software itself, Red Hat sells subscription-based support and warranty services in connection with the software packages it distributes. Red Hat also generates revenue by selling physical copies of its Linux operating systems accompanied by documentation and by providing certification programs for Red Hat products. Since GPL precludes downstream royalties, as described above, Red Hat’s business model is especially suited for GPL.’ (Smith & Chang, 2016, p. 39)

455 ‘In addition, Linux vendors frequently ship proprietary applications with their Linux distributions, although the packaging practices and open source license compliance may vary from one to the next. Major device manufacturers, including Sony, Philips, Cisco, and Nokia, have utilized a Linux operating system in both their open (modifiable) and closed (non-modifiable) devices for some time, although their open source license compliance has also frequently required greater effort.’ (Webbink, 2009, p. 83)

456 ‘The Software as a Service (SaaS) delivery model presents a method for companies to provide customers with their proprietary software without distributing it to them. Under a SaaS delivery model, customers access software hosted on a remote server via the Internet and never receive an executable copy of the software on their computers. As such, no distribution of the software occurs, and the copyleft requirement to provide the underlying source code for the software is not triggered. Many companies, including Google, have taken advantage of this “loophole” to great success by keeping GPL-licensed software in the cloud, thereby avoiding release of the source code for their products.’ (DeBrie & Goeschel, 2016, p. 10)

457 ‘The AGPL requires that you offer corresponding source code to users who interact with your modified version of AGPL-licensed software over a network. Therefore, if you build a server based on improvements to AGPL-licensed software, those improvements must be made available to all who use the software via the network.’ (Fontana et al., 2008, p. 8)

458 ‘In the Affero clause, the copyleft effect is not triggered by distribution, but relies on the right to control modifications. Therefore, anytime software is modified, even if the code is not distributed, but it is consumed through a network interface, there must be a convenient facility where the corresponding source code is included.’ (Piana, 2013, p. 48)

459 ‘AGPL v.3 is made compatible with the GPL v.3 through an express compatibility clause.’ (Piana, 2013, p. 48)

460 ‘For instance, SaaS products may incorporate software tools that cause a portion of the software to execute on a user’s browser. This execution of a copy may well constitute distribution. […] Thus, a SaaS product using JavaScript tools, for example, may well cause distribution of the product, thereby triggering the requirements of the applicable open source software license.’ (DeBrie & Goeschel, 2016, p. 11)

461 ‘Open source licenses are the multilateral consensus of the permissions and norms for a community’ (Phipps, 2018) 462 ‘Free-for-all licenses. These licenses only require licensees to give credit to the original authors. Derivative works

can be made proprietary. These licenses are sometimes referred to as “academic licenses.” Examples are the so-called BSD (Berkeley Software Distribution) and MIT licenses as well as the license used for the Apache Web server.’ (Engelfriet, 2010, p. 48)

463 ‘Keep-open licenses. Modifications to software under these licenses have to be made available as open source as well. Larger works incorporating such software can be kept proprietary. The GNU Lesser General Public License (LGPL), used for Linux system libraries, and the Mozilla Public License, used for the Firefox Web browser, are keep-open licenses.’ (Engelfriet, 2010, p. 48)

464 ‘Share-alike licenses. When software under such a license is modified or extended, the result as a whole has to be made available as open source. The term copyleft is sometimes used to characterize this kind of license. The most famous example is the GNU General Public License (GPL), which applies for example to the Linux operating system. Another example is the Open Software License (OSL).’ (Engelfriet, 2010, p. 49)

465 ‘the Apache 2.0 license and the GPLv3, include not only copyright license grants, but also express patent license grants.” (Haapanen, 2017, p. 17)

466 ‘The BSD license grant simply provides that “[r]edistribution and use in source and binary forms, with or without modification, are permitted” provided certain conditions are met, such as including a copyright notice. While the word “use” is a patent term, and nothing in this grant excludes its applicability to patents, that result is not at all certain. By comparison, the very similar MIT license provides “permission to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.” By using patent terms like “deal in,” “use,” and “sell,” the MIT license grant is more likely to be deemed to include express patent rights.’ (Nadan, 2009, p. 2)

467 ‘… let’s return to the MIT License. There is an express license. Does that express license grant patent rights? Indeed, with permission granted “to deal in the Software without restriction,” it does. And there is no need to arrive at that conclusion via anything more than a direct reading of the words that grant the license.’ (Peterson, 2018b)

468 ‘The main concern of companies that convert their intellectual property into “commons” is that such property should not be appropriated by anyone, especially not competitors. Therefore, a company may choose to release software, say, into the commons (i.e. by publishing it as open source) for a number of reasons, but in essence because the company’s prime profit does not come directly through licence revenue of that software. The company hopes that releasing such software as open source will generate goodwill; provide benefits from the improvements contributed by open source developers (for which the company does not pay); lead to de facto standards in which the company has a prior expertise, even if it does not retain control of the IPR in the form of software, etc. However, although the company cannot prevent the benefits of such software accruing to competitors, it certainly does not want a situation to arise where these benefits accrue exclusively to competitors: i.e. nobody should be able to appropriate the IPR released by the owner company. This explains the popularity in the corporate sector of “copyleft” licences such as the GNU GPL, which require modifications to be also released as open source, i.e. incorporated or returned to the common pool rather than appropriated. As an example, Sendmail, which releases open source software using the GPL, would not like competitors to appropriate and make proprietary improvements to any of the software that Sendmail chooses to make open source. However, as the copyright owner, Sendmail remains free to make its own proprietary improvements to its own open source code for use in commercial products.’ (Ghosh, 2003, p. 9)

469 ‘We recommend that a reference implementation itself be licensed under a copyleft licence, potentially one of the versions of LGPL or GPL. Implementation of a standard in an OSS project under a copyleft licence promotes continued compliance with the standard since contributions to the project’s code base (once accepted by the project managers) will become part of the project’s official release. This, in turn, supports clarity in interpretation of the documented technical specification of the standard, which in turn supports interoperability and conformant implementations of the standard. Use of LGPL would ensure that those wishing to implement a standard in a proprietary product would not be discriminated against, in that they would not be required, when linking the library to their proprietary code, to release the source code of that code, or to license it in its entirety under the same licence. Their obligation would be limited to ensuring that a recipient of the software was able to re-link it to a modified version of the library if they wished to do so (provided that it had the same interface). Technically, this is generally quite straightforward (in many operating system implementations it is simply a case of making sure that the amended compiled library file – for MS Windows, this could be a ‘.DLL’ file – is placed in the same directory as the original).’ (Lundell et al., 2019)

470 ‘use of GPL would promote an entire standard conformant ecosystem when solutions are distributed, since when implementations of standards are provided under GPL it implies that associated applications would need to be provided under GPL when solutions are distributed. For public sector organisations, such policies may be desirable as it would tend to promote a commonly expressed public policy aim that works developed through public spending should remain a public good and accessible to all. In contrast, for companies which distribute proprietary software as part of their business offerings, this would challenge existing business models since it would require them to release their own code under the GPL (and provide the source code).’ (Lundell et al., 2019)

471 ‘there is a consensus that GPLv3 and the Apache License 2.0 are compatible.’ (Sinclair, 2010, p. 112) 472 “For instance, the Apache v2.0 license is incompatible to GPLv2.0 due to the patent termination and

indemnification provisions of Apache v2.0 that pose a restriction to the license not present in GPLv2.0. Specifically, Apache v2.0 states that in case of patent infringement allegations in a lawsuit, any patents that use Apache v2.0 are terminated.” (Kapitsaki et al., 2015, p. 74)

473 ‘The variety of open source licenses makes it difficult for organizations to cope with incompatibilities that might exist due to the use of software libraries based on different licenses. License A is considered one-way ‘compatible’ with license B, if software that contains components from both licenses can be licensed under license B. The term ‘one-way’ is used to highlight that license A is compatible with license B, but the reverse case (i.e., license B is compatible with license A) is not assured.’ (Kapitsaki et al., 2015, p. 73)

474 ‘A patent that protects technology essential to a standard is called a standard-essential patent. It is impossible to manufacture standard-compliant products such as smartphones or tablets without using technologies covered by one or more SEPs. SEPs are different from patents that are not essential to a standard (non-SEPs), such as design patents, for example, which protect the design features of an invention. This is because, generally, companies can invent alternative solutions that do not infringe a non-SEP (whereas they cannot design around a SEP).’ (EC, 2014)

475 (Blind & Böhm, 2019; Lundell et al., 2015, 2019). 476 ‘There are three principal rights under copyright law that are held by the copyright holder in software: the right to

copy the software, the right to modify the software, and the right to distribute the software. Under traditional proprietary models, the copyright holder elects not to share these rights with the party receiving a license in the software. Thus, under most proprietary software licensing models the end user has no right to copy the software (other than the statutory right to make a back-up copy of the software under 17 U.S. Code § 117).’ (Webbink, 2009, p. 84)

477 ‘proprietary vendors commonly include restrictions on the decompiling or reverse engineering of the software (such restrictions being of limited scope with respect to such actions taken purely for the purpose of interoperability), thus barring the modification of the software. Finally, proprietary licenses will generally limit the redistribution of the software to the absolute transfer of the single copy covered by the license. As a consequence, packaging issues in the purely proprietary software context tend to be matters of negotiated contracts, not merely end user licenses.’ (Webbink, 2009, p. 84)

478 ‘FOSS software developers, the attorneys who help them license their creations, and absolutely everyone else.’ (Nemiah, 2014, p. 359)

479 ‘Drafting an effective open source policy does not necessarily require significant new resources as long as the drafting process and implementation are efficient and involve the right people. Avoid reinventing the wheel. Open source software is licensed under standard, frequently used licenses. An open source policy should take advantage of this, and discourage time and effort from being spent to answer the same question more than once.’ (Cohn & Spiegel, 2011, p. 6)

480 ‘There are many good reasons to have an open source policy that is responsive to open source community standards rather than merely focusing on what the license allows. Often, a proposed use of open source is technically (legally) permitted under the applicable license, but is frowned upon in an open source community. Having a good understanding of the community’s needs can be invaluable.’ (Cohn & Spiegel, 2011, p. 7)

481 ‘CockroachDB was conceived of as open source software. In the years since it first appeared on GitHub, we’ve tread a relatively typical path in balancing open source with creating a viable business. We’ve kept our core code under the Apache License version 2 (APL), launched a managed service, and gated some features for established companies under an enterprise license.’ (Cockroach, 2019)

482 ‘The MIT License, probably the simplest of those licenses, imposes almost no restrictions on licensees and no meaningful restriction at all on licensees distributing derivative works. When the original work or “substantial portions” of it are distributed, the licensee is required to include a copyright notice and the notice giving permission to potential licensees of their rights to use the work. The licensee is not even required to include the disclaimer of warranties that was part of the original license. (Such licensees may, however, have good reason to include that disclaimer–in particular, to protect themselves from potential liability.)’ (Laurent, 2004, p. 34)

483 ‘The MIT license recites both “using” and “selling” the software, and therefore mentions at least two of the five enumerated exclusive rights of a patent holder.’ (Haapanen, 2015, p. 20)

484 ‘Perens also used that occasion to promote an alternative system called “coherent open source.” “Let’s scrap the Tower of Babel of 100+ Open Source licenses,” Perens had argued earlier in a mailing list post in September. Coherent Open Source would ask developers to limit themselves to just three licenses – the Affero GPL 3, LGPL3, or Apache 2 – all of which are compatible with each other, flexible, and approved and recognized as freedom-respecting licenses by both the Open Source Initiative and the Free Software Foundation.’ (Cassel, 2020)

485 ‘Interestingly, in the 1970s, there was substantial doubt about whether U.S. federal patent, copyright or any other federal protection would extend to computer software; accordingly, most licensing of computer software was accomplished under state trade secret and state confidentiality law protections.’ (Haapanen, 2015, p. 20)

486 ‘In the 1980s, with the passage of the Computer Software Copyright Act Amendments of 1980 (following the CONTU Commission studies in the 1970s), it was made clear that computer software was automatically protected upon creation by the Federal Copyright Act, but the patentability of software remained unclear.’ (Haapanen, 2015, p. 20)

487 ‘It was only with a number of decisions by the Federal Circuit in the 1990s that computer software patent protection was put beyond doubt. Some twenty years later, following the U.S. Supreme Court’s decision in Alice v. CLS, 134 U.S. 2347 (2014), there remains no doubt that copyright protection extends to computer software, but the extent to which patent protection is available in the face of subject matter objections under 35 U.S.C. Section 101 has reopened the debate. To date, most post-Alice Section 101 subject matter defence motions have succeeded in invalidating over 80% of the software patents challenged, on Rule 12(b)(6) motions to dismiss.. It may be too early to tell if this is just the result of early challenges being against “bad” software patents improperly allowed by the PTO under historical norms, or whether a larger trend toward invalidating most software patents is occurring.’ (Haapanen, 2015, p. 20)

488 ‘If you want to copy, modify, create a derivative of, or distribute OSS, you must either own the copyright in the OSS or have a license from the copyright owner. Further, if a company distributes software that includes or is derived from OSS and doesn’t comply with the terms of the license under which the OSS was made available, the company is likely infringing the copyright in the OSS or breaching the terms of the license agreement–or both.’ (Gaff & Ploussios, 2012, p. 9)

489 ‘In 2003, the FSF formalized its efforts into the GPL Compliance Lab, increased the volume of enforcement, and built community coalitions to encourage copyright holders to together settle amicably with violators. Beginning in 2004, Harald Welte took a more organized public enforcement approach and launched gpl-violations.org, a website and mailing list for collecting reports of GPL violations. On the basis of these reports, Welte successfully pursued many enforcement actions in Europe, including formal legal action. Harald earns the permanent fame as the first copyright holder to bring legal action in a court regarding GPL compliance.’ (Copyleft, 2019, p. 71)

490 (EC, 2004) 491 (NPS, 2016) 492 ’Öppen programvara har också en given roll i arbetet med öppna standarder. Genom att man i

standardiseringsarbetet utvecklar referenser som öppen programvara ökar man kvaliteten i standarden och sänker tröskeln för dem som vill använda standarden i produkter. Detta bidrar till ett större genomslag för en standard varvid nyttoeffekterna kan uppstå tidigare.’ (Verva, 2008, p. 9)

493 (Lundell et al., 2016)

https://gpl-violations.org

494 ’För att möjliggöra interoperabilitet och långsiktigt digitalt bevarande, använd endast öppna standarder och öppna filformat som har implementerats i programvara och som därmed är möjliga att tillhandahålla samt distribuera under olika licenser, inklusive alla licenser för öppen programvara.’ (Lundell et al., 2016, p. 8)

495 ’Referera endast till standarder som inkluderas i Kammarkollegiets vägledning för öppna standarder vid precisering av krav på nya IT-system och redovisa specifikt, för varje referens som myndigheten gör till en standard som saknas i denna vägledning, alla risker för att den egna myndigheten kommer att diskriminera enskilda individer och organisationer med precisering av hur dessa referenser till standarder begränsar konkurrensen.’ (Lundell et al., 2016, p. 8)

496 ’För att hantera data och handlingar som inkommer till en myndighet i slutna filformat, införskaffa innan upphandling alla nödvändiga rättigheter, inklusive alla nödvändiga patentlicenser, för dessa slutna filformat så att de kan implementeras i programvara som kan användas och distribueras under olika licenser, inklusive alla licenser för öppen programvara.’ (Lundell et al., 2016, p. 9)

497 (Lundell et al., 2019) 498 (Lundell et al., 2019) 499 (Lundell et al., 2015; Lundell et al., 2019) 500 ‘As with participation in and sponsorship of a community project, companies that participate in a standards

organization or use standards-based technology might benefit from an open source policy. While standards organizations and standards-based technology are not directly related to open source, some argue that the benefits of open source cannot be fully realized if software is dependent on proprietary standards. As a result, your company might view open standards as an important consideration in its open source strategy. If so, the company should evaluate whether a particular standards organization or standards-based technology promotes open standards and whether that is a critical element of its strategy that should be documented in an open source policy. Companies that are heavily involved in standards activities might also have a separate policy on standards, and should ensure that such a policy is consistent with the company’s open source policy (if it has one).’ (Cohn & Spiegel, 2011, p. 5)

501 I flertalet jurisdiktioner gäller ett patent i 20 år. Detta innebär att i händelse av att en organisation saknar tillgång till den specifika version av den specifika programvaran som användes för att skapade en handling så skulle det (i händelse av att myndigheten har tillgång till den kompletta tekniska specifikationen som användes för att utveckla programvaran som initialt användes) i framtiden vara möjligt att utveckla en programvara som kan tolka handlingen i framtiden (när samtliga patent som tidigare belastat formatet eller standarden har gått ut).

502 ‘Only Royalty Free standards (or more precisely, standards whose implementation does not require per-copy royalties, or “running royalties”, provided that the license does not impose other incompatible conditions) are compatible with Free Software and thus can truly be considered “Open Standards”. Running royalty-bearing RAND [Reasonable And Non Discriminatory] and FRAND [Fair Reasonable And Non Discriminatory] conditions (at least as they are interpreted by most of patent holders), frequently associated with the “open standard” term, are impossible to be made compatible with Free Software.’ (Piana, 2013, p. 45)

503 ‘For any patents controlled by the vendor and affecting the project, there must be an unambiguous, non-restrictive patent grant not just to you but to everyone who receives the code under its open source license.’ (Fogel, 2019, p. 77)

504 (Blind & Böhm, 2019; Lundell et al., 2015, 2019). 505 ‘There is now no credible, current scholarship informed by the data, finding any issue with FRAND licensing in the

standards development context.’ (Kappos, 2017, p. 262) 506 ‘FRAND licenses create barriers for Open Source projects to implement the technical specification’ (EC, 2013a) 507 ‘For example, FFMPEG is a very popular open source audiovisual codec, which encodes and decodes data files

stored in the various standard formats. FFMPEG is licensed under open source licenses, but the patents covering certain MPEG standards are owned by others. Anyone seeking to use the FFMPEG software must consider not only the need to comply with the open source licenses that govern its use but also the need to get a separate patent license–or of course, take a risk of patent infringement claims. This is an example of how open source software licensing and non-free standards can clash.’ (Meeker, 2020, p. 309)

508 ‘a district court awarded $1.52 billion in patent damages, the largest patent award in history, over infringement of the proprietary MP3 music format.’ (Merges & Kuhn, 2009, p. 49)

509 (Held, 2004) 510 (EC, 2004) 511 (SOU, 2009) 512 (NPS, 2016)

513 (EC, 2008) 514 http://web.archive.org/web/20101025142945/http://ec.europa.eu/idabc/en/document/7728.html 515 http://web.archive.org/web/20101025200319/http://ec.europa.eu:80/idabc/en/document/7732.html 516 Vissa remissvar förefaller vara baserade på, medvetna eller omedvetna, missuppfattningar avseende möjligheten att

kunna använda patentbelastade standarder och specifikt möjligheten att anskaffa licenser som möjliggör implementation i öppen programvara. Resultat från senare publicerad forskning visar att det för många standarder kan vara omöjligt att anskaffa alla nödvändiga rättigheter som möjliggör implementation i öppen programvara, se exempelvis: Blind & Böhm (2019); Lundell et al. (2015, 2019).

517 Redovisning av en analys av innehållet i dessa 54 remissvar går utöver fokus för detta sakkunnighetsutlåtande och detta får göras i ett annat sammanhang, men flera av missförstånden har senare klargjorts i flera studier som publicerats senare, se exempelvis: Blind & Böhm (2019); Lundell et al. (2015, 2019).

518 (EC, 2010) 519 (Lundell et al., 2015, 2019) 520 (EC, 2016) 521 http://web.archive.org/web/20161024011839/http://ec.europa.eu/isa/consultations/results/result_impact-assessment-

for-the-revision-of-the-eis-eifl_en.htm 522 (EC, 2017a) 523 (Lundell et al., 2015, 2019) 524 (Lundell et al., 2015) 525 ‘Whilst standards that are set through formal standard setting organisations go through a formal development

process, they may still contain barriers to implementation by all interested parties’ (EU, 2012) 526 (Lundell et al., 2015, 2019) 527 Exempelvis i händelse av att villkoren för användning av tjänsten förändras som en konsekvens av förändrad

lagstiftning i något av de länder där myndighetens data behandlas. 528 Exempelvis i en situation då alla avtalsvillkor för användning av tjänsten är okända för en myndighet, eller i en

situation då myndigheten saknar möjlighet att påverka och förutse under vilken lagstiftning myndighetens data kan komma att behandlas.

529 Dessa frågor är inte unika för öppen programvara och forskning visar att dessa frågor kan bli än mer komplicerade om sluten programvara tillhandahålls som tjänst, exempelvis i situationer då en myndighet saknar uppgift om i vilka jurisdiktioner data behandlas och vilken lagstiftning som påverkar den egna myndigheten.

530 ‘In most cases, license restrictions are only applicable or relevant if a company will be providing copies of the OSS to third parties. With the notable exception of the Affero variant of the GNU General Public License (GPL), generally the restrictions aren’t applicable or relevant when the company is only using the OSS internally, which includes hosting the OSS in a software as a service arrangement for customers or using it to operate a customer-facing website.’ (Gaff & Ploussios, 2012, p. 10)

531 ‘As server based services such as cloud computing or big data may not involve the distribution of code but the utilisation of services from servers running FOSS code, many companies have benefited from FOSS software to build their server side services and now sell those services to third parties without passing on the code itself. In this way they may sell highly profitable services based on FOSS software without making a contribution back or serving Stallman’s greater good.’ (Brock, 2013, p. 130)

532 Beroende på scenario kan en myndighet engagera personal från andra organisationer (exempelvis genom upphandling av externa konsulter) för att hantera lokal drift.

533 ’Är den tekniska specifikationen [som har implementerats i den programvara som tillhandahålls som tjänst till myndigheten] tillgänglig under villkor som möjliggör implementation i programvara så att programvaran kan användas av, samt distribueras till, alla marknadens aktörer utan restriktioner?’ (Lundell et al., 2016, p. 184)

534 ‘Have complete technical specification(s) of the IT standard, including complete technical specification(s) of all its normative references (whether referenced directly or indirectly), been implemented in multiple software projects (including at least one OSS project) that are made available on-premise?’ (Lundell et al., 2019)

535 (Lundell et al., 2019) 536 ’Är den tekniska specifikationen [som har implementerats i den programvara som tillhandahålls som tjänst till

myndigheten] implementerad i programvara av flera oberoende projekt, inklusive projekt som tillhandahålls som öppen programvara under en copyleft-licens?’ (Lundell et al., 2016, p. 185)

http://web.archive.org/web/20161024011839/http://ec.europa.eu/isa/consultations/results/result_impact-assessment-for-the-revision-of-the-eis-eifl_en.htm

http://web.archive.org/web/20161024011839/http://ec.europa.eu/isa/consultations/results/result_impact-assessment-for-the-revision-of-the-eis-eifl_en.htm

http://web.archive.org/web/20101025200319/http://ec.europa.eu:80/idabc/en/document/7732.html

http://web.archive.org/web/20101025142945/http://ec.europa.eu/idabc/en/document/7728.html

537 I sammanhanget ska det betonas att dessa risker blir betydligt större då en myndighet använder en sluten programvara som en extern organisation tillhandahåller till myndigheten som en tjänst. Om däremot en öppen programvara som finns publikt tillgänglig tillhandahålls till myndigheten som tjänst finns möjlighet för myndigheten att själv, eller med stöd av extern expertis, ta del av och genomföra en granskning av den öppna programvarans funktion.

538 Om en leverantör tillhandahåller en programvara som en tjänst ställs det som regel sällan krav på att den kompletta källkoden till den programvara som tillhandahålls som tjänst kontinuerligt kan granskas. För en myndighet kan det i praktiken vara mycket svårt, för att inte säga omöjligt, att granska och avgöra huruvida samtliga versioner av tillhandahållen källkod för den programvara som använts faktiskt är identisk med källkoden för den programvara som (vid varje tidpunkt) har tillhandahållits som tjänst.

539 I händelse av att tjänsteleverantören, i enligt med gällande avtalsvillkor för tjänsten, har rätt att modifiera (och göra förbättringar) av programvaran behöver myndigheten granska samtliga versioner av exakt de versioner av programvaran som faktiskt har använts av myndigheten för att kunna avgöra exakt hur data har behandlats och representerats vid olika tidpunkter då myndigheten använt tjänsten.

540 Resultat från pågående forskning visar att många myndigheter använder sluten programvara som tjänst utan att ha undersökt möjligheterna att med hjälp av tjänsten kunna säkerställa långsiktig förvaltning och återanvändning av uppgifter i myndighetens egna handlingar även efter ett eventuellt beslut om att avsluta användning av tjänsten.

541 Det ska poängteras att denna rekommendation till myndigheter i högsta grad är relevant för anskaffning av all typ av programvara (både öppen programvara och sluten programvara). Tidigare forskning visar att det långt ifrån är ovanligt att myndigheter saknar tillgång till alla avtalsvillkor som den egna myndigheten är bunden av för att använda sluten programvara som tillhandahålls som tjänst.

542 Resultat från forskning visar att många myndigheter underlåtit att genomföra någon gedigen analys och att flera myndigheter även saknar tillgång till alla avtalsvillkor den egna myndigheten är bunden av.

543 Det ska betonas att uppgifter som upprättas i olika handlingar, som en konsekvens av att en myndighet använder en viss programvara som tillhandahålls som tjänst, i flertalet scenarios är av betydligt större värde för myndigheten än tillgången till just denna programvara. I händelse av att uppgifter upprättas i handlingar, som en konsekvens av att en myndighet använder en specifik programvara som tjänst där avtalsvillkoren tillåter att programvarans funktion förändras över tid, kan detta innebära att myndigheten saknar tillgång till programvara som kan tolka alla uppgifter i de handlingar som tidigare upprättats inom myndigheten med hjälp av tjänsten och i händelse av att myndigheten (i ett framtida scenario) väljer att avsluta användning av tjänsten kan detta innebära att myndigheten saknar möjlighet att förvalta sina egna handlingar.

544 Att ha tillgång till den kompletta källkoden (och en exekverbar version av denna) är en förutsättning för att en lokalt installerad öppen programvara ska kunna tas i drift med kort (eller mycket kort) varsel beroende på scenario. Att ha tillgång till en redundant komplett driftsmiljö driver kostnader och beroende på scenario behöver varje myndighet ta ställning till vilka specifika behov som finns. Men en grundförutsättning för att kunna använda programvara med lokal drift är att myndigheten har tillgång till all nödvändig programvara för att snabbt kunna växla upp en begränsad lokal drift till en komplett driftsmiljö (där ytterligare hårdvara kan komma att behöva anskaffas).

545 ‘Science, after all, is ultimately an Open Source enterprise. The scientific method rests on a process of discovery, and a process of justification. For scientific results to be justified, they must be replicable. Replication is not possible unless the source is shared: the hypothesis, the test conditions, and the results. The process of discovery can follow many paths, and at times scientific discoveries do occur in isolation. But ultimately the process of discovery must be served by sharing information: enabling other scientists to go forward where one cannot; pollinating the ideas of others so that something new may grow that otherwise would not have been born.’ (DiBona et al., 1999, p. 8)

546 ‘Besides speed, there are several other advantages of conducting science in the open. The process is transparent, meaning the public can be assured that funding for science, arising from their taxes, is being used responsibly and there is no suggestion of political interference in the scientific process’ (Woelfle et al., 2011, p. 748)

547 ‘The basic tenet of the GNU project and the Free Software Foundation (the umbrella organization for the GNU project) is that source code is fundamental to the furthering of computer science and freely available source code is truly necessary for innovation to continue.’ (DiBona et al., 1999, p. 8)

548 (Donnelly, 2010)

549 ‘On 10 April [2019] astrophysicists announced that they had captured the first ever image of a black hole. This was exhilarating news, but none of the giddy headlines mentioned that the image would have been impossible without open-source software. The image was created using Matplotlib, a Python library for graphing data, as well as other components of the open-source Python ecosystem.’ (Nowogrodzki, 2019, p. 133)

550 (CERN, 2020) 551 http://web.archive.org/web/20190902234309/https://en.wikipedia.org/wiki/White_Rabbit_Project 552 (https://ohwr.org/projects/white-rabbit) 553 ‘All Pytroll code uses copyleft licences (GPLv3 and LGPLv3), ensuring that all the code developed as part of the

Pytroll project remains open. The code is available on GitHub, PyPI and conda-forge.’ (SMHI, 2020) 554 http://web.archive.org/web/20190417165927/http://hypeweb.smhi.se/model-water/ 555 Under senaste åren har frågor om öppen tillgång till resultat från forskning varit föremål för omfattande

diskussioner bland politiska beslutsfattare, finansiärer, forskare och andra intressenter. Frågor om öppen tillgång till data och resultat från den forskning som bedrivs är mycket komplex och behöver ses i ett större sammanhang, där frågor om incitament och styrmedel för forskningen i högsta grad påverkar hur enskilda forskare och andra intressenter kommer att agera framgent.

556 Många forskare drivs av en stark ambition att genomföra och publicera betydelsefulla resultat i vetenskapliga tidskrifter av högt internationellt anseende inom sina respektive områden. Detta innebär att resultat från genomförd forskning redovisas i manuskript som forskare utsätter för en vetenskaplig granskning (s.k. ’peer-review’) innan resultaten kan accepteras för publicering. Inom vissa vetenskapsområden tillhandahålls även data som ligger till grund för en publikation som öppet innehåll och det förekommer också att programvara som utvecklas inom forskningen tillhandahålls som öppen programvara.

557 Enligt författaren till denna rapport har politiska beslutsfattare (som i stor utsträckning påverkar förutsättningar för offentlig finansierad forskning) och finansiärer av forskning i Sverige, tyvärr, haft allt för stort fokus på öppet innehåll (vilket i sig inte är oviktigt) i förhållande till de, i sammanhanget, betydligt viktigare frågorna om öppna standarder och öppen programvara.

558 (CERN, 2020) 559 ‘For software developed solely by CERN, the default licence, a “Copyleft” licence: GPLv3 is to be used whenever

possible. An alternate licence, a “Permissive for Inclusion” licence: LGPLv3 may be used for special cases such as program libraries when the prime objective of the Open Source distribution is the rapid wide-spread adoption of these programs.’ (CERN, 2012)

560 ‘A copyleft approach is seen inline with the spirit of open scientific collaboration, making sure that new modifications made to the software are available with the same freedom to the user. The GPLv3 (GNU General Public License) was recommended as the default licence for CERN developed software and should be proposed for software developed in collaboration with other partners.’ (Nilsen & Anelli, 2016, p. 116)

561 ‘When co-operative research aims at building a common infrastructure, or an open pre-competitive platform or standards, it must not only ensure the openness of the results, but also take some guarantees for this openness to be sustained. A simple publication or “public domain” type of status will not meet the objective of sustainable openness unless it is supported by an adequate license guarantee against re-proprietarisation of slightly extended or improved versions of the results.’ (EC, 2003, p. 9)

562 ‘An exception licence, a “Permissive for Inclusion and Modification” licence: Apache v2 may be used when constraints are imposed on the development of the software by existing agreements, such as an external funding body, or when no control over the possible commercial exploitation of the program by third parties is necessary. If the software makes use of third-party software, the case will be analyzed by the CERN Knowledge Transfer Legal Officer, who may propose a different licence in case of licence incompatibilities.’ (CERN, 2012)

563 ‘Open Hardware allows anyone to study, modify, use and produce a design. For CERN, Open Hardware began in 2009, when a group of electronics designers in CERN’s Beams Department created the Open Hardware Repository. The purpose was to have an Open Source philosophy to hardware development. Later, the CERN Open Hardware Licence (CERN OHL) was created to provide a proper legal framework to distribute these designs. The licence governs the use, copying, modification and distribution of hardware design documentation and the manufacturing and distribution of products based thereon. The licence essentially gives anyone these rights with the condition that new developments are published under the same terms.’ (Nilsen & Anelli, 2016, p. 116)

564 (Svorc & Katz, 2020)

http://web.archive.org/web/20190417165927/http://hypeweb.smhi.se/model-water/

https://ohwr.org/projects/white-rabbit

http://web.archive.org/web/20190902234309/https://en.wikipedia.org/wiki/White_Rabbit_Project

https://possible.An

565 ‘The most surprising thing that the open source movement has shown, in real life, is that this simple model can operate on very different scales, from the small, three-person model I described for simple projects, up to the many thousands of people involved in writing the Linux kernel and the GNU/Linux operating system–an immensely difficult production task.’ (Benkler, 2006, p. 67)

566 ‘For this study, the work of the wider Open Source community is primarily viewed as a social process producing information as a public good. It is a knowledge-intensive process that has inputs in the form of labour (the work of the contributors) and capital (the funding required by the communities). The output is information goods, most prominently the software components that are freely distributed to the public. The nature of free software licenses makes them “non-excludable” and “non-rivalrous” and therefore “public goods”.’ (Boehm, 2019, p. 5)

567 ‘Open source software is an excellent training system, provided essentially at no direct cost to society: i.e. neither public subsidies nor future employers need pay directly for the training provided to (often novice) programmers through their exposure to source code and the open source developer network. This is implicitly recognised by employers, who may favour prospective employees who have worked on open source projects; it is explicitly recognised by developers themselves, 79% of whom start participation in the open source community “to learn and develop new skills”.’ (Ghosh, 2003, p. 61)

568 (Lundell et al., 2010)

Documents

Analys av DIGG:s policy för utveckling av programvara...Utfärdare: Björn Lundell Analys av DIGG:s policy för utveckling av programvara Sammanfattning Denna sammanfattning presenterar