Functioneel Aanbesteden OSS. Versie 1

Functioneel Aanbesteden OSS Versie 1

2 | Functioneel Aanbesteden

Inhoud

blz

Inleiding

4

1 Inzet Open Standaarden

4

2 Inzet Open Source Software

5

3 Bijdragen vanuit DICTU t.a.v. OSS

7

7 7 7 7

3.1 3.2 3.3 3.4

Bijdrage vanuit Architectuur &Strategie t.b.v. OSS Modelteksten bij aanbesteden Functioneel aanbesteden Aanvullende voorwaarden

4 Checklist functioneel aanbesteden

8

4.1 Vragen over open standaarden 4.2 Vragen over open source

8 9

5 Bijlage 1 Modelteksten

10

10 11 12 14 14 14 15 17

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.1.8

Open standaarden Open source en vrije software Selectiefase Gunningsfase Webrichtlijnen Technische onafhankelijkheid Leveranciersonafhankelijkheid Toekomstbestendigheid

Referenties APM-toets en Open Source Software, Engbers, B en G.M.L. Dingemans, Ministerie van LNV, 2010 [GG] Architectuurrichtlijnen gelijke geschiktheid open source software, Engbers, B en G.M.L. Dingemans, Ministerie van LNV, 2010 [GG] Implementatiestratie Open Source Software, Fred Winia, Ministerie van LNV, 2008. Het verwerven van Open Source Software, NOiV, 2007. [VOSS] Praktisch Ontwikkel Raamwerk, Marleen Wijnstok, Ministerie van LNV, 2009. [POR] Productmatrix Open Source Software, Bert Dingemans, Ministerie van EL&I, 2011. [PM] Website www.noiv.nl, Ministerie van BZK, 2011. [NOiV]

Functioneel Aanbesteden | 3

Inleiding De Nederlands overheid propageert het gebruik van Open Standaarden en Open Source Software. Dit document geeft aan wat met deze termen wordt bedoeld en hoe het Ministerie van EL&I vorm geeft aan deze wens in het proces van verkrijgen van ICT hulpmiddelen. Open Standaarden en Open Source Software worden vaak in één adem genoemd. Het is echter van belang om onderscheid te maken tussen Open Standaarden (OS) en Open Source Software (OSS). Bij OS gaat het vooral om definities en afspraken, bij OSS gaat het om programmatuur. De beleidsregels voor OS en OSS zijn verschillend: voor OS geldt het principe van ‘pas toe of leg uit’ (‘comply or explain’); voor OSS geld het principe van ‘gelijke geschiktheid’. De inzet van OS en OSS is verschillend en wordt in de volgende hoofdstukken uitgewerkt. In de open source implementatie strategienota voor LNV [OSI] wordt uitgewerkt hoe open source software wordt ingebed in de organisatie (bedrijfsvoering) van het ministerie van LNV. Voor een nadere uitwerking van de strategie zijn er operationele beleidskaders nodig. Deze “operationalisering” wordt gedaan in de actielijnen. De volgende actielijnen zijn benoemd: 1. Gelijke geschiktheid 2. Internetservice als verandermoment 3. Plaatsbepaling van OSS binnen POR 4. Herijkt beleid t.a.v. Vendor Lock-in 5. Strategiedocument voor infrastructuur 6. Communitybeleid 7. Criteria voor verantwoord teruggeven Dit document richt zich voornamelijk op actielijn 4

1. Inzet Open Standaarden Een belangrijk kenmerk van een open standaarden is dat er geen barrières zijn bij het gebruik ervan door ICT-gebruikers en ICT-aanbieders. Open standaarden staan tegenover gesloten standaarden die wel (potentiële) barrières kennen. Een standaard is volledig ‘open’ als [NOiV]: 1. de standaard is goedgekeurd en wordt gehandhaafd door een non-profit organisatie. De lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.); 2. de standaard is gepubliceerd. Het specificatiedocument van de standaard is openbaar of het is te verkrijgen tegen een nominale bijdrage. Het moet voor iedereen mogelijk zijn om de informatie te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs; 3. het intellectuele eigendom, met betrekking tot mogelijke aanwezige patenten, van (delen) van de standaard is onherroepelijk ter beschikking gesteld op een ‘royalty-free’ basis; 4. er zijn geen beperkingen omtrent het hergebruik van de standaard


Open standaarden zijn met name belangrijk op het vlak van interoparabiliteit (samenwerking tussen systemen). Daarmee is het toepassen van open standaarden een belangrijke eis binnen de Nederlandse Overheid. Het ministerie van EL&I onderschrijft het belang hiervan en sluit daarom aan bij de werkwijze “pas toe of leg uit” bij open standaarden. Zie ook http://www.open-standaarden.nl/open-standaarden/lijsten-met-open-standaarden/ Open Standaarden moeten worden toegepast; bij afwijking hiervan moet uitleg gegeven worden waarom de open standaard niet wordt toegepast. De lijst met standaarden waarvoor dit van toepassing is is te vinden op de website van het Forum Standaardisatie.

