Utgåvehistorik

1          Inledning

Denna anvisning en del av Regelverk för Interoperabilitet inom Vård och omsorg (RIV) [R1], och är framtagen för att tillämpas av samtliga nationella system- och programutvecklingsprojekt inom området. Anvisningen ägs och förvaltas av Inera Arkitektur & Regelverk med huvudsyftet att kunna användas som checklista vid granskning av projekt.

Anvisningen består av en generell del som omfattar alla typer av projekt, och mer specifika delar för olika typer av projekt. Dessa olika typer av projekt baserar sig på en modell som klassificerar projekt med avseende på graden av öppenhet.

2         Direktiv

Projekten klassificeras i olika typer baserat på graden av öppenhet. Modellen i Figur 1 nedan har använts som utgångspunkt i denna anvisning, och för att kunna refereras har de olika typerna av projekt har namngivits från A till F.

Figure 1, Typer av projekt med avseende på graden av öppenhet

Nedan anges ett antal direktiv där vart och ett har en unik identitet som består av ett grupprefix och ett löpnummer. Dels finns en grupp med generella direktiv som således gäller för samtliga typer av projekt och dels så finns det specifika direktiv för varje enskild typ av projekt. Det bör poängteras att den kommersiella problematiken för projekt typ A och B inte är en del av denna anvisning

2.1         Generella direktiv för samtliga projekt (A-F)

Följande direktiv gäller för samtliga projekt (A-F).

Projektetablering

GEN-01   Projektet ska under etableringen fastställa vilken typ (A, B, C, D, E, eller F) som gäller för projektet.

GEN-02  Det ska vara klart huruvida programvaran kommer att distribueras eller om den enbart skall köras som en webbtjänst eller om både och är tillämpligt.

GEN-03  Varje projekt måste skapa och underhålla en förteckning över upphovsrätt och licenser. Förteckningen listar samtliga bidrag till programvaran och vem som har upphovsrätten till dessa bidrag.

GEN-04  Det ska vara dokumenterat under vilken licens alternativt användaravtal som projektresultaten  kommer att distribueras och används under.

GEN-05   Upphovsrätten och ägarskapet till källkod [12] och övriga verk som utvecklas i samarbete mellan flera parter måste vara fastställt innan projektet startar.

GEN-06  Processen för release management och vem som är releaseansvarig ska vara dokumenterat. Projektet ska kommunicera distributioner i form av releaser och det ska vara tydligt om det handlar om stabila produktionsreleaser,  releasekandidater eller andra former av mindre stabila releaser som dagliga byggen.

Programvara och innehåll

GEN-07   Digitala verk oavsett format, såsom dokument, ljud, bild, video, källkod, analysmodeller och övrigt, ska så långt som möjligt vara baserade på öppna standarder [1].

GEN-08  Digitala verk ska inte vara kopieringsskyddade  med DRM [2] teknik.

GEN-09  Digitala verk ska vara arkiverade i en förvaringsplats som har ett dokumenterat säkert sätt att lagra media på.

GEN-10   Historiska versioner av programvaran ska behållas och kunna återställas. GEN-11    Hela historiken med ändringskommentarer ska arkiveras enligt GEN-10.

GEN-12   Projekt som utvecklar programvara ska ha en ändamålsenlig testinfrastruktur  på plats där programvaran kontinuerligt verifieras i en produktionsliknande konfiguration.

GEN-13   För programvara som implementerar en specifik standard ska det finnas tester som demonstrerar uppfyllelsegraden  av standarden ifråga.

GEN-14   Projektet måste uppvisa en process för hur man inför och godkänner programvara baserad på öppen källkod.

GEN-15   Katalogstrukturer,  namnrymder, namn på källkodsfiler och dylikt ska vara fria från namn från andra organisationer än den som har upphovsrätten till källkoden. Undantag är e-post-adresser till enskilda individer som bidragit till utvecklingen.

GEN-16   Källkod ska så långt som det är möjligt vara representerad i åtta-bitars Unicode transformationsformat (UTF-8) [14].

GEN-17   Det måste framgå klart och tydligt vem som har upphovsrätten till projektets källkod och övrigt innehåll. All källkod ska så långt som möjligt innehålla ett huvud som tydligt anger upphovsrätten och licensformen för källkoden. Huvudet ska utformas i enlighet med de direktiv som beskrivs i den aktuella licensen.

