Open Source Software in perspectief

Artikel

Open Source Software in perspectief Wout Schiphors en Alexander Stuivenwold

In dit artikel wordt het fenomeen open source software toegelicht en zijn de specifieke risico’s die samenhangen met het gebruik ervan onder de loep genomen. Tevens is de rol van de IT-auditor in het selectietraject en bij het gebruik en beheer van open source toepassingen beschreven. Want dat IT-auditors te maken krijgen met open source software is evident. Kleinschalige en experimentele projecten maken steeds meer plaats voor serieuze en bedrijfsbrede implemen-

Wat is open source software? Een van de meest in het oog springende kenmerken van open source software (OSS) is dat zij op legale wijze kosteloos verkrijgbaar is. Toch kan niet ieder programma dat gratis via het Internet beschikbaar is, gekenmerkt worden als ’open source’. In navolging van het Open Source Initiative [1] verstaan we onder open source software: programmatuur waarvan de broncode openbaar is, waarbij geen beperkingen gelden ten aanzien van gebruik en verdere verspreiding van de software en die – afhankelijk van de licentie – onder bepaalde voorwaarden aangepast mag worden. Zie ook het tekstkader.

taties. Uit bovenstaande definitie blijkt dat OSS haaks staat op gesloten programmatuur, waarvan de broncode geheim is en waarbij het kopiëren en verspreiden van de software niet is toegestaan. De opmars van OSS in de laatste jaren mag verbazing wekken in een maatschappij waar het vrije markt denken overheerst. Om dat te begrijpen, zullen we terug moeten gaan in de tijd [2]. Historische achtergrond

Drs W. (Wout) Schiphorst is

A.P. (Alexander) Stuivenwold

sinds april 2005 werkzaam

RE RO is organisatie

als zelfstandig organisatie-

adviseur en partner bij

adviseur op het gebied van

Hoffman Krul & Partners.

risicobeheersing in bedrijfs-

Hij heeft ruime ervaring

processen in het algemeen

als IT auditor en wordt in

en in combinatie met

toenemende mate met

informatietechnologie in

open source software

het bijzonder. Daarnaast

vraagstukken bij klanten

is hij als testmanager aan

geconfronteerd.

het open source project Lx-Office verbonden.

Beide auteurs hebben het artikel op persoonlijke titel geschreven.

In de begindagen van het computertijdperk speelde de hardware een overheersende rol, de software was een nevenproduct dat door de hardwareleveranciers erbij werd geleverd of die door de gebruikers zelf werd geprogrammeerd. In de jaren zestig en zeventig zien we dat de programmatuur steeds belangrijker wordt door een aantal technologische ontwikkelingen, zoals timesharingsystemen, de derde generatie taal ’C’, het daarin geschreven besturingssysteem Unix en de opkomst van communicatietechnologieën. Er ontstaat een zogenaamde ’hacker-cultuur’ van mensen die gefascineerd zijn door de nieuwe technologie en gezamenlijk programma’s schrijven. Dat de broncode van programma’s openbaar is, is niet meer dan vanzelfsprekend en zelfs een voorwaarde om ideeën en kennis uit te wisselen. Deze manier van werken werd bovendien in de hand gewerkt vanwege de bijzondere status van Unix. Hoewel dit besturingssysteem toebehoorde aan het bedrijf AT&T, kon deze de rechten hierop niet te gelde maken vanwege een kartelrechtelijke uitspraak. De technologische ontwikkelingen schreden voort en leidden tot steeds kleinere computers, die uitgerust werden met nieuwe, gesloten besturingssystemen. De hacker-gemeenschap werd min of meer uitgesloten van deze ontwikkelingen, temeer omdat leveranciers strenge eisen stelden aan het gebruik van deze nieuwe computers. Begin jaren tachtig volgde een nieuwe kartelrechtelijke uitspraak ten aanzien van AT&T: het bedrijf wordt opgesplitst en de afzonderlijke

8 | de EDP-Auditor nummer 1 | 2006

Nadere definitie open source software Andere elementen in de definitie van open source software zijn dat in de licentie het vrije gebruik van de software niet beperkt mag worden door verwijzingen naar andere licenties en het vrije gebruik niet afhankelijk mag worden gesteld van de toepassing van andere software. De licentie mag verder niet verlangen dat de ontwikkeling van de software zich beperkt tot een bepaalde technologie. In het geval open source software verspreid wordt

den de nieuwe leden er meer pragmatische ideeën op na. Enkele kopstukken binnen de gemeenschap probeerden de ideologische stroming en de commerciële belangen van de IT-industrie met elkaar te verzoenen, hetgeen in 1997 tot uitdrukking komt in de oprichting van het Open Source Initiative (OSI). Het OSI ontwikkelde vervolgens in samenwerking met de IT-industrie de open source definitie, waarmee we dit hoofdstuk geopend hebben alsmede een open source certificeringsprogramma.

met andere programma’s, mag de open source licentie niet eisen dat voor die andere software dezelfde (open source) voorwaarden

Netscape: van closed naar open source

gelden. Een laatste eis ten aanzien van open source software is

Historisch gezien vormen gesloten en openbron software twee gescheiden werelden. Daarom baarde in 1998 de stap van Netscape veel opzien, doordat het zijn voorheen gesloten browser-software vrij gaf aan de open source gemeenschap. Later zouden meer bedrijven, zoals IBM en Sun, volgen en zorgen voor een stroomversnelling en een bredere acceptatie van OSS in het bedrijfsleven.

dat niemand van de ontwikkeling ervan uitgesloten mag worden.

