Sambrusk logotyp, till startsidan

Varför SGM?

Detta dokument är en introduktion till det vi valt att kalla Sambruksgemensamt material (SGM).
Detta är tänkt att vara ett regelverk kring hur framtagning, anskaffning och förvaltning av material kan göras inom Föreningen Sambruks ram, antingen av Sambruk som beställande part, eller av någon eller några av Föreningens medlemmar.

Intellektuellt kapital och upphovssrätt


SGM-regelverket omfattar olika typer av material, som tas fram, anskaffas och/eller förvaltas inom Sambruk och som därmed representerar Föreningens intellektuella kapital. Framtagning/anskaffning av detta material innebär oftast kostnader för Föreningen och/eller någon eller några av dess medlemmar. Regelverket specificerar hur upphovsrätt till framtaget material tillfaller Sambruk. Avsikten med att Sambruk ska inneha upphovsrätt till material är att därmed säkerställa att allt sådant material kan göras tillgängligt för spridning, användning och vidareutveckling bland föreningens medlemmar. SGM är avsett att utgöra det regelverk som specificerar hur denna upphovsrätt ska behandlas för att på bästa sätt ge Föreningen och dess medlemmar relevant nytta av upphovsrätten, men också skydda utnyttjande av materialet så att inte begränsningar eller inlåsningar sker.

Några exempel på det som i SGM-dokumentationen benämns "material" är specifikationer, upphandlingsunderlag, utredningar, rapporter, processmodeller, begreppsmodeller, prototyper och programkod. Exemplen ska inte ses som begränsningar till vad SGM-regelverekt kan omfatta, även andra typer av material kan bli aktuellt att inkluderas i regelverket.

Sambruksgemensamt material bygger på att Föreningen Sambruk har upphovsrätt till det material som kommer att omfattas av regelverket. Detta innebär att Sambruk som upphovsrättsinnehavare har rätt att definiera regler och villkor för nyttjande av materialet.

En möjlighet är att Sambruk står som upphovsrättsinnehavare under en begränsad tid och därefter överlåter upphovsrätten till en tredje, gärna helt oberoende part. Ett exempel på en sådan part skulle kunna vara en stiftelse eller en aktör som programverket.org eller OSOR.

Grundläggande principer

  • SGM bygger på tanken att material som tas fram eller anskaffas till föreningen Sambruk skall vara tillgängliga för alla medlemmar som så önskar
  • All programvara skall i möjligaste mån följa Öppen Teknisk Plattform (ÖTP), och allt material skall i största utsträckning följa öppna standarder
  • Syftet med SGM är att förhindra att upphovsrätt till material som förvärvas via Sambruk blir proprietär och därmed skapar inlåsningseffekter för användare

Omfattning


SGM innehåller ett regelverk samt ett antal standardöverenskommelser avseende:
  • Framtagning och anskaffning av material
  • Överlåtelse av material som benefik gåva från kommun till Sambruk
  • Användning, vidareutveckling och förvaltning av material
Dessa standardöverenskommelser kan sedan anpassas till varje specifik situation och typ av material.
SGM är ett sätt att ta fram, anskaffa och förvalta material inom Sambruk. Detta sätt bygger på principer för öppen programvara men som anpassats till Sambruks situation. Man ska inte uppfatta SGM som det enda sättet som Sambruk kan anskaffa material. Det kan finnas situationer där anskaffning av traditionell proprietär programvara eller öppen programvara är att föredra.

SGM ska vara ett sätt för Sambruk att arrangera användardriven och kommungemensam anskaffning och/eller (vidare-)utveckling av material. För en specifik delmängd av material; programvara (egentligen exekverbar programkod), gäller delvis andra förutsättningar än för annat material. SGM är avsett att reglera även detta, men med de specifika förutsättningar som då gäller.

En SGM-strategi ska kunna samexistera med andra existerande programlicensieringsstrategier, till exempel proprietär respektive helt öppen programvara (typ GPL).

Det är viktigt att man på olika sätt (genom formulering av SGM-Regelverk och andra prioriterade insatser) ger förutsättningar för och uppmuntran att SGM kan prövas och utvecklas som ett livskraftigt alternativ till de andra redan etablerade alternativen.

Livscykeln för programvaror och annat material


En viktig insikt är att inget material inom IT- och verksamhetsutvecklingsområdet förblir statiska. Merparten av material, framförallt programvara, som utvecklas idag följer principen med ständiga uppdateringar.
Rent generellt kan man tala om tre olika faser i en programvaras utveckling; (initial) planering, utveckling och förvaltning. Traditionellt har man ansett att det mesta arbetet ska läggas på de första två faserna. I ett livscykelperspektiv så utgörs dock insatser och kostnader för förvaltning de största.