GEN-18   Om ändamålsenliga alternativ finns ska licenser godkända i enlighet med Open

Source Initiative (OSI) [3] definition föredras framför icke OSI godkända.

GEN-19   Projektet ska för varje release dokumentera samtliga verifierade och supporterade beroenden till tredjepartsprogramvara med versionsindikation  för såväl konstruerandet som användning av programvaran.

GEN-20  Förutom beroendet som sådant ska licenserna som omfattas av beroendet till tredjepartsprogramvara dokumenteras. Det kan handla om operativsystem, kompilatorer, utvecklingsmiljöer,  databaser, web servers etc.

GEN-21   Innehåller programvarupaketeringen licensierade tredjepartsprogramvaror ska motsvarande originallicenser återges i textfiler namngivna LICENSE_[NAMN].txt där [NAMN] ersätts med namnet på tredjepartsprogramvaran. Observera att detta direktiv gäller oberoende om det handlar om öppen källkod eller inte. Eventuell förekomst av dessa licensfiler ska återfinnas roten av filträdet när programvaran packats upp eller på annat sätt installerats.

GEN-22   Förteckningen över inkluderad programvara ska tillhandahållas i en textfil med namnet NOTICE.txt [13]. Denna textfil ska oavsett typen av paketering distribueras med programvaran och då vara placerad i roten av filträdet när programvaran packats upp eller på annat sätt installerats.

2.2        Direktiv för projekttyp A

Följande direktiv gäller för projekt med kommersiell licens och proprietär källkod.

PMA-01   För programvara som distribueras ska det säkerställas att inga beroenden finns till

Copyleft [5] (GPL) licensierad programvara.

PMA-02  För programvara som kommer att användas som webbtjänst ska det säkerställas att inga beroenden finns till Affero AGPL [9] licensierad programvara.

2.3        Direktiv för projekttyp B

Följande direktiv gäller för projekt med kommersiell licens och delad källkod.

PMB-01    Samtliga direktiv från projekttyp A gäller.

PMB-02    Det ska finnas en källkodslicens alternativt ett exklusivt användaravtal som

formulerar rättigheter och skyldigheter för användning och distribution av den delade källkoden.

2.4        Direktiv för projekttyp C

Följande direktiv gäller för projekt med öppen licens och öppen källkod.

PMC-01   Om projektet baseras på källkod från externa bidrag måste motsvarande bidragsavtal

[7] finnas upprättade.

PMC-02  Distributioner ska innehålla en LICENSE.txt textfil som innehåller en originalkopia av licensen ifråga. LICENSE.txt ska oavsett typen av paketering distribueras med programvaran och då vara placerad i roten av filträdet när programvaran packats upp eller på annat sätt installerats.

PMC-03  Projektet ska använda den av CeHis rekommenderade  projektplatsen som därmed är åtkomlig över internet. På denna projektplats kommuniceras projektinformation  och hanteras stödtjänster för projektets källkod, releaser, och problemhantering  etc.

PMC-04  Om projektförvaltningen  är delegerat måste det framgå vem som har detta ansvar och vad ansvaret innebär ur ett beslutsperspektiv.

PMC-05  Upphovsrätten ska tydligt framgå i allt producerat och delat material såsom källkod, analysmodeller, dokument, och manualer.

PMC-06  Användning och distribution av projektresultat såsom källkod, programvara, dokument, manualer, användargränssnitt  måste gälla under en OSI [3] godkänd licensform.

PMC-07   Demonstrationer  av den nuvarande programvarureleasen  ska om möjligt finnas tillgängliga på nätet som webbtjänster eller som körbar programvara för nedladdning.

2.5         Direktiv för projekttyp D

Följande direktiv gäller för projekt med öppen licens, öppen källkod, och öppen kommunikation.

PMD-01  Samtliga direktiv från projekttyp C gäller.

PMD-02  Projektet ska arbeta enligt principerna att publicera inkrementella releaser med fungerande men ännu inte färdig programvara.

PMD-03  Projektet ska hantera releasekommunikation och återkoppling från externa användare.

PMD-04  Det ska vara tydligt vilka delar av programvaran som utvecklats helt och hållet av projektet, vilka delar projektet bidragit till och vilka delar som finansierats från annat håll.