2. Inzet Open Source Software Open source software is software met twee kenmerken: • De broncode van de software is vrij beschikbaar. • In het licentiemodel is het intellectueel eigendom, het (her)gebruik van de software en bijbehorende broncode dusdanig geregeld dat de licentienemer de broncode mag inzien, gebruiken, verbeteren, aanvullen en distribueren. Aan licenties van open source software zijn geen kosten verbonden. Voor ondersteuning, onderhoud, opleiding/training, bijbouwen van maatwerk etc. gelden over het algemeen wél marktconforme bedragen. Bij gelijke geschiktheid verdiend Open Source Software de voorkeur. Ofwel: Als er een keus mogelijk is tussen closed source programmatuur en OSS, en beide zijn even geschikt om te voldoen aan de functionele wens, dan moet de OSS oplossing worden gekozen. Voor het introduceren van software binnen het ministerie van EL&I wordt het Praktisch Ontwikkelraamwerk [POR] gehanteerd. In het POR worden de volgende uitvoeringspaden beschreven: • Hergebruik: het opnieuw gebruiken van reeds (binnen EL&I of de overheid) aanwezige ICT oplossingen, dit kunnen ook OSS pakketten zijn; • EBS: het inzetten van het Enterprise Resource Planning systeem Oracle eBusiness Suite (EBS,dit is closed source software); • Standaardpakket: het aanschaffen en inrichten van een bestaand software pakket. Dit pad mag alleen worden gekozen als hergebruik of inzet van EBS niet toereikend zijn; • Maatwerk: het (laten) maken van nieuwe software. Dit pad mag alleen worden gekozen als hergebruik en de inzet van EBS of standaardpakketten niet toereikend zijn. Hieronder is per uitvoeringspad aangegeven of en zo ja hoe OSS ingezet moet worden. • Hergebruik. Kies bij gelijke geschiktheid voor hergebruik van OSS oplossingen. Bijvoorbeeld toepassingen ontwikkeld door overheidsinstellingen die beschikbaar zijn gesteld als overheidsbrede bouwsteen. • EBS. Inzet van OSS is hier niet van toepassing, met uitzondering van infrastructurele componenten. • Standaardpakket. Kies bij gelijke geschiktheid voor gebruik van OSS oplossingen; denk bijvoorbeeld aan programma’s als Firefox en Open Office, en het CMS Drupal. • Maatwerk, Bij het realiseren van maatwerk kunnen OSS ontwikkelhulpmiddelen ingezet worden; de term ‘gelijke geschiktheid’ heeft hierbij betrekking op de mogelijkheden van het ontwikkelhulpmiddel en op de eisen aan de daarmee ontwikkelde software. Als dat OSS ontwikkelhulpmiddelen worden gebruikt, dan kunnen ook componenten ontwikkeld worden die vervolgens als overheidsbrede voorzieningen ingezet kunnen worden.


De uitvoeringspaden worden voor alle domeinen gebruikt, er wordt echter een onderscheid gemaakt in de keuzepaden op basis van primaire en secundaire (PIOFACH) taken. In onderstaande afbeelding wordt dit grafisch weergegeven.

Afbeelding 1 Ontwikkelpaden en OSS keuzes Afhankelijk van het te gebruiken uitvoeringspad en de uitwerking van dat pad is een aantal activiteiten te benoemen waarbij OSS beleid getoetst moet worden, in deze volgorde:

APM toets Bij de APM toets wordt gekeken of aan een functionele vraag kan worden voldaan met een reeds aanwezige applicatie (hergebruik of eventueel EBS). Zijn er meer kandidaten dan geldt de genoemde regel van gelijke geschiktheid voor OSS. Is er geen geschikte applicatie aanwezig, dan wordt gekeken of er op de markt geschikte pakketten te krijgen zijn (standaardpakket). Zijn er meer kandidaten dan geldt de genoemde regel van gelijke geschiktheid voor OSS.

PSA en ontwerp In de PSA worden de randvoorwaarden benoemd en wordt een globale omschrijving benoemd van de componenten in het toekomstige applicatielandschap. Tijdens het ontwerp wordt dit vertaald naar een specifieke beschrijving van de implementatie. In sommige gevallen worden zelfs de componenten specifiek benoemd. In beide stappen geldt de genoemde regel van gelijke geschiktheid voor OSS.

Functioneel aanbesteden Bij functioneel aanbesteden wordt aan leveranciers gevraagd een voorstel te doen voor een oplossing van een functioneel probleem. De leverancier mag zelf de software uitkiezen die deel uitmaakt van zijn aanbieding. In de opdracht moet staan dat bij gelijke geschiktheid de voorkeur uitgaat naar OSS producten. Eventueel kan een lijst meegeleverd worden die aangeeft welke OSS (reeds bij EL&I aanwezig is en dus zonder problemen) toegepast kan worden.

Ontwikkeling van maatwerk software Tijdens de ontwikkeling kunnen enerzijds frameworks en libraries ingezet worden als generieke onderdelen van de totaaloplossing. Hierbij kan gekozen worden voor OSS producten (bij gelijke geschiktheid). Ook is het in deze fase mogelijk om OSS hulpmiddelen voor ontwikkelaars in te zetten [GG].

Beheer Na de selectie of ontwikkeling van software, zoals uitgewerkt in het POR, volgt de fase van beheer en exploitatie. Tijdens het beheer van het applicatielandschap worden diverse hulpmiddelen als monitoringtools en beheertooling ingezet. Ook hierbij kan bij gelijke geschiktheid gekozen worden voor OSS producten. Echter de keuze voor deze producten zal in een voorgaand traject voor implementatie van monitoring tooling reeds gemaakt zijn


In alle fasen is het van belang dat de keuze voor een open of gesloten oplossing gewogen gemaakt wordt. De keus voor een bepaald product (open of gesloten) heeft gevolgen voor implementatie, beheer en doorontwikkelen. Daarnaast kan het gevolgen hebben voor het verantwoord beschikbaar stellen van producten als overheidsbrede oplossing.

3. Bijdragen vanuit DICTU t.a.v. OSS 3.1 Bijdrage vanuit Architectuur &Strategie t.b.v. OSS De afdeling architectuur en strategie (A&S) heeft architectuurrichtlijnen opgesteld ten behoeve van de beoordeling van ‘gelijke geschiktheid’ van OSS producten. A&S kan verder de volgende bijdragen leveren: • Toetsen van aanbestedingsrequirements en voorwaarden ten aanzien van het OSS beleid van EL&I; • Beantwoorden van vragen van leveranciers betreffende het EL&I open source beleid bij aanbesteden; • Adviseren van intern opdrachtgevers omtrent het inzetten van open source vanuit een functioneel perspectief; • Adviseren van betrokkenen omtrent het community en verantwoord teruggeven beleid van EL&I; • Beheren van de productmatrix open source (of eventuele opvolgers van dit document); • Evalueren van de software stack zoals voorgesteld door leveranciers binnen een functionele aanbesteding.

