Módulos de kernel binários : a saga continua

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.

Anúncios

3 comentários sobre “Módulos de kernel binários : a saga continua

  1. Na teoria é isso mesmo, mas a prática é outra.

    Por exemplo, alguns módulos de kernel para placas de rede de mainframe tem código fechado porque isso revelaria alguns detalhes de outros protocolos proprietários suportados por essa placa, como SNA. E esses mesmos detalhes são usados em outros softwares relacionados, que dão lucro aos seus fabricantes. E porque o fabricante deixaria de ter lucro sobre certa coisa só para satisfazer uma ideologia?

    Quando manter esse código torna-se impraticável, ou quando esse código fechado vira um commodity, ai está na hora de abrir seu fonte. Foi o que aconteceu com o StarOffice/OpenOffice.org, Cloudscape/Derby, WSAD/Eclipse, JBoss, Java (agora que ele foi aberto) e dezenas de outros softwares de outra dezena de diversos fabricantes.

    Na minha opinião, Open Source é saudavelmente visto pelo mundo corporativo como mais uma rota para criar ecossistemas ao redor de seus produtos. Enquanto que na comunidade, Open Source é visto como um fim e um ideal de modelo de desenvolvimento e uso. O choque é produto dessa diferença de abordagens.

  2. Olá Avi,

    Antes de mais nada, obrigado pela visita e por ter deixado um comentário. Saber que existem pessoas lendo é o que me motiva a continuar escrevendo e os comentários são sempre a melhor parte disso tudo para mim.

    Indo a resposta, logicamente existem exceções. Como no caso em que você citou, existem motivos para a não liberação do código. Porém, tais motivos são quase sempre relacionados ao fato de que as empresas perderiam algum lucro liberando algum tipo de especificação ou de propriedade intelectual relacionada ao código.

    O ideal (em um mundo perfeiro, lógico) seria ter todo o código aberto desde o início e não somente quando fosse comercialmente mais interessante, até porque muitos desenvolvedores de códigos livres os liberam desde o início e as empresas ganham dinheiro com o mesmo desde o início.

    Não é ilegal, mas é meio que contra os ideais das comunidades livres só liberar código quando o mesmo já é um estorvo ou mantê-lo implica em custos de manutenção muito altos. Deixa a impressão de se estar passando uma idéia como “ok, agora vamos liberar isso para que esses idiotas que fazem tudo de graça possam cuidar dessa batata quente ao invés de nós mesmo o fazermos”.

    Talvez pelo fato de você ter uma outra visão, provavelmente a visão corporativa (vi que você trabalha na IBM lendo seu blog), você pense de forma diferente e acredite que módulos binários não sejam assim tão ruins e sejam algo necessário.

    Percebi também que você prefere usar o termo “Open Source” ao invés de “software livre”, algo comum no meio corporativo, mesmo o assunto em questão sendo o kernel Linux, que é algo coberto pela GPL e, mesmo que não necessariamente por vontade de seu criador principal (um pragmático), constitui um projeto de software livre.

    Eu, por outro lado, gostaria de ter a liberdade de poder utilizar a distribuição que mais me agrada (o cliente deveria sempre ter a liberdade de utilizar o que deseja), sem ser obrigado (como sou atualmente) a utilizar uma distribuição “enterprise” específica, na grande maioria das vezes devido a um módulo binário específico só estar disponível para essa distribuição teoricamente superior.

    Outro ponto é que módulos binários tem o potencial de não somente serem ruins de um ponto de vista filosófico, mas, como disse o desenvolvedor do kernel Greg Kroah-Hartman em no OLS de 2006 (detalhes em http://www.kroah.com/log/linux/ols_2006_keynote.html), módulos do kernel Linux com código fonte fechado são ilegais.

    E isso vem de alguém que teve a oportunidade de conversar com muitos advogados especializados em propriedade intelectual, que desenvolve módulos de kernel e que trabalha em um grande empresa ligada ao software livre (Novell).

    Finalizando, é visível que temos visões diferentes sonre essa mesma questão e possivelmente um não consiga fazer o outro mudar de opinião, mas é interessante podermos trocar opiniões e visões sobre o tema, mesmo discordando uns dos outros.

  3. Sobre “Open Source”, eu prefiro este termo “Software Livre” não é a tradução correta para “Código Fonte Aberto”. SL tem implicações mais sociais, que não é o que estou querendo focar agora.

    Não é ilegal, mas é meio que contra os ideais das comunidades livres só liberar código quando…

    Pois é. É exatamente essa certa ausência de ideais faz o mundo corporativo ter essa energia pragmática realizadora. Na minha experiência, ideais de mais deixam uma pessoa ou uma comunidade a alguns metros acima do chão, que o fazem conseguir enxergar mais longe, mas também afasta-o um pouco de um senso prático.

    E veja bem, eu sou muito idealista. Mas o mundo corporativo me ensinou na marra que é importante balancear as coisas. É o tal-quê de-pragmatismo.

    Eu conheço as implicações legais de módulos fechados para um kernel GPL, mas quem quer manter o módulo fechado, consegue facilmente contornar as legalidades fazendo um stub aberto ligado ao kernel, que faz chamadas a algo fechado externo.

    Tecnicamente falando, modulos binários são sempre ruins. Abrir o código sempre vai ser a melhor opção para os técnicos. Mas o resto do mundo na verdade não se importa muito se é aberto ou fechado. E quando uma empresa está decidindo se abre alguma coisa ou não, o fator técnico é só um dos pesos que se coloca na balança. Há muitos outros como questões comerciais, controle para poder continuar dando suporte confiável, desconhecimento de como o processo open source realmente funciona, etc. Ou seja, um amalgamado de coisas.

    Na média, a indústria de software (aberto e fechado) é o resultado de todos esses fatores. Se está como está, é porque a média das pessoas e suas forças o fizeram assim. Se enchergamos de outra forma é porque somos idealistas, que olhamos kilometros a frente.

    Sobre distribuições, você (pessoa ou empresa) pode usar a distribuição que quiser. Mas se você é uma empresa que fabrica toalhas (onde TI é um pedaço seu meramente operacional) vai querer se livrar do problema técnico de administrar open source (que dá trabalho e traz uma nova dimensão de riscos). Então acaba sendo mais fácil para você usar uma distribuição de uns caras que suaram a camisa fazendo parcerias para homologar placas de fibra ótica ou aplicações de negócio (que afinal é o que vai resolver seu problema de negócio).

    E pensando bem, na média, tecnicamente, todas as distribuições são iguais. Vantagens e problemas técnicos de uma são contrabalanceados por problemas e vantagens técnicas da outra. A única coisa que não se contrabalanceia é o ecossistema (também conhecido por suor da camisa). Lembre-se: digo isso tentando ser pragmático e não idealista.

    Voltando a ser idealista e membro ativo que sou da comunidade de Software Livre (agora o termo é este mesmo), minha análise final é que todo esse idealismo muito mais atrapalha do que ajuda a evolução técnica e ecossistêmica do Software Livre. Uma pena, porque o potencial é enorme.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s