Hoe veilig is open source?

20 maart 2009
Open-sourcesoftware is bezig aan een ongekende opmars en over niet al te lange tijd zijn software-oplossingen die op geen enkele wijze gebruikmaken van open-sourcecomponenten bijna ondenkbaar.

De voordelen van open source zijn evident en legio: met open-sourcesoftware kunnen bedrijven de investeringen in licentiekosten van traditionele software vermijden, wordt de flexibiliteit voor oplossingen vergroot en de afhankelijkheid van een enkele leverancier veelal vermeden.

Softwareoplossingen zijn steeds vaker samengestelde producten uit verschillende bronnen, waarvan een gedeelte door eigen ontwikkelaars is ontwikkeld, een ander gedeelte wellicht afkomstig is uit de open-sourcecommunity en weer een ander gedeelte gebruikmaakt van proprietary software.

Om de efficiëntie van het softwareontwikkelproces te vergroten, ligt sterke nadruk op het hergebruik van softwarecomponenten. Deze aanpak is vruchtbaar, echter er zijn een aantal aandachtspunten waar organisaties rekening mee moeten houden:
  • Hoe weet een organisatie van welke softwarecomponenten gebruikgemaakt wordt en wat de oorsprong en afkomst is van deze componenten?
  • Hoe weet een organisatie dat de software conform licentievoorwaarden wordt gebruikt en geen non-compliance heeft met deze licentievoorwaarden, waaruit financiële en reputatieschade kunnen ontstaan? Hoe kan een organisatie ervoor zorgen dat het eigen intellectueel eigendom niet op straat komt te liggen zonder dat dit de bedoeling is?
  • Hoe kan een organisatie zeker stellen dat de gebruikte componenten daadwerkelijk onder deze voorwaarden gebruikt mogen worden en men in overeenstemming met de juridische mogelijkheden en beperkingen handelt?
  • En tot slot, hoe kan zeker gesteld worden dat voor de verschillende onderdelen ondersteuning en support beschikbaar zijn in geval er problemen zijn?
Veel organisaties hebben in deze context baat bij een managementraamwerk dat helpt bij het managen en controleren van het gebruik van open-sourcesoftware. Hiermee wordt een beleid geformuleerd voor het gebruik en de selectie van open-sourcesoftware en wordt gewaarborgd dat uitsluitend geselecteerde en goedgekeurde software wordt gebruikt, gedistribueerd en onderhouden. Dit raamwerk bestaat uit een aantal afzonderlijke stappen.

Allereerst is het van belang dat een organisatie inzicht verkrijgt in de mate waarin open source gebruikt wordt binnen de organisatie. Dit kan met behulp van interviews en vragenlijsten aan ontwikkelaars en hiervoor kunnen ook specifieke tools worden ingezet. Het doel is om per component in ieder geval de naam, het versienummer en de licentievoorwaarden vast te stellen en te inventariseren waar (in welke projecten en applicaties) deze componenten gebruikt worden.

Verder dient men vast te stellen of er wijzigingen in de sourcecode zijn aangebracht en of de gebruikte software buiten de eigen organisatie is gedistribueerd. Het open-sourcebeleid bepaalt welke licentievormen binnen de organisatie gebruikt mogen worden en met welke softwareleveranciers en supportverlenende bedrijven mag worden gewerkt.

Het is best practice om dit beleid gezamenlijk op te stellen, met belanghebbenden en (eventueel externe) experts, zoals IT-management, IT-operations, de IT-ontwikkelaars en niet te vergeten de juridische afdeling van een organisatie. Het beleid dient aan te geven wie verantwoordelijk is voor toezicht op naleving en wie de operationele richtlijnen formuleert en onderhoudt.

Voorbeelden hiervan zijn: het opstellen en onderhouden van een lijst met goedgekeurde open-sourcesoftwarecomponenten en het omgaan met ‘grijze gebieden’ en waar nodig het bijwerken of aanpassen van de richt-lijnen. Het mag duidelijk zijn dat dit niet louter een technische aangelegenheid is, maar ook raakvlakken heeft met de business en met het juridische domein.

De volgende stap is de softwareselectie: van softwarecomponenten of een complete oplossing. Bij de selectie van softwarecomponenten moet een keuze gemaakt worden uit de bouwstenen die al beschikbaar zijn in de organisatie of er moeten nieuwe componenten worden geselecteerd.

Hergebruik van aanwezige componenten is doorgaans zinvol. Licentievoorwaarden, service- en support-voorwaarden zijn relevante aspecten bij dit selectieproces. Na selectie van de software kan deze worden toegevoegd aan de lijst van toegestane open-sourcesoftware in de organisatie.

Hierna moet de software gevalideerd en geaccepteerd worden voor het gebruik in de beoogde oplossing in de organisatie. Toetsing is nodig op juridische aspecten (Is de licentievorm in overeenstemming met gangbare licentievormen?) en het geformuleerde beleid voor gebruik van open source in de organisatie.

