As distribuições corporativas e o software livre

Enterprise distributions and free software

Autor original: Jonathan Corbet

Publicado originalmente no: lwn.net

Tradução: Roberto Bechtlufft

A questão das “distribuições corporativas” é curiosa, porque muitas vezes o que temos é uma tentativa da parte dos fabricantes e dos consumidores de encaixar o software livre no modelo de negócios que há tempos é seguido pelos fabricantes de sistemas operacionais proprietários. Isso cria uma tensão entre os valores da comunidade do software livre (incluindo o acesso livre, o desenvolvimento rápido e a colaboração) e os do fabricante (que incluem uma rígida estabilidade e a preservação da vantagem competitiva). Algumas mudanças recentes realizadas pela Red Hat ilustram bem os efeitos que essa tensão pode causar, especialmente quando somados a uma competição forte e possivelmente injusta.

O núcleo da distribuição Red Hat Enterprise Linux (RHEL) é composto inteiramente por software livre (o repositório adicional traz pacotes proprietários feitos por terceiros, como o Flash). O código fonte da distribuição está disponível gratuitamente e pode ser redistribuído por qualquer um, desde que as marcas comerciais sejam removidas. Distribuições como CentOS e Scientific Linux se beneficiam dessa liberdade, mas os concorrentes comerciais também, e eles não veem problema algum em cobrar por suporte à distribuição que a Red Hat criou.

Naturalmente, os concorrentes comercias causam mais problemas à Red Hat, que investe uma quantia considerável no desenvolvimento do software no qual o RHEL se baseia, e na criação do próprio RHEL. Empresas como a Oracle também contribuem com os projetos originais que fornecem software para a distribuição, mas em menor escala, e contribuem muito pouco com o desenvolvimento e a manutenção do RHEL. Como não têm que gastar no desenvolvimento, essas empresas podem oferecer suporte à distribuição da Red Hat (ou a derivadas dela) cobrando bem menos. Dizem que Oracle e afins estão sempre cortejando os clientes da Red Hat, com um bom nível de êxito. Parece um caminho certo para o sucesso, mas também se comenta por aí que a verdadeira intenção é tirar a Red Hat do ramo.

Diante dessa situação, não é de se surpreender que a Red Hat tenha decidido se defender. Empresas que facilitam muito para a concorrência geralmente não duram muito. Ela poderiatentar tornar sua distribuição mais proprietária para evitar que outros a redistribuíssem. O uso de módulos proprietários do kernel para esse fim não é inédito, mas seria surpreendente se a Red Hat seguisse esse caminho. Os componentes proprietários de espaço de usuário, como os usados pelo Google para manter algum controle sobre o Android, não gerariam tanta dificuldade de licenciamento, mas representariam uma grande mudança para uma distribuição (outrora) livre. A boa notícia é que, ao menos até o momento, a Red Hat vem resistindo a esse tipo de pressão.

O que a Red Hat está de fato fazendo, no entanto, não é visto com bons olhos por muitos. Basicamente, ela está impondo controle proprietário sobre os metadados que possui sobre a distribuição RHEL. Esses metadados incluem sua base de dados de conhecimento de problemas e soluções, bugs e correções etc. A ideia é usar a vantagem obtida com o desenvolvimento e o suporte ao RHEL ao longo de todos esses anos, dificultando o uso desse conhecimento por terceiros. A empresa tenta competir oferecendo suporte aprimorado, e uma maneira de fazer isso é impedir que os concorrentes usem as informações que ela coletou e a experiência que acumulou para oferecer um suporte melhor.

Empacotamento de fontes do kernel

Tudo isso saltou aos olhos da comunidade por causa de uma mudança na forma como o arquivo RPM de fontes do kernel do RHEL 6 foi empacotado. A praxe em pacotes de fontes é combinar um arquivo tar compactado do fornecedor original, sem modificações, a um grupo de patches do distribuidor e um script (o arquivo “spec”) que aplica os patches e compila o software. Mas agora, o pacote do kernel do RHEL consiste de um único arquivo tar compactado, com os patches do kernel já devidamente aplicados e não disponíveis separadamente. O arquivo spec tem uma longa lista com nomes de patches, mas não há informações para a obtenção dos patches específicos aplicados.

