APM Toets en Open Source Software. Versie 1

APM Toets en Open Source Software Versie 1

2 | APM Toets en Open Source Software

Inhoud

blz

1 Inleiding

4

1.1 Doelstelling

4

2 Applicatie Portfolio Management Toets

5

2.1 2.2 2.3 2.4 2.5 2.6 2.7

Huidige situatie Plaatsbepaling Open Source Software OSS en EBS Open source tussen Hergebruik en Pakket OSS en maatwerk OSS binnen POR Advies

6 6 7 7 8 9 10

3 APM selectie-traject OSS

11

3.1 Selectie-traject 3.2 Aanbestedingstraject

11 12

4 Bijlage 1 tekstfragmenten open standaarden in aanbesteding

13

4.1 OSS Eisen 4.2 OSS Wensen

14 15

5 Bijlage 2 Open Source Software eis of wens

16

Documenten DYA DYA®: Stap voor stap naar professionele enterprise-architectuur, Berg, M. van den et al, Rijswijk, 2004. OSI Open Source Implementatie strategie, Winia, F. & M. van Nunen, Den Haag, 2008. POR Praktisch ontwikkelraamwerk, Wijnstok, M. et al, Den Haag, 2008. AGG LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software, Dingemans G.M.L. et al, Den Haag, 2009 NOIV Nederland Open in Verbinding Een actieplan voor het gebruik van Open Standaarden en Open Source Software bij de (semi-) publieke sector, Ministerie van EZ, Den Haag, 2007. VOS Het verwerven van Open Source, Pianoo et al, S., Den Haag, 2007.

APM Toets en Open Source Software | 3

1. Inleiding 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. 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 In dit document wordt actielijn 3 uitgewerkt Samenvattend is dit document een uitwerking van onderstaande stelling: - voor LNV het begrip “gelijke geschiktheid” concreet en toepasbaar uitgewerkt en in de inkoopprocedure verankerd, en - is de APM toets uitgebreid met Open Source Software van gelijke geschiktheid ten opzichte van bij LNV in gebruik zijnde software. Het resultaat is dat vaststaat welke bij LNV aanwezige software door OSS van gelijke geschiktheid vervangbaar is en hoe de toetsing geïmplementeerd wordt.

1.1 Doelstelling LNV conformeert zich aan het actieplan Nederland Open in Verbinding. Waar een keuze voor software gemaakt moet worden, wordt OSS meegewogen en bij gelijke geschiktheid bevoordeeld binnen LNV (in de documenten is OSS echter wel steeds apart beschreven, hiervoor is gekozen omdat dit een actuele toevoeging is). Daarbij is LNV géén softwareleverancier, maar wanneer door (of in opdracht van) LNV software ontwikkeld is die, vooral binnen de overheid, breder gebruikt kan worden, dan overweegt LNV deze beschikbaar te stellen in lijn met de European Union Public Licence (EUPL). Doel van dit document is het definiëren van stappen om antwoord te geven op de volgende vraag: Waar staat LNV met Open Source Software eind 2010? Onderstaand de concrete haalbare strategische doelen die bevordering van het gebruik van open source software integreren in LNV. • In alle business cases wordt de afweging tussen open en gesloten source gemaakt volgens een binnen LNV vastgestelde uitwerking van “gelijke geschiktheid”. • Open Source is verankerd in het inkoop-, software- en beheerbeleid. • De maatwerktoepassingen met toekomst, zijn - voor zover mogelijk - beschikbaar gesteld op basis van een Open Source licentie (bijvoorbeeld EUPL). • Het beleid ten aanzien van de vendor-lock-in voor de LNV essentiële closed software binnen LNV is herijkt en verankerd in de applicatieportfolio. • De architectuur richtlijnen zoals opgesteld zijn getoetst in een pilot ontwikkel cq implementatietraject.