onderdelen mogen weer concurreren op de markt. Als logische consequentie werden de commerciële licenties voor Unix vervolgens fors verhoogd. De ontwikkeling van Unix werd bovendien gesplitst in gesloten Unix-varianten en het zogenaamde BSD-Unix van de universiteit Berkeley, dat wel vrij verspreid mocht worden. Door de sterke groei van personal computers met gesloten besturingssystemen stond de Unix-markt als geheel echter in toenemende mate onder druk. De ideologische stroming

In reactie op de steeds verdergaande commercialisering van de IT-markt en de daarmee gepaard gaande beperkingen voor gebruikers, richt Richard Stallman in 1985 de Free Software Foundation (FSF) op, de eerste mijlpaal in de geschiedenis van open source software. Deze stichting stelt zich ten doel de filosofie van vrije software te promoten en een platform te zijn voor programmeurs van deze software. De FSF wordt beschouwd als een politiek-georiënteerde, ideologische en anti-commerciële stroming binnen de open source gemeenschap. Het eerste project van de FSF was een volledig vrij besturingssysteem ter vervanging van Unix te ontwikkelen, het zogenaamde GNU (GNU Not Unix). Om het nieuwe systeem vrij te laten blijven, waren specifieke licentievoorwaarden nodig. Stallman nam het Amerikaanse copyright als uitgangspunt en keerde vervolgens iedere bepaling om (’copyleft’), wat in 1989 uitmondde in de GNU General Public Licence (GPL). In de loop van de tijd werden talloze Unix-programma’s herschreven, op het belangrijkste bestanddeel van een besturingssysteem na: de kernel. De pragmatische stroming

In 1991 slaagde Linus Torvalds er als eerste in een vrije Unixkernel te ontwikkelen. Hoewel geen lid van de FSF, besloot Torvalds de kernel onder de GPL ter beschikking te stellen. In de jaren daarna werkten duizenden vrijwilligers wereldwijd aan de samenvoeging van de GNU-programma’s en de kernel tot één functionerend systeem: Linux. Het ontstaan van Linux heeft voor een sterke uitbreiding en verbreding van de open source gemeenschap gezorgd. In tegenstelling tot de FSF hiel-

Software-octrooien

Sinds het einde van de jaren negentig is binnen Europa gediscussieerd over de mogelijke patentering van softwarematige uitvindingen, zoals dat ook in de Verenigde Staten mogelijk is [3]. Voorstanders van OSS maakten hiertegen bezwaar, omdat hiermee – anders dan het auteursrecht – software-functionaliteit zodanig beschermd kan worden, dat realisatie van dezelfde functionaliteit op een andere manier verboden kan worden. In juli 2005 heeft het Europees Parlement echter definitief het wetsvoorstel inzake softwareoctrooien afgewezen, waarmee een belangrijke barrière voor de ontwikkeling en toepassing van OSS is weggenomen. Ontwikkeling van open source software

Open source software ontstaat veelal met een idee van een programmeur, die tegen een bepaald probleem aanloopt, dat hij met een nieuw programma wil oplossen. De programmeur schrijft een eerste versie: instabiel, onvolledig en slecht gedocumenteerd, maar wel met een duidelijke, modulaire structuur. Een modulaire structuur is een belangrijke voorwaarde om later nieuwe ontwikkelaars aan te trekken. Immers, bij de ontwikkeling van OSS zijn wereldwijd mensen betrokken, die vaak in deeltijd, op vrijwillige basis en zonder direct onderling contact hun bijdrage leveren. Een modulair ontwerp maakt dan een losse organisatie mogelijk, nieuwkomers kunnen de code snel begrijpen en bij aanpassingen van een deel kan de rest van de programmatuur ongewijzigd blijven. Oefent daarnaast de nieuwe software voldoende aantrekkingskracht uit op gebruikers en ontwikkelaars, dan staat de sprong naar een volwaardig project niets meer in de weg. Het project

Een open source project bestaat in de eerste plaats uit gemotiveerde leden, die in tegenstelling tot commerciële projecten niet door geld, maar door andere zaken gedreven worden. De leden halen hun motivatie uit het program-


meren an sich en de daarmee samenhangende intellectuele uitdaging, het feit dat hun code door andere mensen gebruikt wordt en de erkenning alsmede de sociale status binnen de groep van programmeurs. Het spreekt voor zich dat wanneer mensen op vrijwillige basis aan een project meewerken, sturing en coördinatie ook op een geheel andere wijze plaatsvinden dan wanneer zij hiervoor betaald zouden worden. Overigens komt het ook voor dat bepaalde leden geld proberen te verdienen met OSS. In de praktijk levert dit vaak spanningen op met de leden die in hun vrije tijd aan het project bijdragen. De organisatie richt zich over het algemeen naar diegenen die het meest aan het project bijdragen (meritocratie). Hoewel uitzonderingen op de regel bestaan, is dat vaak de oprichter van het project, die als ’benevolent dictator’ (vrij vertaald: verlichte despoot) gekenmerkt wordt. De oprichter neemt de rol van projectleider op zich en is degene die belangrijke beslissingen over het project neemt, bijvoorbeeld welke wijzigingen in de volgende versie opgenomen worden. In de regel geniet de oprichter een hoog aanzien in de groep en worden zijn beslissingen gerespecteerd. De oprichter verzamelt een kleine groep van kernontwikkelaars om zich heen, die ieder hun eigen aandachtsgebied hebben. Omdat de software veelal modulair opgebouwd is, ontstaan voor specifieke onderwerpen ’zelfsturende teams’. In deze teams zitten ook programmeurs en gebruikers, die minder intensief een bijdrage leveren. Deze projectstructuur is gevisualiseerd in Afbeelding 1. Bij grote projecten wordt vaak een

