ULA vs. PULA: lo que las empresas deben entender

Pocas propuestas de Oracle se presentan con tanto entusiasmo como un contrato ilimitado. La promesa es fácil de entender: dejar de contar, desplegar lo que necesites y pagar una tarifa predecible. Para algunas empresas, esa promesa es real. Para otras, se convierte en un compromiso costoso con productos que nunca terminan de usar, o en una estructura de la que es difícil salir cuando cambia la estrategia.

Este artículo explica la diferencia entre un Unlimited License Agreement (ULA) de Oracle y un ULA perpetuo (PULA), y las preguntas que conviene hacerse antes de firmar cualquiera de los dos.

¿Cuál es la diferencia básica entre un ULA y un PULA?

No existe un documento público de Oracle que defina por completo ninguna de las dos estructuras. Cada una es un acuerdo negociado, y sus términos están en el documento de pedido que firmas. Dicho esto, las estructuras que se usan comúnmente son estas:

• ULA. Durante un plazo fijo, con frecuencia de algunos años, el cliente puede desplegar una cantidad ilimitada de una lista definida de productos, en entidades legales definidas, por una tarifa fija. Al final del plazo, el cliente certifica su despliegue. Las cantidades certificadas suelen convertirse en su posición de licencias perpetuas y el derecho ilimitado termina, salvo que el contrato se renueve.
• PULA. El derecho ilimitado no tiene fecha de fin ni certificación programada. Por lo general continúa mientras se pague el soporte acordado.

La diferencia práctica está en dónde queda el riesgo. En un ULA, una cláusula débil vence en algún momento con la certificación. En un PULA, puede acompañarte mientras exista el contrato.

¿Qué ocurre en la certificación de un ULA?

La certificación es el momento en que un ULA se convierte en algo permanente, y merece tratarse como un acto corporativo formal, no como un trámite.

La mecánica la define tu contrato, así que léelo con atención. Algunos puntos que suelen determinar el resultado:

• La ventana de certificación y los pasos necesarios para completarla.
• Qué se cuenta. Muchos contratos se refieren a lo que está instalado y en ejecución en una fecha determinada, no al pico de uso durante el plazo. Un despliegue planificado “para más adelante” puede no contar.
• Quién firma. La certificación suele ser una declaración realizada por un directivo de la empresa, con el peso legal que eso implica.
• Cierre. Acuerda por escrito qué confirma que la certificación está completa y en qué plazo Oracle confirmará las cantidades certificadas.

Empezar tarde es el error más frecuente y el más caro. Descubrir despliegues, resolver cuestiones técnicas y decidir entre certificar, renovar o salir lleva meses, no semanas.

¿Qué despliegues generan dudas en el conteo?

Varias áreas generan disputas o incertidumbre con frecuencia:

• Virtualización. La Partitioning Policy de Oracle clasifica las tecnologías de particionamiento blando (soft partitioning), incluido VMware, como no permitidas para determinar o limitar la cantidad de licencias necesarias. Por eso, la forma en que se cuente tu entorno virtualizado en la certificación puede ser determinante.
• Nube pública. La política de Oracle sobre licenciamiento de su software en entornos de nube autorizados (AWS, Azure y Google Cloud) establece que las licencias adquiridas bajo un ULA pueden usarse en esos entornos, pero no pueden incluirse en la certificación al final del plazo. Salvo que tu contrato diga otra cosa, las cargas migradas a esas nubes durante el plazo podrían no convertirse en licencias perpetuas.
• Entidades legales. Solo están cubiertas las entidades nombradas en el contrato. Las subsidiarias que se incorporen después, las adquisiciones y las desinversiones necesitan un tratamiento explícito.
• Standby y recuperación ante desastres. Que estos entornos cuenten o no depende de cómo tu contrato define el despliegue.

Ten en cuenta que Oracle presenta estos documentos de política como guías con fines educativos que no forman parte de un contrato. Lo que decide es tu documento de pedido y tu contrato marco; las políticas explican cómo aborda Oracle la cuestión.

¿Por qué el costo del soporte pesa tanto en los contratos ilimitados?

En los contratos ilimitados, el soporte anual suele calcularse sobre el valor del contrato, no sobre la cantidad que terminas desplegando. De ahí se desprenden dos consecuencias:

• Cada producto incluido en el contrato que nunca despliegues encarece igual la tarifa y, por lo tanto, el soporte, potencialmente durante muchos años.
• Certificar un despliegue grande no reduce por sí solo el soporte. Si el soporte cambia en la certificación o la renovación, y cómo, depende de tu contrato.

Antes de firmar, pide el monto del soporte, cómo se calculó y si aplica algún tope a los aumentos futuros. Pide precios con y sin los productos que no tienes claro si necesitas.

¿Cuándo tiene sentido cada estructura?

Un ULA puede encajar cuando la empresa tiene un crecimiento financiado y sostenido en un conjunto definido de productos Oracle y quiere desplegar rápido sin gestionar licencias proyecto por proyecto, conservando un punto final claro para reordenar su posición.

Un PULA puede encajar cuando el entorno es muy grande, se espera que el crecimiento en los productos cubiertos continúe durante muchos años y la organización tiene un compromiso de largo plazo con la tecnología de Oracle.

Ninguno encaja naturalmente cuando el uso es estable o decreciente, cuando hay prevista una migración fuera de los productos cubiertos, cuando se esperan adquisiciones o desinversiones importantes sin un tratamiento contractual claro, o cuando la organización podría querer cambiar su modelo de soporte.

¿Cómo salimos de un PULA si cambia nuestra estrategia?

Esta es la pregunta que hay que hacerse antes de firmar, no después. Como un PULA no tiene certificación programada, la salida no está disponible automáticamente. Salvo que el contrato prevea un derecho de certificación optativa o de salida, salir suele requerir una negociación con Oracle en sus términos.

En cualquier conversación sobre un PULA conviene pedir un derecho de certificación optativa, cláusulas de desinversión que permitan transferir los derechos certificados junto con un negocio vendido, un tratamiento definido para las adquisiciones, un tope a los aumentos de soporte y puntos de revisión periódicos.

¿Un contrato ilimitado interactúa con los programas de nube?

Puede hacerlo. Dos ejemplos tomados de la documentación pública de programas de Oracle:

• El programa Oracle Support Rewards acumula recompensas a una tasa más alta para clientes con un ULA vigente (33% del consumo elegible de OCI, frente a 25% para el resto), aplicables al soporte de licencias de tecnología.
• Las preguntas frecuentes de Support Rewards también indican que los clientes que usan ULA2PaaS no pueden combinar ULA2PaaS con Support Rewards.

Los incentivos de nube pueden ser valiosos, pero deben evaluarse por sus propios méritos. Mantener los compromisos de nube en documentos separados del contrato ilimitado facilita evaluar y modificar cada uno.

Implicaciones prácticas

• Para el CIO: confirmar que la lista de productos coincide con la hoja de ruta real y planificar la evidencia de certificación desde el primer día.
• Para el CFO: modelar el costo total en un horizonte largo, incluido el soporte, frente a la alternativa de comprar licencias convencionales.
• Para compras: pedir cotizaciones comparables para distintas estructuras y cotizaciones separadas para los componentes de nube.
• Para legal: concentrarse en las definiciones de entidades, de despliegue y de conteo, el tratamiento de la nube, la mecánica de certificación y los derechos de salida.

Para grupos que operan en varios países de América Latina, el alcance de entidades merece especial cuidado. Las estructuras regionales suelen incluir subsidiarias en distintos países, entidades contratantes locales y cambios societarios frecuentes. Si el contrato nombra las entidades de forma restrictiva, parte del grupo puede quedar afuera.

Lista de verificación práctica: antes de firmar cualquier contrato ilimitado

Errores frecuentes

• Tratar la certificación como una formalidad. Es una declaración corporativa con consecuencias duraderas.
• Detenerse en el envío. Asegúrate de que el cierre quede confirmado por escrito.
• Renovar sobre un crecimiento que ya se frenó. Una renovación basada en los planes de ayer consolida el sobrecosto de hoy.
• Suponer que “ilimitado” lo cubre todo. Los productos, entidades, territorios y nubes fuera de las definiciones no están cubiertos.
• Mezclar temas sin relación. Incluir hallazgos de auditoría o créditos de nube en un contrato ilimitado dificulta evaluar cada uno.

Preguntas frecuentes