2. Applicatie Portfolio Management Toets De toets zoals die wordt uitgevoerd door de afdeling A&S, is een functie binnen LNV die voorziet in het implementeren van een strategie voor software selectie. De functie maakt onderdeel uit van het dienstenpakket van DICTU. A&S adviseert, en toetst aanvragen voor applicaties van alle directies en diensten binnen LNV. In het praktisch ontwikkel raamwerk [POR] worden de volgende uitvoeringspaden voor applicatieselectie onderkend: • eBS (ERP werkprocesimplementatie) • Hergebruik • Pakketselectie • Maatwerk Voor uitvoering van de PIOFAH-taken (Personeel-Informatisering/automatisering-Organisatie-FinanciënAdministratie en Aanschaf-Huisvesting) wordt allereerst uitgegaan van het gebruik van Rijksbrede oplossingen. Wanneer die niet aanwezig zijn wordt achtereenvolgens beoordeeld of hergebruik - EBS – pakket – maatwerk in de behoefte kunnen voorzien. Het uitvoeringspad binnen APM voor deze interne taken is daarmee “Rijksbrede toepassingen – EBS – Pakket – Maatwerk”. Voor uitvoering van publieke taken is het traject “Hergebruik – Pakket of EBS – Maatwerk” met dien verstande dat EBS alleen ingezet mag worden wanneer daar voldoende mapping voor is. EBS op zich kent geen Open Source modules. De EBS-modules zelf kunnen wel Open Source componenten aanroepen. Open Source Software zal binnen deze vier groepen een plaats moeten vinden. In onderstaande paragrafen wordt beschreven op welke momenten Open Source geïntroduceerd kan worden en worden de voor- en nadelen van de verschillende momenten uitgewerkt. Op basis van deze uitwerking wordt een advies gegeven. Wanneer EBS niet geschikt is voor invulling van de functionele behoefte wordt bekeken in hoeverre bestaande pakketten of maatwerk soelaas bieden. De wijze waarop open source hierbij eventueel ingezet kan worden is gelijk voor zowel interne - als publieke taken. Uitgangspunt blijft dat hergebruik (inclusief EBS en Rijksbrede oplossingen) de voorkeur geniet. APMtoetsing voor nieuwe software vindt alleen plaats indien daar vanuit de business om gevraagd wordt of wanneer de levenscyclus van een product is afgelopen.


2.1 Huidige situatie Het praktisch ontwikkelraamwerk [POR] beschrijft het startpunt en de fasering van het informatieplanningstraject. Hierbij wordt de volgende fasering onderkend: • Diagnose (bepalen van de oplossingsrichting) • Strategie (voorbereiden van de uitvoering) • Interventie (doorlopen van het meest geschikte uitvoeringspad) Binnen de strategie fase wordt een uitvoeringspad geselecteerd door APM. Dit wordt gedaan op basis van een “functional fit”. In de onderstaande afbeelding worden de huidige stappen getoond. In de volgende paragraaf zal deze afbeelding als uitgangspunt gebruikt worden voor de plaatsbepaling van OSS.

Afbeelding 1: Huidige uitvoeringspaden Resultaat van “functional fit” binnen de huidige situatie is als volgend. Binnen de huidige situatie doet de “functional fit” uitspraken over de volgende vragen of onderwerpen: • De gevraagde bedrijfstoepassing kan gerealiseerd worden binnen Oracle EBS (ERP). • De functionele vraag kan ingevuld worden met behulp van bestaande applicaties (APM). • De functionele vraag kan ingevuld worden met behulp van op de markt beschikbare applicaties. • Er is een keuze gemaakt over de in te zetten middelen (pakketten, EBS, maatwerk).

2.2 Plaatsbepaling Open Source Software In de vorige paragraaf is aangegeven wat het resultaat is van de functional fit binnen de strategie fase [POR]. Door de uitbreiding met OSS wordt dit resultaat uitgebreid op de volgende wijze: • De gevraagde bedrijfstoepassing kan gerealiseerd worden binnen Oracle EBS (ERP). • De functionele vraag kan ingevuld worden met behulp van bestaande applicaties (APM). • De functionele vraag kan ingevuld worden met behulp van op de markt beschikbare applicaties. • Er is een keuze gemaakt over de in te zetten middelen (pakketten, EBS, maatwerk). Om tot dit resultaat te komen wordt de toets uitgevoerd in de volgorde zoals geschetst in de vorige paragraaf. In onderstaande opsomming wordt aangegeven wat de voor- en nadelen zijn van OSS als “stap” binnen de andere selectiestappen.


2.3 OSS en EBS