stichting opgericht om de ontwikkeling minder afhankelijk te maken van enkele personen. In de praktijk komen afsplitsingen van projecten voor. Deze afsplitsingen, ook wel ’forks’ genoemd, zijn het gevolg van een breuk binnen de oorspronkelijke projectgroep, waarbij een aantal leden het vertrouwen in de projectleiding opzegt en een nieuw, concurrerend project begint. Forking wordt in de open source gemeenschap normaal gesproken afgewezen, omdat de beschikbare capaciteit dan verdeeld moet worden over meerdere projecten, ontwikkeling en ondersteuning lastiger wordt en de projectorganisatie alle aandacht opeist in plaats van waar het uiteindelijk om gaat: de ontwikkeling van nieuwe software. Wel kan gesteld worden, dat het risico op afsplitsingen de huidige projectleiding scherp houdt. Naast gemotiveerde leden en sturing is de technische infrastructuur op het Internet een andere belangrijke pijler van een open source project. Via de infrastructuur communiceren de leden met elkaar en wordt de ontwikkeling gecoördineerd. Bij vrijwel ieder project komen we in de infrastructuur de volgende onderdelen tegen: • website, fungeert als startpunt voor iedere nieuwe geïnteresseerde in het project, alsmede voor de bekendmaking van nieuws en het maken van reclame • mailinglijsten en nieuwsgroepen, voor de communicatie tussen ontwikkelaars en gebruikers over de (ontbrekende) functionaliteit van de software en de wijze waarop ontwikkeling plaats moet vinden

Afbeelding 1 | Organisatie van een open source project

,EDENDIEINCIDENTEEL EENBIJDRAGELEVEREN

+ERNONTWIKKELAARS

/PRICHTERS

/VERIGENDIEZICH VOORHETPROJECT INTERESSEREN

,EDENDIEREGELMATIG EENBIJDRAGELEVERENAAN HETSPECIFIEKONTWERP

/NTWIKKELAAR SPECIFIEK ONTWERP


,EDENDIEINCIDENTEEL EENBIJDRAGELEVEREN VOORHETSPECIFIEKONTWERP

• foutregistratie (‘bug tracking’), veelal een webgebaseerde applicatie waar fouten in de software gemeld kunnen worden en waar tevens de afhandeling ervan geregistreerd wordt • versiebeheer, hulpmiddel om wijzigingen ten opzichte van vorige versies te registreren en om verschillende versies van verschillende programmeurs met elkaar samen te voegen • documentatie, zoals technische ontwerpdocumenten en handleidingen voor de installatie en gebruik van de software; vaak onderdeel van de website • forum, waar gebruikers vragen kunnen stellen die door andere gebruikers en projectmedewerkers beantwoord worden; vaak eveneens onderdeel van de site Het ontwikkelproces is het laatste onderdeel van een open source project. Ook hier speelt een modulair ontwerp een belangrijke rol, omdat dit een parallelle ontwikkeling in onafhankelijke groepen mogelijk maakt. Kenmerkend voor een open source project is verder dat gebruikers een belangrijke rol spelen bij het testen en het opsporen van fouten. In plaats van een gestructureerd, top-down testplan, proberen honderden tot duizenden gebruikers bottom-up de software uit en koppelen de gevonden fouten aan het project terug; eventueel zelfs met een oplossing. In vergelijking met gesloten software worden fouten in OSS op deze manier sneller verholpen. Vaak zien we dat een project onderscheid maakt tussen een stabiele versie van de software – gericht op de inzet in productie-omgevingen – en een ontwikkelversie, waar de nieuwste functies zijn ingebouwd, maar waarvan niet gegarandeerd is dat zij vrij is van fouten. De kathedraal en de bazaar

Deze vorm van systeemontwikkeling, als samenstel van vrijwillige en gemotiveerde leden, sturing en coördinatie door de oprichter, de bijbehorende technische infrastructuur via het Internet en het ontwikkelproces zelf, wordt in de literatuur aangeduid als het bazaarmodel [4]. Als handelaren op een open bazaar wisselen ontwikkelaars programmacode uit en vindt veel interactie plaats tussen gebruikers en programmeurs (geven en nemen van software, ondersteuning, nieuwe ideeën, testresultaten). Over het algemeen kan gesteld worden dat het bazaarmodel een sterk bottom-up karakter heeft. Een uitzondering geldt voor het initiële ontwerp van de software, dat van begin af aan goed geregeld moet zijn. Tegenover het open bazaarmodel staat het gesloten kathedraalmodel, dat de traditionele systeemontwikkeling zoals de watervalmethode beschrijft. Deze vorm van systeemontwikkeling wordt gekenmerkt door een strakke, hiërarchische organisatie in een geïsoleerde en gesloten omgeving. Daarnaast worden de spelers geleid door economische motieven, die kunnen leiden tot het treffen van maatregelen om concurrenten uit de markt te houden met bijvoorbeeld octrooien en gesloten standaarden en bestandsformaten. Overigens worden bepaalde elementen van OSS-ontwikkeling wel meer toegepast in gesloten projecten binnen organisaties, denk bijvoorbeeld aan Rapid Application Development als systeemontwikkelingsmethode.

Volgens het OSI leidt deze evolutionaire vorm van systeemontwikkeling tot betere software dan in het traditionele model

Is het bazaarmodel nu beter dan het kathedraalmodel? Het OSI zegt hierover dat indien programmeurs de broncode kunnen lezen, verspreiden en veranderen voor een bepaalde toepassing, de software zich ontwikkelt. Verschillende mensen verbeteren het programma, passen het aan en halen de fouten eruit; vaak zelfs in een sneller tempo dan bij traditionele systeemontwikkeling. Volgens het OSI leidt deze evolutionaire vorm van systeemontwikkeling tot betere software dan in het traditionele model, waarbij slechts enkelen toegang tot de broncode hebben en anderen alleen de buitenkant van de software kunnen beoordelen. Door de open broncode is peer review mogelijk (de kwaliteitsmaatregel bij OSS) en kan iedereen fouten corrigeren. Een laatste argument voor evolutionaire systeemontwikkeling is dat een project normaal gesproken niet onder tijdsdruk staat. Het ontbreken van deadlines werkt kwaliteitsbevorderend, omdat in alle rust de programmatuur ontwikkeld en getest kan worden, voordat zij als stabiele versie wordt uitgebracht. Licentievormen