PMD-05  Programvarans plan för framtida versioner dvs. dess roadmap ska kommuniceras.

2.6        Direktiv för projekttyp E

Följande direktiv gäller för projekt med öppen licens, öppen källkod, öppen kommunikation, och öppet deltagande.

PME-01   Samtliga direktiv från projekttyp D gäller.

PME-02  Projektet ska demonstrera hur man uppmuntrar att programvaran används i en vidare utsträckning än för projektets egenintresse.

PME-03  Projektet ska kunna hantera felrapporter, källkodsbidrag, översättningar och återkoppling från externa deltagare och bidragare, dvs. utanför projektgruppen som sådan.

PME-04  Projektet ska öppet på sin officiella projektplats kommunicera licensmodellen och den policy som gäller för bidragsgivare [7].

2.7         Direktiv för projekttyp F

Följande direktiv gäller för projekt med öppen licens, öppen källkod, öppen kommunikation, öppet deltagande, och öppet beslutsforum.

PMF-01  Samtliga direktiv från projekttyp E gäller.

PMF-02 Beslutsprocessen  ska vara väl dokumenterad och öppet publicerad på den officiella projektplatsen.

PMF-03 Samtliga beslut ska journalföras och redovisas på den officiella projektplatsen.

3         Rekommendationer

3.1         Projektplats

Rekommenderad projektplats är för närvarande Bitbucket [R2].

3.2        Källkodslicenser

Rekommendationen är att man först och främst använder sig av Apache License [11] om det är möjligt. Alternativet är någon av GNU General Public License versionerna som mer utförligt beskrivs nedan.

Generellt beror valet av källkodslicens på hur mycket man värnar om att bevara öppenheten för framtida verk som bygger vidare på programvaran ifråga. Men valet styrs också i hög grad av de eventuella verk som programvaran bygger vidare på och den licensform som gäller för dessa. Det rekommenderas att man håller sig till någon av 2 olika grundtyper av licenser nämligen GNU General Public License (GPL) och Apache License där 2 ytterligare varianter från GPL nämligen AGPL och LGPL måste tas under beaktande:

•    Apache-2.0 [11] för att minimera kraven på framtida verks öppenhet och användning.

•    GPL-3.0 [8] för att säkerställa maximal öppenhet för programvara som distribueras.

    Inkluderar alla framtida derivat av programvaran.

•      AGPL-3.0 [9] för att säkerställa maximal öppenhet för programvara som körs som webbtjänst. Inkluderar alla framtida derivat av programvaran.

•      LGPL-3.0 [10] för att säkerställa öppenhet vad gäller t.ex. en Web applikation (WAR arkiv) eller ett bibliotek (JAR arkiv), men tillåta att programvaran används i ett system av proprietär karaktär som distribueras under kommersiell licens. Inkluderar alla framtida derivat av programvaran.

Det är inte möjligt att inkludera verk med starkare licenser avseende öppenhet än den som man valt för sitt projekt, dvs. en programvara som är licensierad under den starkare GPL kan inte under några omständigheter användas och distribueras i en programvara som licensieras under LGPL eller Apache och då självfallet inte heller i en proprietär lösning.

3.3        Licenser för övriga verk

Det rekommenderas att licensformen Creative Commons CC-BY-SA [6] används för övrigt media och innehåll som inte är rena källkodsverk såsom hemsidor, dokumentation, och bilder mm.

3.4        Licens för bidragsgivare

För att förhindra komplexiteten kring ägarskapet i öppna källkodsprojekt så bör man skriva särskilda avtal med bidragsgivare (contributors). Dessa avtal berör framför allt ägarskapet och upphovsrätten till källkoden, men även patent och supportfrågor klargörs. Det rekommenderas att licenser för bidragsgivare bygger vidare på Apache Individual Contributor License Agreement för individer och Software Grant and Corporate Contributor License Agreement för företag och organisationer [7].

3.5         Projektägare

Det rekommenderas att projektägarskapet för öppen källkodsprojekt och därmed upphovsrätten tillhör en organisation som har förmåga att utveckla och förvalta programvaruprojektet, som Inera AB. Notera att med projekt avses det öppna källkodsprojektet  och inte enstaka utvecklingsprojekt  inom ramarna för detta. Dvs ett öppet källkodsprojekt är i enlighet med gängse nomenklatur snarare att jämföra med ett program.