Afbeelding2: OSS en EBS Voorzover bekend is Oracle EBS een closed source applicatie waaraan geen Open Source modules toegevoegd kunnen worden. De meeste functionaliteit kan binnen EBS gerealiseerd worden op basis van configuratie van een van de vele standaard-modules. Voor sommige functionaliteitswensen is het echter noodzakelijk dat er communicatie met de omgeving plaatsvindt. Oracle adviseert in diverse white papers om voor de communicatie tussen EBS en de omgeving gebruik te maken van Open Source componenten. Hiermee wordt voorkomen dat in de toekomst weer een vendor lock-in situatie ontstaat.

2.4 Open source tussen Hergebruik en Pakket Binnen dit model wordt eerst onderzocht welke applicaties reeds binnen LNV aanwezig zijn om als oplossing ingezet te worden, vervolgens wordt gezocht naar een OSS oplossing voor de functionele vraag. Deze oplossing zorgt er enerzijds voor dat software hergebruikt kan worden maar dat ook OSS software ingang kan vinden.

Afbeelding 3: OSS tussen hergebruik en pakket


Voordelen: • Hergebruik en kennisopbouw van de bestaande software is geborgd. • Door gecontroleerd het applicatie-aanbod uit te breiden met OSS kan gecontroleerd toegewerkt worden naar een Open Source st.ack Nadelen: • Kosten voor licenties en beheer zullen pas dalen wanneer applicaties aan het einde van hun levenscyclus zijn. • Het is onduidelijk hoe er gereageerd moet worden op nieuwe releases van het her te gebruiken product.

2.5 OSS en maatwerk Wanneer na marktconsultatie blijkt dat er geen Open of Closed Source applicaties beschikbaar zijn kan er een maatwerktraject ingegaan worden. Per applicatie zal bekeken moeten worden in hoeverre het maatwerk realiseerbaar is bij gebruikmaking van Open Source componenten.

Afbeelding 4: OSS en maatwerk Voordelen: • Werkwijze komt overeen met de huidige opzet van de APM toets • Er kan enige besparing plaatsvinden op het moment dat er voor gebruik van OSS componenten gekozen wordt. Nadelen: • Introductie van OSS zal nauwelijks plaatsvinden • De introductie van OSS zal als zodanig nauwelijks herkenbaar zijn.


2.6 OSS binnen POR

Afbeelding 5: OSS en POR Het POR onderscheidt de volgende uitvoeringspaden: a) Uitvoeringspad Hergebruik b) Uitvoeringspad ERP c) Uitvoeringspakket Pakket-oplossing d) Uitvoeringspad Maatwerk Het POR spreekt zich niet uit over de rol die OSS in deze trajecten inneemt. LNV heeft echter wel uitgesproken dat zij zich verbindt aan het actieplan Nederland Open in Verbinding. Uitvloeisel hiervan is dat in elk uitvoeringspad OSS meegenomen moet worden in de oplossings-overwegingen.


2.7 Advies Op basis van de hierboven genoemde voor- en nadelen van de oplossingsrichtingen is het advies om OSS bij iedere stap mee te nemen in de overweging. Door daarbij uit te gaan van het hieronder geschetste stappenplan wordt bereikt dat op elk moment de mogelijkheden die geboden worden door de inzet van OSS, zorgvuldig getoetst worden.

Afbeelding 6. Stroomschema implementatie OSS


3. APM selectie-traject OSS In de bovenstaande paragrafen is beschreven op welke momenten de OSS-toets ingebouwd kan worden binnen de APM-uitvoeringstrajecten. Tevens zijn de voor en nadelen van de diverse mogelijke toetslocaties besproken. In dit hoofdstuk gaan we in op de selectie van Open Source producten binnen APM. Een APM toets begint met een vraag vanuit de directies en diensten van LNV. Soms wordt hierbij al een voorkeur voor een bepaald applicatie aangegeven. De vraag zal in eerste instantie binnen APM echter herleid worden tot een functionele vraag. De gepresenteerde oplossing richt zich primair op invulling van deze vraag. Wanneer blijkt dat er in het geval dat er meerdere softwarepakketten in aanmerking komen voor selectie, zal bij gebleken gelijkheid de voorkeur gegeven worden aan een Open Source alternatief. Bij de APM toets kunnen een tweetal trajecten onderscheiden worden. In het tweede traject wordt voor het vinden van de oplossing een aanbestedingstraject gestart. In onderstaande tabel wordt een samenvattend beeld gegeven van de verschillen tussen selectie en aanbesteding [VOS].

selectie-traject

