Analista

Uma das reclamações mais comuns entre pessoas que começam a usar o Linux é que ele não suporta peças de hardware que elas possuem. E a resposta mais comum entre os veteranos é “a culpa não é do Linux, mas sim do fabricantes que não liberam as especificações”. Entretanto, ao ler o artigo Myths, Lies, and Truths about the Linux kernel, escrito por Greg Kroah-Hartman (um dos mantenedores do kernel do Linux), percebi que não é bem assim. Claro, os fabricantes realmente não liberam as especificações – o que é um direito deles. Mas não é esse o ponto, e sim o motivo de eles mesmo não fazerem os drivers para o Linux; obviamente, desconsiderando questões de custos e retorno, pois é lugar-comum. O texto do Greg Kroah-Hartman tem como objetivo defender o Linux, porém o que ele disse também pode ser usado de outra forma, dependendo do contexto e de que partes dele são destacadas – que é justamente o que eu vou fazer agora. Quem quiser ler o original completo, basta visitar o site.

Pois bem: ao ler o artigo, eu pude concluir que os desenvolvedores de drivers de código proprietário e fechado não têm incentivo algum para desenvolvê-los para Linux. Enfrentam algo mais ou menos do tipo “ou abre esse módulo, ou nós não queremos”. Isso em grande parte por causa da GPL, mas mesmo assim. Os mantenedores do kernel dizem que deixar o módulo fechado não é ético, é errado, pois ao fazer isso os desenvolvedores estão implicitamente declarando que são “superiores” ao pessoal do Linux, estão afirmando que o código deles é mais importante que o de todo o kernel.

O artigo também fala que módulos fechados, além de ilegais (por violarem a GPL), não são aceitos no kernel devido ao seu design – que evolui e muda constantemente, o que normalmente faz com que os módulos, com o passar do tempo, tornem-se incompatíveis; daí a necessidade de serem abertos e livres, para que o próprio pessoal do Linux possa atualizá-los. Também tem a questão de combinar partes de módulos que fazem a mesma coisa, para diminuir a redundância de código.

Difícil fazer alguém que vive de código fechado aceitar essas regras, inerentes à filosofia do Linux e da GPL. Se o desenvolvedor do driver prefere que seu código seja fechado (direito dele, tem seus motivos), então ter que abri-lo para ser aceito no kernel do Linux (direito de quem mantêm o kernel) acaba sendo realmente um desincentivo. Não que esse desincentivo seja o maior motivo para a indisponibilidade de drivers oficiais por parte dos fabricantes de hardware, mas tem a sua parcela.