NL EN
  • Home»
  • Weblog »
  • Richtlijnen bij keuze open source / proprietary software

Richtlijnen bij keuze open source / proprietary software

De Australische overheid (meer specifiek: de “Department of Finance and Deregulation”) heeft recent vernieuwde richtlijnen gepubliceerd voor  gebruik van open source software door Australische overheidsinstellingen. Deze “Guide to Open Source Software” geeft informatie over open source software alsmede biedt het inzicht in de risico’s en voordelen van gebruik, verspreiding en ontwikkeling van open source software. Het document biedt Australische overheidsinstellingen tevens richtlijnen voor het gebruik van open source software.

Hoewel het document in principe is bedoeld voor Australische overheidsinstellingen, biedt het document ook goede richtlijnen voor ((niet-)Australische) projectmanagers, aanbestedende diensten en inschrijvers op ICT-aanbestedingen. Met name wanneer open source software én bijbehorende diensten in beeld komen*. Om die reden bespreek ik dit document op deze weblog. Vandaag zal ik het eerste gedeelte bespreken: de “Guide to Open Source Software for Australian Government Agencies”. In het tweede bericht zal ik het Open Source Software Licensing Risk Framework bespreken, welke als bijlage bij voornoemd document is toegevoegd.

*Immers, de Europese Ombudsman heeft afgelopen jaar beslist dat open source software in Europa niet altijd hoeft te worden aanbesteed. Wanneer betaald moet worden, voor bijvoorbeeld een bijbehorende service-overeenkomst, zijn de aanbestedingsregels wel van toepassing.

 

Introductie

Het document geeft allereerst een omschrijving van open source software. Daarbij wordt gerefereerd naar de Open Source Definition van het Open Source Initiative. Tevens wordt nog eens benadrukt dat open source software niet gratis hoeft te zijn: open source software is “free” in die zin dat men “vrij” in staat is om de broncode van de software te lezen, te wijzigen en te verspreiden. 

Vervolgens geeft het document een omschrijving van drie modellen van ontwikkeling van en support bij open source software:

(i)             door de community (voor support wordt doorgaans geen service level agreement gegeven);

(ii)            door een onderneming-gedreven community (support wordt doorgaans op basis van een service level agreement gegeven; er bestaat veel concurrentie); en

(iii)           commerciële open source software (ontwikkeling en support door één onderneming).

Tenslotte omschrijft het document een aantal – algemeen kernmerkende – voordelen van open source software, waaronder

(i)             het veelal ontbreken van kosten vooraf;

(ii)            minder beperkingen voor de gebruikers;

(iii)           het voorkomen van een vendor lock-in;

(iv)          interoperabiliteit; en

(v)           veelal modulaire ontwikkeling.

 

Open source beleid

De gids beschrijft vervolgens een aantal beginselen betreffende de aanbesteding van open source software en geeft een aantal suggesties hoe de overwegingen omtrent open source software in de aanbestedingsprocedure kunnen worden geïncorporeerd. De gids sluit daarbij aan bij het “Open Source Software Policy”-document, welke de Australische overheid begin dit jaar heeft gepubliceerd. Daaruit blijkt dat instellingen verplicht zijn om open source software voor alle aanbestedingen van software te overwegen. Dit beleid stelt dat instellingen moeten voldoen aan drie kern beginselen:

(i)             Australische ICT-aanbestedingsprocedures moeten op actieve en eerlijke wijze alle types* van beschikbare software overwegen;

(ii)            leveranciers moeten alle types* van beschikbare software overwegen indien Australische overheidsinstellingen gemoeid zijn;

(iii)           Australische overheidsinstellingen zullen op actieve wijze deelnemen in open source software communities en terug bijdragen aan de community, waar geschikt.

*Het document spreekt over “types of available software”. Dit is m.i. niet helemaal zuiver: open source software is geen ander type software dan proprietary software. Het is de licentie die het verschil maakt – het gaat dus om types licenties, i.p.v. software.

 