3.2 Modelteksten bij aanbesteden https://noiv.nl/modelteksten/

3.3 Functioneel aanbesteden Wikipedia geeft een goede beschrijving van de ins en outs van aanbesteden op: http://nl.wikipedia.org/wiki/Aanbesteden

3.4 Aanvullende voorwaarden • • • •

Gelijke geschiktheid Productenmatrix EL&I Beheer door Dictu Keuze van frameworks bij verantwoord beschikbaar stellen


4. Checklist functioneel aanbesteden Leveranciers stellen met grote regelmaat ‘open’ te zijn. Dit document beoogt om dergelijke claims te waarderen door middel van een checklist met vragen. Deze vragenlijst is verdeeld in vragen over open standaarden en over open source software. De vragenlijst is nadrukkelijk niet bedoeld om leveranciers uit te sluiten. Het ‘pas toe of leg uit’ beginsel staat overheden immers toe om onder omstandigheden open standaarden niet dwingend op te leggen en voor open source software geldt dat overheden hier bij gelijke bekwaamheid een voorkeur aan dienen te geven. Ook dient opgemerkt te worden dat de leveranciersafhankelijkheid niet uitsluitend geborgd wordt door een leverancier te zoeken die alle onderstaande vragen bevredigend kan beantwoorden. Onderstaande vragenlijst is vooral bedoeld om bijvoorbeeld al tijdens een marktconsultatie een beeld te krijgen van de mate van openheid in een bepaald marktsegment.

4.1 Vragen over open standaarden Een leverancier stelt dat zijn oplossing gebaseerd is op open standaarden. Hierover kunnen de volgende vragen gesteld worden: • Welke standaarden betreft dit? Dekken deze 100% van de functionaliteit af of worden er ook gesloten standaarden gebruikt? • Welke standaarden worden binnen de oplossing gebruikt en welke zijn beschikbaar op de koppelvlakken? • Zijn deze standaarden uitgebreid door leverancier? • Zo ja, hoe en met welk doel zijn deze uitgebreid? • Welke van de door leverancier gebruikte standaarden voldoen aan de criteria van het Europees Interoperabiliteitsraamwerk versie 1.0? Dit zijn: -- De standaard is goedgekeurd en zal worden gehandhaafd door een non-profit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.); -- De standaard is gepubliceerd en over het specificatiedocument van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor eenieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs; -- Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen) van de standaard is onherroepelijk ter beschikking gesteld op een ‘royalty-free’ basis; -- Er zijn geen beperkingen omtrent het hergebruik van de standaard. • Hoe volgt leverancier het releasebeleid van de gebruikte standaarden? • In hoeverre dwingt leverancier opdrachtgever om diens releasebeleid te volgen? • Met welke andere producten is de interoperabiliteit daadwerkelijk getest en aangetoond?


4.2 Vragen over open source Welke licentie(s) zijn van toepassing op de door leverancier aangeboden computerprogrammatuur? 1. Welke van deze licentie(s) zijn gecertificieerd door het Open Source Initiative (OSI)? 2. Voldoen de licentie(s) welke niet zijn gecertificieerd door het OSI aan de door OSI gehanteerde Open Source Definitie? Dit zijn de volgende tien criteria (vertaling door NOiV, OSI versie is leidend): 1. Vrije distributie: de licentie bevat geen verboden ter zake van de verdere verspreiding van de software (al dan niet tegen betaling), zowel zelfstandig of als onderdeel van een groter geheel. De licentie vereist geen vergoedingen voor verdere verspreiding; 2. Broncode: de computerprogrammatuur wordt inclusief broncode geleverd en de licentie verdere distributie van de broncode en/of gecompileerde versies toe. In het geval de computerprogrammatuur zonder broncode beschikbaar wordt gesteld dient er een goed gepubliceerde verkrijgingswijze van de broncode zijn welke geen andere kosten dan de reproductiekosten met zich meebrengt. Dit bij voorkeur kosteloos via het internet. Als broncode wordt beschouwd de verschijningsvorm van de computerprogrammatuur welke door de programmeurs gebruikt wordt om deze te ontwikkelen en/of aan te passen. Bewuste versluiering van de broncode en verschijningsvormen welke voortvloeien uit tussenstappen van een eventueel compilatieproces worden niet als broncode gezien; 3. Afgeleide werken: de licentie staat modificatie van de computerprogrammatuur alsmede de schepping van afgeleide werken toe en staat verdere verspreiding van deze gewijzigde of afgeleide versies toe met als maximale door de licentie opgelegde restrictie de toepassing van dezelfde licentie. 4. Integriteit van de broncode van de auteur: de licentie kan beperkingen opleggen aan verspreiding van de broncode in gewijzigde vorm, maar uitsluitend als de licentie toestaat dat wijzigingen in broncode worden verspreid als zogenaamde “patch files” teneinde de wijzigingen in de computerprogrammatuur aan te kunnen brengen als onderdeel van het compilatieproces. De licentie mag van afgeleide werken vergen dat deze een andere titel of versienummer krijgen; 5. Geen discriminatie tegen personen of groepen: de licentie mag niet discrimineren jegens bepaalde personen of groepen; 6. Geen discriminatie tegen toepassingsgebieden: de licentie mag geen specifieke gebieden van toepassing van de computerprogrammatuur uitsluiten. Voorbeelden van dergelijke uitsluitingen zijn uitsluiting van commercieel gebruik of gebruik voor genetisch onderzoek; 7. Verdere verspreiding van de licentie: de gebruiksrechten welke toegekend worden door de licentie zijn van toepassing voor iedere verdere gebruiker aan wie de computerprogrammatuur verder wordt verspreid zonder een aanvullende licentie(overeenkomst) met die verdere gebruikers te vergen; 8. Licentie niet specifiek voor een product: de gebruiksrechten op de computerprogrammatuur mogen niet verbonden zijn aan een specifieke publicatie van de computerprogrammatuur. Indien de computerprogrammatuur slechts gedeeltelijk verder verspreid wordt (binnen de door de licentie toegekende distributiebevoegdheden) dienen alle verdere gebruikers dezelfde gebruiksrechten te ontvangen als bij de oorspronkelijke publicatie van de computerprogrammatuur; 9. Licentie schept geen restricties voor andere computerprogrammatuur: de licentie mag geen restricties opleggen aan andere computerprogrammatuur welke gezamenlijk met de computerprogrammatuur waar de licenties op van toepassing is verspreid wordt. De licentie mag bijvoorbeeld niet vereisen dat de computerprogrammatuur uitsluitend met andere open source software verspreid mag worden. 10. Technologie-neutraal: geen enkele voorwaarde van de licentie mag gerelateerd zijn aan een specifieke technologie of koppelvlak. 3. Gelden de licentie(s) welke a) gecertificeerd zijn door het OSI of b) aan de onder 3) genoemde criteria voldoen voor alle door leverancier aangeboden computerprogrammatuur? 4. Zo niet, in hoeverre zijn de componenten welke niet open source software zijn cruciaal voor het functioneren voor de totaaloplossing? Hierbij kan gedacht worden aan: 5. betreft het componenten die vooral het beheersgemak vergroten? 6. betreft het cruciale koppelvlakken met andere componenten in de informatiehuishouding van opdrachtgever? 7. Heeft de leverancier als enige copyright over het product (en kan dus toekomstige versies onder een andere licentie uitbrengen), of zijn er meerdere partijen die copyright hebben?


