Mr. M.H.Paapst Open voorkeur in een aanbesteding Deel III: Modelteksten Onderstaande wensen, eisen en teksten hebben tot doel de leveranciersonafhankelijkheid, flexibiliteit en interoperabiliteit te bevorderen op een wijze waarmee tegemoet kan worden gekomen aan de uitgangspunten van het actieplan NOiV. Aanbestedende diensten kunnen op basis van de generieke implementatiestrategie, die 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 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 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 1 bijvoorbeeld niet van toepassing zijn bij ICT opdrachten waarbij in het geheel geen gebruik wordt gemaakt van een database. 1 De software is zoveel mogelijk database-onafhankelijk 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. De software is slechts koppelbaar met één database; Het systeem is koppelbaar met meerdere closed source databases, óf met meerdere open source databases; Het systeem is koppelbaar met meerdere databases, waarvan in ieder geval één open source en één closed source database; 4,5 Deze wens wordt beoordeeld op de mate waarin c.q de wijze waarop invulling wordt gegeven aan het gestelde.
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. 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. Alle gebruikersinterfaces zijn niet platformonafhankelijk; Alle gebruikersinterfaces zijn in zeer beperkte mate platformonafhankelijk; Alle gebruikersinterfaces zijn in beperkte mate platformonafhankelijk; Alle gebruikersinterfaces zijn zo veel mogelijk platformonafhankelijk. 6 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. De wens wordt beoordeeld op de mate waarin er naast community support ook professioneel support mogelijk is door van de leverancier onafhankelijke onderhoudsbedrijven. maken kan niet of door slechts 1 partij geleverd worden; maken kan door een beperkt (<) aantal partijen geleverd worden; maken kan door een grote diversiteit aan partijen geleverd worden; maken kan door een grote diversiteit aan van de leverancier onafhankelijke partijen geleverd worden. 6 Toelichting: Bovenstaande drie voorbeeldteksten hebben als voornaamste doel het voorkomen van leveranciersafhankelijkheid en van een vendor lockin. 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. Open source software zal hier in veel gevallen aan kunnen voldoen. 4 De leverancier van de applicatie kan op basis van vooraf gecommuniceerde heldere (licentie)voorwaarden De leverancier van de applicatie laat niet toe dat het systeem en de applicaties die daar onderdeel van vormen op enigerlei
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. 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, echter niet op source code 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 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 passen aan de eigen wensen dan wel deze verder te ontwikkelen of verder te verspreiden. Hierbij gelden geen beperkingen. 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. 5 onderdeel van uit maken, kent 1 of meerdere onafhankelijke gebruikersgroepen of vrij toegankelijke communities 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. onderdeel van uit maken, kent geen gebruikersgroepen; onderdeel van uit maken, kent 1 of meerdere gebruikersgroepen; onderdeel van uit maken, kent 1 of meerdere gebruikersgroepen die onafhankelijk opereren; onderdeel van uit maken, kent 1 of meerdere onafhankelijke gebruikersgroepen welke zijn/worden betrokken bij de ontwikkeling van 6
(toekomstige versies van) de applicatie. 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. 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. De applicaties in het Systeem laten geen ruimte voor de keuze van hardware en operating system; De applicaties in het Systeem laten in beperkte mate ruimte voor de keuze van hardware en het operating system; De applicaties in het Systeem laten veel ruimte voor de keuze van hardware en operating system. 4,5 Toelichting: De opdrachtgever kan met 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 (operating system en hardware). De reden hiervoor is gelegen in eisen van flexibiliteit en leveranciersonafhankelijkheid.
Open standaarden: 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.); 2. 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; 4. Er zijn geen beperkingen omtrent het hergebruik van de standaard; onderdeel van uit maken maken geen gebruik van open standaarden; onderdeel van uit maken, maken gebruik van standaarden die voldoen aan minimaal drie van de vier kenmerken; onderdeel van uit maken, maken deels gebruik van open standaarden en deels gebruik van standaarden die voldoen aan minimaal drie van de vier kenmerken; onderdeel van uit maken, maken volledig gebruik van open standaarden. 6 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 maken gebruik maken van open standaarden. Toelichting: Met 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. 7 vloeit voort uit de motie Vendrik en is als beleidsmiddel opgenomen in de uitvoeringsagenda NOiV en het Nationaal Uitvoeringsprogramma betere dienstverlening en e- overheid (NUP).
Intellectueel eigendomsrechten en escrow: Eis 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/> Toelichting: Bovenstaande eis vindt zijn basis in de veelal door het Rijk gebruikte Arvodi voorwaarden voor dienstverlening 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. 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 nieuwbouw software of componenten welke specifiek voor de opdrachtgever gemaakt worden. Eis 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). Toelichting: Dit laatste voorbeeld gaat in op het aspect van goed opdrachtgeverschap en ook hier kan een keuze gemaakt worden voor het meenemen als eis of als wens. Een opdrachtgever zal op voorhand rekening moeten houden met een mogelijkheid dat een leverancier failliet gaat of bijvoorbeeld besluit zijn bedrijf te beëindigen. Om in dergelijke gevallen zekerheid te hebben voor de continuïteit kan in het geval van proprietary gesloten software gekozen worden voor een escrow regeling. De extra kosten voor een escrowregeling dienen uiteraard te worden meegenomen bij de uiteindelijke beoordeling van de inschrijvingen. In het geval van open source software is een
dergelijke escrowregeling niet noodzakelijk omdat er bij open source software sprake is van een directe beschikbaarheidstelling van de broncode.
Algemene onderbouwing Open standaarden & 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: Opdrachtgever acht het om de volgende redenen van belang dat aangeboden oplossingen gebruik maken van open standaarden. Open standaard: 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 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. 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: Opdrachtgever acht het om de volgende redenen van belang om te beschikken over de broncode van de software en het recht te hebben om deze zelf te gebruiken, verder te verspreiden, aan te passen of deze te laten aanpassen door iedere derde partij. 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 kunnen derde partijen hiervan kennis nemen, en is de drempel voor deze partijen 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 2, 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.