Modelteksten voor open voorkeur in een (Europese) aanbesteding (NOiV - November 2010)
Inhoudsopgave Modelteksten voor open voorkeur in een (Europese) aanbesteding....................................................................1 Table of Contents................................................................................................................................................2 Modelteksten voor open voorkeur in een (Europese) aanbesteding ...................................................................3 Inleiding .........................................................................................................................................................3 Aanleiding, geschiedenis en verantwoording ...........................................................................................3 Doelstelling en leeswijzer .........................................................................................................................3 Aanbestedingsproces en samenwerking ....................................................................................................4 Structuur ....................................................................................................................................................5 Toelichting beleidsimplicaties van open standaarden en open source software ............................................5 Open standaarden ......................................................................................................................................5 Open source en vrije software ...................................................................................................................6 Selectiefase ....................................................................................................................................................9 Gunningsfase ...............................................................................................................................................12 Webrichtlijnen .........................................................................................................................................12 Technische onafhankelijkheid .................................................................................................................13 Leveranciersonafhankelijkheid ...............................................................................................................15 Toekomstbestendigheid ...........................................................................................................................19
Modelteksten voor open voorkeur in een (Europese) aanbesteding Inleiding Aanleiding, geschiedenis en verantwoording Dit document is tot stand gekomen in het kader van Actielijn 4 (advies bij aanbestedingen) van het Actieplan Nederland Open in Verbinding (hierna: het Actieplan). Als zodanig is dit document de opvolger van het in 2009 gepubliceerde document wat onder redactie van Mr. M.H. Paapst tot stand is gekomen. Niet alleen uit het Actieplan, maar ook uit de vragen die het Programmabureau NOiV vanuit het veld krijgt en de aanbestedingen die ter toetsing worden voorgelegd, blijkt nadrukkelijk dat inkopers en juristen in de praktijk nog zoekende zijn naar wegen om een gelijk speelveld voor open source leveranciers te realiseren. De auteurs van dit document hopen hiermee deze zoektocht te vergemakkelijken en zo mogelijk af te ronden. In deze versie zijn voortgeschreden inzichten naar aanleiding van het daadwerkelijk gebruik alsmede terugkoppeling uit het veld verwerkt waarbij mede gebruik is gemaakt van bijdragen welke door middel van een zogenaamde wiki zijn verzameld. De eindredactie is door Mr. Drs. W.H. van Holst gedaan.
Doelstelling en leeswijzer Onderstaande wensen, eisen en teksten hebben tot doel inkopers van dienst te zijn bij het gestalte geven van de overheidsambities om de leveranciersonafhankelijkheid, flexibiliteit en interoperabiliteit te bevorderen. En wel op een wijze waarmee tegemoet kan worden gekomen aan de uitgangspunten van het actieplan NOiV. Aanbestedende diensten kunnen op basis van de generieke implementatiestrategie, welke op bestuurlijke en strategische hoofdlijnen vastlegt hoe er door een organisatie moet worden omgegaan met open source software, zelf per tekstonderdeel bepalen of zij kiezen voor een wens, een eis of het achterwege laten van een onderdeel. Bij een wens kan men ook de punten classificatie cq het gewicht hierop aanpassen. Een aanbestedende dienst die veel belang hecht aan leveranciersonafhankelijkheid kan aan onderstaande wensen een zwaarder gewicht hangen dan diensten die hier juist weinig belang aan hechten. De hieronder weergegeven keuzes voor een wens of een eis en de daarbij gehanteerde punten classificatie dienen derhalve slechts ter illustratie. Een aanbestedende dienst dient zelf van geval tot geval te beoordelen welke van deze onderdelen relevant of in redelijkheid toepasbaar is. Zo zal de hieronder beschreven “Wens 1” onder het kopje gunningscriteria bijvoorbeeld niet van toepassing zijn bij ICT opdrachten waarbij in het geheel geen gebruik wordt gemaakt van een database. Ook zullen de selectiecriteria welke we aanreiken zelden zinvol zijn in markten waar in het geheel geen open source software aangeboden worden. Ten tijde waarin we dit schrijven zijn er bijvoorbeeld geen open source softwarepakketten bekend op het gebied van vergunningsverlening en salarisadministraties. In zijn algemeenheid verdient het ten zeerste aanbeveling om de modelteksten primair als inspiratiebron te gebruiken en niet zozeer één op één over te nemen. Voor het ene systeem zal het eisen van webrichtlijnen als knock-out eis een volstrekt proportionele eis zijn. Voor een ander systeem kan dit resulteren in het eisen van volledige nieuwbouw door pakketleveranciers, wat ook objectief bezien niet snel in het belang van een aanbestedende dienst zal zijn. In dergelijke gevallen is het zeer wel verdedigbaar dat een aanbestedende dienst deze eis omzet in een eis dat men aan minimaal X van de in totaal 125 webrichtlijnen of een specifieke selectie daarvan (bijvoorbeeld de webrichtlijnen welke van belang zijn voor visueel gehandicapten). Ook het
laten varen van de eis maar het inzetten van een wens kan heel wel verdedigbaar zijn. Het 'pas toe of leg uit' principe laat dit ook toe, mits het geheel met een uitleg gepaard gaat. Het spreekt voor zich dat iedere aanbesteding zijn eigen kenmerken heeft en dat het aan de aanbestedende dienst is om de doelstellingen achter de regels in voor de leverancier transparante eisen en wensen te vertalen. In dit document hebben wij er voor gekozen om generieken eisen en wensen, namelijk eisen en wensen die aan leveranciers van gesloten als van open source software voorgelegd kunnen worden te formuleren alsmede specifieke eisen en wensen, namelijk wensen die uitsluitend aan leveranciers van open source software voorgelegd kunnen worden. Benadrukt moet worden dat dergelijke specifieke eisen en wensen alleen ingezet kunnen worden als vervanging van klassieke eisen en wensen voor leveranciers van gesloten software, dus niet als aanvullende eisen en wensen. Anders zou een situatie ontstaan waarin een cumulatie van ongepaste en gepaste eisen en wensen ontstaat die het speelveld juist ongelijker maakt in plaats van het meer gelijk te maken. Voorts dient voor ogen gehouden te worden dat er een viertal situaties denkbaar is waarbij 'open' aanbesteden een rol speelt, namelijk: 1. bij de verwerving van hardware en/of software in combinatie met complexe diensten, zoals implementatiediensten; bij verwerving van diensten waarbij informatie uitgewisseld dient te worden door middel van een (semantische) standaard, bijvoorbeeld urenverantwoordingen bij de inhuur van personeel; de kale verwerving van gebruiksrechten op software; 2. de kale verwerving van hardware, met hooguit onderhoudscontracten als diensten, bijvoorbeeld de verwerving van multifunctionals. Opgemerkt dient te worden dat dit document zich vooral richt op het eerste scenario, hoewel ook van toepassing op het vierde scenario. De kale verwerving van specifieke licenties is een scenario wat zich uiterst moeizaam verhoudt tot het aanbestedingsrecht. In het geval van gesloten software is het onvermijdelijk dat bij een dergelijke aanbesteding om specifieke productnamen gevraagd wordt, iets wat alleen bij uitzondering is toegestaan. Daarbij zal er soms zelfs van een dusdanige monopoliepositie van licentiegever gesproken kunnen worden dat een Europese aanbestedingsprocedure in het geheel geen zin heeft. In het geval van open source software vindt er geen verwerving onder bezwarende titel plaats en is het aanbestedingsregime als zodanig niet van toepassing.
Aanbestedingsproces en samenwerking Het proces van verwerving van ICT en daarmee ook het proces van het Europees aanbesteden van ICTproducten en -diensten is een bij uitstek interdisciplinair proces. Het vergt een geoliede samenwerking tussen IT- en inkoopafdelingen alsmede die van de juridische ondersteuning van een aanbestedende dienst. Dit proces zal veelal vanuit inkoop aangestuurd worden waarbij de IT-afdeling de technische inhoud voor haar rekening neemt en een eventuele betrokken jurist de juridische borging. De daarvoor vereiste dialoog is dan ook essentieel voor het succes van een aanbesteding. Toegepast op open aanbesteden betekent dit bijvoorbeeld dat van de betrokken IT-experts verlangd kan worden dat zij de technisch-inhoudelijke eisen kunnen formuleren in functionele termen (de 'wat'-vraag) en niet zozeer in de door hen voorziene oplossingen. Zeker als er sprake is van werken onder architectuur is het aan de IT-experts om weer te geven wat de beoogde koppelvlakken van de te verwerven producten of diensten zijn met de rest van de ICThuishouding van de aanbestedende dienst of de buitenwereld van de aanbestedende dienst. De rol van inkoop is die van een kritisch klankbord, zich in de positie van de potentiële inschrijver die op zo veel mogelijk vragen 'ja' wil kunnen zeggen verplaatsend. Daarbij kan het geen kwaad zich te realiseren dat er altijd een nuttig en noodzakelijk spanningsveld zal bestaan tussen functionarissen die uit hoofde van hun technisch-
inhoudelijke hoedanigheid vaak al een oplossing voor ogen hebben en functionarissen die het belang van een organisatie bij keuzevrijheid en het aan kunnen gaan van een zakelijke relatie met toeleveranciers voor ogen hebben. Inkopen is iets anders dan bestellen, zeker bij meer complexe producten en diensten met een hoog innovatietempo in de markt waardoor het bijna per definitie onmogelijk is om, zelfs bij een degelijke marktconsultatie, verrassende nieuwe oplossingen niet over het hoofd te zien.
Structuur De modelteksten zijn gestructureerd naar analogie van de fasering van een niet-openbare Europese aanbesteding, dus met een gescheiden selectie- en gunningsfase. Dit laat toepasbaarheid bij een openbare Europese of een onderhandse aanbesteding onverlet, ook bij deze procedures is het een goede praktijk om selectie- en gunningscriteria te scheiden. Ook bij de meer exotische procedure van de concurrentiegerichte dialoog vindt doorgaanse een duidelijke scheiding tussen selectie- en gunningscriteria plaats, al zal de toepasbaarheid van deze teksten in het geval van een dergelijke procedure wellicht lager liggen. Daarbij verdient het aanbeveling om leveranciers te informeren over de uitgangspunten en de achterliggende motieven van de aanbestedende dienst om een open voorkeur te hebben. Ook daarvoor bevat dit document een aantal voorbeeldteksten, waarmee we de eigenlijke inhoud van dit document mee laten beginnen.
Toelichting beleidsimplicaties van open standaarden en open source software Het verdient de aanbeveling om in de aanbestedingsdocumenten afzonderlijk op te nemen waarom de opdrachtgever door middel van de gunningscriteria een voorkeur heeft ten aanzien van open standaarden en open source software. Daarbij kan gedacht worden aan de volgende tekst of onderdelen daarvan:
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.
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 Normalisatie-Instituut) 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.
Selectiefase Specifieke wens voor OSSleveranciers: 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 0 'commit' status in dienst; Leverancier heeft niet meer dan drie ontwikkelaars met 'commit' status in dienst;
4,5
Leverancer 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 OSSleveranciers: sturing van ontwikkeling 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.
wijze van puntentoekenning
classificatie
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
wijze van puntentoekenning
classificatie
Leverancier geen ervaring met het conform webrichtlijnen inrichten van webapplicaties;
0
Leverancier heeft ervaring met het conform webrichtlijnen inrichten van webapplicaties.
Leverancier heeft niet meer dan één maal 4,5 een webapplicatie conform webrichtlijnen ingericht danwel meerdere malen een webapplicatie conform de W3C standaarden ingericht;
Leverancer heeft ten minste twee maal een webapplicatie conform webrichtlijnen 9 ingericht. 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
wijze van puntentoekenning
classificatie
Leverancier heeft het Manifest Open Leveranciers niet ondertekend.
0
Leverancier heeft het Manifest Open leveranciers ondertekend.
5
Leverancier heeft het Manifest Open Leveranciers ondertekend.
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.
Gunningsfase 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.
Technische onafhankelijkheid Wens 1
wijze van puntentoekenning
classificatie
De software is zoveel mogelijk 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 0 database; Het systeem is koppelbaar met meerdere closed source databases, óf met meerdere 4,5 open source databases; Het systeem is koppelbaar met meerdere databases, waarvan in ieder geval één open source en één closed source database.
Wens 2
wijze van puntentoekenning
9
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 3 minste twee families van besturingssystemen); Alle gebruikersinterfaces zijn in beperkte mate platformonafhankelijk (twee tot vijf 4,5 families van besturingssystemen); Alle gebruikersinterfaces zijn zo veel mogelijk platformonafhankelijk (bijvoorbeeld uitsluitend webinterfaces welke aan de webrichtlijnen voldoen of alle interfaces kunnen op een Posixcompliant besturingssysteem draaien).
9
wijze van puntentoekenning
classificatie
Leveranciersonafhankelijkheid Wens 3 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. e wens wordt beoordeeld op de mate waarin naast 'community support' ook professionele onderhouds- en ondersteuningsdiensten beschikbaar zijn. Het onderhoud van het systeem en de 0 applicaties welke daar deel van uitmaken
kan door slechts één partij geleverd worden of slechts één partij per deelcomponent; Het onderhoud van het systeem en de applicaties welke daar deel van uitmaken 4,5 kan door een beperkt (<3) aantal partijen geleverd worden; Het onderhoud van het systeem en de applicaties welke daar deel van uitmaken kan door een meer dan drie partijen 9 welke in de Nederlandse markta actief zijn geleverd worden; 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
wijze van puntentoekenning
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 0 wijze aan te passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden; 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,
3
echter niet op source code 3 niveau; 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 6 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; 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 9 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. 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 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.
wijze van puntentoekenning
classificatie
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.
Toekomstbestendigheid Wens 6
wijze van puntentoekenning
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 0 operating system; De applicaties in het Systeem laten in beperkte mate ruimte voor de keuze van 3 hardware en het operating system; 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 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.); 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; Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis; 2. 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.
wijze van puntentoekenning
classificatie
Het systeem en de applicatie(s) die daar onderdeel van uit maken maken geen 0 gebruik van open standaarden; Het systeem en de applicatie(s) die daar onderdeel van uit maken, maken gebruik 6 van standaarden die voldoen aan minimaal drie van de vier kenmerken; Het systeem en de applicatie(s) die daar onderdeel van uit maken, maken deels gebruik van open standaarden en deels 4 gebruik van standaarden die voldoen aan minimaal drie van de vier kenmerken; Het systeem en de applicatie(s) die daar onderdeel van uit maken, maken volledig 6 gebruik van open standaarden. 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
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.