Aanbesteding van open source software

In het vierde deel geeft de gids aan dat de aanbesteding van open source software in veel gevallen hetzelfde is als de aanbesteding van proprietary software. Bij de aanbesteding van software moet volgens de gids onder meer het volgende worden overwogen:

(i)             total costs of ownership (dus niet alleen de aanschaf van de software, maar ook bijvoorbeeld support-, onderhouds- en exitkosten);

(ii)            support en onderhoudsafspraken die passen bij de vereisten van de instelling;

(iii)           variaties in stabiliteit, mate van innovatie en ‘maturity’ van de software;

(iv)          beginselen,standaarden en technologieën gebruikt door de instelling;

 

Vergelijking van open source software met proprietary software

Tenslotte biedt het document een aantal kern aspecten voor instellingen als zij open source software vergelijken met proprietary software. Daarbij wordt opgemerkt dat de implementatie van open source software niet noodzakelijkerwijs grotere risico’s met zich meebrengt dan proprietary software, maar dat er wel een ander risicio profiel kan zijn. De kern aspecten zijn:

(i)             toegang tot broncode; (bij open source is toegang tot de broncode beschikbaar, bij proprietary software veelal niet)

(ii)            “capital expenditure”’; (de kosten voor zowel open source software als proprietary software bestaan niet enkel uit (g)een aanschafprijs, maar ook uit support-, onderhouds-, trainings en exitkosten bijvoorbeeld)

(iii)           maatwerk; (is maatwerk vereist en, zo ja, kan de instelling daar zelf in voorzien of is inschakeling van een derde partij vereist, en wat zijn de kosten van beiden. Hoe zit het met licentie verplichtingen e.d.?)

(iv)          ontwikkeling/governance; (welk ontwikkelmodel is van toepassing (zie onder het kopje Introductie))

(v)           eind gebruikers; (denk aan training)

(vi)          innovatie; (open source software stimuleert innovatie door de community; bij proprietary software is men afhankelijk van de leverancier)

(vii)         intellectueel eigendom; (mag de instelling ie-rechten bezitten, zo nee, is er een uitzondering indien de software open source is?)

(viii)        aansprakelijkheid; (wie is aansprakelijk bij (aanpassing van) open source software? Wat stellen de licentievoorwaarden over aansprakelijkheid?)

(ix)          licentie verplichtingen; (welke voorwaarden stelt de licentie? Is ‘dual licensing’ (lees: gebruik van twee verschillende soorten open source en/of proprietary licenties) mogelijk? Wat gebeurt er met eigen code die wordt gecombineerd met open source software? (Zie hieronder))

(x)           lock-in; (open source software kan interoperabiliteit stimuleren en vendor lock-ins beperken; maar denk ook aan het gebrek aan support-mogelijkheden)

(xi)          ‘maturity’ en portabiliteit; (bestaat er een risico dat op den duur moet worden overgeschakeld op een ander product?)

(xii)         release management; (open source software kent veelal vaker releasemomenten, hetgeen een negatief effect kan hebben op vereisten voor integratie testen, release management, bug fixes, risk management en support)

(xiii)        betrouwbaarheid;

(xiv)        gebruiksbeperkingen; (staan de licentievoorwaarden wijzigingen in de broncode toe, en zo ja, onder welke voorwaarden? Hoe zit het met afspraken omtrent support en/of eventuele licentiekosten)

(xv)         hergebruik;

(xvi)        beveiliging;

(xvii)       support en onderhoud; (intern, community of commercieel?)

(xviii)      garanties;

(xix)        code forking; (van code forking is, kort gezegd, sprake als op basis van de software een nieuw project wordt gestart. Door forking kan het lastig worden om upgrades in een nieuwe versie van de originele broncode door te voeren in de ‘fork’ (het nieuwe project); dit kan tevens meer tijd en kosten met zich mee brengen. Mogelijk stelt de licentie het verplicht dat de ‘fork’ ook open source moet zijn.) en

