Durante años, Oracle ha vendido a través de los Unlimited License Agreements (ULA) una promesa muy atractiva: “despliega lo que quieras y olvida las preocupaciones (y potenciales riesgos) de una auditoría”.
En Evergreen Compliance vemos organizaciones en España y LATAM que han creído este discurso hasta que realmente se plantean la certificación o aparece en escena la palabra “auditoría”.
Nuestro propósito con el siguiente artículo, más allá del “ULA sí / ULA no”, es ayudar a entender algunas cuestiones esenciales como:
- El funcionamiento real de un ULA (y su primo, el PULA (https://evergreencompliance.com/pula-de-oracle/))
- Por qué este es uno de los últimos dominios donde Oracle sigue utilizando auditorías formales de software
- Qué pasa en la certificación y por qué puede convertirse en una auditoría encubierta (https://evergreencompliance.com/oracle-ula-faq-s/)
- Cómo reducir el riesgo de que, después de certificar, Oracle anuncie una auditoría formal para forzar un nuevo ULA
- Y, sobre todo, qué puedes hacer para recuperar el control.
Qué es realmente un ULA (y por qué gusta tanto a Oracle)
Un ULA de Oracle es un contrato por un período limitado (normalmente 2–5 años) que permite desplegar y usar sin límite únicamente los productos expresamente incluidos en el acuerdo.
Ciertamente, el mensaje que ha tratado de transmitir Oracle de “despliega lo que quieras y olvida las preocupaciones (y potenciales riesgos) de una auditoría”, tiene cierto fundamento ya que mientras el contrato está vigente y el cliente se mantiene dentro del marco pactado, la probabilidad de una auditoría formal baja mucho (aunque no desaparece por completo, especialmente si hay otros productos fuera del ULA, como Java).
Para muchas organizaciones el ULA tiene tres atractivos claros:
- Simplicidad aparente por no tener que calcular procesadores, usuarios ni métricas (lo que implica no tener que gestionar y por tanto disparar las posibilidades de que afloren incumplimientos que después pueden costar muy caros).
- Cobertura en escenarios de necesidad masiva de licencias: adquisiciones de empresas, consolidaciones, fusiones, cambios de infraestructura, etc.
- Sensación de “inmunidad” frente a auditorías: la idea (muy extendida) de que mientras se tenga un ULA, Oracle no va a auditar.
Pero el problema aquí de fondo no es el ULA en sí, sino más bien cómo y en qué condiciones se entra y, sobre todo, cómo se sale (lo cual no le hace a Oracle ninguna gracia).
El modelo económico de Oracle con los ULA
Oracle ha ido orientando cada vez más su negocio hacia servicios cloud y soporte de licencias, que hoy concentran la mayoría de sus ingresos recurrentes. En sus últimos resultados financieros, la compañía indica que los servicios cloud y el soporte de licencias son con diferencia su principal fuente de facturación.
Además, el soporte de software de Oracle es un negocio de altísimo margen (con márgenes de alrededor de un 90% según diversos análisis del mercado). Y esos ingresos de soporte se calculan, de forma estándar, como un 22% del precio de lista de las licencias, con incrementos anuales que hacen que la factura crezca incluso aunque no se añadan nuevos productos gracias al Inflationnary Adjustment Rate (IAR) de Oracle.
¿Dónde encaja el ULA aquí?
- Cada nuevo ULA consolida y aumenta la base de soporte: se suman las licencias antiguas más las nuevas ilimitadas, y el soporte resultante se convierte en la “nueva normalidad”.
- En la práctica, el cliente paga por las licencias históricas y por el nuevo paquete “ilimitado”, generando una dependencia económica muy difícil de revertir.
Desde la óptica de Oracle, tiene todo el sentido: ingresos recurrentes, previsibles y crecientes. Desde la óptica del cliente, si no se gestiona bien, el ULA puede degenerar en una surte de “ULA as a Service” y convertirse en una dependencia estructural.
ULA como uno de los últimos territorios de auditorías formales
Aunque parte de la atención se ha desplazado en estos últimos tiempos hacia temas como Java o la nube, los ULAs siguen siendo uno de los últimos dominios donde Oracle utiliza con fuerza la herramienta de la auditoría.
Lo vemos en dos momentos clave:
Durante la vida del ULA:
-
- Formalmente, Oracle puede auditar aunque haya un ULA vigente, especialmente para productos no cubiertos por él o para comprobar el uso correcto (por ejemplo, Java).
- En la práctica, no es frecuente que lance una auditoría formal en pleno ULA, pero sí puede utilizar supuestos incumplimientos como argumento para forzar renovaciones o nuevos acuerdos.
Al aproximarse y después de la certificación:
Es aquí donde Oracle concentra buena parte de sus esfuerzos:
- Certificación convertida en auditoría encubierta.
- Y, si sospecha infracertificación o desajustes (especialmente en entornos virtualizados o cloud), posible anuncio de auditoría formal una vez cerrada la certificación.
En otras palabras, y a través de nuestra experiencia, el ULA no elimina el riesgo de auditoría sino que lo desplaza y lo concentra en la fase más delicada (y que más quiere evitar Oracle), que es la salida.
La certificación: el momento en el que la “tranquilidad” se convierte en riesgo
La certificación del ULA es el proceso mediante el cual el cliente declara a Oracle cuántas licencias de los productos incluidos en el ULA tiene instaladas y/o en ejecución (que es como debiera ser por la definición de Processor y no como aparece redactado en ciertos contratos) en la fecha de finalización del período ilimitado. Suele haber un plazo muy breve (por ejemplo, un mes) para remitir esa información.
Sobre el papel suena sencillo. En la realidad, es un terreno plagado de riesgos que pueden condicionar nuestro futuro con un proveedor estratégico como es Oracle:
Definiciones que no encajan con la realidad técnica
- Efectivamente, la certificación suele hablar de instalado y en uso, mientras que las métricas de licenciamiento (como Processor) se basan en dónde está instalado y/o en uso, incluyendo hosts donde el producto puede potencialmente ejecutarse, aunque no lo haga de hecho.
- En entornos virtualizados tipo VMware, donde aplican las políticas de soft partitioning de Oracle, por ejemplo, esto significa que hay que licenciar clústeres completos si se cumple determinado diseño técnico, no solo las VMs que realmente usan Oracle.
Un error de interpretación aquí puede llevar a:
- Subestimar el número de licencias en la certificación (infracertificación).
- Dejar fuera productos u opciones activadas “sin querer” (por ejemplo, opciones de base de datos habilitadas por defecto).
Ambos escenarios son munición perfecta para que, más adelante, Oracle utlice la certificación en nuestra contra.
El papel de cloud en el ULA
Otra trampa frecuente es el uso de productos del ULA en cloud:
- Muchos contratos permiten desplegar productos del ULA en determinados entornos cloud durante la vigencia.
- Pero no siempre permiten que esos despliegues cuenten para la certificación, o lo condicionan a cláusulas muy concretas.
Resultado típico: el cliente ha construido parte de su arquitectura en cloud asumiendo que “todo está cubierto por el ULA”, pero al certificar descubre que no puede convertir en licencias perpetuas lo que tiene desplegado allí. Eso abre la puerta a:
- Escenarios de incumplimiento post-ULA si sigue usando esos recursos.
- Presión comercial para renovar el ULA o pasar a un modelo cloud de Oracle en condiciones poco favorables.
Cuando la certificación se convierte en auditoría encubierta
En Evergreen Compliance vemos a menudo certificaciones donde:
- Oracle quiere implicar obligatoriamente a su equipo de LMS/GLAS.
- Solicita scripts, inventarios e informaciones muy similares a las de una auditoría formal.
- Extiende el alcance más allá de los productos del ULA o introduce temas como Java, PULA, cloud, etc.
El mensaje suele presentarse como “ayuda para certificar correctamente” o “información prevista en contrato”. En la práctica, Oracle está recopilando información que no va a dudar en utilizar para:
- Argumentar que la certificación es poco fiable o incompleta.
- Plantear que existe un riesgo de incumplimiento significativo.
- Forzar una renovación del ULA como “solución” a esos riesgos.
Después de certificar: por qué aún puede aparecer una auditoría formal
Incluso cuando el cliente ha certificado y Oracle ha aceptado (al menos formalmente) esa certificación, el riesgo no desaparece.
Oracle sigue manteniendo en sus contratos un derecho de auditoría que puede ejercer con posterioridad, y que en el ámbito de bases de datos, middleware y ULAs sigue siendo una de las palancas comerciales más potentes.
Los escenarios que más vemos como detonantes de una auditoría después de la certificación son:
- Sospecha de infracertificación:
- Números “demasiado bajos” para lo que Oracle esperaba teniendo en cuenta entornos virtualizados o de cloud (una certificación puede nacer muerta su no se aplican las mismas reglas para la determinación del despliegue de las licencias que Oracle va a emplear en caso de auditoría -> Esto es muy muy importante).
- Diferencias llamativas respecto a las previsiones internas que el equipo comercial de Oracle había manejado cuando se diseñó el ULA.
- Desajustes técnicos posteriores:
- Cambios en la plataforma (nuevas granjas de virtualización, movimientos a cloud, fusiones, etc.) donde Oracle percibe que la organización no está gestionando bien el licenciamiento.
- Uso de productos no incluidos en el ULA o activación de nuevas opciones no licenciadas.
- Oportunidad comercial:
- Fin de un ULA o PULA “pequeño” en comparación con el parque real de Oracle.
- Objetivos comerciales internos que empujan a renovar o ampliar contrato.
En todos estos casos, anunciar una auditoría formal es una forma muy eficaz de recuperar palanca de negociación y volver a poner sobre la mesa la opción de un nuevo ULA como “salida razonable”.
Cómo romper el ciclo: recomendaciones prácticas
La buena noticia: es posible utilizar un ULA (o un PULA) de forma estratégica, sin caer en la trampa de la dependencia permanente. Pero exige cambiar el enfoque: considerar el ULA solo ante escenarios de necesidades masivas de licencias, dejar de “pagar por tranquilidad” y empezar a gestionar activamente el contrato.
Empezar la preparación de la certificación con mucha antelación
Para ULAs complejos, es razonable empezar a preparar la certificación 12–18 meses antes de la fecha de fin, especialmente si se quiere optimizar el resultado y reducir riesgos.
Eso implica:
- Tener una posición efectiva de licenciamiento clara y basada, únicamente, a partir de la metodología e interpretaciones que hace Oracle en sus auditorías de software: de nada sirve aplicar e interpretar nosotros el licenciamiento a nuestra manera si después va a venir a Oracle y va a determinar una situación totalmente diferente que nos puede meter en problemas.
- Revisar arquitectura de virtualización, clusters, DR, entornos de pruebas, etc. y conocer el impacto que tiene en licenciamiento Oracle.
- Revisar despliegues en cloud y su encaje con las cláusulas de certificación, conociendo también el impacto que tiene en licenciamiento.
Tratar la certificación como una “pre-auditoría interna”
Antes de enseñar nada a Oracle, es recomendable hacer un ensayo general interno:
- Emplear la misma metodología, e interpretaciones, que la utilizada por Oracle en sus auditorías reales.
- Identificar posibles focos de riesgo.
- Simular distintos escenarios de certificación, siempre muy controlados, empleando las posibilidades que el licenciamiento de Oracle nos ofrece (ej. política de soft partitioning).
El objetivo es que la organización llegue a la certificación sabiendo:
- Qué números quiere declarar y si esos números cubren las necesidades actuales e incluso a medio-largo plazo.
- Qué riesgos conlleva cada escenario.
- Qué estrategia de negociación seguirá (certificar y salir -recomendable 9 de cada 1º veces-, renegociar a la baja, etc.).
Controlar el perímetro de la certificación frente a Oracle
Cuando Oracle empieza a pedir información:
- Definir claramente el alcance: certificación del ULA ≠ auditoría general.
- Negociar quién participa (LMS/GLAS sí o no, en qué términos, etc. ).
- Evitar compartir innecesarios para la certificación (y menos sin saber el impacto que pueden tener a la hora de determinar la situación de cumplimiento).
La idea aquí no es confrontar, sino mantener el proceso bajo control y tratar de minimizar al máximo los riesgos al mismo tiempo que exprimimos las posibilidades de la certificación del ULA.
Prepararse para el “día después” del ULA
Salir de un ULA (o de un PULA) no significa “problema resuelto”. Significa que:
- A partir de la certificación, vuelves a un modelo clásico de licencias perpetuas con soporte (el pactado cuando se firmó el ULA con independencia de la cantidad de licencias certificadas, esto es muy importante mantenerlo siempre en la cabeza) y con derecho de auditoría.
- Si no gestionas bien los cambios posteriores (nuevos entornos, cloud, fusiones, etc.), puedes generar en pocos meses un escenario perfecto para una auditoría.
- Ya no digamos si ha habido errores y la certificación “ha nacido muerta” por no comprender todas las licencias instaladas y/o en ejecución.
Por eso, es clave definir una gestión del licenciamiento post-ULA y revisar periódicamente la posición efectiva de licenciamiento.
Cómo ayuda Evergreen Compliance en este contexto
Desde Evergreen Compliance trabajamos precisamente en este punto de fricción entre lo contractual, lo técnico y lo financiero:
- Ayudamos a nuestros clientes a definir si un ULA/PULA tiene sentido en su contexto o si existen alternativas más eficientes.
- Diseñamos y ejecutamos proyectos de salida y certificación de ULAs y PULAs: desde la recogida y depuración de datos técnicos hasta la negociación con Oracle.
- Hemos acompañado a clientes en certificaciones con volúmenes de licencias muy significativos (> 1.000 M €), maximizando el ROI y neutralizando riesgos de auditoría posteriores.
- Y, una vez certifican, les ayudamos a evitar volver a caer en la espiral de “comprar tranquilidad” cada vez que Oracle llama a la puerta, asegurando que únicamente se paga por lo que se usa Y necesita.
Conclusión
Un ULA bien planteado puede ser una herramienta poderosa para acompañar un crecimiento real, ordenado y controlado. El problema aparece cuando el contrato se utiliza como sustituto de una gestión profesional del licenciamiento.
En el dominio de Oracle, y especialmente en el ámbito de ULAs y PULAs, la auditoría sigue siendo una realidad muy presente: quizá no durante los años del despliegue ilimitado (aunque podría darse!), pero sí en el momento clave de la certificación y posteriormente si Oracle ve posibilidades comerciales.
La verdadera “tranquilidad” no viene de firmar más ULAs.
Viene de saber exactamente qué usas y necesitas, cómo estás licenciado, qué dice el contrato y cómo te afecta, y cómo quieres que sea la relación con Oracle en los próximos 5–10 años.
En el momento en que dejas de pagar por comodidad y empiezas a pagar por control y estrategia, dejas de estar atrapado en el ULA y vuelves a recuperar el control.
