Lá pelo final do século passado, um importante fabricante de hardware especializado tomou uma decisão inédita: liberar as especificações técnicas de seus produtos, para que os desenvolvedores pudessem criar drivers livres com o suporte adequado (sob um contrato de não-divulgação dessas informações chamado NDA). Tal evento permitiu na entrada do Tux em uma nova área da computação, até antes inimaginável: os jogos. O fabricante em questão era a “finada” Voodoo (adquirida pela nVidia), os drivers criados ofereciam suporte à API Glide (já extinta) por parte do servido XFree86 (hoje X.org) e os produtos vendidos eram as aceleradoras 3D da série Voodoo, como as Voodoo clássicas, a série Banshee e as “novíssimas” Voodoo 3…
Nos dias atuais, a nVidia e a AMD/ATI vêm atacando nas duas frentes, liberando tanto drivers proprietários (ForceWare e Catalyst) quanto auxiliando as investidas na criação de drivers livres (Noveau e RadeonHD), embora muitas das inovações tecnológicas ainda estejam concentradas para a plataforma Windows. Quanto às demais (Intel), há tempos dispõem de drivers abertos (mas pela insignificante parte do mercado que dominam, a Via e a SiS não contam). Mesmo assim, nem tudo são flores no universo dos drivers & firmwares proprietários para sistemas GNU/Linux.
Ainda por volta desses anos, o mercado nacional foi invadido com uma enxurrada de modens especiais, chamados de softmodens: estes, ao invés de processarem via hardware as instruções relacionadas ao tratamento do sinal, forneciam apenas os componentes físicos necessários para prover a conexão com a linha telefônica, deixando a CPU responsável por esta tarefa, mediante do uso de drivers especiais. Ora, como a grande maioria das empresas dedicavam-se ao Windows por questões mercadológicas (motivo pelos quais estes dispositivos eram também chamados de winmodens), muitos linuxers iniciantes ficaram à ver navios, dependendo de conexões banda-larga compartilhadas ou até mesmo um PC desktop com o Windows, compartilhando a conexão discada.
Outra situação interessante a ser citada, são os drivers proprietários para alguns chips das interface de redes wireless. Empresas, como a Atheros e Broadcom (infelizmente, as principais), não fornecem drivers livres para o Tux, nos obrigando a nos contentar com limitados drivers livres desenvolvidos por terceiros, onde a sua implementação foi baseada no uso de técnicas de engenharia reversa. Entretanto, através de programas como o NDISWrapper, poderemos utilizar drivers feitos para o Windows no Linux, pois tal solução atua como uma espécie de interpretador, traduzindo comandos nativos para o kernel daquele sistema para o nosso amado Tux. Funciona? Sim, mas não como desejaríamos, com uma série de limitações e instabilidades. Pelo menos, com a grande adoção do Android em dispositivos móveis, esperamos que este cenário mude à meio ou longo prazo.
Estes são apenas alguns exemplos clássicos de hardwares não são suportados, devido ao fato de muitos fabricantes não se interessarem em desenvolverem os drivers de código-aberto adequados, para que estes possam ser integrados ao kernel Linux. Em muitos casos, até existe um certo interesse; mas, devido à forte concorrência entre os fabricantes, eles temem que a publicação destas peças de softwares possam revelar a forma como as suas tecnologias funcionam debaixo dos panos, possibilitando a concorrência utilizá-las para outros propósitos. Em outras circunstâncias, determinadas codificações “denunciam” o uso de métodos e/ou procedimentos protegidos por patentes de softwares, os quais acabam resultando em caros processos na justiça.
Por outro lado, graças à este cenário sombrio, uma série de iniciativas começaram a aparecer, em prol do desenvolvimento de drivers livres. Uma delas até inusitadas, como foi o caso de um físico francês que desenvolveu os drivers necessários para o funcionamento de 235 webcams diferentes. E o mais interessante: ele o fez puramente por hobby, para atender os desejos da filha que não podia usar os dispositivos, porque simplesmente não eram suportados! Isto foi possível devido ao fato de que diferentes webcams compartilham o mesmo projeto de controlador; neste caso, os drivers genéricos SPCA5XX e o GSPCA (Generic Software Package for a Camera Adapters) possibilitaram o suporte de uma pequena família de controladores para webcams.
Mas foi no final de janeiro de 2007, que Greg Kroah-Hartman escreveu um novo capítulo, ao postar em seu blog o anúncio da comunidade de desenvolvedores do kernel Linux, para o desenvolvimento gratuito de drivers de dispositivos sem suporte ao Tux. Bastaria apenas aos fabricantes interessados enviar as especificações técnicas do dispositivo, descrevendo como ele funcional, além de reportar o contato (e-mail) do engenheiro responsável pelo projeto do hardware, para que este último possa responder algumas questões técnicas sobre o projeto, a fim de facilitar o desenvolvimento dos drivers em questão. Inclusive, as cláusulas NDA (Non-Disclosure Agreement) seriam respeitadas. Eis, uma grande iniciativa! No entanto, se por um lado os problemas de falta de drivers são resolvidos, por outro lado novos inconvenientes começam a surgir: a indignação dos entusiastas do Software Livre em relação à utilização de firmwares proprietários no kernel (também chamados de blob binários).
Como bem sabemos, todo e qualquer software – firmwares ou drivers – escrito que esteja interagindo com o kernel e utilizando os seus recursos, deverá ter o seu código-fonte disponibilizado livremente, sob os termos da licença GNU GPL. No entanto, devido às questões mercadológicas envolvidas, muitos fabricantes não aceitam tais termos, o que penalizaria bastante o kernel Linux no que concerne o suporte a hardwares. As desculpas (por parte das empresas), é a mesma: proteção de sua propriedade intelectual, que pode ser usada pela concorrência, se for revelada através da abertura do código-fonte de seus firmwares. Tal problema é (ideologicamente) tão grave, que Richard Stallman chegou a anunciar que o kernel Linux “não é Livre”.
A partir deste contexto, surgiram algumas interessantes iniciativas. Em destaque, temos o anúncio do Linux Libre, o qual disponibiliza o próprio kernel Linux, mas adaptado com a remoção de todos os trechos de códigos que fazem a ligação do núcleo com os firmwares proprietários dos dispositivos suportados. A ideia original já havia sido adotada pelo gNewSense, que nada mais era uma derivação direta do Ubuntu, mas livre de todo o tipo de softwares proprietários. A seguir, veio o Debian, que lançou a sua mais recente distribuição (Squeeze) dotada de um kernel totalmente livre de softwares proprietários. Porém, embora estejam desabilitados, tais peças de softwares ainda se encontram disponíveis, em um repositório à parte denominados firmware-nonfree.
E assim, a vida (do Tux) continua…
Se até este presente momento, os leitores do Hardware.com.br acham que os softwares proprietários são o maior problema, ainda há mais por vir: trata-se do DRM, um mecanismo de regulamentação de direitos autorais que impede os usuários de executarem ou reproduzirem conteúdos modificados – neste caso, um software (firmware) de um determinado hardware protegido pela DRM. Prevendo estas (e outras) possibilidades, a GNU GPL em sua versão 3 considera uma série de aspectos restritivos relacionados à estas práticas, criando regras que restringem o uso de proteções como o DRM, quando este último é designado para impedir a possibilidade de edição do código-fonte licenciado sob os termos da GNU GPL (embora não proíba o seu uso, ao contrário dos que muitos pensam). Bem, tais mudanças repercutiram tanto na comunidade, que até o próprio Linus Torvalds a rejeitou.
Até mesmo as tão temidas e odiadas patentes de softwares não ficam de fora, por tornarem a vida dos desenvolvedores um verdadeiro campo minado. Mesmo que o software livre tenha sido escrito à partir do zero, as ideias e os seus conceitos, além das tecnologias envolvidas, podem estar “protegidas” por patentes de softwares, que não só inviabiliza o seu desenvolvimento, como também concede aos donos das patentes o “direito” de decidir o destino de todo o trabalho desenvolvido até então. Idem sobre as leis de direitos autorais, que dificultam a redistribuição de um código-fonte protegido por ela.
Mas este assunto, fica para uma próxima oportunidade… &;-D
Por Ednei Pacheco <ednei [at]hardware.com.br>
Veja também
Sobre o Autor
Deixe seu comentário