Aanbestedingstraject

Nadruk op marktonderzoek

Nadruk op specificeren

Kennis (OSS) producten vereist

(Leveranciers)Markt doet voorstel/denkt mee

Dienstverlening kan los worden aanbesteed

Dienstverlening kan in combinatie worden aanbesteed

3.1 Selectie-traject De selectie wordt door A&S uitgevoerd bijvoorbeeld bij het opstellen van een PSA. Voor het uitvoeren van deze activiteiten zal APM specifieke OSS kennis moeten vergaren en tijd moeten krijgen voor het doen van deze (onderzoeks)activiteiten[VOS]. De eerste stap in een selectie-traject is het doen van marktonderzoek. In het geval van closed source programmatuur is vanuit de leverancier meestal een marketingapparaat beschikbaar dat ervoor zorgt dat de software onder de aandacht van potentiële klanten gebracht wordt. Denk hierbij aan foldermateriaal, presentaties en demo’s. Bij OSS is dit marketingapparaat minder ontwikkeld of afwezig. Om productkennis te ontwikkelen op het gebied van Open Source Software zal men daarom vaak aangewezen zijn op internet. Bekende sites voor OSS zijn: • http://sourceforge.net (register van open source producten) • http://freshmeat.net (register van open source producten met name voor Mac OS en Linux) • http://opensourcexs.info (lijst van open source producten ingedeeld naar diverse categorieën) • http://www.osalt.com (vergelijken van gesloten software producten met open source alternatieven. Naast deze onderzoeksactiviteiten die resulteren in een lijst van producten is het aan te bevelen om dit marktonderzoek uit te breiden met een inventarisatie van ervaringen met de geselecteerde producten bij andere (overheids)instellingen.


Op basis van gevonden Open Source producten en eventuele gesloten alternatieven kan de tweede stap uitgevoerd worden, te weten: • de kwaliteitstoets • functionele toets. • TCO toets (Total Cost of Ownership?) Op basis van deze toetsen worden de verschillende producten met elkaar vergeleken. De stappen voor deze activiteit zijn uitgewerkt in LNV architectuurrichtlijn Gelijke Geschiktheid Open Source Software [AGG]. Afhankelijk van de omvang, complexiteit of strategische positie van de software kunnen één of meer toetsen genoemd binnen deze architectuurrichtlijn uitgevoerd worden.

3.2 Aanbestedingstraject Bij een aanbestedingstraject voert niet de afdeling A&S de selectie (marktonderzoek/toetsen) van de software uit, maar wordt dit gedaan door de opdrachtnemer. De geselecteerde software zal dan veelal in combinatie met een aantal andere producten en diensten (zoals installatie en beheer) aangeboden worden [VOS]. Dictu kan hier het standpunt innemen dat de leverancier vrij is in de keuze van open of gesloten software. Dictu kan echter ook hieromtrent eisen stellen en/of aanbevelingen doen omtrent het gebruik van OSS. Dit kan op de volgende manieren gerealiseerd worden: • Opstellen van een bestek • Vereisen van standaarden Standaarden zijn technische specificaties en als zodanig een onderdeel van het pakket van eisen. Standaarden kunnen als eis in het bestek opgenomen worden. Soms zijn er meerdere standaarden die functioneel gelijkwaardig zijn. In het bestek moet daarom het noemen van de naam van de standaard gevolgde worden door de zinsnede ‘of gelijkwaardig’. • Bepalen van een lijst van toe te passen componenten en hulpmiddelen • Vereisen dat standaarden open zijn ten aanzien van het gebruik van open standaarden geldt het principe van ‘comply or explain’. • Bevorderen dat software open source is Het beleidsstandpunt dat bij gelijke geschiktheid open source de voorkeur geniet, kan expliciet als uitgangspunt in het bestek worden opgenomen.


