‘Tivemos que educar a Oracle sobre nosso contrato’, diz CIO após auditoria da Big Red

As práticas agressivas de licenciamento e auditoria da Oracle estão levando muitas organizações a repensar sua dependência de seus bancos de dados, Java e outros produtos. Comentadores descrevem auditorias que parecem “extorsões” voltadas a maximizar receita, um lock-in profundo de fornecedor por meio de recursos proprietários e até uma indústria paralela de consultores ex-Oracle ajudando empresas a navegar pela conformidade. Embora a tecnologia central seja frequentemente elogiada, a maioria argumenta que o risco jurídico, o custo e a inflexibilidade agora superam os benefícios, levando muitos a preferir PostgreSQL, SQL Server e outras alternativas de código aberto ou menos litigiosas.

Ecossistema de licenciamento, auditorias e conformidade da Oracle

  • Muitos კომენტadores descrevem a postura padrão da Oracle como “vocês estão fora de conformidade”, usando auditorias como uma ferramenta de receita.
  • As auditorias são retratadas como agressivas, às vezes disparadas por ex-funcionários ou por telemetria de downloads (por exemplo, Java, VirtualBox).
  • Existe um ecossistema de consultoria em torno da conformidade de licenças da Oracle, muitas vezes formado por ex-pessoas da Oracle, visto por alguns como uma “máfia”.
  • Algumas empresas negociaram ou até receberam reembolsos; outras enfrentaram cobranças retroativas de seis dígitos e, em pelo menos um caso, fecharam as portas logo depois.

Java e outros produtos da Oracle

  • As recentes mudanças na assinatura do Java SE (licenciamento por funcionário) levaram algumas organizações a migrar para fora do Oracle Java.
  • O consenso: usar JDKs que não sejam da Oracle (builds do OpenJDK, Corretto, Azul, builds de distribuições) evita grande parte do drama de licenciamento, embora as políticas de suporte e LTS variem.
  • A fiscalização da Oracle sobre o licenciamento do VirtualBox Extension Pack alarmou alguns; outros observam que a Docker faz uma aplicação de licença semelhante.

Lock-in de fornecedor e dificuldade de migração

  • O uso profundo do Oracle DB (SQL proprietário, PL/SQL, stored procedures, triggers, suítes ERP como EBS) cria custos de mudança muito altos.
  • Há várias histórias de migrações de vários anos (incluindo grandes provedores de nuvem) para fora da Oracle, para PostgreSQL, DynamoDB ou outros sistemas.
  • Comentadores enfatizam que trocar de banco de dados envolve reescrever extensivamente queries e procedures, ajustes de schema e casos de borda ocultos (por exemplo, a semântica de string vazia).
  • Alguns argumentam que a migração “não é impossível” e compartilham mudanças bem-sucedidas para MySQL/MariaDB/Postgres; outros ressaltam o risco e o custo para sistemas críticos de missão com 30–40 anos de idade.

Visões técnicas da Oracle vs. alternativas

  • Tecnicamente, o Oracle DB é frequentemente descrito como poderoso, maduro e forte em transações, rollbacks e analytics.
  • Muitos dizem que o PostgreSQL agora é “bom o suficiente” ou preferido para novos projetos; outros mencionam MS SQL Server, MariaDB e sistemas modernos especializados para escala ou casos de uso de nicho.
  • Alguns observam que o principal problema da Oracle não é a tecnologia, mas sim o risco jurídico e de custo.

Por que organizações ainda escolhem Oracle (ou SAP, etc.)

  • Compradores corporativos e do governo valorizam “um fornecedor para ligar” e transferência de risco mais do que a opinião dos desenvolvedores.
  • As decisões são frequentemente tomadas por executivos não técnicos ou por funções de contabilidade/ERP, às vezes influenciadas por vendas agressivas e benefícios.
  • Vários veem a Oracle e fornecedores semelhantes sendo sustentados pela inércia, pelas habilidades já enraizadas da equipe e pelo medo de reescrever enormes sistemas legados.