Quando muitas pessoas da área de TI pensam sobre Linux, elas imaginam um kernel do sistema operacional de código-fonte aberto, juntamente com outros software, se juntando para criar o sistema operacional de servidores e desktosp baseado em Software Livre. Essa imagem é precisa - e não há dúvidas que seu código-fonte aberto (e cooperação da comunidade) ajudou a torna-lo a potência que é hoje.
Mas em que momento nós vamos aceitar que - gostemos ou não - aplicações de código-fonte fechado terão de ser inseridas nesse outro mundo "livre"? Afinal, isso já acontece por anos, apesar dos Linuxistas puritanos batendo o pé o tempo todo.
Na realidade, software proprietário é usado todos os dias dentro do mundo Linux. E o que é engraçado: a maioria de nós nunca pensa duas vezes sobre isso.
Código-fonte fechado com Linux - não é um conceito novo
Enquanto o núcleo do sistema operacional Linux (independente da distribuição) é provido por código-fonte aberto, muitas vezes ele é usado por todos os cantos com códigos que recebem menos atenção - na verdade, muitos Linuxistas puritanos parecem se esquecer: Software e drivers com código-fonte fechado são usados com desktop Linux todos os dias por milhares de pessoas.
De firmware específicos adicionados por distribuições específicas para assegurar compatibilidade wireless até softwares de código-fonte aberto conhecidos como o WINE, que permite que usuários rodem aplicações Windows de código-fechado, os códigos proprietários têm espaço no desktop Linux.
Além disso, como a maioria dos notebooks inicialmente feitos para Windows teriam conexão wireless sem o NDISWrapper usando drivers proprietários projetados pra Windows? Software com código-fonte fechado era, é - e pode muito bem sempre ser - a principal parte na utilização do Linux no desktop.
Um acontecimento recente que, de novo, criou hostilidade entre usuários de código-fonte aberto e fechado foi o fracasso da NVIDIA em fornecer um código-fonte de seus drivers gráficos para Linux. Mas, ao contrários da ATI, nunca tive nenhum problemas usando os drivers fechados da NVIDIA. Todas questões que surgiram foram tratados rapidamente pela própria NVIDIA.
Então por que há um problema, de novo?
No passado, desenvolvedores do Linux manifestaram preocupação em ter "trabalho em torno" desses drivers fornecidos pela NVIDIA. Basicamente pensando no futuro, na forma como as coisas acabariam se um usuários optasse por instalar esses "binários bolhas", como os desenvolvedores gostavam de se referir a eles.
Apesar da preocupação deles, gostaria de observar que a NVIDIA tem um histórico bastante decente com controle de bugs e, misteriosamente, os desenvolvedores do Linux têm sido capazes de fazer as coisas funcionarem no final, apesar dessas questões com o licenciamento por trás do atual driver fechado da NVIDIA.
Independente da frustração de qualquer desenvolvedor sobre o licenciamento do driver da NVIDIA, o que importa é que o fornecimento de drivers fechados tem funcionado muito bem para todos os envolvidos - por muitos anos.
Não me entenda mal, adoraria ver a NVIDIA abrir os drivers tão quanto esses caras. Entretanto, vendo os puritanos pedir por boicotes contra um fabricante que está na verdade apoiando a plataforma Linux é simplesmente implorar por repercussões que ainda surgirão.
Sentimentos negativos expressados acima eventualmente apresentarão grandes problemas para qualquer empresa de código-fechado que queira dar um mergulho nas águas do desenvolvimento do Linux. Já que a maioria das empresas de software usam software proprietário e muitas empresas de hardware fazem o mesmo, a reação à decisão da NVIDIA vai marcar fortemente como os fabricantes de hardware, que buscam compatibilidade com Linux, optem seguir em frente.
O patético é que muitos deles irão resistir o máximo de tempo possível, já que os desenvolvedores do Linux são amplamente considerados uma dor de cabeça pelo mundo do software proprietário.
Coerência da aplicação, não política de código-fonte
Independente do como as pessoas se sentem sobre as escolhas de licenciamento de empresas com a NVIDIA, na verdade existem muitos software proprietários utilizados com Linux hoje que, por alguns motivos misteriosos, ninguém parece reclamar, apesar do fato do software ser um pouco restritivo na disponibilidade de seu código. O Skype me vem na cabeça como um exemplo primordial.
O Skype fornece um excelente cliente VoIP para usuários Linux, entre outras plataformas populares. Esse software VoIP faz de tudo, de chamada telefónica a transmissão de vídeo ao vivo. Então, apesar do acesso imediato a outras alternativas de código-aberto comparáveis como o Ekiga (disponível tanto para Linux quanto para Windows), a maioria das pessoas que usam um cliente VoIP em suas casas no Linux estão fielmente agarrados com o Skype.
Ainda que uma alternativa de código-aberto comparável, curiosamente chamada de "Ekiga", esteja instalada por padrão em distribuições Linux como Ubuntu, a maioria dos usuários que querem um cliente VoIP escolherão pelo Skype todas as vezes. Vários desses indivíduos não ligam como o Skype é licenciado. Tudo o que sabem é que isso é o que todos já estão usando em outras plataformas.
Além disso, o Skype pode rodarem praticamente qualquer plataforma que você imaginar. O Ekiga, por outro lado, foi primeiro criado para Linux e depois para Windows. Usuários OSX foram deixados de fora.
Entender que o Skype fornece a seus usuários com um senso de coerência é o fator chave. Dominando isso é a melhor forma de entender porque mais pessoas não irão se preocupar em procurar alternativas de código-fonte aberto, como o Ekiga. A opção do Ekiga talvez fornece mais "escolhas" do que a maioria das pessoas estejam procurando. O Ekiga suporta o SIP, dentre outros protocolos, considerando que o Skype suporta seu próprio protocolo - o period. Baseado no número de usuários, possivelmente devido ao marketing, os usuários do Skype realmente não se importam sobre o tipo de protocolo VoIP que está sendo usado para sua comunicação.
Mantendo o "caminho aberto"
É importante perceber como você lê esse artigo, ele não é um ataque ao Linux ou ao software livre de jeito nenhum. Em vez disso, considere esse artigo mais como uma sacudida no que diz respeito a utilização e disponibilidade de software.
Adoraria ver cada desafio apresentado a plataforma Linux ser alcançado por um software livre sempre que possível. Entretanto, quando você vive num mundo de MP3's patenteadas, DVD criptografados, módulos de drivers de aceleração 3D e adaptadores para drivers wireless proprietários para Windows, você logo percebe que software proprietário é bem presente - independente de qual plataforma você decida usar cada dia.
E há a barreira. Se existe valor na aplicação proprietária em determinada plataforma, os usuários pagarão por ele alegremente.
Talvez um dos mais fantásticos exemplos de usuários comprando software proprietário para Linux teria que ser uma aplicação específica de edição de vídeo. Uma aplicação atualmente descontinuada, conhecida como MainActor, fornece um benefício significante para os usuários Linux cansados de estarem limitados às alternativas de código-fonte meia-boca como o KDENLive.
Para o usuário normal, esse foi o caminho mais fácil. Isso permitiu que usuários de todos os níveis de habilidades editem vídeos de forma sensata e amigável. Então, mesmo existindo alternativas livres nesse segmento, elas não eram intuitivas o bastante para satisfazer as necessidades da massa Linux, e além disso, eram vistas como sendo simplesmente muito instáveis para o uso a sério.
O software proprietário é uma ameaça às distribuições Linux de hoje?
Quando envolver seus pensamentos em torno da questão de software proprietário no desktop Linux, uma coisa para se ter em mente é que o kernel Linux se manterá puro e, ao contrário do que se pensa, não está sob ataque.
Isso significa que nenhum código proprietário vai aparecer de repente nos altos níveis do desenvolvimento do kernel, violando assim o Linux como o conhecemos. Nunca será uma ameaça real ao Linux como o conhecemos.
O pedaço mais importante do código que compõe o sistema operacional tem garantias para assegurar que ele nunca cruzará com códigos que não sejam licenciados com licença open source. Não quer dizer que algumas distribuições não liguem para o kernel vanilla e adicionem aquilo que eles bem entenderem. Mas isso não tem nenhum efeito naqueles que escolhem não usar essas distribuições.
No final das contas, o código proprietário está ai para ficar. Como usuários Linux, para muitos de nós, ele é parte do nosso dia-a-dia em muitas tarefas básicas. E sim, ele certamente é parte significante do universo existente do desktop Linux - essa fato é difícil de negar. Como reagimos a esse fato, porém, é algo que cada usuário terá de lidar consigo mesmo.
Fonte: Matt Hartley@EarthWeb
