Depois de muita polêmica em torno do código do sistema Red Hat Enterprise Linux, na semana passada, o projeto Rocky Linux disse que havia encontrado uma maneira de continuar entregando sua distribuição baseada em RHEL. Agora temos algumas informações sobre como ele está fazendo isso.
A batalha de décadas entre a Red Hat e as várias organizações que clonam sua distribuição Linux corporativa tomou um novo rumo. Se você está acompanhando as notícias recentemente, a Red Hat disparou uma salva contra as reconstruções do RHEL, interrompendo a publicação do código-fonte de sua distribuição corporativa em seu repositório Git. Logo depois, cobrimos a notícia de que o projeto Rocky Linux anunciou que havia encontrado uma solução alternativa.
Em uma postagem de blog corajosamente intitulada “Mantendo o código aberto aberto“, o projeto descreve duas maneiras diferentes de obter o código-fonte RHEL sem violar os contratos de licença da Red Hat.
Uma delas é por meio das imagens de contêiner UBI públicas do Hat. Essas chamadas imagens de base universal são subconjuntos discretos da área de usuário do RHEL, destinados a serem executados em uma ferramenta de orquestração de contêiner como um contêiner totalmente compatível para executar aplicativos específicos do RHEL. Isso é muito bom, mas por sua própria definição, um contêiner não contém o kernel do sistema operacional ou drivers – são apenas componentes do espaço do usuário. No entanto, esses UBIs estão disponíveis para todos, sejam clientes do RHEL ou não, portanto, eles fornecem um bom começo.
Rocky Linux detalha como vai usar a base do RHEL live
No entanto, para criar uma distribuição autônoma completa, você também precisa obter o código-fonte do kernel e dos drivers. Esse código-fonte está disponível para clientes da Red Hat – e atualmente, apenas para clientes – na forma de SRPMs ou RPMs de origem. Em praticamente todas as distribuições do Linux, para cada pacote binário contendo um programa compilado e pronto para execução, há também um pacote correspondente de código-fonte nos repositórios da distro.
No uso comum, você normalmente nunca precisa deles, mas é da natureza do software de código aberto que você mesmo possa compilá-lo. Então, por exemplo, se você precisa de um programa que não está nos repositórios da sua distro, você pode obter o código-fonte desse programa e construí-lo você mesmo. O problema é que a maioria dos programas não triviais incorpora pedaços de muitos outros programas – em alguns casos, um número ridículo deles.
Este é um problema ocasionalmente apontado por luminares de código aberto; por exemplo, o ensaio de Poul-Henning Kamp “A Generation Lost in the Bazaar“, que apontou que mesmo em 2012 você precisava de 122 pacotes externos para compilar o Firefox. (Isso foi logo no início do rápido ciclo de lançamento do Firefox para o Mozilla.)
Você pode não precisar reconstruir partes da distribuição em si, mas ainda precisa do código-fonte para criar coisas que não fazem parte da distribuição. Portanto, as distros incluem pacotes de origem, e é disso que os reconstrutores RHEL precisam.
Os contêineres RHEL UBI também incluem os cabeçalhos do kernel – o código-fonte necessário para compilar os módulos do kernel. Se você executar uma distribuição Linux em uma VM e instalar as adições de convidado do hypervisor – por exemplo, para habilitar a aceleração 3D – você pode ter visto uma mensagem de aviso de que precisa instalar o pacote de origem dos cabeçalhos do kernel.
A outra solução alternativa do projeto Rocky usa RHEL VMs em provedores de nuvem pública de pagamento por uso. Essas VMs em nuvem executam instâncias RHEL completas e completas. O sistema de integração contínua da Rocky pode iniciar uma instância RHEL na nuvem – tornando-os clientes da Red Hat, pelo menos brevemente – usando essa instância para buscar todos os pacotes de origem novos ou alterados e postar seu conteúdo nos servidores Rocky Git, depois desligar e exclua a VM… nesse ponto, a propriedade – e o contrato de licença – são rescindidos.
A postagem do blog diz:
Esses métodos nos permitem obter binários RHEL e SRPMs legitimamente sem comprometer nosso compromisso com o software de código aberto ou concordar com limitações de TOS ou EULA que impedem nossos direitos. Nossos consultores jurídicos nos garantiram que temos o direito de obter a fonte de qualquer binário que recebermos, garantindo que possamos continuar avançando o Rocky Linux de acordo com nossas intenções originais.
O projeto parece confiante de que está totalmente em conformidade com a licença, embora observe:
Embora exploremos continuamente outras opções, as abordagens mencionadas acima estão sujeitas a alterações.
Suspeitamos que esta abordagem pode estar sujeita a mudanças muito rápidas. Embora a propriedade do RHEL da instância VM seja realmente temporária, os provedores de nuvem estão atuando efetivamente como revendedores dos produtos da Red Hat. Em nosso artigo original, observamos que as tentativas de usar as contas de desenvolvedor gratuitas da Red Hat para acessar o código-fonte do RHEL podem resultar em jogos de gato e rato, com a Hat encerrando contas que considera infratoras.
Suspeitamos que isso se aplique igualmente a contas em fornecedores de nuvem: se elas forem usadas para obter a fonte de maneiras que o Hat não gosta, parece muito provável para nós que o Hat instruirá os provedores de nuvem a fechar essas contas de clientes… ou corre o risco de perder os direitos de revenda do RHEL.
RHEL continua sendo um produto importante para muitas grandes empresas, como é enfatizado pelo fato de que “Big Purple” acabou de estender a vida útil do suporte para RHEL 7. introduzido, mas acabou de receber uma suspensão de execução: ELS até 2028… completo com kernel versão 3.10.
Como relatamos anteriormente, muitas pessoas na comunidade de usuários da Red Hat continuam extremamente chateadas com essa mudança na política de código-fonte, e muitas delas relatam que estão investigando a mudança para outras distribuições – notadamente o Debian, possivelmente por sua vida de suporte de longo prazo ciclo. O problema é que os usuários corporativos não escolhem distribuições com base no mérito técnico, mas sim em termos de suporte de terceiros. Se você estiver usando hardware cujo fornecedor oferece apenas drivers para RHEL, ou os aplicativos de que você precisa são suportados apenas no RHEL – ou pior ainda, uma versão específica (e possivelmente já obsoleta) do RHEL – então você pode não estar livre para mover para qualquer outra coisa.
Como descrevemos recentemente, a Red Hat faz de tudo para manter os kernels antigos com suporte e seguros . Suspeitamos, em parte, que seja por isso que é bom distribuir imagens de contêiner – porque elas não incluem o kernel superestável e muito importante.
Ninguém escolhe o RHEL porque é o que há de mais moderno. Não é. Na verdade, está o mais longe possível do estado da arte e, no mundo em rápida mudança do código aberto, esse é um atributo muito desejável para um certo tipo de comprador. Eles o escolhem porque uma versão específica terá suporte por mais uma década e, por sua vez, é por isso que os fornecedores oferecem suporte ao RHEL e, geralmente, nada além do RHEL.
Na década de 1990, houve uma campanha cujo site foi nomeado redhatisnotlinux.org– especificamente porque aos olhos de tantas pessoas e empresas, o Red Hat Linux realmente era a única distribuição que importava. Para as grandes empresas de hoje, seu descendente muitas vezes ainda é.