4. Bijlage 1 tekstfragmenten open standaarden in aanbesteding Uit verwerven van Open Source, Eilander, S., Den Haag, 2007. [VOS] 1. Open besluitvormingsprocedure Dit kenmerk zorgt ervoor dat de aanbestedende dienst 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. 2. 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 bevorder lijk 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 kan worden geopend. 3. Geen intellectuele eigendomclaims Voor het gebruik van standaarden worden geen licentiegelden op basis van intellectuele eigendomsrechten in rekening gebracht. De royaltyfree 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. 4. 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. Voor een aanbestedende overheidsorganisatie kan dit betekenen dat de organisaties en instellingen waaraan de aanbestedende overheidsorganisatie gegevens verstrekt of waarvan de aanbestedende overheidsorganisatie gegevens ontvangt geen gebruik kunnen maken van de standaard. In dat geval kan de standaard veel minder toegevoegde waarde hebben voor de aanbestedende overheidsorganisatie. Ook dit kenmerk is een randvoorwaarde voor het implementeren van de standaard in open source software. Een aantal specifieke eisen en wensen met betrekking tot Open Source Software en Open Standaarden zijn hieronder geformuleerd. Voor meer informatie over deze elementen verwijs ik naar www.noiv.nl/ modelteksten


4.1 OSS Eisen 1. 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/ 2. De Opdrachtnemer garandeert Opdrachtgever gedurende een periode van (x) jaar beschikbaarheid en toegankelijkheid van de relevante delen van de broncode van de software van het Systeem voor Opdrachtgever op een dusdanige wijze dat de software als geheel kan worden onderhouden en aangepast door of namens de Opdrachtgever, indien de Opdrachtnemer niet (langer) beschikbaar is (door bijvoorbeeld een faillissement). Die beschikbaarheid en toegankelijkheid kan door middel van een directe beschikbaarheidstelling van de broncode of een Escrow overeenkomst worden gerealiseerd, maar ook andere methoden zijn in principe aanvaardbaar. De Opdrachtnemer is gerechtigd Opdrachtgever een voorstel te doen op dit punt. Bij gebreke van acceptatie van dit voorstel door de Opdrachtgever is de Opdrachtnemer gehouden de beschikbaarheid en toegankelijkheid te realiseren door middel van (een) Escrow overeenkomst(en).