(xx)         reciprociteit (moet de broncode van de wijziging vrij beschikbaar worden gesteld, indien de wijziging wordt verspreid?).

 

Relevantie

Kortom, hoewel dit Australische document is bedoeld voor met name Australische overheidsinstellingen bij aanbesteding van (open source) software, is het document tevens een handige richtlijn voor iedere projectmanager die een keuze moet maken tussen open source en proprietary software.

Één en ander is echter niet nieuw in Nederland. Zo heeft het programma Nederland Open in Verbinding een aantal documenten gepubliceerd die in Nederland relevant zijn bij de aanbesteding van (open source) software. Bijvoorbeeld documenten met modelteksten hoe rekening te houden met open source leveranciers en producten binnen aanbestedingen; welke eisen en wensen moeten worden opgenomen in de aanbestedingsdocumentatie en hoe kan vorm worden gegeven aan ‘voorkeur bij gelijke geschiktheid’; een handreiking waarbij wordt ingegaan op de vraag in hoeverre de overheidsorganisatie als opdrachtgever van tevoren aan de ontwikkelaar van de software duidelijk moet maken dat het de bedoeling is dat de broncode en software onder een open source licentie beschikbaar zal komen; de ‘Instructie rijksdienst bij aanschaf ICT-diensten en ICT-producten’, het “Onderzoek naar gelijke kansen voor open source aanbieders”, de “Handleiding Open Standaarden en Open Source Software in aanbestedingen” en meer.

Zoals gezegd, zal ik in een tweede weblog bericht ingaan op het Open Source Software Licensing Risk Framework, welke als bijlage is toegevoegd bij de Guide to Open Source Software for Australian Government Agencies.



PAGINA DOORSTUREN

DEZE PAGINA IS SUCCESVOL DOORGESTUURD!

REACTIES (3)

Jan Stedehouder woensdag 6 juli 2011 12:53

Ik ben het niet helemaal met je eens dat de Australische handreiking vergelijkbaar is met de Nederlandse documenten, maar misschien ben ik ook wat bevooroordeeld ;-) . Puur gevoelsmatig ervaar al lezende dat de Australische handreiking gesloten en open source software gelijkelijk waardeert, iets wat ik Nederland (nog) niet ervaar. De vraag: "Waarom zouden we iets met open source moeten doen", moet nog te vaak worden beantwoord.

De Australische handreiking gaat impliciet uit van een overheid die zelfstandig en actief met de software aan de slag gaat, zoals zichtbaar in de opmerkingen over actieve participatie in open source gemeenschappen (tegen het Nederlandse: "Moeten we dit wel willen") en het bespreken van de risico's van forking (door in-house ontwikkeling van features, welke je zelf moet toevoegen bij de volgende release van het mainstream pakket). Een ander voorbeeld vind ik de bespreking over het virale karakter van de eigen wijzigingen bij hergebruik tussen overheidsinstellingen. Het beeld dat opduikt is een overheid die actief stuurt, ontwikkelt, samenwerkt, een beeld dat ik graag ook voor de Nederlandse overheid zou zien (i.p.v. bestuurstafels, papieren intenties en 'doorbraken').

Anastasia Da paxiao maandag 12 augustus 2013 17:22

hallo, meneer / mevrouw, er is business Ik wil dat we together.can je antwoord terug naar mij?
Thanks jouwe Anastasia.

Anastasia Da paxiao maandag 12 augustus 2013 17:23

hallo, meneer / mevrouw, er is business Ik wil dat we together.can je antwoord terug naar mij?
Thanks jouwe Anastasia.

EEN REACTIE PLAATSEN

UW E-MAIL ADRES WORDT NIET GETOOND AAN ANDERE BEZOEKERS.

  1. NAAM
  2. E-MAILADRES
  3. BERICHT
  4. WANNEER U DEZE REGEL KUNT LEZEN, VUL HET VOLGENDE VELD DAN NIET IN!
  5.