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.
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.
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.
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.
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.
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
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.
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.


Arbetet har även godkänts av Vinnova.