Detta gäller även de flesta former av dokumentation. Idag måste olika typer av dokument anpassas efter hand. Detta kallas för att dokumentet är "levande". I princip gäller samma förutsättningar för alla typer av material som för programvaror.

"Blackbox"


En traditionell upphandling av programvaror sker oftast på det sätt som kallas "blackbox". Kunden skickar över en detaljerad specifikation över vad programvaran skall utföra och leverantören levererar allt i ett färdigt paket. I den typen av programvara har alltså en stor mängd arbete lagts ned i planeringsfasen, där kunden noggrant försökt specificera det som programvaran skall utföra och innehålla.

Specifikationen är värdefull i sig själv. Den ger insikter om hur en organisation arbetar, vilken information som behövs och hur den ska behandlas och vilken typ av programvaror som organisationen anser sig behöva för sin informationsbehandling. Ofta är en specifikation resultatet av ett intensivt arbete, som kostat både pengar och tid att ta fram. Därför anser Sambruk att även den här typen av material bör skyddas, genom att tydliggöra att SGM-regelverket även inkluderar denna typ av dokumentation.

Leverantören har å sin sida arbetat hårt med utvecklingen för att se till att programvaran i största möjliga mån uppfyller specifikationen som de fått av kunden och alltså lagt en stor del av arbetet på utvecklingen. En fördel för en leverantör brukar vara att det de utvecklar kan de återanvända till andra kunder. De försöker därigenom utveckla "standardprogram" och en stor del av utvecklingen (som de första kunderna betalar) läggs på att kunna bygga ut programvaran så att den passar flera.

De flesta programvaror som idag kallas "standardprogram" är i själva verket projekt som leverantören fått med sina tidiga kunder. I praktiken har dessa kunder därigenom finansierat utvecklingen av de program som sedan säljs "från hyllan". Detta är den viktigaste anledningen till varför programvaror anses ha den högsta marginalen av alla produkter.
I många fall klarar inte "standardprogrammen" av att möta de krav som verksamheten har på systemet, och det kräver dyrbar konsulttid för anpassning. Detta beror på att leverantören av dessa program har, genom sin affärsmodell, ensamrätt att ändra och komplettera programvaran. Dessutom brukar de flesta specifikationer, oavsett hur välgjorda de är, ändå inte få med alla krav och situationer som verksamheten har. Dessa misstag under planering/specificering kan ibland bli väldigt kostsamma, eftersom de kräver dyrbara konsulttimmar för att åtgärda.

"Greybox"


En alternativ utvecklings/leveransmodell är "greybox"; som bland annat tillämpas inom öppna programvaror. Detta innebär att kunden och leverantören (även leverantörerna) har en kontinuerlig kontakt genom alla faserna av produktens livscykel. Detta innebär att leverantörerna bör kopplas in så tidigt som möjligt i processen även under planeringsfasen. Kundens kunskap om sin verksamhet och behov kan då bättre mötas av leverantörens kompetens och erfarenheter av programmering. Istället för att kunden måste arbeta "på sin kammare" för att försöka få fram en så detaljerad specifikation, så kan programvaran tas fram i steg och testas i verksamheten under drift. Det gör att programvaran utvecklas sida vid sida med verksamheten.

Det finns flera vinster med greybox-utveckling. Den utvecklade programvaran bör bli väl anpassad till den aktuella verksamheten. En risk kan dock vara om leverantören försvinner efter att programvaran levererats. Detta problem kan hanteras genom att dels använda öppna och kända standarder, dels genom att kunden kräver att programvaran är öppen, och att källkoden ägs av kunden. På det sättet kan kunden själv se hur koden ser ut (och faktiskt kräva att den kommenteras och dokumenteras). Kunden kan dessutom utnyttja, eller anställa egna resurser som är med och övervakar utvecklingen. Utöver detta kan kunden dessutom byta leverantör om något skulle uppstå på vägen.
Genom att sikta mot greybox-utveckling så får kunderna oftast bättre system och samtidigt bättre kontroll på utvecklingen som de har betalat för.

Licenser


Alla programvaror har eller bör ha ett licensavtal. Detta avtal reglerar vilka rättigheter och skyldigheter som användarna respektive leverantören (dvs upphovsrättsinnehavaren) av programvaran har att följa. Generellt finns det två typer av licensformer, proprietära (slutna) och öppna. Genom licensavtalet så reglerar licensgivaren användarnas rättigheter och skyldigheter vad gäller tillgång till och användning av programvaran.

