Ict-complexiteit zit niet alleen in software zelf; licenties zijn soms nog complexer. Dit is de discussiestelling die Computable-lezers vandaag krijgen voorgelegd.
Licenties voor software kunnen niet alleen gebruik bepalen, maar kunnen ook gebruik verbieden. Hoeveel gebruikers van welk pakket en gaat het daarbij om seats, installs, gelijktijdige gebruikers, connecties met serversoftware, et cetera? Het bijhouden en kloppend hebben van kluwens aan softwarelicenties vormt zo een vak apart. Een kostbaar vak, want het gaat uiteindelijk om geld.
Wordt er niet te weinig betaald en dreigt er een BSA-inval of zelfs pc-gijzeling? En wordt er niet te veel betaald en dreigt er een miljoenenstrop? Dit geldt overigens niet alleen voor de daadwerkelijke gebruikers van software, maar ook voor tussenpartijen die ict-producten en -diensten aanbieden. De ex parte veroordeling van en vervolgens inval bij werkplekaanbieder Wipa maakt dat wel heel duidelijk. Die partner van Microsoft voelt zich nu vast minder geliefd. Licentie-administratie en audits zijn net als relaties: het moet van beide kanten komen, het verdient aandacht en zorg, en het moet op orde zijn. Een vak apart dus. Wat vind jij?
Het hoort geen vak apart te zijn, het moet zo transparant te zijn met eventuele tools dat het geen probleem is.
Ik heb het meegemaakt dat er een dure consultant dagen aan het werk was een licenties uit te zoeken van een bekende database leverancier. Het gebruik van een bepaalde query die niet is afgeschermd en nodig is voor diag kon al een fikse boete opleveren.
De oplossing is niet eenvoudig. Maar een complete analyse van de context biedt wellicht een structurele opening.
De ontwikkeling van software is technisch gezien relatief eenvoudig. De ontwikkeling van de software markt is “iets” complexer. Van “service (klant) gericht” naar “verdienmodel ((eigen) geld) gericht” heeft die marktwerking inmiddels een proces opgeleverd dat bijna(?) onbeheersbaar is vanuit de klant gezien.
De klanten kunnen meerdere kanten uit. Zich aanpassen aan de markt is op dit moment de meest logische richting. Het is echter ook de meest afhankelijke dus onzekere richting en bovendien de duurste…
Een andere richting is het uitoefenen van druk op marktpartijen om de zaken “beter te regelen”. Dat zal optisch zeker gebeuren maar of het inhoudelijk veel zoden aan de dijk zet is niet echt te verwachten. Bovendien dreigen de Amerikaanse verdienmodellen na de komst van Trump nog Amerikaanser te worden.
Angela Merkel pleitte drie geleden, bij de opening van CeBIT dacht ik, voor een Europese variant van het Internet. Duitsland heeft in het begin van deze eeuw ook al pogingen ondernomen om minder leverancier afhankelijk te worden. De recente discussies rond de gemeentelijke open source software in München zijn een voorbeeld van de stelling.
Een structurele oplossing ligt in het anders organiseren van de softwareontwikkeling en daarmee van de bijbehorende (niet aan voorafgaande!) markt. Daarbij kunnen meteen een paar “foutjes” uit het verleden worden opgelost. De meeste software heeft ongeveer dezelfde functies. Echter in de tijd gezien op een verschillend moment ontwikkeld. Bovendien meestal niet op basis van een standaard architectuur. Wel meestal voor een standaard gebruiker, die zelf zijn/haar specifieke aanpassingen moest maken. In de software of in het -min of meer unieke- werkproces.
De inmiddels volwassen geworden gebruikers/samenleving zouden samen de generieke functies kunnen definiëren waaraan hun software moet voldoen. De specifieke, op individuele eisen gebaseerde software, kan hier bovenop worden gedefinieerd. Een goed project voor in eerste instantie het onderwijs. Maar nog beter voor de samenleving als geheel…
Het is inmiddels 10 jaar geleden dat ik in (toen nog) tijdschrift Computable het eea schreef over dit onderwerp, en 8 jaar geleden schreef ik er opnieuw iets over in Computable: https://www.computable.nl/artikel/ict_topics/overheid/2979059/1277202/licentiecompliance-overheid-nog-steeds-lastig.html
Een licentie is een juridische overeenkomst met rechten en plichten voor beide partijen. Dat beoordelen is inderdaad een vak apart, en daarom zijn er ook in ICT gespecialiseerde juristen die organisaties hierbij kunnen helpen. Sterker nog, er bestaat al zeker 15 jaar een gespecialiseerde opleiding voor. Het echte probleem is dat de verantwoordelijken voor ICT klaarblijkelijk nog steeds denken dat ze een open hart operatie over kunnen laten aan de huisarts.
De oplossing is niet eenvoudig. Maar een complete analyse van de context biedt wellicht een structurele opening.
De ontwikkeling van software is technisch gezien relatief eenvoudig. De ontwikkeling van de software markt is “iets” complexer. Van “service (klant) gericht” naar “verdienmodel ((eigen) geld) gericht” heeft die marktwerking inmiddels een proces opgeleverd dat bijna(?) onbeheersbaar is vanuit de klant gezien.
De klanten kunnen meerdere kanten uit. Zich aanpassen aan de markt is op dit moment de meest logische richting. Het is echter ook de meest afhankelijke dus onzekere richting en bovendien de duurste…
Een andere richting is het uitoefenen van druk op marktpartijen om de zaken “beter te regelen”. Dat zal optisch zeker gebeuren maar of het inhoudelijk veel zoden aan de dijk zet is niet echt te verwachten. Bovendien dreigen de Amerikaanse verdienmodellen na de komst van Trump nog Amerikaanser te worden.
Angela Merkel pleitte drie geleden, bij de opening van CeBIT dacht ik, voor een Europese variant van het Internet. Duitsland heeft in het begin van deze eeuw ook al pogingen ondernomen om minder leverancier afhankelijk te worden. De recente discussies rond de gemeentelijke open source software in München zijn een voorbeeld van de stelling.
Een structurele oplossing ligt in het anders organiseren van de softwareontwikkeling en daarmee van de bijbehorende (niet aan voorafgaande!) markt. Daarbij kunnen meteen een paar “foutjes” uit het verleden worden opgelost. De meeste software heeft ongeveer dezelfde functies. Echter in de tijd gezien op een verschillend moment ontwikkeld. Bovendien meestal niet op basis van een standaard architectuur. Wel meestal voor een standaard gebruiker, die zelf zijn/haar specifieke aanpassingen moest maken. In de software of in het -min of meer unieke- werkproces.
De inmiddels volwassen geworden gebruikers/samenleving zouden samen de generieke functies kunnen definiëren waaraan hun software moet voldoen. De specifieke, op individuele eisen gebaseerde software, kan hier bovenop worden gedefinieerd. Een goed project voor in eerste instantie het onderwijs. Maar nog beter voor de samenleving als geheel…
De oplossing is niet eenvoudig. Maar een complete analyse van de context biedt wellicht een structurele opening.
De ontwikkeling van software is technisch gezien relatief eenvoudig. De ontwikkeling van de software markt is “iets” complexer. Van “service (klant) gericht” naar “verdienmodel ((eigen) geld) gericht” heeft die marktwerking inmiddels een proces opgeleverd dat bijna(?) onbeheersbaar is vanuit de klant gezien.
De klanten kunnen meerdere kanten uit. Zich aanpassen aan de markt is op dit moment de meest logische richting. Het is echter ook de meest afhankelijke dus onzekere richting en bovendien de duurste…
Een andere richting is het uitoefenen van druk op marktpartijen om de zaken “beter te regelen”. Dat zal optisch zeker gebeuren maar of het inhoudelijk veel zoden aan de dijk zet is niet echt te verwachten. Bovendien dreigen de Amerikaanse verdienmodellen na de komst van Trump nog Amerikaanser te worden.
Angela Merkel pleitte drie geleden, bij de opening van CeBIT dacht ik, voor een Europese variant van het Internet. Duitsland heeft in het begin van deze eeuw ook al pogingen ondernomen om minder leverancier afhankelijk te worden. De recente discussies rond de gemeentelijke open source software in München zijn een voorbeeld van de stelling.
Een structurele oplossing ligt in het anders organiseren van de softwareontwikkeling en daarmee van de bijbehorende (niet aan voorafgaande!) markt. Daarbij kunnen meteen een paar “foutjes” uit het verleden worden opgelost. De meeste software heeft ongeveer dezelfde functies. Echter in de tijd gezien op een verschillend moment ontwikkeld. Bovendien meestal niet op basis van een standaard architectuur. Wel meestal voor een standaard gebruiker, die zelf zijn/haar specifieke aanpassingen moest maken. In de software of in het -min of meer unieke- werkproces.
De inmiddels volwassen geworden gebruikers/samenleving zouden samen de generieke functies kunnen definiëren waaraan hun software moet voldoen. De specifieke, op individuele eisen gebaseerde software, kan hier bovenop worden gedefinieerd. Een goed project voor in eerste instantie het onderwijs. Maar nog beter voor de samenleving als geheel…
Daarom OSS. Dat is wellicht niet gratis maar de verdienmodellen zijn daar doorgaans veel eenvoudiger en het is makkelijker om een support contract af te sluiten plus de licentiemodellen zijn doorgaans ook standaard.
Daar kunnen de voorstanders van ingewikkelde licentiemodellen nog wat van leren. Want daar lijkt het wel alsof het moeilijker is om de software te licenseren dan te gebruiken.
@Johan: Ook bij OSS kun je je aardig vastbijten in de licentievoorwaarden hoor, zo heb ik ervaren. Zeker wanneer je OSS gebruikt als onderdeel van je eigen product dien je de diverse licenties goed te begrijpen om te voorkomen dat je achteraf voor verrassingen komt te staan.
Softwarelicenties zijn inderdaad een vak apart. De software vendoren maken de licentieregels ook steeds complexer en daardoor ondoorzichtelijker waardoor veel klanten door de bomen het bos niet meer zien. Daarnaast hebben de software vendoren het kanaal zo opgezet dat de resellers ook worden ingezet om het advies te geven. Het grote risico bestaat dat dit advies gekleurd is (omdat ze nou eenmaal baat hebben bij de verkoop van zoveel mogelijk licenties). Win je advies dus altijd in bij een onafhankelijke partij (dit levert in de praktijk altijd geld op!).
Met vriendelijke groet,
Kevin Pastor
LicenseConsult Experts BV / LCXP
Your independent software advisor…without revenue target…
Ik denk ook dat het een vak apart is, al ben ik er niet zo zeer van overtuigd dat er een duidelijke strategy van de software publishers achter zit om juist op die mannier achteraf met audit meer geld te verdienen. Uit een ruime ervaring aan beide kanten weet ik dat veel ‘complexe’ regels worden toegevoeg om een het gebruik van een software product te beperken zodat er uiteindelijk een acceptable prijs voor de klant uit komt of om een product vergelijkend te laten zijn met een product van de concurrentie.
Hoe meer keuze mogelijkheden een klant heeft qua deployment, gebruik, inrichting, integratie, etc. des te meer regels er komen om gebruik toe te laten of te verbieden. Hetzelfde is gebeurd in de ziekenkosten verzekering. Als je niet zwanger kunt/wilt worden wil je daar ook geen ziekenkosten voor betalen. Software gebruikers hebben dezelfde eisen; bij een bepaald voorgenomen gebruik wordt de prijs aangepast met regels (restrictions) om het juiste prijs niveau te halen. Daarin moeten geen kosten zitten voor wat toch niet gebruikt wordt. Dit is het meest zichtbaar in enterprise software contracten. Veelal zijn deze regels ‘zachte’ regels, ofwel technisch is het mogelijk maar in de overeenkomst is afgesproken dat niet te doen.
Als je deze keuzes weg haalt, wordt de pricing ook simpler. Een mooi voorbeeld is SaaS Software. Daar is er een hoge mate van standaardisatie en ook de infrastructuur e.d. kan niet bepaald worden door de gebruiker. Het aantal restricties en regels is daar dan ook aanzienlijk minder en de pricing ook veel eenvoudiger.
De kosten om de regels goed in kaart te brengen, te delen met de juiste mensen en van tijd tot tijd te bepalen of er aan deze regels gehouden word is aanzienlijk minder dan de kosten die het heeft om overal maar onbeperkt gebruik voor te betalen. Het is uiteindelijk een economische keuze.