O propósito disso, obviamente, é o de complicar as coisas para a concorrência, que vai ter que descobrir por que certos patches foram criados. Muitas das alterações aplicadas ao kernel do RHEL são feitas para atender a problemas específicos dos usuários; entender esses problemas e como eles foram resolvidos vai ajudar a lidar com outras situações de suporte no futuro. Juntando os patches todos num arquivo só, sem changelogs, a Red Hat pretende esconder essas valiosas informações de suporte de terceiros.

Vai funcionar? É certo que restringindo as informações, a Red Hat tira de seus concorrentes um recurso útil, mas os mais cínicos vão dizer que o acesso a essas informações pode ser recuperado por meio de uma assinatura baratinha do RHEL. Mas ainda não está bem claro se os patches específicos aplicados ao kernel vão ter alguma utilidade para os concorrentes. É bem provável que a Red Hat tenha conseguido irritar e complicar as coisas apenas para a comunidade de desenvolvimento, e mais ninguém.

A Red Hat afirma que a mudança no empacotamento não deve incomodar à comunidade de desenvolvimento, observando que a novidade esteve em prática por quatro meses até que alguém reclamasse. Uma das bases dessa afirmação é o fato de que o RHEL “2.6.32” é bem diferente do que outros chamam de “2.6.32” por aí… como a própria empresa já disse:

O kernel do Red Hat Enterprise Linux 6 inclui vários subsistemas e melhorias em relação ao 2.6.34 e seus predecessores. Com isso, o kernel do Red Hat Enterprise Linux 6 não pode ser rotulado da mesma forma que alguma versão específica do kernel original. O kernel do Red Hat Enterprise Linux 6 é um híbrido de várias versões mais recentes do kernel. Como a Red Hat oferece atualizações regulares durante o ciclo de vida do produto, esperamos que o kernel do Red Hat Enterprise Linux 6 incorpore recursos selecionados de futuras versões do kernel original, e que ainda estejam em desenvolvimento.

O kernel do RHEL é um Frankenstein cheio de correções e backports, muito diferente do kernel original. Como a Red Hat já disse, a maioria dos patches desse kernel não tem utilidade nos kernels que outras pessoas usam. Em suma, eles afirmam que a maior parte dos patches do kernel do RHEL não tem valor para a comunidade.

O mais importante é que a Red Hat continua dizendo que acredita fortemente no trabalho em parceria com a fonte original do kernel. Todos os patches que ela desenvolve e que têm relevância para os kernels originais são enviados na mesma hora para inclusão. Essa linha de raciocínio sugere que os kernels do RHEL não terão nada que interesse à comunidade; tudo o que tem algum valor já foi enviado para a fonte original do kernel. O histórico da empresa corrobora essa afirmação: poucos contribuíram tanto com o kernel, e essa parceira com o projeto original está enraizada na cultura da empresa.

Apesar disso, os mantenedores dos kernels estáveis da comunidade (e outros desenvolvedores) vêm alegando que a prática da Red Hat torna mais difícil trabalhar com a empresa. Seja como for, o fato é que essa prática deixa a comunidade com um gosto amargo na boca. O desenvolvimento de um fork expressivo do kernel do Linux se tornou possível graças a uma tentativa (talvez ineficaz) de favorecer interesses corporativos. O fato desses interesses corporativos serem do interesse pessoal de todos os assalariados da empresa, e de todos que se beneficiam das contribuições da empresa, talvez suavize o golpe, mas não melhora muito as coisas. Muitos estão se perguntando o que virá a seguir.

O ramo das distribuições corporativas

A preocupação com o futuro talvez se justifique. O modelo de “distribuição corporativa”, na forma como é implementado hoje, é uma estranha distorção da comunidade de desenvolvimento. Há quem diga que ele viola a GPL, ou que “estica” excessivamente o espírito da coisa. Vamos discutir isso em outro artigo. O que interessa aqui é que o modelo levou à criação de kernels tão divergentes que alterações simples não podem mais ser aplicadas ao kernel original. Não consigo deixar de pensar na clássica apresentação de Andrew Morton no Ottawa Linux Symposium de 2004:

Quero destinar algumas palavras às empresas que vendem o Linux. Sei que é tentador para quem comercializa o Linux tentar diferenciar seu produto adicionando recursos ao kernel. Ok. Mas essa abordagem significa que versões incompatíveis do Linux serão disponibilizadas aos usuários. Isso vai prender alguns usuários a implementações do Linux de empresas específicas. Além disso, a prática expõe toda a indústria do Linux a acusações de fragmentação, e nós expõe à acusação de que estaríamos trilhando o mesmo rumo dos Unixes proprietários que mereceram mesmo desaparecer… como alguém que tem uma certa responsabilidade pelo Linux como um todo, vejo a estratégia plenamente compreensível de empresas que querem diferenciar seus produtos como em conflito direto com os interesses do Linux a longo prazo.

O kernel do RHEL, que certamente é diferente de todos os outros kernels, parece se encaixar na descrição de Andrew. A estratégia da Red Hat de restringir as informações sobre esse kernel é uma tentativa assumida de prender seus clientes à empresa, dificultando a migração para outro provedor de suporte. Será que isso é bom para o Linux?

As manobras corporativas não ocorrem em um vácuo, e os concorrentes da Red Hat vão bolar uma resposta à altura. Talvez eles apenas deem outro jeito de conseguir as informações necessárias. Mas se em vez disso eles adotarem uma estratégia como a da Red Hat, podemos acabar com um grupo fragmentado de distribuições Linux incompatíveis, cada uma tentando “amarrar” seus usuários com uma combinação única de recursos e informações proprietárias. Os veteranos das guerras do Unix devem estar estremecendo só de pensar nisso.

Uma alternativa possível é se afastar da ideia de kernels “congelados” nas distribuições corporativas. A verdade é que esses kernels não são congelados: o kernel “2.6.32” do RHEL tem recursos do kernel 2.6.38, e talvez vá além disso. Ninguém quer um kernel parado há anos, então as adaptações de recursos não param de ser incluídas nesses kernels “estáveis”. O resultado é uma combinação nunca vista antes, e que pode ter seus próprios problemas de estabilidade, além de ser cara para se criar e manter.

Talvez as distribuições corporativas devam se aproximar dos kernels originais, e até migrar para versões mais novas de vez em quando. O “Unbreakable Enterprise Kernel” da Oracle parece um passo nessa direção. A Novell fez algo parecido com a atualização SP1 do SUSE Linux Enterprise 11. Essa abordagem parece oferecer mais vantagens reais: os usuários obtêm novos recursos e correções dos projetos originais, e os distribuidores não precisam pagar o preço de criar e manter um kernel altamente divergente. Também não há tanta necessidade de se tratar informações relacionadas como proprietárias: as empresas competem em termos de suporte ao software da linha principal, e não a um kernel de uma empresa específica. Esse parece ser um ambiente no qual a Red Hat, que se esforça tanto para criar os kernels da linha principal, poderia competir de forma mais eficaz.

É claro que quem ouvir meus conselhos corporativos tem grandes chances de aprender bastante sobre o processo de falência em pouco tempo. Mas o fato é que essa ideia não é nova, e já foi discutida aqui em 2007. O modelo de distribuições corporativas ultraestáveis não parece ameaçado, apesar das empresas que investem nele estarem experimentando mudanças. Se há clientes, então haverá empresas vendendo o Linux.

No fim das contas, as empresas precisam gerar dinheiro, senão desaparecem. Até agora, a Red Hat encontrou meios para deixar seus acionistas felizes e ainda dar suporte à comunidade de desenvolvimento que torna tudo possível. Conforme o mercado fica mais competitivo, esperamos que as empresas envolvidas continuem encontrando formas de equilibrar esses interesses tão importantes; do contrário, o resultado pode ser destruidor para todos.

Créditos a Jonathan Corbet – lwn.net

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>