3.6        Projekttyp

Det rekommenderas att man så långt som möjligt utvecklar i öppen källkodsprojekt, och i praktiken innebär detta i de allra flesta fall projekttyp C eller D. Vilken av dessa är beroende på hur mycket kommunikation projektet har med externa intressenter. I fallet nationella tjänstekontrakt så är bör projekttyp D föredras då det finns flera externa intressenter som förväntas realisera dessa.

4         Förtydliganden

[1]    Användning av öppna standarder innebär ökad hållbarhet för resultaten ifråga. Exempel på lämpliga standardforum är ISO (http://www.iso.org),  W3C (http://www.w3.org), OMG (http://www.omg.org)  och IETF (http://www.ietf.org).

[2]    DRM (http://en.wikipedia.org/wiki/Digital_rights_management)  är en förkortning för Digital Rights Management och används för att begränsa användningen av digitalt material. Till exempel kan dokument skapade med Microsoft och Adobe verktyg skyddas med denna teknik.

[3]    OSI (http://www.opensource.org/docs/osd) är en förkortning för Open Source Initative, och är en organisation som definierar öppen källkod och godkända licenser i enlighet med definitionen (http://www.opensource.org/licenses/alphabetical).

[4]    Copyleft medger användaren långtgående rättigheter att modifiera och sprida ett verk så länge det görs under de ursprungliga villkoren. Termen är sprungen ur ”Copyleft – all rights reversed” som är en travesti på satsen ”Copyright – all rights reserved”. Denna formulerades 1984 av Don Hopkins i ett brev till Richard Stallman.

[5]    Creative Commons CC-BY-SA (http://creativecommons.org/licenses/by-sa/2.5/se).
Denna innebär att man fritt får kopiera, distribuera och skapa bearbetningar av licensierat media under förutsättning att upphovsmannen  anges.

[6]    En bidragsgivarlicens  definierar villkoren för de verk (intellektuellt kapital) som en individ eller organisation överlåtit till ett projekt. Exempel på sådana avtal är Apache Individual Contributor License Agreement (http://www.apache.org/licenses/icla.txt) och Software Grant and Corporate Contributor License Agreement (http://www.apache.org/licenses/cla-corporate.txt).

[7]    GPL (http://www.opensource.org/licenses/GPL-3.0), GNU General Public License är en upphovsrättslicens  för fri programvara ursprungligen författad av Richard Stallman.

[8]   AGPL (http://www.opensource.org/licenses/AGPL-3.0), GNU Affero General Public License är för program, som inriktar sig på webtjänster som t.ex. Facebook, Flickr och Google. Om någon ändrar källkod licenserad med AGPL och bara publicerar det som en webbtjänst så måste de fortfarande publicera källkoden, enligt sektion 2(d) i AGPL.

[9]    LGPL (http://www.opensource.org/licenses/LGPL-3.0), GNU Lesser General Public License, är en licens för fri programvara. Den främsta skillnaden mot GPL är att det är tillåtet att inkludera program licenserade under LGPL i ett nytt program, utan att det nya programmet omfattas av LGPL.

[10]Apache Licensen (http://www.opensource.org/licenses/Apache-2.0) är en licens för programvara författad av Apache Software Foundation och innebär att programvaran fritt får distribueras och användas utan restriktioner förutom kravet på en notis om upphovsrätt och en friskrivning om ansvar.

[11] Källkod, med källkod avses innehåll skrivet i språk som syftar till att tolkas maskinellt.
Inom RIV Tekniska Anvisningar är följande exempel belysande programkod, konfiguration av automatiserade byggen, och tekniska tjänstekontrakt.

[12] Apache exempel på en NOTICE.txt textfil (http://www.apache.org/licenses/example- NOTICE.txt).

[13] UTF-8 har valts som huvudsaklig teckenkodning i internetprotokoll:  nya protokoll måste stöda denna teckenkodning, om det inte av speciella skäl är olämpligt. Se även IETF Policy (http://tools.ietf.org/html/rfc2277).

5         Referenser

[R1]                 RIV-TA http://rivta.se/

[R2]                Bitbucket, Projektplats https://bitbucket.org

[R3]                Inera, Arkitektur och regelverk http://www.inera.se/TJANSTER--PROJEKT/Arkitektur-och-regelverk