Les logiciels Oracle Technology sont actuellement vendus selon deux unités de tarification (communément dit « metrics ») :
- Le « Processor » pour couvrir l’usage du logiciel pour une machine quel que soit le nombre d’utilisateurs.
- Le « Named User Plus » pour couvrir l’usage du logiciel pour un individu quel que soit le nombre de machines.
La définition de ces unités de tarification détermine aussi bien la façon dont doit être utilisé le logiciel (périmètre et/ou limite de la licence, …) que la façon dont son usage doit être mesuré et quantifié.
Ces définitions peuvent paraitre compliquées et leur portée parfois mal maitrisée peut engendrer des situations de non-conformité d’une ampleur significative.
Cet article explique en détail comment doit être interprétée définition du NUP, quel en est le périmètre, quelles en sont les limites et où sont les risques inhérents à l’usage des licences NUP.
Pour plus de précision, le sujet est découpé en 6 points d’attention édités en 4 épisodes dont voici le deuxième.
Point d’attention n°2 – Le NUP est multi serveurs.
La définition indique : « … autorisée à utiliser le(s) Logiciel(s) Oracle sur un serveur unique ou sur plusieurs serveurs ».
Sauf restriction spécifique mentionnée au contrat, un individu couvert par une licence NUP (Full Use) pour un logiciel donné est autorisé à utiliser ce logiciel sur toutes les applications du client et sur tous les serveurs quel qu’en soit le nombre.
Attention : pour déterminer globalement le nombre de licences NUP nécessaires pour un environnement il faut prendre soin de « dé doublonner ». C’est-à-dire ne pas compter en double un même utilisateur qui accèderait à plusieurs applications distinctes installées sur différents serveurs.
Point d’attention n°3 – Le NUP ne se limite pas à l’usage avéré.
La définition stipule: « …. autorisée à utiliser le(s) Logiciel(s) Oracle …, indépendamment du fait qu’elle l’utilise ou non activement à un instant donné. »
Cela signifie que toute personne pouvant potentiellement accéder à un logiciel Oracle (directement ou indirectement) doit aussi être identifiable, quantifiable et disposer d’une licence. Doivent donc être couverts par des licences NUP les accès potentiels au logiciel.
Attention : l’aspect nominatif occulte parfois le problème d’accès potentiel.
C’est par exemple le cas d’un système d’accès à des locaux dont les portes seraient activées par les employés via un badge nominatif et par les visiteurs via 5 badges génériques (visiteur1, visiteur2, … visiteur5) distribués par le gardien sans vérification / saisie de l’identité de la personne.
Une évaluation rapide du nombre de licences nécessaires pourrait conclure que le nombre de NUP correspond au nombre d’employés + 5 NUP pour 5 badges génériques.
En fait, les badges génériques étant ici distribués à toutes personnes se présentant à l’accueil sans vérification, même s’ils sont quantifiés avec exactitude on ne peut pas prétendre qu’ils soient nominatifs.
Dans ce cas, la licence NUP n’est par conséquent pas applicable et Oracle demanderait l’affectation de licences Processeur sur une telle application.
Dans le prochain épisode 3 seront abordés :
- Point d’attention n°4 – Le NUP ne s’applique pas qu’aux individus
- Point d’attention n°5 – le NUP demande de licencier les accès indirects
Puis, épisode 4 :
- Point d’attention n°6 – le NUP implique de savoir compter le nombre de licences Processeur
Easyteam par son service de Software Asset Management dispose de l’expertise nécessaire pour aider ses clients à maîtriser ce risque et en contrôler parfaitement les impacts.
