Après ULA, . Comprenez : après l’Unlimited License Agreement, le . Soit des installations à volonté, sans limite de durée contre une redevance annuelle. Les CIO en rêvaient, Oracle pourrait annoncer tout prochainement cette nouvelle licence pour ses bases de données. Un changement radical de la part du géant des DBMS décrié pour les méandres de son .

Selon The Register, les clients auraient l’occasion de piocher sans limite dans le catalogue . PULA reposerait sur le paiement d’une redevance annuelle -calculée par sur base de l’usage estimé au sein de l’entreprise concernée- couvrant le déploiement illimité de bases de données et de leurs options.

PULA permettrait surtout aux clients d’éviter les coûts d’achat de licence, bref de passer dans un modèle plutôt que CAPEX. Surtout, la logique de PULA devrait enlever une épée de Damoclès au-dessus de la tête de nombre de CIO : celle des audits d’Oracle ! Depuis plusieurs années, l’éditeur a fait de LMS (License Management Services), son bras armé en matière d’audits de licences, un des moteurs de son activité. A croire certains spécialistes dans le conseil en licensing, LMS serait à l’origine d’un euro engrangé sur deux par l’éditeur au logo rouge…

Qui plus est, cette licence -qui n’est pas sans rappeler le modèle du (Software as-a-Service) constitue une façon pour l’éditeur américain de barrer la route à ses concurrents agressifs : Postgres, MongoDB ou Cassandra. Ou ceux qui, à l’instar de SAP avec HANA, tentent d’écarter Oracle de leur base installée !

Il y a cependant fort à parier qu’il n’y aura pas de grille tarifaire claire -en tout cas pas publique. Et que ce prix sera le fruit, en réalité, d’une négociation commerciale. Bref, à existants égaux, deux licences PULA chez deux clients différents risquent de ne pas être facturées au même montant !

Sommaire
Oracle peaufine une licence illimitée et perpétuelle
Titre
Oracle peaufine une licence illimitée et perpétuelle
Description
PULA d'Oracle permettrait surtout aux clients d’éviter les coûts d’achat de licence, bref de passer dans un modèle OPEX plutôt que CAPEX
Auteur