Proprietära licensavtal, exempelvis Microsofts End User License Agreement, tillåter egentligen användare att använda programvaran, med tydliga begränsningar. Detta kan innebära att programvaran inte får kopieras, användas på mer än ett system, vidaredistribueras, etc. Licenserna bygger vanligtvis på amerikansk lagstiftning kring upphovsrätt (copyright). I praktiken har varje typ av proprietär programvara en unik licens som enbart gäller för det aktuella programmet. Det finns med andra ord tusentals olika licensformer.

Öppna programvaror ger oftast användarna mycket stora friheter, inklusive rätten att ändra i programvaran. Den vanligaste öppna programlicensen heter General Public License (GPL) och den finns i tre olika varianter. GPL är även den på baserad på amerikansk upphovsrätt, men vänder på begreppen och istället för att ta ifrån användarna rättigheter så delar de ut dem. Därför kallas GPL ibland skämtsamt för copyleft.

Det finns en stor mängd licenser som ger användarna olika grad av rättigheter. De mest öppna kallas även för "public domain" därför att de ger samtliga friheter till användarna, exempelvis att helt enkelt ta källkoden och göra en proprietär licens av den. Ett exempel på detta är licensen för Berkeley Software Distribution (BSD). Den används för en variant av operativsystemet UNIX. MacOS X bygger på BSD-distributionen FreeBSD men är en proprietär licens.1
Eftersom öppna licenser inte nödvändigtvis behöver vara knutna till en särskild programvara, så kan de användas till flera programvaror. För att få lite ordning och reda bland licenserna startades stiftelsen Open Source Initiative (OSI). De utvärderar och godkänner licenser för öppna programvaror och har för tillfället godkänt cirka 70 licenser.2

1 Se exempelvis:
2 Se för mer information om Open Source Initiative.

Det är upphovsrättsinnehavaren som avgör vilken typ av licens som skall användas. Det är möjligt att ha en öppen licens samtidigt som man har en sluten. Detta kallas "dual licensing". Ett exempel är MySQL.3
Även dokumentation och andra typer av material behöver ha motsvarande upphovsrättsskydd som programvarulicenser har. Det vill säga vilka rättigheter som användare (läsare) har att återanvända, förändra och vidaredistribuera materialet. Det finns flera försök att skapa relevanta licensformer för material som inte bara är programvaror, ett exempel på detta är Creative Commons. Genom de licensformer som finns via Creative Commons kan upphovsrättsinnehavaren specificera vilka rättigheter användarna av materialet har, exempelvis om materialet får användas i kommersiellt syfte, eller fritt vidaredistribueras.4

Inom ramen för Sambruksgemensamt material regleras användarnas utnyttjande av olika material, alltså deras rättigheter och skyldigheter. Detta beskrivs specifikt i Regelverket "Sambruks överenskommelse om fri användning, vidareutveckling och förvaltning av gemensamt material", benämnt SGM — Regelverk. Denna överenskommelse bygger på principer om öppen programvara, men går längre än flera motsvarande licensieringsformer, genom att förutsätta att användare som utfört förändringar i programvaran återför dessa nya versioner till användarkollektivet. Denna överenskommelse syftar därmed till att klargöra rättigheter och skyldigheter för Föreningen Sambruk, dess medlemmar och eventuella externa parter.

Tillgång till programkoden


En risk som ibland tas upp när man diskuterar för- och nackdelar med olika licensformer, är risken att leverantören försvinner efter att programvaran levererats. Detta problem kan uppstå oavsett om leverantören utvecklat programvaran med ett slutet eller öppet licensavtal. Med ett öppet licensavtal har man bättre möjligheter att hantera problemet om leverantören försvinner genom att källkoden faktiskt ägs och innehas av kunden. På det sättet har kunden själv insikt i hur koden ser ut och kräva att den kommenteras och dokumenteras. Kunden kan dessutom utnyttja, eller anställa egna resurser som deltar i utvecklingsarbetet.

Förvaltningsråd


Förvaltningsråd består av medlemmar som bidragit till anskaffning av programvara och som har infört, eller tänker införa den i sin kommun. Förvaltningsrådet är de som ansvarar för att programvaran förvaltas i enlighet med projektmedlemmarnas önskemål och det är de som avgör vem som får tillgång till programvaror och tjänster, samt villkoren för användning. Det är alltså upp till projektmedlemmarna att avgöra dessa frågor.

Förvaltningsrådet är också ansvarigt för att upphandla tjänster kopplade till förvaltningen av programvaran. Det kan handla om sådant som installation, programförvaltning, anpassning, samt service och support.

Sambruks trädet
Sambruk
Säte: c/o Sandvikens kommun, Kommunledningskontoret, 811 80 Sandviken
Postadress: c/o Sandbacka Park, Högbovägen 45, 811 32 Sandviken
Organisationsnummer: 802428-2785