5. Bijlage 1 Modelteksten 5.1.1 Open standaarden Opdrachtgever acht de kenmerken van open standaarden van belang om de volgende redenen:


Kenmerk

Reden

Open besluitvormingsprocedure:

Dit kenmerk zorgt ervoor dat de aanbestedende overheidsorganisatie niet afhankelijk is van één partij voor het beheer en de doorontwikkeling van de standaard. De open besluitvormingsprocedure maakt het mogelijk dat bij het beheer en de doorontwikkeling rekening zal worden gehouden met diverse belangen. Het biedt de aanbestedende overheidsorganisatie zelf ook de mogelijkheid om eventueel invloed uit te oefenen op de ontwikkelingsrichting van de standaard.

Eenvoudig beschikbaar:

Publicatie van een standaard maakt het mogelijk dat de standaard onafhankelijk van de beheerder van de standaard kan worden geïmplementeerd. Hierdoor is de aanbestedende overheidsorganisatie niet afhankelijk van één organisatie bij het uitwisselen van gegevens. Met name in informatie ketens waarin veel partijen participeren is het bevorderlijk voor de toegankelijkheid dat de standaard is gepubliceerd. Wanneer gegevens voor langere tijd worden vastgelegd, zorgt de beschikbaarheid van de beschrijving van het bestandsformaat dat de gegevens ook in de toekomst kunnen worden ontsloten.

Geen drempels op basis van intellectuele rechten:

Voor het gebruik van standaarden worden geen licentievergoedingen op basis van intellectuele rechten in rekening gebracht. De vergoedingsvrije basis voor gebruik zorgt ervoor dat er geen financiële drempel voor andere deelnemers in de informatieketen en voor andere software-ontwikkelaars is om de standaard te implementeren of zelfs maar te gebruiken. Dit is een belangrijke randvoorwaarde voor de toekomstige beschikbaarheid van overheidsinformatie. Dit is ook een randvoorwaarde voor het implementeren van de standaard in open source software.

Geen beperkingen omtrent hergebruik:

Beperkingen omtrent het hergebruik van de standaard kan bepaalde partijen binnen de informatieketen uitsluiten van het gebruik van de betreffende standaard. Een standaard zou bijvoorbeeld alleen voor overheidspartijen kunnen gelden. Indien marktpartijen in de informatieketen zitten, dan zijn deze in dat geval uitgesloten van het gebruik van de standaard. Open standaarden voorkomen dit.

5.1.2 Open source en vrije software Opdrachtgever acht de kenmerken van open source software om de volgende redenen van dusdanig belang dat hij een voorkeur uitspreekt voor aanbiedingen welke open source software omvatten:

Kenmerk

reden

Leveranciersonafhankelijkheid:

Opdrachtgever wil na de eerste ontwikkelfase zelf kunnen bepalen wie de software beheert en/of verder ontwikkeld zonder daarbij afhankelijk te zijn van de oorspronkelijke leverancier; Het criterium ziet daarbij niet alleen op de technische mogelijkheid tot wijziging, maar ook op de juridische. Daarmee wordt bedoeld dat het bewerken niet alleen technisch mogelijk moet zijn, maar ook moet worden toegestaan door de rechthebbende door verlening van een ruim gebruiksrecht. Ook in gevallen wanneer een leverancier besluit een bepaald pakket niet verder te ontwikkelen of te ondersteunen, wil de opdrachtgever een andere leverancier kunnen zoeken om daarmee de continuïteit van de bedrijfsvoering te kunnen garanderen.

Concurrentiebevordering:

Doordat de broncode van de software vrij beschikbaar is staat het Opdrachtgever vrij derden hiervan kennis de doen nemen, en is de drempel voor deze derden lager om deel te nemen aan latere aanbestedingstrajecten inzake het beheer en/of de doorontwikkeling van de software;

Flexibiliteit:

