andrelop's blog

Uma das reclamações que mais ouvimos é a de que não existiria suporte para software livre. Existem pessoas e empresas que tendem a acreditar que, como o software é livre e não simplesmente desenvolvido por uma única entidade (empresa ou indivíduo), não existe suporte para o mesmo e os seus usuários teriam que “rebolar” para resolver seus problemas com softwares livres.

Sabemos que não é verdade e que, de fato, existem inúmeras empresas oferecendo serviços de suporte a inúmeros softwares livres. Não só para os sistemas operacionais livres, mas também para a grande maioria dos sotwares livres que rodam sob sistemas operacionais livres.

Existem empresas no mercado oferecendo diversos níveis de suporte diferenciados, desde o mais básico até o mais avançado, oferecendo diversos pacotes de serviços intermediários. E temos empresas como IBM e HP (para citar somente duas gigantes), que oferecem suporte global, 24×7, em qualquer lugar, a qualquer hora, para aqueles com necessidades mais complexas e/ou mais críticas.

Porém, para nós que estamos vivenciando software livre em nosso dia-a-dia, isso não é novidade alguma. O que realmente me levou a fazer esse post é que a síndrome de final ano, que nos leva a leituras de retrospectivas destrinchando as principais ocorrências relacionadas a softwares livres no ano todo, me apontou para algo sobre o que eu ainda não havia comentado.

Antes de mais nada, eu sei que a história é velha (síndrome de final de ano com leituras de retrospectivas, lembra ?) , mas ainda é importante citá-la de qualquer forma, até para tentar desmistificar a idéia da não existência de suporte para softwares livres (espalhe a palavra negando essa idéia, por favor).

Usando minha máquina do tempo, cheguei a essa carta aberta da empresa Pervasive PostgreSQL, na qual a empresa explicitamente cita que estaria abandonando o negócio de suporte ao PostgreSQL (uma excelente gerenciador de bancos de dados livre) por um motivo que deixaria os que afirmam que não existe suporte para softwares livres decepcionados : a comunidade do PostgreSQL existente já fornecia um suporte de alto nível.

Segundo a carta aberta da empresa, as oportunidades da empresa de fornecer uma fonte de suporte e serviços alternativos era bastante limitada, devido a existência de suporte de excelente nível já fornecido pela própria comunidade PostgreSQL aos seus usuários, de forma gratuita, algo com o que ela não poderia concorrer, logicamente.

Como concorrer com uma comunidade grande de usuários avançados e experientes, que muitas vezes conta até mesmo com os principais desenvolvedores dos softwares que utilizamos ? Quem melhor que os próprios criadores para nos auxiliarem com dúvidas e/ou problemas que temos com sua criação ? Não só temos excelentes soluções em softwares livres, mas também temos excelente suporte comunitário.

Estava lendo a retrospectiva de 2006 do lwn.net (desculpe, conteúdo somente para assinantes, mas em uma semana o conteúdo será liberado para todos) e algo que me chamou a atenção foi novamente a citação do caso dos módulos de kernel somente binários (módulos para os quais não existem código-fonte liberado). Não vou entrar em detalhes sobre o que foi dito na retrospectiva aqui porque seria injusto de minha parte reproduzir conteúdo de acesso restrito.

O que me levou a escrever este post foi o fato de, recentemente, os próprios desenvolvedores do kernel terem considerado a idéia de banir completamente o carregamento de módulos somente binários do kernel. Sim, isso mesmo, banir completamente. E a idéia teve gente importante e influente que a apoiasse (como Andrew Morton e Greg Kroah-Hartman), inclusive com patches para colocá-lo em prática postados na lista de discussão dos desenvolvedores do kernel.

No final, porém, depois de muita discussão, a idéia foi abandonada, infelizmente. Um dos pontos principais que levou a idéia a não ser levada adiante e ser concretizada foi o fato de que, na verdade, a licença usada pelo kernel Linux (a GPL) não impede explicitamente que você USE (maiúsculas usadas intencionalmente aqui) código GPL com qualquer outro código, seja ele livre ou um monte de lixo binário sem fonte algum disponível.

Veja bem, existem restrições em relação a mesclar código licenciado sob GPL com código coberto por outras licenças (mas não vou entrar em detalhes até porque não sou especialista na àrea jurídica e não quero correr o risco de falar bobeira), mas não em relação a USAR software licenciado sob GPL com softwares somente binários não cobertos pela GPL.

