Meer en meer overheden geven te kennen dat ze een beleidsmatige voorkeur hebben voor open source-software vanwege de mogelijkheid om daarmee een grotere omvang van leveranciersonafhankelijkheid te bereiken. Het komt de laatste tijd echter met grote regelmaat voor dat deze overheden zich tijdens een aanbestedingsprocedure afvragen of een aan hen aangeboden product wel echt open source is. Vaak is de aanleiding dat een leverancier ergens in de offerte of de nota van inlichtingen schrijft dat zij een commercieel open source-product aanbieden zonder daarbij uit te leggen waarin deze 'commerciële' open source zich onderscheidt van 'gewone' open source.
In de gevallen waarbij er sprake is van 'commerciële open source' bestaan er vaak twee verschillende versies van het product waarbij een duale licentiestructuur wordt gebruikt. In dit businessmodel is de ene versie van het product bijvoorbeeld beschikbaar onder een OSI goedgekeurde licentie en is daarmee te beschouwen als 'normale' open source, oftewel een community-edition, terwijl de andere versie, de enterprise-edition, onder de noemer 'commerciële open source' geleverd wordt onder een bedrijfseigen licentie en vaak ook zonder de broncode. In dat laatste geval kun je je natuurlijk afvragen in hoeverre een dergelijke licentie nog voordelen heeft ten opzichte van de licenties die doorgaans bij proprietary closed source-software worden gehanteerd.
Een andere variant is de situatie waarbij daadwerkelijk de communityversie inclusief broncode geleverd wordt, maar waarbij er aanvullend een aantal closed source-extensies of plug-ins bijgeleverd worden. Op deze extensies is dan een andere bedrijfseigen licentie van toepassing. Dit businessmodel noemt men buiten Nederland ook wel 'open-core' oplossingen.
Bij een derde variant is er helemaal geen sprake van een open source-communityversie. Daarbij noemt men op de vraag of het product open source is, dat het product is ontwikkeld met open source. Een goed verstaander leest daarin dat alleen de gebruikte ontwikkeltools open source zijn, maar dat de daarmee ontwikkelde software dat niet is.
In die gevallen waarbij de bijbehorende licentie-overeenkomst niet is goedgekeurd door de OSI, strekt het tot de aanbeveling om deze te onderzoeken op aanwezigheid van de volgende vier gebruiksrechten:
● De gebruiker mag en kan de software vrij (zonder gebruiksvergoeding) en onbeperkt gebruiken.
● De gebruiker mag en kan de broncode (zonder gebruiksvergoeding) inzien.
● De gebruiker mag en kan de broncode (zonder gebruiksvergoeding) bewerken, verbeteren en aanvullen.
● De gebruiker mag en kan de broncode en de software vrij distribueren (verspreiden).
Regelmatig blijkt uit een dergelijk onderzoek dat deze rechten niet of zeer beperkt aanwezig zijn bij de zogenoemde 'commerciële open source'. Wat heeft een organisatie er echter aan dat de communityversie van een willekeurig softwareprogramma als 'normale' open source onder een OSI goedgekeurde licentie verkrijgbaar is wanneer de daadwerkelijk in gebruik te nemen commerciële versie een lock-in veroorzaakt doordat bijvoorbeeld niet de volledige broncode beschikbaar is, eventuele verbeteringen niet zomaar vrij kunnen worden gegeven, het aantal gebruikers gelimiteerd is en er op de commerciële versie slechts één leverancier support kan geven. Het feit dat er een andere veelal afwijkende versie als open source beschikbaar is, kan naar mijn mening niet per definitie gezien worden als een goede exitstrategie en een middel om leveranciersonafhankelijkheid te vergroten. Bij het 'open-core' businessmodel speelt dit overigens al weer iets minder.
Daarom adviseer ik deze aanbestedende diensten vrijwel altijd om voorafgaand aan de gunning de volgende twee vragen te (laten) beantwoorden:
1 wordt de gehele software geleverd onder een OSI goedgekeurde licentie, en
2 wordt de gehele broncode onder diezelfde licentie meegeleverd en komt deze overeen met de geleverde software?
Indien een van deze vragen negatief beantwoord wordt, dan zal er bij deze aanbieding nader moeten worden gekeken naar de daadwerkelijke voorwaarden van de licentie. Zogenaamde open source-producten, waarbij de vier door mij genoemde gebruiksrechten niet aanwezig zijn, zullen daarbij door de mand vallen en mogen wat mij betreft niet langer meeliften op de soortnaam 'open source'. Het OSOR-programma van de Europese Commissie gaat daarbij overigens nog een stap verder en noemt alle software waarbij niet een viertal basisvrijheden zijn gewaarborgd simpelweg 'proprietary software'.
Daarbij heb ik overigens niets tegen de gehanteerde businessmodellen. Wel denk ik dat er sprake is van misleidende reclame wanneer leveranciers ten onrechte de indruk wekken dat hun gehele product open source is terwijl dat klaarblijkelijk niet het geval is. Onder misleidende reclame wordt verstaan elke vorm van reclame door een professionele verkoper, die een koper op enigerlei wijze, of het nu door de formulering of de opmaak is, zodanig misleidt of kan misleiden dat dit de keuze van de producten of diensten die een koper wenst te kopen beïnvloedt, of die door haar misleidende karakter het economisch gedrag van een koper kan beïnvloeden of een concurrent schade toebrengt of kan toebrengen.
Het gebruik van de term 'commerciële open source' wekt tot slot ten onrechte de suggestie dat er met 'gewone' open source-software geen geld kan worden verdiend. Er bestaan echter genoeg voorbeelden van (Nederlandse) bedrijven die er wel in slagen om met dienstverlening rond deze 'normale' open source, en dus met alle voordelen van open source-software intact, een commercieel succes te behalen.
Ik begin me steeds vaker af te vragen of de overheden nu echt wel voldoende hebben nagedacht over de keuze om open source voor te schrijven.
Even los van de discussie over voor- en nadelen van open source (een dergelijke discussie is namelijk vergelijkbaar met Windows versus Linux adepten), lijkt het mij veel beter om je als overheid te beperken tot het eisen dat aan Open Standaarden voldaan wordt.
Of dat nu met open source bereikt wordt (die garantie heb je overigens ook totaal niet) of met de zogenaamde close source producten is dan minder interessant.
@Oene Doevendans: Microsoft heeft met OOXML bewezen dat je met een open standaard (ISO/IEC 29500:2008) in de documentatie kunt verwijzen naar andere documentatie die voor anderen niet toegankelijk is. Daarnaast zijn er conflicten met andere standaarden van de ISO en bugs in MS Office die nu ineens de standaard zijn geworden. De besluitvorming over deze standaard is ook zeer discutabel, het is maar de vraag of je daarmee wil worden geassocieerd, dit soort “open standaarden” zijn volkomen waardeloos.
Verder blijft goed licentiebeheer vereist, maar dat is met closed source niet anders. Zie de opmerkingen van Balmer over het licentiebeleid van Microsoft. Hij is daar zelf ook niet tevreden over maar ziet geen oplossing om het om korte termijn eenvoudiger te maken. Licentiebeleid moet dus altijd worden gedaan, kost je dus altijd tijd en dus geld.
Met open source leg je in elk geval het vuur aan de schenen van de closed source leveranciers, dat financieel voordeel kun je direct opstrijken. Open source zal niet altijd een open standaard opleveren, je kunt wel altijd bij je code en data komen, dat is inherent aan open source. Mits het natuurlijk wel echt open is en niet slechts een verkooppraatje.
Prikkelend artikel.
Ik sluit me deels aan bij Oene. De vraag is in hoeverre het besloten deel de afnemer beperkt in verdere ontwikkeling, leverancierskeuze en/of interoperabiliteit.
Open source broncode blijft altijd open source ook al is het gecombineerd met gesloten broncode.
Een leverancier is niet verplicht om open source broncode mee te leveren. Het mag ook duidelijk maken waar dit gedownload kan worden. Uiteraard is dit niet van toepassing op het gesloten deel.
Licenties als MPL staan combineren van open source met gesloten delen toe. Deze licentie is zelfs erkend door de Free Software Foundation.
Kunnen we op basis van je artikel concluderen dat je het niet eens bent met de FSF?
Ik ben benieuwd naar concrete voorbeelden van bedrijven die volgens jou niet aan de 4 door jou gestelde criteria voldoen.
Ook ben ik benieuwd naar de bronnen achter het volgende statement: “Regelmatig blijkt uit een dergelijk onderzoek dat deze rechten niet of zeer beperkt aanwezig zijn bij de zogenoemde ‘commerci�le open source’.”