6 Ideas erróneas sobre Licenciamiento de Oracle muy caras

Ago 28, 2023 | Auditorías de software

El licenciamiento es un tema complejo y crucial que afecta a activos –los de software- que son absolutamente críticos para el funcionamiento de muchas empresas hasta el punto que las ideas erróneas sobre licenciamiento de Oracle (cualquiera de ellas en realidad) puede derivar en incumplimientos susceptibles de impactar en el core mismo del negocio y en nuestra competitividad.

A través de nuestra experiencia, hemos comprobado cómo ciertas asunciones falsas e ideas erróneas se repiten sistemáticamente con relación al licenciamiento de Oracle: Y el problema es que estos errores, pueden llevar a incumplimientos y los incumplimientos en materia de licenciamiento suponen muchas veces exposiciones financieras desmedidas y reclamaciones formales de muchos ceros por parte de Oracle.

En este artículo, enumeraremos las principales ideas erróneas sobre licenciamiento de Oracle que (aún hoy) nos seguimos encontrando para aclararlas y poder aportar así información que permita evitar riesgos y exposiciones financieras innecesarias en la gestión de un activo absolutamente crítico para nuestro negocio.

Idea errónea #1: El licenciamiento de Oracle es similar al de otros proveedores de software

Una de las ideas erróneas más comunes es creer que el licenciamiento de Oracle sigue el mismo esquema que el de otros proveedores de software: Nada más lejos de la realidad.

Ya no es que Oracle tenga un licenciamiento diferente al de otros fabricantes, que lo tiene, sino que incluso dentro de Oracle pueden variar las reglas de licenciamiento dependiendo de factores como el tipo de producto o la edición.

Un buen ejemplo de esto es, por ejemplo, la diferencia en la definición de métrica Processor entre:

  • Oracle Database Enterprise Edition: donde se tiene en cuenta el número de cores para multiplicarlo por el core factor aplicable
  • Oracle Database Standard Edition 2: donde no aplica el cómputo de cores ni la aplicación del core factor sino el concepto de socket ocupado

Es crucial en licenciamiento no dar nunca nada por supuesto, tener un buen conocimiento de los derechos de uso adquiridos y saber, caso por paso, qué reglas de licenciamiento aplican.

Idea errónea #2: Solo hay que licenciar donde se usan productos de Oracle

A pesar de que la definición contractual de la métrica Processor establece que hay que licenciar todos los procesadores en los que Oracle esté instalado y/o en uso, lo cierto es que existen matices:

Oracle establece por ejemplo en sus políticas que ciertas tecnologías de virtualización consideradas “soft partitioning” no son un medio apto para limitar el número de licencias software requeridas para un servidor o cluster de servidores: Para saber más sobre Oracle Partitioning Policy de Oracle, pinche aquí.

Esto supone en la práctica que, en entornos virtualizados con tecnología considerada soft partitoning (ej. VMware), Oracle obligue a licenciar hosts o granjas enteras en los que sus productos no se están utilizando: Dicho de otra manera, en ciertos supuestos Oracle obliga a licenciar entornos simplemente por la posibilidad de que sus productos se termine usando en ellos… aunque realmente no se están usando en ellos, lo que supone reclamaciones desproporcionadas: Para saber más, pinche aquí o descárguese nuestro White Paper.

Por otra parte, en la Partitioning Policy, se establecen excepciones en las que Oracle reconoce la sub-capacidad y por tanto la limitación de los cores que van a tenerse en cuenta para determinar el número de licencias requeridas, como por ejemplo:

  • Hard Partitioning
  • Trusted Partitions y Capacity on Demand: para saber más sobre Exadata Licensing, pinche aquí.

El problema es que el incumplimiento de cualquier condición lleva a que no se reconozca la sub-capacidad y por tanto a que se exija de nuevo el licenciamiento de todos los cores (con independencia de lo que realmente se está usando), por lo que es crítico llevar a cabo una revisión detallada del impacto del licenciamiento de Oracle y contar con ayuda especializada e independiente para comprender qué reglas aplican y cómo podemos protegernos frente a posibles reclamaciones en este ámbito.

Idea errónea #3: Sólo se requiere licenciar a los usuarios que utilizan el software de Oracle

Es importante tener en cuenta que puede ser necesario licenciar un número diferente de usuarios que el de personas que están utilizando el software de Oracle.

En este sentido, es fundamental entender la regla de mínimos y cómo puede cambiar en función del producto o de la edición del producto. Así:

  • En Oracle Database Enterprise Edition, se requiere un mínimo de 25 Named User Plus (NUP) por Processor.
  • En Oracle Database Standard Edition sin embargo, se necesita un mínimo de 10 Named User Plus por servidor.
  • Mientras que en productos como Weblogic Suite el mínimo es de 10 Named User Plus por Processor.

Hay que tener además en cuenta que, a efectos de licenciamiento, un “dispositivo no humano” puede tener la consideración de usuario y debe licenciarse.