4.2 OSS Wensen 1. 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. 2. Alle gebruikersinterfaces (inclusief eventuele editors en beheertools) dienen zo veel mogelijk platformonafhankelijk te zijn. Motiveer en geef aan met welke platforms de gebruikersinterfaces niet compatibel zijn. 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 de leverancier gelieerd zijn . 4. 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. 5. Het systeem en de applicatie(s) die daar onderdeel van uit maken, kent één of meerdere onafhankelijke gebruikersgroepen of vrij toegankelijke communities welke zijn/worden betrokken bij de ontwikkeling van (toekomstige versies van) de applicatie. 6. De applicaties in het Systeem laten veel ruimte voor de keuze van hardware en operating system. Beschrijf de wijze waarop invulling aan deze wens wordt gegeven. 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: • 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 het specificatie document van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder 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; • De standaard staat op de lijst gepubliceerd door het forum standaardisatie (http://www.forumstandaardisatie.nl/)


5. Bijlage 2 Open Source Software eis of wens Uit verwerven van Open Source, Eilander, S., Den Haag, 2007. [VOS] Indien de overheid behoefte heeft aan het verwerven van software en zij die behoefte invult door middel van een aanbesteding, rijst de relevante vraag of zij daarbij specifiek mag voorschrijven dat zij OSS wenst te verwerven. Met andere woorden, mag OSS als wens of eis worden opgenomen in de aanbestedingsstukken? A.2.i Typering OSS Naar onze mening dienen de verschillende kenmerken van OSS in aanbestedingsrechtelijke zin te worden gekwalificeerd als gunningcriteria en niet als technische specificatie. De definitie van een technische specificatie blijkt uit artikel 1 sub ll Bao. De kern van de definitie (voor overheidsopdrachten voor leveringen en diensten) is dat sprake is van een specificatie ter omschrijving van de vereiste kenmerken van een product of dienst. De kenmerken van OSS zeggen niets over de (technische kenmerken van) software, maar juist iets over de (juridische) gebruiksvoorwaarden. Immers, de kenmerken van OSS hebben betrekking op aspecten als de beschikbaarheid van de broncode en de voorwaarden voor wijziging en verdere verspreiding van de software. Het Bao kent twee soorten gunningcriteria, namelijk de laagste prijs en de economisch meest voordelige inschrijving. Wanneer de overheid ervoor kiest om de offerte te beoordelen op meer elementen dan alleen de prijs, komt zij automatisch uit bij de economisch meest voordelige inschrijving. Het staat de overheid vrij verschillende subcriteria te hanteren ter bepaling van de economisch meest voordelige inschrijving zolang deze maar verband houden met het voorwerp van de aanbesteding. In de toelichting op artikel 54 Bao noemt de wetgever – overeenkomstig Richtlijn 2004/18/EG – als voorbeeld ‘de kwaliteit, de prijs, de milieukenmerken, (…), de datum en de termijn voor levering of uitvoering.’ De (juridische) gebruiksvoorwaarden waarop de kenmerken van OSS betrekking hebben passen bij deze voorbeelden. Ze hebben namelijk betrekking op het voorwerp van de aanbesteding en dienen ter bepaling van de economisch meest voordelige aanbieding.


A.2.ii Randvoorwaarden OSS is geen vaststaand begrip. Het enkele voorschrijven van OSS als eis of wens in een aanbesteding zal daarom niet toegelaten zijn vanwege strijdigheid met het transparantiebeginsel. De overheid zal dus aan de hand van specifieke kenmerken moeten definiëren wat men verstaat onder OSS, wil voor een ieder op dezelfde wijze duidelijk (kunnen) zijn wat de inhoud van de opdracht is. Dan resteert nog de vraag of het wel is toegestaan de kenmerken van OSS als eis of wens te hanteren in een aanbesteding. Het antwoord op die vraag is in die zin kort dat er geen regelgeving is die zulks verbiedt. Wel dienen de volgende randvoorwaarden in acht te worden genomen: De overheid dient bij een aanbesteding de opdracht altijd zo objectief mogelijk te definiëren. De opdracht mag niet worden toegeschreven naar een bepaald product en/of een bepaalde leverancier. Dit vloeit voort uit de beginselen van objectiviteit en non-discriminatie. De overheid kan aan deze beginselen tegemoet komen door op functionele wijze haar behoeftestelling weer te geven in de aanbestedingsdocumentatie. De kenmerken van OSS, in de kern vaak juridisch van aard, dienen naar hun functie te worden bezien. Als juist dit functionele doel wordt weergegeven in de aanbestedingsstukken blijft de kans het grootst dat ook leveranciers van producten waaraan de overheid zelf in eerste instantie wellicht niet had gedacht, kunnen deelnemen aan de aanbesteding. Dit is niet alleen in het belang van de desbetreffende leveranciers, maar ook in het belang van de overheid die immers een ruimere keuze krijgt in besteksconforme oplossingen. De verschillende kenmerken van OSS die in een aanbesteding worden voorgeschreven als wens of eis worden gekwalificeerd als gunningcriteria. Over gunningcriteria zegt het Bao in dit verband niet meer dan dat de criteria verband moeten houden met het voorwerp van de opdracht. Buiten deze concrete regel geldt echter op de achtergrond telkens het zogenaamde proportionaliteitsbeginsel.16 De wensen en eisen die worden gesteld dienen telkens in redelijke verhouding te staan tot hetgeen een aanbestedende dienst door middel van een aanbesteding wenst te verkrijgen en dienen ook niet restrictiever te werken dan noodzakelijk. In wezen is hier sprake van een belangenafweging tussen de belangen van de overheid enerzijds en de belangen van de leveranciers anderzijds. Het proportionaliteitsbeginsel (samen met het transparantiebeginsel) leidt er toe dat de overheid altijd zal moeten kunnen verantwoorden waarom zij een bepaalde wens of eis hanteert, alsook waarom de doelstelling nu juist is weergegeven in de vorm van een eis of juist een wens. Immers, een eis heeft zwaardere gevolgen dan een wens. Een eis heeft namelijk een knock out-karakter. Indien de overheid bij een bepaald kenmerk de verantwoording niet sluitend krijgt, of anders gezegd, indien uit de belangenafweging volgt dat het belang om de wens of eis te stellen minder zwaar is dan een ander aan de markt toebehorend belang, moet de desbetreffende wens of eis achterwege blijven. De vorenbedoelde verantwoording kan bestaan uit verschillende argumenten die veelal zullen zijn gelegen in de behoefte als zodanig en de omstandigheden waaronder die behoefte is ontstaan. Een relevante omstandigheid zou bijvoorbeeld kunnen zijn dat weten regelgeving bepaalde kenmerken van OSS voorschrijft.


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

APM Toets en Open Source Software. Versie 1

Recommend Documents