Het is de wens van de aanbestedende dienst dat systemen snel kunnen worden aangepast aan en uitgebreid omwille van nieuwe wensen en behoeften. IT-systemen gaan doorgaans lang mee, veel langer vaak dan oorspronkelijk begroot. Het is dan ook van belang, dat een IT-systeem met de organisatie kan meegroeien. Waarborgen daartoe kunnen worden gegeven door een ruim gebruiksrecht waarbij de aanbestedende dienst of een derde de broncode mag aanvullen en wijzigen.

Transparantie:

Opdrachtgever wil inzage hebben in de werking van de software. Het moet om redenen van veiligheid en privacy mogelijk zijn de software op ieder moment tot op ieder niveau te (laten) controleren; Het Voorschrift Informatiebeveiliging Rijksdienst – Bijzondere Informatie (VIR-BI) omvat regels voor de beveiliging van bijzondere informatie bij de Rijksdienst. Ten aanzien van de ontwikkeling en onderhoud van systemen stelt het VIR-BI als eis dat alle wijzigingen in apparatuur, software of procedures controleerbaar moeten zijn. De beschikbaarheid van de broncode, maakt het mogelijk om wijzigingen in detail te controleren. Daarnaast wordt gewezen op de continuïteitseis en de verplichte code review uit het studierapport ‘beveiliging persoonsgegevens’. Het College Bescherming Persoonsgegevens vereist bijvoorbeeld dat een code review wordt uit gevoerd op systemen die werken met gevoelige persoonsinformatie. Om Trojaanse paarden en/ of geheime communicatiekanalen te voorkomen of op te sporen, stelt de Code voor informatiebeveiliging (Code voor Informatiebeveiliging 2000, Ministerie van Economische Zaken/Ministerie van Verkeer en Waterstaat/Nederlands NormalisatieInstituut) onder andere voor om softwareprogramma’s “aan te schaffen” als broncode. Wanneer de broncode beschikbaar is, kan en moet deze in detail worden geïnspecteerd om ongewenste functionaliteit op te sporen. De beschikbaarheid van de broncode is een voordeel vanuit het perspectief van beveiliging.

Ruime mogelijkheden voor hergebruik:

Opdrachtgever wil dat zijn investering van publieke middelen niet alleen aan hemzelf, maar ook aan een breder publiek ter beschikking staat. Derde partijen moeten daarom vrij zijn om de software te gebruiken.


5.1.3 Selectiefase Specifieke wens voor OSS-leveranciers: betrokkenheid bij ontwikkelgemeenschap

wijze van puntentoekenning

classificatie

Leverancier is actief betrokken bij de ontwikkelgemeenschap(pen) van de open source software welke hij in zijn oplossingen aanbiedt. Dit uit zich in het aantal ontwikkelaars uit de ontwikkelgemeenschap van de oplossingen welke hij aanbiedt dat hij in dienst heeft.

Leverancier heeft geen ontwikkelaars met ‘commit’ status in dienst;

0

Leverancier heeft niet meer dan drie ontwikkelaars met ‘commit’ status in dienst;

4,5

Leverancier heeft drie of meer ontwikkelaars met ‘commit’ status in dienst.

9

Toelichting: In een selectiefase wordt vooral gekeken of een leverancier wel een passende partner voor de aanbestedende dienst is en of deze inhoudelijk bekwaam genoeg geacht kan worden om een geloofwaardige aanbieder van zijn oplossingen te zijn. Een typische vraag die aan implementatiepartners van klassieke softwarehuizen gesteld wordt is hoe goed de banden met de pakketleverancier zijn. Dit is met name bij open source software minder opportuun en bovenstaande vraag is een voorbeeld van een alternatieve vraag om hetzelfde doel te bereiken: inzicht in de relatie tussen implementatiepartner en de feitelijke ontwikkelaars. Meer nog dan bij andere voorbeelden verdient het aanbeveling om de puntentoekenning per aanbesteding te herzien. Zo is het denkbaar dat het aantal punten wat bij deze wens toegekend wordt lager uitvalt in het geval men graag nieuwe toetreders in een markt ziet. Ook bij het eisen van een minimumscore op deze vraag dient grote terughoudendheid betracht te worden.

Specifieke wens voor OSS-leveranciers: sturing van ontwikkeling


classificatie

Leverancier is actief betrokken bij de ontwikkelgemeenschap van de open source software welke hij in zijn oplossingen aanbiedt. Dit uit zich in het aantal regels code dat hij bijgedragen heeft aan het systeem wat leverancier wil aanbieden.

Leverancier heeft geen code bijgedragen;

0

Leverancier geen code maar een substantiële hoeveelheid documentatie bijgedragen;

4,5

Leverancer heeft ten minste 5% aan de programmacode bijgedragen en tevens documentatie bijgedragen.

9

Toelichting: deze vraag is een aanvulling op hiervoorgaande vraag en de antwoorden bieden inzicht in de kennis welke bij leverancier aanwezig is over de open source oplossingen welke leverancier aanbiedt én van de mate van invloed van leverancier op de ontwikkeling van de software. De dynamiek van open source gemeenschappen is doorgaans minder hiërarchisch van aard als die van een klassieke pakketleverancier en de mate van grip op de richting waarin de software zich ontwikkelt is vaak afhankelijk van de hoeveelheid code die bijgedragen wordt. De hoeveelheid code welke in het verleden is bijgedragen is een indicator van de mate waarin leverancier hier invloed op heeft. Wens 3 Leverancier heeft mechanismes en procedures in zijn organisatie gerealiseerd om de herkomst van de broncode van de software welke hij aanbiedt voor zichzelf vast te stellen. Beschrijf deze mechanismes en procedures.