Además, hay que saber también que en entornos donde el número de usuarios no se puede potencialmente contar ni identificar, Oracle va a obligar a licenciar el entorno con métrica Processor y no con Named User Plus: esto puede tener mucha relevancia en casos de acceso de usuarios a través de internet o en escenarios de multiplexing donde tienen que tenerse en cuenta los usuarios finales en el front end.

Asimismo, en los productos que se licencian mediante métrica Employee (como Java SE Universal Subscriptions) deben adquirirse licencias para todos los trabajadores de la empresa (además de agentes, contratistas o outsourcers que trabajen para tus operaciones internas de negocio…) con independencia de que estén utilizando el software o no.

Idea errónea #4: Solo hay que licenciar los entornos de producción

Algunas empresas creen erróneamente que pueden utilizar Oracle por defecto en entornos no productivos (por ejemplo de desarrollo o test) sin licenciar.

Hay que tener muy claro que, si bien excepcionalmente Oracle puede ofrecer excepcionalmente licencias de prueba siempre que se cumplan ciertas condiciones, el principio general que aplica es que todos los entornos en los que se utiliza Oracle (con independencia de que sean productivos o no) deben estar siempre licenciados.

Esto aplica también a los entornos de Disaster Recovery: el principio general es que deben estar siempre licenciados si bien Oracle permite excepcionalmente y siempre y cuando se cumplan ciertas condiciones que algunos de estos entornos no se tengan que licencias (ej. failover). Para saber más, descargue nuestro White Paper.

Este punto, también puede adquirir una especial relevancia en caso de certificación de ULA de Oracle.

Idea errónea #5: La nube está exenta de problemas de licenciamiento

Los equipos comerciales han utilizado como argumento de venta que la migración a nube implica olvidarse de los problemas de cumplimiento con las licencias: nada más lejos de la realidad.

Migrar a la nube puede parecer una solución fácil para evitar problemas de licenciamiento, pero no es necesariamente así: Algunos servicios en la nube pueden incluir el uso de productos de Oracle, y la responsabilidad de la licencia sigue recayendo en el cliente.

Es crucial entender los términos de licenciamiento específicos para la nube y asegurarse de que se cumplan adecuadamente para evitar posibles costos inesperados.

Este punto además, al igual que el ya visto de la virtualización, puede tener un impacto reseñable en caso de certificación de ULA. Para saber más, pinche aquí o descárguese nuestro White Paper.

Idea errónea #6: «Mi riesgo financiero en caso de incumplimiento llega hasta el importe que esté pagando en soporte de Oracle»

Nos seguimos encontrando –aunque cada vez menos- con empresas que, por alguna extraña razón, han asumido que su responsabilidad con Oracle está limitada al importe que pagan en soporte.

En este sentido, hemos asistido en numerosas ocasiones a afirmaciones del tipo: “Si pagamos al año a Oracle x, no nos pueden reclamar 10x

Hay que dejar claro que las reclamaciones que pueda hacer Oracle en caso de detectar un supuesto incumplimiento, no guarda ninguna correlación ni con el importe de las licencias que ya se hayan adquirido ni con el soporte que se siga pagando.

Las reclamaciones de Oracle, incluyen además sanción retroactiva para compensar el tiempo que se ha estado utilizando el software sin la debida licencia y puede llegar (lo hemos visto) a cientos de millones de Euros. Ocho ceros, literalmente.

Conclusión

Las empresas son las responsables de cumplir con las obligaciones derivadas de los términos y condiciones de sus licencias Oracle y evitar cualquier tipo de incumplimiento.

Incumplimientos que, como hemos visto, además de suponer exposiciones financieras desproporcionadas, pueden tener además no solo impactos indeseables desde el punto de vista legal o reputaciones sino efectos negativos sobre el mismo funcionamiento del negocio.

Simplemente comprendiendo las aclaraciones aportadas en este artículo, se pueden reducir las probabilidades de incumplimiento, ya no para evitar solamente posibles sanciones sino para dejar claro el compromiso de la empresa en el control de su propio negocio a través de la gestión responsable de sus activos –críticos- de software Oracle.

En Evergreen Compliance, somos ex auditores del fabricante y de Big Four, y sabemos cómo exprimir el valor de los activos de software Oracle, asegurando el cumplimiento y por tanto sin la contrapartida de un riesgo de incumplimiento: Contacte hoy mismo con nosotros y conviértase en nuestro próximo caso de éxito conociendo cómo lo hemos conseguido en otros clientes.

También te puede interesar:

Oracle Audit Triggers: Tendencias en 2023

Oracle Audit Triggers: Tendencias en 2023

Conocer los Oracle Audit Triggers y saber qué puede desencadenar una auditoría de licenciamiento en nuestra empresa, es el primer paso para prepararse de forma efectiva. Desde hace varios meses, y con relación a las auditorías de licencias de Oracle, estamos...