├── README.md ├── LICENSE └── riktlinje.md /README.md: -------------------------------------------------------------------------------- 1 | # Riktlinje för öppen källkod 2 | ## Information och bakgrund 3 | Försäkringskassan antog 2018-12-17 ett inom myndigheten formellt styrdokument (Dnr: 15918-2018) gällande öppen källkod. Riktlinjen som gäller på myndighetsnivå hanterar både användandet och delande av öppen källkod samt när personal från myndigheten deltar i öppna samarbeten. 4 | 5 | Riktlinjen finns som diariefört dokument inom myndigheten, men för att öka samverkan finns dokumentets textinnehåll publicerat här för att enklare kunna spridas och förbättras. 6 | 7 | ## Användande och spridning 8 | Beslutad licensform för riktlinjens innehåll är MIT och får därmed laddas ner, modifieras och vidaredistribueras. 9 | Även om MIT licens använts tas förbättringsförslag tacksamt emot så vi gemensamt kan förbättra dokumentet. 10 | 11 | Försäkringkassan använder den publicerade versionen som "upstream" projekt vilket innebär att någon ytterligare information inte kommer finnas i den inom myndigheten publicerade versionen, däremot kan innehåll från den publicerde versionen komma att exkluderas internt. 12 | 13 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Försäkringskassan 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /riktlinje.md: -------------------------------------------------------------------------------- 1 | # Riktlinjer för öppen källkod 2 | De här riktlinjerna vänder sig till medarbetare inom it-avdelningen. 3 | 4 | ## Det här handlar riktlinjerna om 5 | Riktlinjer för öppen källkod beskriver myndighetens förhållningssätt till öppen källkod och närliggande principer på en övergripande nivå och är styrande för it-avdelningens domänstrategier, arkitekturriktlinjer och berörda processer. 6 | 7 | ### Det här är styrande i riktlinjerna 8 | De styrande delarna i riktlinjerna finns beskrivet i nedanstående angivna kapitel. 9 | * Kapitel 3 visar myndighetens förhållningssätt till de i kapitel 2 beskrivna direktiv från Europeiska kommissionen och Sveriges regering. 10 | * Avsnitt 3.1, 3.2 och 3.3 beskriver de styrande delarna kring produktval, supporttjänster och val av öppna projekt. 11 | * Kapitel 5 och 6 beskriver styrande delar gällande hur myndighetens personal kan delta i öppna samarbeten och hur delning av källkod kan ske. 12 |   13 | # 1 - Bakgrundsinformation 14 | Öppen källkod kommer från den engelska termen Open Source som har rötterna i 50-talet där program- och maskinvara delades för att gemensamt utveckla tekniken och 1997 blev Open Source ett formellt begrepp. 15 | 16 | Öppen källkod handlar till stor del om att källkod i form av funktionella program, fristående funktioner och script ska göras tillgängliga för andra att fritt använda, förbättra och sprida, för att på så sätt driva utvecklingen framåt. Förutom detta handlar konceptet Öppen källkod om öppenhet i både arbetssätt och styrning vilket ofta realiseras med öppna gemenskapsprojekt (eng. "community") där vem som helst får ta del av utvecklingen, planer och själv komma med förslag och förbättringar. 17 | 18 |   19 | # 2 - Styrande förutsättningar 20 | **Europeiska kommissionen** 21 | 22 | I Europeiska kommissionens publicerade dokument "Europeiska interoperabililtetsramen - Genomförandestrategi" finns styrande rekommendationer för hur medlemsstaterna ska bygga it-tjänster. Rekommendationerna återkommer ofta till att både data och kod om möjligt ska göras tillgänglig för medborgarna och att medlemsstaterna helst ska återge förbättringar till de öppna projekten. 23 | 24 | > **Rekommendation 2:** 25 | > 26 | > Säkerställa lika villkor för programvara med öppen källkod och på ett aktivt och rättvist sätt överväga att använda programvara med öppen källkod, med beaktande av lösningens sammanlagda ägandekostnader. 27 | > Användningen av teknik och produkter för programvara med öppen källkod kan bidra till minskade utvecklingskostnader, undvika inlåsning och möjliggöra snabb anpassning till bestämda verksamhetsbehov, eftersom utvecklarna hela tiden anpassar dem. Offentliga förvaltningar bör inte endast använda programvara med öppen källkod, utan när så är möjligt bidra till de berörda utvecklarna. Öppen källkod är en nyckelfaktor för den grundläggande EIF-principen om vidareutnyttjande. 28 | 29 | Inom EU finns även en strategi för öppen källkod för kommissionens interna utvecklingsprojekt i syfte att stärka och styra användningen av programvara med öppen källkod. Se Open Source Software Strategy. 30 | 31 | **Sveriges regering** 32 | 33 | I regeringsdokumentet "Så enkelt som möjligt för så många som möjligt - från strategi till handling för e-förvaltning" finns nedanstående rekommendation. 34 | 35 | _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._ 36 | 37 | **Statens inköpscentral** 38 | 39 | Statens inköpscentral vid Kammarkollegiet har villkor i flera av sina ramavtal för öppen källkod som kan användas som utgångspunkt för det juridiska förhållandet mellan myndigheten och en leverantör av källkod. 40 | 41 | Statens inköpscentral tillhandahåller även en lista över öppna standarder som följer rekommendationerna från Europeiska kommissionen och regeringen. 42 | 43 |   44 | # 3 - Användande av lösningar med öppen källkod 45 | Detta kapitel beskriver de styrande principerna för användande av lösningar baserade på öppen källkod inom myndigheten. Det generella förhållningssättet är att följa direktiven från Europeiska kommissionen och regeringen och därför alltid sträva efter användande av produkter med öppna och fria gränssnitt, baserade på öppna standarder. Detta i kombination med målet om öppenhet mot medborgare samt viljan om samverkan gör att öppna lösningar primärt ska väljas. 46 | ## 3.1 - Produktvalsprocessen 47 | Vid anskaffning av nya produkter ska processen för produktval följas. Denna process ska följa ovanstående rekommendation om att programvara med öppen källkod alltid ska övervägas förutsatt att ett öppet alternativ som uppfyller ställda krav finns tillgängligt samt att totalkostnaden inkl. implementering och ev. omställning är rimlig. 48 | 49 | ## 3.2 - Support och Enterprise-paketeringar 50 | Ifall support och garanti om felrättningar på en programvara med öppen källkod krävs finns normalt nedanstående varianter. 51 | Om behov av support för en viss produkt föreligger ska normalt sett alltid en s.k. Enterprise-paketering väljas. Detta eftersom en sådan är väl testad, innehåller dokumentation och anpassade utbildningar samt att det i modellen ingår rättsligt skydd mot eventuellt patentintrång i den aktuella programvaran. Vid köp av Enterprise-paketering ska det i första hand väljas leverantörer som arbetar enligt principen "community first" för att säkerställa att inga funktioner byggs exklusivt för enterprise-paketeringen vilket kan bidra till inlåsningseffekter. 52 | 53 | **Enterprise-paketering** 54 | 55 | En leverantör som arbetar i ett eller flera community-projekt och gör en egen paketering av projektets källkod för att leverera den som en väl testad leverans. Programvaran är ofta certifierad ihop med andra tillverkares produkter och betalning sker vanligtvis genom köp av support-prenumerationer. 56 | 57 | **Community-release med support** 58 | 59 | En leverantör med god kunskap kring en programvara med öppen källkod som erbjuder supporttjänster för den aktuella programvaran. Leverantörens personal deltar ofta i community:n och kan på så sätt erbjuda både kunskap och möjlighet till felrättningar. 60 | 61 | Vid köp av support på en community-baserad produkt måste det i upphandlingsfasen säkerställas att den som ger support dels har rätt kunskap men också möjlighet att utföra felrättningar i programvaran och få dessa accepterade av community:n. Ett sätt att göra det är ställa krav på leverantörens deltagande i community:n, kräva redogörelse och insyn i historik av förbättringsförslag och kodbidrag i community:n. 62 | ## 3.3 - Välja rätt projekt 63 | Det finns ett stort antal öppen källkodsprojekt tillgängliga på internet, vissa är väldigt aktiva med många medlemmar medan några är vilande eller består endast av ett fåtal personer. 64 | 65 | Vid val av öppen källkodsprojekt ska nedanstående checklista följas för att säkerställa ett bra och lämpligt val. 66 | * Projektet ska vara publikt tillgängligt på internet där källkod, felrapporter och förbättringsförslag kan läsas av vem som helst. 67 | * Projektet ska vara öppet för bidrag av källkod eller andra förbättringsförslag från vem som helst. 68 | * Projektets källkod ska av vem som helst kunna laddas ner, användas, spridas och förändras utan motprestation. 69 | * Projektet ska vara aktivt, dvs. källkod och arbetsuppgifter uppdateras löpande. 70 | * Projektets deltagare och de som aktivt bidrar med källkod bör inte enbart bestå av personal från ett och samma företag. Om så är fallet, verifiera att det aktuella företaget har en policy eller skrivelse som beskriver hur de arbetar med öppen källkod och säkerställer projektets framtid. 71 | * Projektets bidragsgivare av källkod bör vara flera personer, undvik enmansprojekt. 72 | * Projektet ska ha en kommitté eller motsvarande som granskar och godkänner kodbidrag för att säkerställa kvaliteten på källkoden innan den accepteras av projektet. 73 | * Projektets källkod ska distribueras under en licens som är godkänd av Open Source Initiative. https://opensource.org/licenses 74 | 75 | # 4 - Deltagande i öppna samarbeten 76 | Myndigheten och dess personal får och bör aktivt delta i community:n genom att t.ex. rapportera problem, ge återkoppling, leverera förbättringsförslag och kodrättningar. 77 | 78 | Ifall ett öppen källkodsprojekt bedöms vara viktigt för den egna myndigheten men saknar avgörande funktionalitet kan anställd eller inhyrd personal tillåtas att på arbetstid bidra med kompetens och utvecklingsinsatser i projektet. 79 | Genom att lämna ett bidrag till ett befintligt öppen källkodsprojekt ärver den aktuella koden den licensmodell som projektet använder. 80 | 81 | Ifall omfattande eller strategiskt stöd ska ges till ett öppen källkodsprojekt ska det godkännas av it-avdelningens arkitekturstyrning. 82 | # 5 - Skapande och delning av öppen källkod 83 | I linje med rekommendationer från Europeiska kommissionen och regeringen ska offentlig verksamhet aktivt arbeta med öppenhet och att dela med sig av data, information och källkod där det är möjligt. Myndigheten ska därför aktivt arbeta med att öppna upp sina applikationer, egenutvecklade funktioner och lösningar för att där det är möjligt tillgängliggöras publikt. 84 | 85 | Innan publicering ska materialets ägare först bedöma innehållets konfidentialitet och därefter beslutar och dokumenterar ansvarig it-arkitekt publiceringen. 86 | 87 | **Checklista inför publicering** 88 | * En beskrivning av underhållet för publiceringen ska finnas. 89 | * Materialet ska utifrån gällande informationsklassningsmodell och säkerhetsskydd vara lämpligt för publicering. 90 | * Materialet ska vara av generell karaktär och får inte innehålla konfigurationsparametrar som är specifika för myndigheten. 91 | * Källkoden får inte omfattas av en licensmodell som omöjliggör publicering. 92 | * Källkoden ska vara helt skriven inom myndigheten, om tredjepartsprogramvara används i källkodform måste licensformerna vara kompatibla och ingå till fullo eller i enlighet med tredje parts krav. 93 | * Kvaliteten på publicerat innehåll ska vara hög och inte innehålla irrelevant information. 94 | * Publicerat material får inte utsätta myndigheten för ökad risk eller på annat sätt påverka myndighetens anseende negativt. 95 | * Licensform ska vara bestämd och vara godkänd av Open Source Initiative. 96 | * Säkerhetsbedömning av källkod ska göras och åtgärder ska vidtas för att säkra kvalitet. 97 | 98 | # 6 - Planerad uppföljningsmetod 99 | Uppföljning av riktlinjens efterlevnad samt uppdatering av innehåll och kontroll av dess aktualitet utförs av strategisk arkitekturstyrning på it-avdelningen. Ändringar beslutas av it-avdelningens ledningsgrupp. 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | --------------------------------------------------------------------------------