O que é interessante de se notar é que, caso fossem implementadas maneiras de impedir o carregamento de módulos somente binários, na prática estariam implementando um artifício técnico para impedir algo que no fundo ninguém gosta (seria ótimo ter drivers livres e especificações liberadas para todo tipo de hardware), mas que é explicitamente permitido pela licença sob a qual o kernel é lançado. Ou seja, estariam restringindo um direito que a própria licença garante aos usuários de software cobertos pela mesma.

Ok, não é lá muito inteligente retirar intencionalmente uma liberdade explicitamente garantida pela própria licença do software que você desenvolve, mas, convenhamos : que muita gente ficaria feliz caso isso acontecesse, ah, isso ficaria sim. Pena que tenhamos que ser boas almas e não forçar a barra para acabar com um problema maior.

Um dos problemas de módulos binários (além do problema óbvio de não serem livres) é que, como não existe código fonte disponível, não há como os desenvolvedores do kernel suportá-los. Na verdade, qualquer pessoa que relata um problema com os mesmos para a lista dos desenvolvedores do kernel é informada que, infelizmente, vai ter que entrar em contato com o fornecedor do módulo binário, geralmente o mesmo fornecedor do hardware que teria que funcionar com o módulo binário em questão mas que, por algum motivo, não o está.

Basicamente, o usuário fica escravo do fornecedor do módulo binário e cria-se aí uma relação de dependência, mesmo o usuário muitas vezes tendo migrado para softwares livres exatamente para fugir dessa armadilha de dependência de um único fornecedor. Quer um exemplo fácil do dia-a-dia ? Quantos são impedidos de atualizarem seus kernels antes que a nVidia lance versões novas de seus drivers fechados compatíveis com a nova versão do kernel ?

Ou, pior ainda, quantos nem sabem que esse problema existe e atualizam para uma versão mais nova do kernel (com as ferramentas de atualização de software modernas das distribuições atuais isso é moleza, feito com um ou dois cliques) e descobrem que perderam seu ambiente gráfico completamente ? E quantos desses usuários põem a culpa no “Linux” por isso ? E quantos desses usuários realmente sabem que não há nada que os desenvolvedores do kernel possam fazer em relação a isso, mesmo se quisessem ?

Percebeu o problema ? Eu ainda não li (e creio que, se lesse, provavelmente não entenderia a maior parte), mas gostaria que a GPLv3 ajudasse de alguma forma nesse sentido, criando algum tipo de mecanismo legal que, de alguma forma inteligente, obrigasse a liberação dos códigos-fonte dos módulos binários ou pelo menos tornasse o uso dos mesmos com um software GPL (o kernel, por exemplo) algo ilegal.

Esse seria meu presente de Natal preferido. Infelizmente, parece que, ao menos por um bom tempo, isso não vai acontecer. Eu adoraria estar errado e presenciar uma liberaçao em massa de fontes por parte dos desenvolvedores de módulos binários, já que, de outra forma, o hardware que os mesmos desenvolvem não funcionariam em Linux. Atualmente, Linux já é algo que atingiu massa crítica grande o bastante para forçar movimentos nessa direção. Só não acontece porque não é algo que seja estritamente necessário, legalmente falando.

Seria ótimo também, na minha próxima compra, poder comprar hardware sem medo de que o mesmo não funcione por eu estar utilizando uma distribuição “não recomendada para uso empresarial” (já me falaram isso, śerio) e, portanto, ignorada pelos desenvolvedores de módulos binários, que muitas vezes só lançam versões binárias de seus módulos para distribuições específicas e não de uma forma genérica que possa ser utilizada por todas as distribuições.

Lógico, é impraticável manter versões para cada distribuição, mas liberar o código faria com que o mesmo fosse melhorado pelos desenvolvedores da comunidade, possivelmente incorporado a árvore oficial e mantido atualizado constantemente, como é feito com todos os outros drivers que já foram liberados e já estão incorporados na árvore oficial do kernel. Não existiria a necessidade de manter versões para cada distribuição, visto que o código seria genérico o bastante para funcionar em todas elas.

Todos sairiam ganhando : o usuário, que poderia optar por utilizar a distribuição que mais lhe agradasse, e a empresa fabricante do hardware, que não teria o trabalho de manter seu código atualizado e alinhado com todas as constantes modificações que ocorrem no código do kernel e demandam trabalho constante dos mantenedores de código que roda em nível de kernel.