Toelichting: Omdat het distributiekanaal van open source software betrekkelijk informeel georganiseerd pleegt te zijn, is de beantwoording van deze vraag een indicatie voor de mate van georganiseerdheid van de achterliggende communities en de toegang van leverancier daartoe. Deze vraag is tevens legitiem om aan leveranciers van gesloten software te stellen, het vermogen om de herkomst van de software te traceren is indicatief voor de professionaliteit van een leverancier.

Wens 4


classificatie

Leverancier heeft ervaring met het conform webrichtlijnen inrichten van webapplicaties.

Leverancier geen ervaring met het conform webrichtlijnen inrichten van webapplicaties;

0

Leverancier heeft niet meer dan één maal een webapplicatie conform webrichtlijnen ingericht danwel meerdere malen een webapplicatie conform de W3C standaarden ingericht;

4,5

Leverancer heeft ten minste twee maal een webapplicatie conform webrichtlijnen ingericht.

9

Toelichting: de webrichtlijnen zijn essentieel voor de toegankelijkheid van webapplicaties voor mensen met een visuele beperking. Dit is onderkend in het NUP en het Besluit Kwaliteit Rijksoverheidswebsites. Ook uit hoofde van de Wet gelijke behandeling op grond van handicap of chronische ziekte rust op werkgevers een zorgplicht ten aanzien van de arbeidsomstandigheden voor werknemers met een visuele beperking. Tevens zijn de webrichtlijnen van belang voor de doorzoekbaarheid van overheidswebsites voor zoekmachines en de toegankelijkheid voor webbrowsers van mobiele telefoons en PDA’s. het verplichte karakter speelt sterker in de publieke sector en daarom is het gerechtvaardigd om een voorkeur te hebben voor een leverancier met ervaring op dit gebied. Deze wens is uiteraard uitsluitend van toepassing als de te verwerven informatiesystemen geen webinterfaces hebben.

Wens 5


classificatie

Leverancier heeft het Manifest Open Leveranciers ondertekend.

Leverancier heeft het Manifest Open Leveranciers niet ondertekend.

0

Leverancier heeft het Manifest Open leveranciers ondertekend.

5

Toelichting: het is voor overheden wenselijk om zaken te doen met leveranciers die niet alleen bij één specifieke aanbesteding een open oplossing aanbieden, maar er ook blijk van geven strategisch te kiezen voor een meer open en zakelijke relatie met overheden. De bereidheid om het Manifest Open Leveranciers te onderschrijven is een indicator van een dergelijke strategische keuze. Het blijft vanzelfsprekend de verantwoordelijkheid van de aanbestedende dienst om ook zelfstandig toe te zien op de mate waarin de open intenties van de ondertekenaars van het Manifest Open Leveranciers in de praktijk ten uitvoer worden gelegd.


5.1.4 Gunningsfase 5.1.5 Webrichtlijnen Eis 1: Conformiteit aan webrichtlijnen Alle gebruikersinterfaces welke met behulp van webtechnologieën worden gerealiseerd voldoen aan de webrichtlijnen op het moment van oplevering van het systeem. Toelichting: Bovenstaande eis vindt zijn basis in het Besluit Kwaliteit Rijksoverheidswebsites , de Instructie rijksdienst inzake aanschaf ICT-diensten en ICT producten en het Nationaal Uitvoeringsprogramma (NUP). Het Besluit Kwaliteit Rijksoverheidswebsites is alleen van toepassing op de rijksoverheid. De decentrale overheden hebben zich op 1 november 2008 gecommitteerd aan het NUP. De webrichtlijnen zijn bedoeld om toegankelijkheid van websites voor mensen van een visuele handicap, bruikbaarheid voor andere browsers (bijvoorbeeld op mobiele telefoons) en de doorzoekbaarheid van websites van de overheid te garanderen. Voor websites welke alleen binnen overheden toegankelijk zijn (intranetten e.d.) geldt dat de Wet gelijke behandeling op grond van handicap of chronische ziekte aanknopingspunten biedt om een groot gewicht aan conformiteit aan de webrichtlijnen toe te kennen. In de praktijk kan het voorkomen dat op basis van een marktconsultatie geconstateerd moet worden dat er nog geen standaardoplossingen voorhanden zijn welke conform webrichtlijnen zijn. In dat geval laat het ‘pas toe of leg uit’ principe toe dat afgeweken wordt van de webrichtlijnen als eis. Wel dienen de webrichtlijnen dan nog steeds als (dringende) wens gehanteerd te worden en raden wij aan om een groeipad naar webrichtlijnenconformiteit als eis in de aanbesteding op te nemen. Opgemerkt dient te worden dat de webrichtlijnen per richtlijn een drietal conformiteitsniveau’s kennen, aangeduid met A, AA of AAA. Het verdient aanbeveling om een bewuste keuze te maken ter zake van het gewenste conformiteitsniveau, waarbij A uiteraard als generiek minimum geldt.

5.1.6 Technische onafhankelijkheid


wens 1


classificatie

databaseonafhankelijk en koppelbaar met databases van meerdere leveranciers (zoals bijvoorbeeld Oracle, MS-SQL, PostgrSQL en MySQL), waarbij het de voorkeur geniet dat de software koppelbaar is met zowel closed source als open source databases. De reden hiervoor is gelegen in flexibiliteit en leveranciersonafhankelijkheid. Deze wens wordt beoordeeld op de mate waarin c.q de wijze waarop invulling wordt gegeven aan het gestelde.

De software is slechts koppelbaar met één database;

0

Het systeem is koppelbaar met meerdere closed source databases, óf met meerdere open source databases;

4,5

Het systeem is koppelbaar met meerdere databases, waarvan in ieder geval één open source en één closed source database.

9

wens 2


classificatie