Dit proces borgt dat de support op de software van voldoende niveau is, dat de kwaliteit van de documentatie in orde is en dat er trainingen beschikbaar zijn voor huidige en toekomstige gebruikers van de software. Door gebruikers te betrekken bij de acceptatie van het product wordt gecontroleerd dat het product inderdaad aan de behoeften voldoet en inzetbaar is.

Vervolgens moet de software gedistribueerd worden. Nadat de (gecompileerde) code is getest, kan hij vrijgegeven worden voor gebruik in de beoogde context. Dit proces wijkt niet wezenlijk af van de ingebruikname van traditionele software, echter de licentievoorwaarden van de verschillende bouwstenen mogen in het geval van open-sourcesoftware niet met elkaar conflicteren (zie kader).

Nadat de software daadwerkelijk in gebruik is genomen, moet tot slot voor het beheer rekening gehouden worden met verschillende scenario’s.

Voor standaard-open-sourcesoftware (bijvoorbeeld operatingsystemen en applicatieservers) kan doorgaans volstaan worden met soortgelijke afspraken die ook gemaakt worden voor ‘traditionele’ software, hoewel de complexiteit iets hoger kan liggen.

Als de oplossing echter bestaat uit verschillende open-sourcesoftwarecomponenten, is de situatie ten aanzien van beheer complexer. Ieder component zal beheerd moeten worden. In dergelijke gevallen is het inzichtelijk maken van beheerkosten, zodat deze kunnen worden doorbelast aan de gebruikers, niet eenvoudig.

Typische factoren die de complexiteit verhogen, zijn bijvoorbeeld de (hoge) frequentie van updates van componenten, mogelijke veranderingen in de licentievoorwaarden en een toename van het aantal verschillende platformen binnen de organisatie.

Kortom, open-sourcesoftware is realiteit en steeds meer oplossingen maken gebruik van open-sourcecomponenten. Organisaties kunnen en moeten de voordelen van open source benutten en er tegelijkertijd voor zorgen dat ze compliant zijn met de licentievoorwaarden van de software en voorkomen dat ze risico lopen.

Het compliancyraamwerk hoort thuis in het IT-governance-domein en bij de uitvoering hiervan kan gebruik worden gemaakt van ondersteunende gereedschappen, zodat bedrijven volledig en met beheersbare risico’s kunnen profiteren van de voordelen van het gebruik van open-sourcesoftware.

Geert Batterink is werkzaam als manager bij Accenture (geert.batterink@accenture.com). Esther Lasschuijt is werkzaam als sales director bij Code Experts (esther.lasschuijt@codeexperts.eu).

Compliance-management
Softwarecompliancemanagement is onderdeel van IT-governance. Bij het gebruik van hybride en/of open-sourcesoftware is het noodzaak om zorgvuldig vast te leggen uit welke componenten de broncode is opgebouwd.

Als gelicenseerd materiaal toegevoegd wordt aan de broncode, neemt de urgentie voor compliancemanagement toe. Welke licentieverplichtingen rusten op de code? Zijn de licenties onderling compatibel? Voldoet het nog aan alle wet- en regel-geving?

De risico’s die voortvloeien uit het niet correct managen van open-sourcesoftware kunnen leiden tot onder meer het verlies van het intellectueel eigendom (IE) op de software, juridische acties, boetes, een verbod op distributie van de software of zelfs het terug moeten halen van reeds gedistribueerde producten. Eventuele negatieve publiciteit kan leiden tot reputatie- en integriteitschade van het bedrijf, met alle directe en indirecte gevolgschade van dien.

Verschillende instanties kunnen adviseren en controleren bij compliancemanagement, de bescherming van intellectueel eigendom en het nakomen van licentieverplichtingen in het domein van open-sourcesoftware.

Licentieanalyse
In de markt zijn diverse partijen die oplossingen en hulpmiddelen aanreiken voor het managen van en controleren op het gebruik van open source in software. Deze geautomatiseerde scanningtools detecteren het gebruik van open-sourcecomponenten, documenteren de licentieverplichtingen en identificeren mogelijke licentieconflicten.

Door middel van een scan wordt een licentieanalyse uitgevoerd op de broncode van de software. Deze analyse maakt inzichtelijk welke open-sourcecomponenten in gebruik zijn en welke licentieverplichtingen hierop rusten. Zo ook kunnen eventuele licentieconflicten tussen de open-sourcecomponenten en/of proprietary componenten worden weergegeven en gecorrigeerd.

Dat het handmatig analyseren van code-componenten een complexe en tijdrovende aangelegenheid is, mag duidelijk zijn. Een softwarecompliancemanagementtool is dus geen overbodige luxe en een betrouwbaar middel om te zorgen dat software het intellectueel eigendom (IE) blijft beschermen. Een softwarescan levert als het ware een software-IE-compliancykeurmerk op voor wat betreft de componenten die in de software zijn verwerkt.

Een voorbeeld hiervan is Protex, de softwarecomplianceoplossing van Black Duck Software. Deze tool ondersteunt bij het managen van open-sourcecomponenten en geeft inzicht in de gebruikte codecomponenten, licenties en conflicten om zo de bedrijfsrisico’s te reduceren en softwarecompliant te zijn en te blijven. Een open-sourcevariant van een dergelijke tool is Fossology van HP.
 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!