"Tuvimos que explicarle a Oracle nuestro contrato", dice el CIO tras la auditoría de Big Red

Artículo original ↗ Discusión en Hacker News ↗

Las prácticas agresivas de licencias y auditorías de Oracle están empujando a muchas organizaciones a replantearse su dependencia de sus bases de datos, Java y otros productos. Los comentaristas describen auditorías que parecen «extorsiones» maximizadoras de ingresos, un bloqueo profundo con el proveedor mediante funciones propietarias, e incluso una industria secundaria de consultores ex-Oracle que ayudan a las empresas a navegar el cumplimiento. Aunque la tecnología central suele ser elogiada, la mayoría sostiene que el riesgo legal, el coste y la inflexibilidad ahora superan los beneficios, lo que lleva a muchos a preferir PostgreSQL, SQL Server y otras alternativas de código abierto o menos litigiosas.

Ecosistema de licencias, auditorías y cumplimiento de Oracle

  • Muchos comentaristas describen la postura predeterminada de Oracle como «están fuera de cumplimiento», usando las auditorías como herramienta de ingresos.
  • Las auditorías se presentan como agresivas, a veces provocadas por exempleados o por telemetría de descargas (p. ej., Java, VirtualBox).
  • Existe un ecosistema de consultoría en torno al cumplimiento de licencias de Oracle, a menudo integrado por ex empleados de Oracle, visto por algunos como un «negocio turbio».
  • Algunas empresas negociaron o incluso recibieron reembolsos; otras enfrentaron facturas retroactivas de seis cifras y, en al menos un caso, cerraron poco después.

Java y otros productos de Oracle

  • Los cambios recientes en la suscripción de Java SE (licenciamiento por empleado) empujaron a algunas organizaciones a migrar fuera de Oracle Java.
  • El consenso: usar JDKs que no sean de Oracle (compilaciones de OpenJDK, Corretto, Azul, compilaciones de distribuciones) evita gran parte del drama de licencias, aunque el soporte y las políticas de LTS varían.
  • La vigilancia por parte de Oracle de las licencias del Extension Pack de VirtualBox alarmó a algunos; otros señalan que Docker hace algo similar con la aplicación de licencias.

Bloqueo con proveedor y dificultad de migración

  • El uso profundo de Oracle DB (SQL propietario, PL/SQL, procedimientos almacenados, triggers, suites ERP como EBS) crea costes de cambio muy altos.
  • Múltiples historias de migraciones de varios años (incluidos grandes proveedores de nube) fuera de Oracle hacia PostgreSQL, DynamoDB u otros sistemas.
  • Los comentaristas subrayan que cambiar de base de datos implica reescrituras extensas de consultas y procedimientos, ajustes de esquema y casos límite ocultos (p. ej., la semántica de cadena vacía).
  • Algunos sostienen que la migración «no es imposible» y comparten movimientos exitosos a MySQL/MariaDB/Postgres; otros enfatizan el riesgo y el coste para sistemas críticos de 30–40 años.

Visiones técnicas de Oracle frente a alternativas

  • Técnicamente, Oracle DB suele describirse como potente, maduro y sólido en transacciones, rollbacks y analítica.
  • Muchos dicen que PostgreSQL ahora es «suficientemente bueno» o preferido para proyectos nuevos; otros mencionan MS SQL Server, MariaDB y sistemas modernos especializados para escala o casos de uso de nicho.
  • Algunos señalan que el principal problema de Oracle no es la tecnología, sino el riesgo legal y de costes.

Por qué las organizaciones siguen eligiendo Oracle (o SAP, etc.)

  • Los compradores empresariales y gubernamentales valoran «tener a un proveedor al que llamar» y transferir el riesgo más que la opinión de los desarrolladores.
  • Las decisiones a menudo las toman ejecutivos no técnicos o funciones de contabilidad/ERP, a veces influidos por ventas agresivas y ventajas.
  • Varios ven a Oracle y a proveedores similares sostenidos por la inercia, las habilidades arraigadas del personal y el miedo a reescribir enormes sistemas heredados.