Alle gebruikersinterfaces (inclusief eventuele editors en beheertools) dienen zo veel mogelijk platformonafhankelijk te zijn. Motiveer en geef aan met welke platforms de gebruikersinterfaces in ieder geval compatibel zijn. De wens zal worden beoordeeld op de mate van platform onafhankelijkheid waarbij de voorkeur wordt gegeven aan een volledige dan wel grote mate van platformonafhankelijkheid.

Gebruikersinterfaces zijn platformonafhankelijk;

0

Alle gebruikersinterfaces zijn in zeer beperkte mate platformonafhankelijk (ten minste twee families van besturingssystemen);

3

Alle gebruikersinterfaces zijn in beperkte mate platformonafhankelijk (twee tot vijf families van besturingssystemen);

4,5

Alle gebruikersinterfaces zijn zo veel mogelijk platformonafhankelijk (bijvoorbeeld uitsluitend webinterfaces welke aan de webrichtlijnen voldoen of alle interfaces kunnen op een Posix-compliant besturingssysteem draaien).

9

5.1.7 Leveranciersonafhankelijkheid wens 3


classificatie

Het onderhoud van het systeem en de applicatie(s) die daar onderdeel van uit maken kan door een grote diversiteit aan partijen geleverd worden. Geef aan welke partijen dit zijn en of deze partijen aan leverancier gelieerd zijn. De wens wordt beoordeeld op de mate waarin naast ‘community support’ ook professionele onderhouds- en ondersteuningsdiensten beschikbaar zijn.

Het onderhoud van het systeem en de applicaties welke daar deel van uitmaken kan door slechts één partij geleverd worden of slechts één partij per deelcomponent;

0

Het onderhoud van het systeem en de applicaties welke daar deel van uitmaken kan door een beperkt (<3) aantal partijen geleverd worden;

4,5

Alle gebruikersinterfaces zijn in beperkte mate platformonafhankelijk (twee tot vijf families van besturingssystemen);

9

Toelichting: Bovenstaande drie voorbeeldteksten hebben als voornaamste doel het voorkomen van leveranciersafhankelijkheid en van een vendor lock-in. Een goed opdrachtgever zal bij het opstellen van zijn programma van eisen in ieder geval moeten nadenken over deze punten en zal, indien ze relevant zijn voor het project, een keuze kunnen maken voor het meenemen als eis of als wens. In de praktijk pleegt open source software, indien voorhanden als oplossing voor het gevraagde, hier veelal aan te kunnen voldoen.


wens 4


classificatie

De leverancier van de applicatie kan op basis van vooraf gecommuniceerde heldere (licentie)voorwaarden gebruikers rechten toekennen om het systeem en de applicaties die daar onderdeel van vormen op source code niveau aan te passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden. Beschrijf de procedure en voorwaarden.

De leverancier van de applicatie laat niet 0 toe dat het systeem en de applicaties die daar onderdeel van vormen op enigerlei wijze aan te passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden;

0

De leverancier van de applicatie kan op basis van vooraf gecommuniceerde heldere voorwaarden gebruikers rechten toekennen om het systeem en de applicaties die daar onderdeel van vormen aan te passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden, echter niet op source code 3 niveau;

3

De leverancier van de applicatie kan op basis van vooraf gecommuniceerde heldere voorwaarden gebruikers rechten toekennen om het systeem en de applicaties die daar onderdeel van vormen op source code niveau aan te passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden. Hierbij worden kosten in rekening gebracht of is sprake van één of meerdere beperkingen;

6

De leverancier van de applicatie kan op basis van vooraf gecommuniceerde heldere voorwaarden gebruikers rechten toekennen om het systeem en de applicaties die daar onderdeel van vormen op source code niveau aan te passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden. Hierbij gelden hooguit beperkingen ten aanzien van de bij verdere verspreiding te hanteren licentie.

9

Toelichting: Omdat de open source licentie aan de opdrachtgever ruime rechten geeft en daarmee belangrijke voordelen op het gebied van bijvoorbeeld leveranciersonafhankelijkheid en flexibiliteit kan bieden, kan open source software, of beter gezegd de gebruiksrechten welke een open source licentie aan de gebruiker geeft, vrijwel altijd als wens in een bestek worden opgenomen. Het kan door de opdrachtgever noodzakelijk worden geacht om een dergelijke wens nog nader te onderbouwen. Daarvoor is verderop nog een standaard tekst opgenomen.


wens 5


classificatie

Het systeem en de applicatie(s) die daar onderdeel van uit maken, kent één of meerdere onafhankelijke gebruikersgroepen of vrij toegankelijke gemeenschappen welke zijn/ worden betrokken bij de ontwikkeling van (toekomstige versies van) de applicatie. De wens zal worden beoordeeld op de aanwezigheid van een gebruikersgroep, de onafhankelijkheid van deze gebruikersgroep en de mate waarin de gebruikersgroep invloed heeft of kan hebben op de (verdere) ontwikkeling van de software.

Het systeem en de applicatie(s) die daar onderdeel van uit maken, kent geen gebruikersgroepen;

0

Het systeem en de applicatie(s) die daar onderdeel van uit maken, kent één of meerdere gebruikersgroepen;

3

Het systeem en de applicatie(s) die daar onderdeel van uit maken, kent één of meerdere gebruikersgroepen die onafhankelijk opereren;

6

Het systeem en de applicatie(s) die daar onderdeel van uit maken, kent één of meerdere onafhankelijke gebruikersgroepen welke zijn/worden betrokken bij de ontwikkeling van (toekomstige versies van) de applicatie en het stellen van prioriteiten voor het onderhoud.

9

Toelichting: Bovenstaande wens heeft tot doel om de opdrachtgever via een gebruikersvereniging of een community invloed te kunnen geven op de verdere ontwikkeling van de software waardoor leveranciersafhankelijkheid zal afnemen. In het geval van open source software bestaan er veelal één of meerdere communities en gebruikersverenigingen die betrokken zijn bij de verdere ontwikkeling.

