Los siete pecados capitales que conducen a una auditoría de Oracle
Oracle es notorio por su confusa política de licencias. Aquí hay siete comportamientos que pueden llevar a una auditoría y sus costosos honorarios.
Las políticas de licencias de Oracle son notoriamente vagas y confusas. Un paso en falso y puede terminar debiendo miles de dólares en honorarios de auditoría. Sin embargo, el software de Oracle, con su deslumbrante variedad de módulos de administración y opciones preinstaladas, es fácil de usar de modo indebido; tan fácil, de hecho, que usted podría encontrarse fuera de cumplimiento y navegando por altos mares de la piratería antes de poder decir "Barba Negra".
Y no crea que Oracle no lo perseguirá. Según un reciente informe de Flexera/IDC, el 63% de las organizaciones encuestadas fueron auditadas por un proveedor de software en los últimos 18 a 24 meses, y 56% tuvo que pagar tasas adicionales, muchas por más de un millón de dólares. Oracle es reconocido habitualmente como uno de los mejores auditores entre los proveedores de software, ejercitando con gusto su derecho a asegurar que los clientes siguen la línea, sin importar cuán confusas sean las reglas.
Esta perspectiva es particularmente preocupante si considera que el 85% de las organizaciones encuestadas están fuera del cumplimiento con sus acuerdos de licencia de software. Es probable que su empresa sea una de los delincuentes, sobre todo si está ejecutando productos de Oracle. Aun así, no siempre está claro qué pecados ha cometido para llegar allí. Aquí nos fijamos en siete de los más comunes –y generalmente los más mortales– comportamientos que pueden resultar en esas contenciosas auditorías de Oracle y los exorbitantes honorarios de licencias que siguen.
La falta de inventario de licencias
Hacer el seguimiento de la documentación de licencias de su software puede ser una tarea desalentadora. Además de los acuerdos de servicio y licencias (OLSA) de Oracle, usted debería tener acceso a los historiales completos de órdenes, fechas de renovación, ofertas de descuento y cualquier otra información relevante para sus inversiones en software. Si usted está trabajando con acuerdos OLSA viejos, también es necesario realizar un seguimiento de los nombres de productos y métricas que han cambiado con el tiempo.
La disponibilidad de la información de licencias es esencial para comprender plenamente qué productos ha adquirido y cómo usted está autorizado a utilizar estos productos. Una licencia de uso completo (FU), por ejemplo, es muy diferente de una licencia de uso completo específica para la aplicación (ASFU). Si no se hace seguimiento de esta información, la incertidumbre puede surgir en una serie de áreas, incluyendo la precedencia de los contratos cuando se producen conflictos entre un OLSA y diversas adendas.
No saber lo que está instalado dónde
Igualmente importante que saber lo que está autorizado a hacer es saber lo que realmente está haciendo. Sin embargo, pocas organizaciones tienen un inventario completo de qué productos han implementado, y mucho menos qué ediciones o versiones. Lo que complica las cosas es que usted puede fácilmente utilizar las opciones y módulos de administración sin que estén licenciadas.
El reto con el software de Oracle, en particular, es que las opciones de productos y módulos de administración se instalan con los principales productos y se activan por defecto. Esto es particularmente cierto para las ediciones empresariales. Los administradores pueden utilizar fácilmente estas características, incluso si no tienen licencia. Para organizaciones que implementan software en numerosos servidores, en múltiples ubicaciones, las posibilidades de estar fuera de cumplimiento crecen exponencialmente.
Malentendido de métricas
Determinar el uso apropiado del software puede ser un negocio difícil cuando se trata de aplicar las métricas correctas. Por ejemplo, un administrador puede utilizar tanto las métricas de Procesador y Usuario Nombrado Extra (Named User Plus o NUP) al instalar un producto en un solo servidor. Otro administrador podría confundir las métricas de legado, como Usuarios Simultáneos (Concurrent Users), con métricas actuales, como NUP.
Muchas de las cuestiones relacionadas con el uso indebido de métricas se plantean debido a un conteo incorrecto. Por ejemplo, una organización que utiliza la métrica de Procesador podría no contar núcleos o enchufes ocupados, o no redondear el número de núcleos al siguiente número entero para cada procesador. Cuando se utiliza la métrica NUP, las empresas subestiman sistemáticamente el número real, sin tomar en cuenta los requisitos mínimos o sin contar los usuarios indirectos, como los que acceden al software a través de las aplicaciones conectadas en serie. Cada vez que usted está tratando con los productos de Oracle, puede estar seguro de que no hay tal cosa como una métrica simple.
Virtualización indiscriminada
Una de las mayores trampas en el mundo de las licencias de Oracle es la virtualización, donde es tan fácil caer en incumplimiento que puede ser mejor que escriba su cheque ahora si Oracle decide auditar. Uno de los retos es que Oracle soporta solo la partición de hardware, no la partición de software que se obtiene con VMWare. Como resultado, debe licenciar todos los procesadores y núcleos accesibles al producto de Oracle.
Pero que por lo general no es lo que sucede. En cambio, las organizaciones licencian las particiones lógicas, pero no tienen en cuenta los procesadores físicos del hardware subyacente. Cuando se establece un entorno virtual, necesita tener en cuenta toda la arquitectura del sistema, incluyendo las máquinas virtuales, agrupaciones y almacenamiento. Un pequeño desliz podría costarle más que la licencia original.
Tolerancia a fallos mal administrados
Las organizaciones también tienden a caer fuera de cumplimiento al implementar la recuperación de desastres y alta disponibilidad. Por ejemplo, podrían dejar licenciar nodos de clúster de conmutación por error o servidores utilizados como espejos y de espera, a menudo porque creen que estos componentes no necesitan tener licencia. En otros casos, podrían utilizar diferentes métricas para licenciar distintos nodos.
Muchas organizaciones también fallan en tener en cuenta los trabajos de mantenimiento en los servidores de conmutación por error o se olvidan de volver de un nodo secundario a uno primario después de que una situación de conmutación por error se ha resuelto. Además, es posible que se olviden de la licencia de las opciones y módulos de administración en sus servidores de reserva, a pesar de que tienen licencia en las primarias. Los entornos en clúster también tienden a agravar otras violaciones, como las relacionados con las métricas mal aplicadas y la virtualización díscola.
El mal uso de licencias
Ya sea intencional o no, muchas organizaciones utilizan el software de Oracle de manera que la licencia no permite. El ejemplo clásico es el Acuerdo de Licencia Ilimitada (ULA), que se interpreta a menudo como una mezcla heterogénea de software que le otorga el derecho de usar casi cualquier cosa, en cualquier lugar que desee. Sin embargo, un ULA limita qué productos puede utilizar, dónde puede utilizar esos productos, y el tiempo que puede utilizarlos.
Pero ULAs no son la única trampa. Una organización puede modificar una aplicación Oracle sin actualizar la licencia, ejecutar varias ediciones de productos en un único servidor, pero licenciar solo uno, o no cumplir con las restricciones de hardware obligatorias al instalar ediciones específicas de software. De hecho, usted puede encontrarse utilizando productos de Oracle en muchas formas en que las licencias no lo pretenden, y este tipo de prácticas pueden convertirse en empresas costosas si Oracle se enterara alguna vez.
Implementaciones indiscriminadas
El último de los siete pecados capitales, pero ciertamente no menos importante, es la instalación de productos sin pagar por una licencia de ningún tipo. Los entornos no productivos son quizás algunos de los mayores culpables. Oracle espera que usted licencie sus entornos de desarrollo, pruebas y preproducción, como lo haría con un entorno de producción. Usted debe tener en cuenta a los usuarios, procesadores, ediciones, versiones, módulos de administración y todas esas opciones incorporadas. Y no se deje engañar por la complacencia de la licencia Oracle Technology Network (OTN). No es tan despreocupada como se podría esperar.
Luego están todos esos otros lugares que usted puede deslizar, como los dispositivos operados por no humanos. Ellos pueden no requerir de una persona real para ejecutarlos, pero todavía deben cumplir con las licencias de Oracle y ser contados como otros usuarios. Las transferencias de datos también pueden caer en el agujero negro de las licencias si no tiene cuidado. Los usuarios que activan lotes manuales deben ser contados, al igual que los usuarios (o dispositivos) que realizan transferencias de archivos planos. Incluso los datos transferidos a través de una infraestructura de multiplexado requieren que los usuarios tengan licencia.
No sea una víctima de la piratería
Es fácil caer fuera del cumplimiento con las licencias de software de Oracle, especialmente si usted está trabajando con muchos productos de Oracle en entornos distribuidos. Los siete comportamientos descritos aquí pintan solo una parte de la imagen. Oracle facilita meter la pata de muchas maneras, y la compañía está feliz de cosechar los beneficios de su dolor. Es evidente que, si su organización está ejecutando productos de Oracle, usted debería monitorear continuamente la totalidad de su patrimonio Oracle en todas las plataformas. Cualquier otra cosa podría convertirse en una pesadilla de auditoría y dejar a su organización debiendo astronómicas cuentas de licenciamiento que nunca sospechó que estaban en el horizonte. Y si eso no es piratería, ¿qué es?
