applatenmaken.com/kennisbank/licentievoorwaarden
Als de licentievoorwaarden van uw leverancier veranderen
Microsoft kondigde deze maand aan te stoppen met de gekoppelde VMware-licenties binnen Azure. Voor organisaties die daarop hebben gebouwd is dat geen aankondiging maar een opdracht: kiezen tussen meer betalen en verhuizen. Dit soort wijzigingen komt vaker voor dan het lijkt en raakt vrijwel elke organisatie die software laat bouwen. Deze pagina gaat over hoe u de schade beperkt.
Waarom dit vaker gebeurt
Softwarelicenties zijn de afgelopen jaren van een prijskaartje veranderd in een instrument. Aanbieders gebruiken het model om klanten naar een bepaald product te bewegen, om overstappen duurder te maken, of om na een overname twee portfolio's te harmoniseren. De aankondiging van deze maand over de VMware-licenties binnen Azure is daar een voorbeeld van, en niet het eerste.
Voor u als afnemer van maatwerksoftware is dit zelden een direct probleem en vrijwel altijd een indirect. U koopt de licentie meestal niet zelf; hij zit in de stack waarop uw applicatie draait, of bij uw hostingpartij, of in een component dat uw leverancier heeft gekozen. De rekening komt daarom met vertraging en via een andere partij.
Het patroon is bovendien niet beperkt tot grote infrastructuurpartijen. Ook bibliotheken die jarenlang vrij te gebruiken waren, wisselen soms van licentie zodra er een bedrijf omheen wordt gebouwd. Dat is legaal, gebruikelijk en vrijwel nooit iets waar u van tevoren over wordt geraadpleegd.
- Wat er verandert
- Prijs per eenheid, wat een eenheid is, welke combinaties nog mogen, of de voorwaarden voor commercieel gebruik.
- Waarom het u raakt
- De licentie zit meestal niet bij u maar in de stack, bij uw hoster of in een component dat uw leverancier koos.
- Wat u niet kunt
- De wijziging tegenhouden of terugdraaien.
- Wat u wel kunt
- Weten waar u op leunt, zodat een aankondiging een besluit wordt en geen verrassing.
Waar de afhankelijkheden zitten
De eerste stap is bijna altijd hetzelfde: weten waar u op bouwt. In de praktijk is dat overzicht er niet, of het is gemaakt bij oplevering en sindsdien niet meer bijgewerkt.
| Waar de licentie zit | Hoe u het merkt | Waar u op let |
|---|---|---|
| De infrastructuur waarop u draait | ✓Via uw hostingpartij of uw eigen cloudrekening | !Of uw architectuur aan één aanbieder vastzit of verplaatsbaar is |
| Componenten van derden in de code | ✓Meestal helemaal niet, tot iemand ernaar vraagt | !Dat er een actueel overzicht is met versie en licentie per component |
| Diensten die uw software aanroept | ✓Bij een prijswijziging of een gewijzigde limiet | !Of er een alternatief bestaat en hoeveel werk overstappen is |
| Ontwikkelgereedschap van uw leverancier | !Indirect, via zijn tarief | !Dat het niet uw probleem is, tenzij het in uw prijs wordt doorberekend |
| Databases en middleware | ✓Vaak bij een versie-upgrade of bij groei | !Of de licentie meeschaalt met gebruik, gebruikers of processorkernen |
Het overzicht van componenten is het punt dat het vaakst ontbreekt en het makkelijkst te regelen is. Vraag uw leverancier om een actuele lijst met per component de versie en de licentie. Dat is dezelfde lijst die u nodig heeft als er ergens een kwetsbaarheid bekend wordt, dus u heeft hem sowieso.
Wat u in het contract kunt regelen
U kunt een leverancier niet verbieden zijn voorwaarden te wijzigen, maar u kunt wel afspreken wat er dan met u gebeurt. Deze bepalingen zijn realistisch om te vragen bij een maatwerkopdracht.
Het vierde punt is belangrijker dan het lijkt. Een component met een licentie die commercieel gebruik beperkt, is een probleem dat pas opduikt als uw software succesvol wordt.
Deze punten horen bij de bepalingen over onderhoud en niet bij de bouwafspraken. Wat daar verder in hoort staat in het onderhoudscontract.
Wat u doet als het al gebeurd is
Ligt de aankondiging er, dan is de valkuil om meteen op de aangeboden route te stappen. Aanbieders bieden bij zo'n wijziging bijna altijd een alternatief aan dat toevallig hun eigen product is, en het gemak daarvan verhult dat u opnieuw kiest voor dezelfde afhankelijkheid.
Reken eerst door wat het u werkelijk kost. Niet alleen het verschil in licentiekosten, maar ook wat het zou kosten om níet mee te gaan: het werk van een migratie, het risico en de tijd van uw eigen mensen. In een deel van de gevallen blijkt meebetalen de goedkope optie, en dan is dat een besluit in plaats van een gelatenheid.
Gebruik het moment wel om de bredere vraag te stellen. Een gedwongen wijziging is de goedkoopste aanleiding die u krijgt om te kijken of uw architectuur aan één aanbieder vastzit. Dat is precies de afweging die in soevereiniteit is geen locatie maar rechtsmacht aan bod komt, en die bij zo'n moment concreet wordt in plaats van theoretisch.
Overweegt u een migratie, behandel die dan als een project met een eigen plan en niet als een technische ingreep tussendoor. Wat daarbij komt kijken en waar het meestal misgaat, staat in een oud systeem uitfaseren.
Veelgestelde vragen
Waarom raakt een licentiewijziging bij een grote aanbieder mij?
Omdat de licentie meestal niet bij u zit maar in de stack waarop uw applicatie draait, bij uw hostingpartij of in een component dat uw leverancier heeft gekozen. De rekening komt daardoor met vertraging en via een andere partij, wat het lastig maakt om te zien dat het om dezelfde oorzaak gaat.
Kan ik een licentiewijziging tegenhouden?
Nee. Een aanbieder mag zijn voorwaarden en modellen wijzigen binnen de kaders van zijn eigen overeenkomst. Wat u wel kunt regelen is wat er dan met u gebeurt: dat u vooraf wordt geïnformeerd, binnen welke termijn iets mag worden doorberekend, en of u een opzegmogelijkheid heeft als de kosten boven een grens uitkomen.
Wat is het belangrijkste dat ik nu kan doen?
Een actueel overzicht opvragen van alle componenten van derden in uw software, met versie en licentie. Dat overzicht ontbreekt bij de meeste organisaties of dateert van de oplevering. U heeft dezelfde lijst nodig zodra er ergens een kwetsbaarheid bekend wordt, dus het is werk dat u sowieso moet doen.
Wat gebeurt er als een gratis component betaald wordt?
Dat komt geregeld voor, vooral bij bibliotheken waar een bedrijf omheen is gebouwd. Meestal blijft de bestaande versie onder de oude voorwaarden bruikbaar en gelden de nieuwe voorwaarden vanaf een bepaalde versie. Dat geeft u tijd, maar het betekent ook dat u vast komt te zitten op een versie die geen beveiligingsupdates meer krijgt.
Moet ik meegaan met het alternatief dat de aanbieder aanbiedt?
Niet automatisch. Dat alternatief is bijna altijd hun eigen product, en het gemak ervan verhult dat u opnieuw voor dezelfde afhankelijkheid kiest. Reken eerst door wat meegaan kost tegenover wat vertrekken kost, inclusief het werk en het risico van een migratie. In een deel van de gevallen is meebetalen terecht de goedkoopste keuze.
Wat is een licentie die commercieel gebruik beperkt?
Sommige open bronnen mogen vrij worden gebruikt zolang u ze niet als onderdeel van een commerciële dienst aanbiedt, of verplichten u uw eigen code onder dezelfde voorwaarden te publiceren. Zo'n component in uw software is een probleem dat pas opduikt op het moment dat uw product succesvol wordt, en dan is het duur op te lossen.
Hoe voorkom ik dit bij een nieuw project?
Door bij de architectuurkeuze niet alleen naar functionaliteit te kijken maar ook naar verplaatsbaarheid, en door in het contract vast te leggen dat het overzicht van componenten actueel blijft. Volledig voorkomen kan niet, want u kunt niet buiten alle externe onderdelen. Wat u wel kunt is weten waar u op leunt.
Is dit een reden om alles zelf te bouwen?
Vrijwel nooit. Componenten van derden besparen zoveel werk dat zelf bouwen om licentierisico's te vermijden meestal duurder uitpakt dan het risico zelf. De verstandige middenweg is bewust kiezen: weten welke afhankelijkheden bedrijfskritisch zijn en daar strenger op selecteren dan bij de rest.