5.1.8 Toekomstbestendigheid wens 6


classificatie

De applicaties in het Systeem laten zoveel mogelijk ruimte voor de keuze van hardware en besturingssysteem. Beschrijf de wijze waarop invulling aan deze wens wordt gegeven.

De applicaties in het Systeem laten geen ruimte voor de keuze van hardware en operating system;

0

De applicaties in het Systeem laten in beperkte mate ruimte voor de keuze van hardware en het operating system;

3

De applicaties in het Systeem laten veel ruimte voor de keuze van hardware en operating system.

6

Toelichting: De opdrachtgever kan met Wens 6 een voorkeur uitspreken voor een Systeem dat op een zodanige wijze is samengesteld dat de keuze van de applicatie(s) geen tot weinig dwingende consequenties heeft voor de keuze van de onderliggende lagen (operatingsystem en hardware). De reden hiervoor is gelegen in eisen van flexibiliteit en leveranciersonafhankelijkheid.


wens 7


classificatie

Opdrachtgever geeft de voorkeur aan oplossingen en producten welke gebruik maken van, danwel ondersteuning geven aan open standaarden. Onder een ‘open standaard’ wordt een standaard verstaan die voldoet aan de volgende kenmerken: 1. De standaard is goedgekeurd en zal worden gehandhaafd door een not-forprofit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.); 2. De standaard is gepubliceerd en over de specificatiedocumentatie van de standaard kan vrijelijk worden beschikt of deze is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om de specificatiedocumentatie te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs; 3. Het intellectuele eigendom – m.b.t. mogelijk aanwezige patenten – van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis; 4. Er zijn geen beperkingen omtrent het hergebruik van de standaard; De wens zal worden beoordeeld op de mate waarin wordt voldaan aan de elementen zoals opgenomen in de definitie van open standaard en de mate waarin het systeem en de applicatie(s) die daar onderdeel van uit maken gebruik maken van open standaarden.

Het systeem en de applicatie(s) die daar onderdeel van uit maken maken geen gebruik van open standaarden;

0

Het systeem en de applicatie(s) die daar onderdeel van uit maken, maken gebruik van standaarden die voldoen aan minimaal drie van de vier kenmerken;

6

Het systeem en de applicatie(s) die daar onderdeel van uit maken, maken deels gebruik van open standaarden en deels gebruik van standaarden die voldoen aan minimaal drie van de vier kenmerken;

4

Het systeem en de applicatie(s) die daar onderdeel van uit maken, maken volledig gebruik van open standaarden.

6

Toelichting: Met Wens 7 wordt tegemoet gekomen aan het algemene streven van de overheid om meer gebruik te maken van open standaarden waardoor op termijn de leveranciersafhankelijkheid zal kunnen afnemen. Indien software gebruik maakt van open standaarden wordt het mogelijk om verschillende leveranciers te betrekken bij de ontwikkeling en implementatie van ICT-systemen die op elkaar aansluiten. Het gebruik van gesloten en niet vrije specificaties voor ICT standaarden brengt vaak belemmeringen met zich mee zoals geheimhoudingsverklaringen en licentieconstructies. Dergelijke beperkingen hinderen de keuze vrijheid voor software (zowel open als gesloten). Dergelijke problemen doen zich niet voor bij open standaarden. Het gebruik van open standaarden werkt daarom drempelverlagend voor de inzet van (Open source) software. Wens 7 vloeit voort uit de motie Vendrik en is als beleidsmiddel opgenomen in de uitvoeringsagenda NOiV en het Nationaal Uitvoeringsprogramma betere dienstverlening en eoverheid (NUP).


Eis 2: intellectuele rechten op maatwerk Het uitgangspunt is dat de volledige intellectuele eigendomsrechten, waaronder het auteursrecht, op nieuwbouw componenten (maatwerk) (d.w.z. inclusief broncode en documentatie) worden overgedragen aan de Opdrachtgever. Een alternatieve mogelijkheid is dat de nieuwbouw componenten ter beschikking worden gesteld aan Opdrachtgever door Opdrachtnemer onder de European Union Public License (EUPL v1.1) of een andere een OSI goedgekeurde open source software licentie of daarmee overeenstemmend, zodat Opdrachtgever het recht heeft de software te kopiëren, verder te verspreiden en aan te (laten) passen. Bij dit criterium spelen overwegingen met betrekking tot aanpasbaarheid, leveranciersonafhankelijkheid, ruime mogelijkheden voor hergebruik, duurzaamheid, transparantie, en de afwezigheid van licentiekosten een rol. Voor een overzicht van OSI goedgekeurde open source licenties zie http://www.opensource.org/ licenses/ Toelichting: Bovenstaande eis vindt zijn basis in de veelal door het Rijk gebruikte ARVODI (inkoopvoorwaarden voor dienstverlening) en de ARBIT en is te beschouwen als een algemeen uitgangspunt bij IT aanbestedingen. Door naast de standaard overdracht van het auteursrecht op nieuwbouwcomponenten nu ook levering onder een open source licentie als extra mogelijkheid te benoemen geeft het leveranciers zelfs meer mogelijkheden dan de ARVODI en de ARBIT. Bij levering onder een dergelijke licentie blijft de leverancier immers zelf de auteursrechthebbende waar hij dat normaal gesproken was verloren aan de opdrachtgever. Let op: het gaat hier niet om standaard software welke al ontwikkeld is en waarop al auteursrechten rusten. Het gaat om echte nieuwbouwsoftware of componenten welke specifiek voor de opdrachtgever gemaakt worden.


Deze brochure is een uitgave van: Ministerie van Economische Zaken, Landbouw en Innovatie Prins Clauslaan 8 Postbus 20401 | 2400 EK Den Haag www.mineleni.nl © Rijksoverheid | juli 2011

Functioneel Aanbesteden OSS. Versie 1

Recommend Documents