Waar licenties van gesloten software de rechten van de eigenaar moeten waarborgen, zijn licenties van open source software gericht op het garanderen van de vrijheid van de programmatuur. Er bestaan vele vormen van open source licenties. Kenmerkend voor alle licenties is dat zij geen garantie bieden voor het gebruik van de software, omdat zij anders niet gratis aangeboden kan worden. Enkele van de meest voorkomende licenties zijn hieronder opgesomd: • GPL (GNU General Public Licence): de meest bekende en meest toegepaste licentie; heeft ’virale werking’ doordat zij voorschrijft dat bij hergebruik van de code de nieuwe software per definitie ook onder de GPL valt; • LGPL (GNU Lesser/Library General Public Licence): licentie oorspronkelijk bedoeld voor verzameling van functies (bibliotheken); heeft geen virale werking; • BSD-licentie: oorspronkelijk opgesteld om het gebruik van BSD-Unix te regelen; software mag op welke wijze dan ook gebruikt en gekopieerd worden (’copycenter’), zolang maar een verwijzing wordt opgenomen naar degenen die aan de software hebben bijgedragen;


projecten maken we onderscheid naar de aanbod- en vraagkant.

• NPL/MPL (Netscape/Mozilla Public Licence): deze licenties schrijven voor dat wijzigingen van de broncode onder dezelfde licentie vallen, maar dat het gebruik van uitbreidingen (in afzonderlijke bestanden) in andere licenties geregeld mag worden; de NPL geeft een bedrijf als Netscape bijzondere rechten voor het gebruik van codeonderdelen, de MPL kent deze bepalingen niet; is later door andere ondernemingen toegepast om hun eigen, eerst gesloten software, openbaar te maken. In onderstaande tabel is een samenvatting opgenomen van deze licentievormen.

Aanbieders van open source software

Bij de aanbodkant gaat het om de projecten zelf die software opleveren, waarbij een verder onderscheid mogelijk is naar technische, infrastructurele software, standaard gebruikersapplicaties en complexe client-server toepassingen. Hoewel eenduidige statistieken ontbreken, wordt over het algemeen aangenomen dat de penetratiegraad van OSS bij technische, infrastructurele software het grootst is. Voorbeelden van dergelijke software zijn webservers (Apache), databasemanagementsystemen (MySQL, PostgreSQL), software voor het verzenden van e-mails (mail transfer agents, zoals sendmail) en scripttalen voor het genereren van dynamische webpagina’s (Perl, Python en PHP). Als we kijken naar de standaard gebruikersapplicaties, dan bestaat inmiddels voor ieder gesloten programma een volwaardige open source tegenhanger. Op basis van de vrijgegeven Netscape-code zijn uiteindelijk Firefox als browser en Thunderbird als e-mailprogramma ontstaan. Uit het door Sun openbaar gemaakte StarOffice is OpenOffice voor kantoorautomatisering naar voren gekomen. Andere bekende OSS zijn Evolution als groupware en The Gimp voor het bewerken van afbeeldingen en foto’s. Een laatste categorie software betreft complexe client-server applicaties, die veelal in hoge mate geparametriseerd moeten worden en/of die aangepast moeten worden om aan alle eisen te voldoen (maatwerk). In deze groep komen we ondermeer systemen tegen op het gebied van boekhouding (SQL-Ledger en afgeleide varianten), CRM (OpenCRX, vtiger) en ERP (Compière, TinyERP).

De keus van een project voor een bepaalde licentie kan grote gevolgen hebben voor de zakelijke toepassing van de software. De GPL biedt de ontwikkelaar weliswaar de beste bescherming tegen misbruik van zijn code in gesloten software, maar is daardoor voor de meeste commerciële projecten onbruikbaar. De opname van GPL-code in een project verbiedt immers de verspreiding van de nieuwe code als gesloten software. Overigens moet hierbij wel aangemerkt worden dat dit probleem niet speelt bij intern gebruik van code die door de GPL beschermd wordt. De LGPL kent dit probleem evenmin, ook in situaties waarin beoogd is de afgeleide software (commercieel) te verspreiden. De BSDlicentie biedt de meeste vrijheid voor gebruikers. De bepaling, dat alle ontwikkelaars zelfs in reclame-uitingen genoemd moeten worden, is echter problematisch. Afgeleide licenties van de BSD kennen een dergelijke bepaling niet. In het licht van het voorgaande zijn de latere licenties als de NPL en de MPL praktischer in het gebruik. De NPL is formeel gezien overigens geen open source licentie, vanwege de bijzondere rechten die aan de eigenaar toegekend worden.

Gebruikers van open source software Bekende open source programma’s en projecten

Naast aanbieders van OSS zijn er ook gebruikers die deze applicaties daadwerkelijk toepassen. Enerzijds worden afzonderlijke toepassingen door organisaties gebruikt, anderzijds komen we in toenemende mate grootschalige en complexe open source projecten tegen, vooral bij overheidsinstanties. Bekende voorbeelden van dergelijke projecten zijn het besluit van de Franse regering meer dan één miljoen computers van ambtenaren uit te rusten met OSS en verschillende overheidsinstellingen in Duitsland om tienduizenden werkplekken te migreren naar Linux (stad München, politie Nedersaksen). In Nederland kan het programma OSOSS genoemd worden, dat overheidsinstanties stimuleert gebruik te maken van open standaarden en OSS

Er is een groot aantal open source programmatuur beschikbaar. Alleen al bij SourceForge, een verzamelplaats voor open source software-ontwikkeling, waren medio mei 2005 meer dan honderdduizend projecten aangemeld [5]. Dat betekent overigens niet dat ieder project even succesvol is en bruikbare software oplevert. Het succes van een project wordt vooral bepaald of de op te leveren software een groot publiek aanspreekt. Alleen dan kan het bovengenoemde evolutionaire ontwikkelproces zich voltrekken. Om deze reden komen we niet vaak gespecialiseerde OSS tegen, die voor een beperkte groep gebruikers geschikt is. Bij een beschrijving van bekende open source programma’s en Tabel 1 | Voorbeelden open source licenties GPL (broncode) mag met niet-vrije software gebruikt worden

LGPL

BSD

MPL

NPL

●

●

●

●

●

●

wijzigingen moeten vrij zijn

●

●

uitbreidingen moeten vrij zijn

●

● ●

bijzondere rechten voor de eigenaar


[6]. Behalve wetsvoorstellen, haalbaarheidsstudies, proefopstellingen en enkele kleinschalige migraties, zijn in Nederland geen grote open source projecten bekend, die vergelijkbaar zijn met die in de ons omringende landen.

gesloten software) worden nieuwe producten ontwikkeld en verspreid. De werkwijze en projectorganisatie wijken daarbij sterk af van meer traditionele ontwikkeltrajecten. Dit brengt een aantal risico’s met zich mee. Hieronder zijn deze risico’s en mogelijke maatregelen nader toegelicht.

Waarom kiezen organisaties voor open source software?

Organisaties kunnen verschillende redenen hebben om voor open source software te kiezen [7]. • De gebruiker krijgt meer macht ten opzichte van de leverancier, omdat de broncode vrij toegankelijk is. Voor ondersteuning en eventuele aanpassingen is hij daarom niet meer gebonden aan het bedrijf dat de software oorspronkelijk geleverd heeft, maar kan kiezen voor een aanbieder met de beste prijs-kwaliteitverhouding. • De openbaarheid van de broncode verhoogt de flexibiliteit en de integratiemogelijkheden van de software; aanpassingen om de functionaliteit toe te snijden op een specifieke situatie zijn altijd mogelijk. • Doordat de code door veel personen is in te zien, kan OSS bovendien veiliger worden beschouwd. Eventuele veiligheidslekken kunnen op deze wijze ook sneller gedicht worden. • Technische overwegingen om voor open source producten te kiezen, betreffen schaalbaarheid, stabiliteit en performance. Overigens geldt voor het laatste aspect dat dit behoorlijk kan verschillen per situatie. In het verleden is bijvoorbeeld aangetoond dat een Linux webserver beter presteerde bij het uitgeven van dynamische webpagina’s, terwijl zijn Windows-tegenhanger hoger scoorde bij statische pagina’s. OSS hoeft dus niet voor iedere organisatie beter te zijn dan gesloten software. • OSS is goedkoper. In beginsel is de software zelfs gratis, maar voor deze prijs wordt geen garantie en ondersteuning gegeven. Onderhouds- en servicecontracten kunnen wel tegen betaling bij gespecialiseerde IT-bedrijven worden afgesloten. Ook dienen organisaties die willen overstappen rekening te houden met extra kosten op het gebied van migratie, opleiding en training. Desalniettemin blijft in de meeste gevallen een kostenvoordeel bestaan ten opzichte van gesloten software. • Er zijn ook maatschappelijke overwegingen om voor open source te kiezen. Deze motieven zien we vooral terug bij overheden, die concurrentie op de IT-markt willen stimuleren (Duitsland, Frankrijk) of die hun eigen IT-industrie van de grond af aan willen opbouwen (economisch opkomende landen in Azië en Zuid-Amerika). • Tot slot kunnen organisaties voor open source kiezen, omdat zij ervan overtuigd zijn dat deze uit principe beter is dan gesloten software. Weliswaar zijn dergelijke ethische en morele argumenten abstract van aard, maar daarom niet minder belangrijk. Risico’s open source software OSS onderscheidt zich voornamelijk van traditionele software in het ontwikkelproces. Het bazaarmodel is al eerder genoemd: op basis van nieuwe en bestaande componenten (soms ook

Juridische risico’s

Aansprakelijkheden en garantie bij uitval of fouten in OSS is niet geregeld. Dus als een ernstige verstoring zich voordoet kan de gebruiker er niemand op aanspreken. Eventuele herstelkosten komen voor de rekening van de gebruiker of de community (gebruikersgroep). Het is dus belangrijk OSS goed te testen of na te gaan hoe de software in het ontwikkeltraject is getest. Om dit risico te mitigeren is het tegenwoordig ook mogelijk een servicecontract af te sluiten. Door de virale werking van sommige licenties zijn de commerciële mogelijkheden van OSS producten beperkt. Wanneer een leverancier in zijn gesloten systeem GPL-code opneemt, dan moet het product in het vervolg onder GPL worden vermarkt. Als het bedrijfsmodel daarop niet ingespeeld is, kan dit verlies of gederfde inkomsten betekenen. Hiermee dient een leverancier rekening te houden: vooraf onderzoek is noodzakelijk. Bij integratie van OSS en traditionele systemen voor intern gebruik, is dit risico niet direct aanwezig. In een dergelijke situatie zal de organisatie niet voornemens zijn de aldus ontstane oplossing te vermarkten of anderszins ter verdere verspreiding beschikbaar te stellen. Het patenteringsvraagstuk van softwarematige uitvindingen gold lang als een belangrijk risico voor de verdere ontwikkeling en het gebruik van OSS. Door de uitspraak van het Europees parlement medio 2005 bestaan er wat dit punt betreft geen belemmeringen (meer) in Europa. Het auteursrecht bergt wel een zeker risico in zich. Indien voorheen gesloten code op illegale wijze terecht komt in OSS, dan lopen zowel de aanbieders als gebruikers het risico door de eigenaar aangeklaagd te worden wegens inbreuk op zijn auteursrecht. Nu doet dit risico zich ook voor bij gesloten software; de openbaarheid van OSS maakt deze echter extra kwetsbaar, omdat iedereen de code kan controleren. Daarentegen kan ook gesteld worden, dat van deze openbaarheid een preventieve werking uitgaat en daardoor juist bescherming biedt. Omdat illegaal handelen direct zichtbaar is, zullen weinig programmeurs geneigd zijn gesloten code te gebruiken in hun open code. Continuïteitsrisico

Het ontwikkelproces kenmerkt zich door ontwikkeling van componenten, vaak geprogrammeerd rond specifieke onderwerpen. De aldus gevormde brokken functionaliteit vormen uiteindelijk samen het product. Omdat de open source elementen vrij beschikbaar zijn en principe oneindig ontwikkelbaar, kunnen er in principe meerdere (eind)producten ontstaan. Door deze wijze van ontwikkeling is nooit exact duide-


lijk in welk stadium een product zich bevindt of hoe levendig een product is. Dit is zeker het geval als er sprake is van forking, waarbij op basis van de oorspronkelijke componenten meerdere vergelijkbare producten kunnen ontstaan. Ook kan de ontwikkelcapaciteit opdrogen doordat de programmeurs geen tijd meer hebben of zich aansluiten bij een ander project. Het afsterven van een product of project betekent in beginsel een continuïteitsrisico voor de organisatie die met het betreffende product werkt. Nu is de broncode vrij, dus kan de organisatie het product zelf in stand houden door het zelf of met andere gebruikers verder te ontwikkelen. Eventueel kan een (hoofd)ontwikkelaar uit het project in dienst worden genomen. Het risico kan vooraf worden verkleind door het afsluiten van een servicecontract of het project actief te ondersteunen door bijvoorbeeld input te leveren, een infrastructuur ter beschikking te stellen of door middel van financiële bijdragen (schenkingen). Het continuïteitsrisico geldt in mindere mate voor de maatwerktoepassingen, daarvan is reeds vanaf het begin duidelijk dat de organisatie zelf moet zorgdragen voor de verdere ontwikkeling en instandhouding. Kwaliteit software

Een belangrijk verschil in de ontwikkeling van OSS met traditionele ontwikkelingen is dat zij evolutionair tot stand komt met als kenmerken een sterk bottom-up karakter, grote groepen ontwikkelaars en (eind) gebruikers die testen. Een kritische succesfactor voor een goed en betrouwbaar OSS product is de grootte en samenstelling van de groep ontwikkelaars, programmeurs en gebruikers. Het OSS ontwikkelmodel levert een kwalitatief goed product op indien er meerdere partijen betrokken zijn, deze partijen verschillende rollen vervullen en/of een tegengesteld belang hebben bij het eindproduct. Indien er een beperkt aantal gebruikers zijn, bestaat het risico dat er onvoldoende wordt getest (en er dus kans is op fouten). Hebben betrokkenen geen aandacht voor beveiliging, dan ontstaat er vanuit dit oogpunt mogelijk een onbetrouwbaar systeem en als er te weinig documentalisten zijn zal dit invloed hebben op de kwaliteit van de documentatie. Een organisatie dient zich ervan te vergewissen dat ze alleen software gebruikt uit actieve projecten. De kwaliteit kan verder worden vastgesteld door zelf uitvoerig te testen. Ook kan er voor gekozen worden de problemen en fouten die nog boven komen drijven zelf op te lossen. Dit betekent wel een zwaardere belasting voor het incident-, probleem- en wijzigingsbeheer. Met betrekking tot documentatie zien we dat commerciële partijen in toenemende mate goede en bruikbare handleidingen op de markt brengen van veel gebruikte producten. Hierdoor is het risico beperkt dat organisaties in aanraking komen met producten die niet of beperkt gedocumenteerd zijn. Compatibiliteitsrisico

Het vervangen van gebruikerssoftware door een open source equivalent kan gepaard gaan met conversieproblemen van bestaande documenten. Niet zozeer met het openen en

bewerken ervan (standaard documenten kunnen vaak moeiteloos worden opgevraagd) maar bij het gebruik van complexe macro’s, formats en sjabonen. Vaak dienen deze na een migratie opnieuw gedefinieerd te worden. Ook koppeling met bestaande systemen kan door het ontbreken van inzicht in de gesloten standaarden problemen opleveren. Bovendien zijn er producten die alleen nog maar een interface hebben met Microsoft producten als Word en Excel. Het gevolg kan zijn dat traditionele en open source software naast elkaar blijven draaien omdat de gewenste integratie niet goed realiseerbaar is of te veel kosten met zich meebrengt. In de praktijk blijken er bij een migratie van het besturingssyteem, bijvoorbeeld van Windows naar Linux, soms andere hardware eisen te bestaan. Dit manifesteert zich vooral op het gebied van aansturing van (externe) apparatuur, zoals printers en videokaarten. Indien hiermee op voorhand geen rekening is gehouden kan dit leiden tot een langer implementatietraject en extra kosten. Ook de koppelingsmogelijkheden met handheldcomputers zit nog in een beginstadium. Door vooraf een (impact)analyse op de migratie uit te voeren kan het compatibiliteitsrisico inzichtelijk worden gemaakt en kunnen passende maatregelen worden genomen. Dit is zeker noodzakelijk als er op het niveau van besturingssysteem wordt gemigreerd. Om problemen in de toekomst te voorkomen, is het aan te bevelen bij selectie van nieuwe hardware te eisen dat deze platform-onafhankelijk functioneert. Andere aandachtspunten

Naast deze risico’s die samenhangen met het OSS en de wijze van systeemontwikkeling is er nog een aantal andere aandachtspunten bij OSS te noemen. Dit zijn tevens aandachtspunten die in meer of mindere mate ook gelden voor traditionele software-ontwikkelingstrajecten. Kostenaspect

Door de relatieve onbekendheid met OSS kunnen de kosten en de moeite die samenhangen met een implementatie of migratie ernstig worden onderschat. De kosten van verdere ontwikkeling van een product staan bij maatwerk geenszins in verhouding met de ‘verkrijgingswaarde’ van de componenten. Weerstand gebruikers

Een ander belangrijk aandachtspunt is de acceptatie van OSS door de eindgebruikers. OSS kent soms een andere ‘look and feel’ dan de software waaraan de gebruikers ondertussen zijn gewend, én die in toenemende mate ook nog afgeleid is van de bekende PC-omgeving thuis. Mede door het in sommige gevallen ontbreken van een goede (Nederlandstalige) vraagbaak kan dit leiden tot afkeuring en weerstand. Opleiding, training en voorlichting zijn nog meer dan bij traditionele software belangrijke aandachtspunten.


Migratie ontwikkelomgeving

Indien de organisatie zelf applicaties ontwikkelt, moet in veel gevallen de ontwikkelomgeving ook gemigreerd worden om OSS software te kunnen testen en ontwikkelen. Dit betekent een extra (financiële) inspanning waarmee op voorhand geen rekening wordt gehouden. Om bij implementatie van OSS niet voor verrassingen te komen staan, dienen ook deze punten in een impactanalyse expliciet aandacht te krijgen. De IT-auditor en open source software Door de verbreding van de open source softwaremarkt en de toename in het productenaanbod, zullen IT-auditors in toenemende mate geconfronteerd worden met open source software. Hierbij dienen IT-auditors zich bewust te zijn van de specifieke risico’s die de evolutionaire ontwikkeling van open source software en het beheren van deze software met zich meebrengt. Hierna is per fase (idee- en planvormingsfase, ontwikkelen implementatiefase en exploitatiefase) een korte schets gegeven van de aandachtspunten voor de IT-auditor. Deze aandachtspunten komen bovenop de reguliere maatregelen die bij het ontwikkelen, selecteren, gebruiken en beheren van software van belang zijn. Want ook de general controls zijn onverkort van toepassing in een omgeving waarin sprake is van open source software. Idee- en planvormingsfase

In de idee- en planvormingsfase vindt een impliciete of expliciete oriëntatie plaats met betrekking tot open source software. De IT-auditor kan hierin een belangrijke rol vervullen door te adviseren over de mogelijkheden, maar vooral ook de risico’s, die samenhangen met OSS. Door het toetsen van het ICT-beleid kan de IT-auditor zich ervan vergewissen dat de organisatie voldoende heeft nagedacht over de risico’s die een ontwikkel- of migratietraject van OSS met zich meebrengt. In de financiële paragraaf wordt expliciet nagegaan of de (implementatie)kosten van OSS reëel zijn ingeschat. Om de risico’s inzichtelijk te krijgen, kan de IT-auditor participeren in risico-workshops of bij het uitvoeren van de impactanalyse. Als reeds een impactanalyse is uitgevoerd kan de IT-auditor de resultaten beoordelen. In het geval de organisatie nog geen focus heeft op open source software kan door de IT-auditor worden nagegaan of in het ICTbeleid of de investeringsvraagstukken rekening gehouden is met OSS als alternatief voor traditionele software. Ontwikkel- en implementatiefase

Aangezien de werkwijze en groep betrokkenen belangrijke succesfactoren vormen, is het voor de IT-auditor van belang na te gaan hoe het ontwikkelproces is verlopen. Hierbij wordt beoordeeld hoe de functionaliteit tot stand is gekomen en hoe kwaliteit en betrouwbaarheid van het product is bewaakt (waaronder beveiliging, testtraject en dergelijke). Dit is lastiger dan in een traditionele situatie door het ont-

IT-auditors moeten zich bewust zijn van de specifieke risico’s die de evolutionaire ontwikkeling van open source software met zich meebrengt breken van een formele projectstructuur en het naar verwachting niet voorhanden zijn van kwaliteits- en testplannen, testverslagen en voortgangsrapportages. Door het bezoeken van het Internetportaal van het project en (andere) gebruikersfora zal de IT-auditor zich een beeld moeten vormen van de projectorganisatie en wie daarachter zitten. Vragen als: Wie zijn de oprichters en welke motieven hebben ze? Hoeveel gebruikers van het product zijn er? Hoe levendig is het project?, zijn daarbij belangrijk. Met andere woorden: de IT-auditor dient zich een beeld te vormen van de levendigheid en daarmee de potentie en toekomstvastheid van het product. De snelheid waarmee fouten en problemen worden opgelost, de frequentie waarmee nieuwe releases uitkomen, de uitgebreidheid van mailinglisten maken dat zichtbaar. Uiteraard dient de auditor vast te stellen dat de organisatie heeft gekozen voor de stabiele (geteste) versie van OSS in plaats van de ontwikkelversie. Zoals eerder beschreven, bevat deze ontwikkelversie meestal de nieuwste functionaliteiten en is de kans groot dat deze versie nog fouten bevat die nog niet ontdekt zijn door testers en gebruikers. Verder is het van belang vast te stellen op welke wijze de betrouwbaarheid van het product door de organisatie zelf is vastgesteld. Wellicht is er om voornoemde redenen al meer getest dan in een normale situatie. Wanneer sprake is van een overgang van een gesloten omgeving naar een omgeving waarin open source software wordt gebruikt of waarbij gesloten en open source producten gekoppeld worden gebruikt, zal de IT-auditor bij het beoordelen van het implementatieplan op een aantal zaken moeten letten. Bijzondere aandacht dient te worden besteed aan de conversieproblematiek van documenten, eventueel de hardware-eisen, de koppelingen en eventuele migratie van de ontwikkelomgeving. Zoals eerder aangegeven, liggen daar belangrijke aandachtspunten. Ook dient vastgesteld te worden of de organisatie voldoende rekening heeft gehouden met het opleiden en trainen van gebruikers. Indien in het ontwikkelen implementatietraject minder aandacht is voor de specifieke OSS risico’s heeft de IT-auditor een belangrijke voorlichtende en adviserende rol.


Exploitatiefase

Literatuurlijst

In de exploitatiefase gelden nagenoeg dezelfde risico’s als bij traditionele gesloten software. Gezien de specifieke risico’s van OSS besteedt de IT-auditor in deze fase expliciet aandacht aan de kwaliteit van de (gebruikers)documentatie, het releasebeleid en de kwaliteit van de processen rondom incident-, probleem- en wijzigingsbeheer. Dit laatste is van belang om te waarborgen dat fouten snel en efficiënt worden opgelost. Hierbij geldt de vraag wie de contacten met de ontwikkelaars houdt als deze buiten de organisatie zitten.

1

Als er servicecontracten voor het onderhoud zijn afgesloten, dient de auditor vast te stellen of dit een betrouwbare partij is, opdat de continuïteit van het beheer gewaarborgd is. Dit moet in reguliere situaties ook, maar is hier extra van belang omdat er veel nieuwkomers in de markt zijn waarvan het bestaanrecht nog moet blijken. De auditor kan ook gevraagd worden een oordeel te geven over de afspraken die zijn vastgelegd in het contract, bijvoorbeeld of deze helder en eenduidig zijn. Ook in deze fase is het continuïteitsvraagstuk rond OSS van belang. Het is dus zaak de levendheid van een product te blijven volgen. De organisatie dient een goed beeld te hebben van de strategie die gevolgd wordt als het project door forking of het opdrogen van ontwikkelcapaciteit op een dood spoor dreigt te raken.

6 OSOSS, Programma Open Standaarden en Open Source Software voor

Tot slot Afsluitend kan geconcludeerd worden dat OSS naast de gangbare risico’s bij ontwikkeling, gebruik en beheer ook een aantal specifieke risico’s en beheersmaatregelen kent. Voor een belangrijk deel worden deze risico’s veroorzaakt door de wijze waarop de producten tot stand komen. Ook de relatief jonge historie van OSS voor het brede publiek is daar debet aan. Verwacht mag worden dat de verdere ontwikkeling van deze producten en commercialisering OSS tot een gemeengoed verwordt. Deze volwassenheid heeft ertoe bijgedragen dat in toenemende mate aandacht wordt besteed aan de risico’s op het gebied van documentatie, beveiliging en het ontwikkeltraject. Naast het inzichtelijk maken van de risico’s rond OSS biedt dit artikel een aantal handvatten voor IT-auditors die zij kunnen gebruiken in situaties waarbij zij geconfronteerd worden met OSS. Omdat ook hier geldt ‘voorkomen is beter dan genezen’, is het van belang de IT-auditor zo vroeg mogelijk in een open source vraagstuk te participeren. Hierbij geldt dat de IT-auditor zich bewust moet zijn van het evolutionaire of incrementale (RAD-achtig) karakter van open source software ontwikkeling. Met een schets van het OSS ontwikkelproces in het achterhoofd kan een zinvolle discussie worden gevoerd, waarbij de IT-auditor vanuit zijn achtergrond zijn toegevoegde waarde kan laten zien. ■

Nieuw OSSOS-programma: openheid voor overheid

Open Source Initiative, Web site Open Source Initiative OSI, http://www.opensource.org, geraadpleegd op 18 augustus 2005

2 Busskamp, D., Open Source Tutorial, http://www.dbus.de/eip/inhalt. html, geraadpleegd op 15 juli 2005 3 Kuri, J., Der Streit um Softwarepatente, http://www.heise.de/ct/aktuell/meldung/61230, geraadpleegd op 17 augustus 2005 4 Raymond, E.S., The cathedral and the bazaar, http://www.catb.org/ ~esr/writings/cathedral-bazaar, geraadpleegd op 17 augustus 2005 5 Moorman, J., SourceForge.net Surpasses 100,000 Projects!, http://sourceforge.net, geraadpleegd op 17 augustus 2005 de overheid, http://www.ososs.nl, geraadpleegd op 17 augustus 2005 7 Wheeler, D.A., Why Open Source Software? Look at the numbers!, http://www.dwheeler.com/oss_fs_why.html, geraadpleegd op 17 augustus 2005

Het programma OSSOS informeert overheidsorganisaties over de mogelijkheden van open source software en stimuleert hen deze waar mogelijk toe te passen in hun informatiesystemen. OSSOS staat voor Open Source als Onderdeel van de Software Strategie (voor de overheid) en is de opvolger van het programma OSOSS (Open Standaarden en Open Source Software) dat liep van 2003 tot 2006. Het programma OSOSS biedt concrete ondersteuning in de vorm van voorlichting, kennisuitwisseling en instrumenten, waarmee elke overheidsorganisatie zelf open source software kan toepassen. Het programma wordt uitgevoerd door de Stichting ICTU in opdracht van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties en het Ministerie van Economische Zaken. Op 26 januari jl. heeft er een kennismakingsoverleg plaatsgevonden tussen OSOSS-programmamanager J.W. Broekema en de NOREA-voorzitter. Meer weten over OSOSS? ICTU Postbus 84011 2508 AA DEN HAAG Tel: 070-888 7717 www.ossos.nl


Open Source Software in perspectief

Recommend Documents