“Quanto mais gente resistir,
mais gente será Livre, e
mais gente será livre para ser Livre.”
Mais que um artigo, hoje nós editores do escovando bits nos juntamos para compilar o kernel-libre. Alexandre Oliva, membro da FSFLA e engenheiro de compiladores da Red Hat, anunciou que está trabalhando na limpeza de códigos não-livres (binários initeligíveis) do branch oficial do kernel.
Resolvemos então fazer um teste (rodá-lo em nossas máquinas) e ver quais são as diferenças. Aproveitem a leitura.
Nós estamos utilizando o Ubuntu 8.04, mas em breve no Slackware 12 e Gentoo 2007.0. Com relação ao kernel, você pode ver os módulos que são afetados nesse arquivo que foi criado buscando-se pela sequência “/*(DEBLOBBED)*/” no código-fonte.
O que realmente muda?
Apenas a pasta drivers/ e sound/ são afetadas, são basicamente códigos binários ou seguências de números incompreensíveis.
Comparamos dois arquivos: /usr/src/linux/drivers/atm/atmsar11.data e /usr/src/linux-libre/drivers/atm/atmsar11.data e podemos constatar que parte do código do kernel são construídas com códigos binários que mesmo licenciados sob a GPL não permitem estudar o código-fonte e modificá-lo para que faça o que você quiser (liberdade no. 1).
/* Madge Ambassador ATM Adapter microcode. Copyright (C) 1995-1999 Madge Networks Ltd. This microcode data is placed under the terms of the GNU General Public License. The GPL is contained in /usr/doc/copyright/GPL on a Debian system and in the file COPYING in the Linux kernel source. We would prefer you not to distribute modified versions without consultation and not to ask for assembly/other microcode source. */ 0x401a6800, 0x00000000, 0x335b007c, 0x13600005, 0x335b1000, 0x3c1aa0c0, (...)/* Madge Ambassador ATM Adapter microcode. Copyright (C) 1995-1999 Madge Networks Ltd. This microcode data is placed under the terms of the GNU General Public License. The GPL is contained in /usr/doc/copyright/GPL on a Debian system and in the file COPYING in the Linux kernel source. We would prefer you not to distribute modified versions without consultation and not to ask for assembly/other microcode source. */ /*(DEBLOBBED)*/Na nossa máquina de teste, nenhum desses módulos retirados afetava o funcionamento do sistema, então conseguimos um kernel 100% livre, contudo se essa compilação afetasse o módulo da placa de rede, teríamos que tomar outras medidas para sanar o problema. É um incentivo ao pessoal contribuir no trabalho do Alexandre Oliva e escrever códigos que substituam os drivers proprietários e que não firam a liberdade das pessoas.
Muitas pessoas podem questionar se o código já é livre, se já é GPL, porquê então fazer questão de eliminar os trechos binários?Aproveitando a resposta do Alexandre Oliva na lista de desenvolvimento do Fedora:It indeed doesn't cause me any direct harm if there are non-Free bits that I don't depend on in the kernel or the distro I use. That's why I can choose Fedora. But this does cause me harm when I want to recommend a distro to someone else. I can't recommend my distro of choice, Fedora, because Fedora endorses and promotes non-Free Software, and this endorses and feeds the social problem that I devote my life to fighting. I can't distribute my distro of choice, Fedora, because Fedora doesn't permit me to do so in a way that doesn't involve my distributing non-Free Software and feeding this social problem myself. Regardless of what happens on my computer, when I recommend Fedora to others, or give them copies of Fedora, they might become dependent on the non-Free bits, and only realize it after recommending it to others, saying things like "it just works". I've seen this happen to many Ubuntu users, including ones that were fervorous Free Software advocates but who didn't realize there were hidden non-Free bits in Ubuntu. When they figure that out, they may even come back to me and ask me how I could recommend it to them, being the 100% Free Software guy that I am. See how it can hurt me?
Por fim terminando com esse poema retirado do site da FSFLA.Quanto mais gente resistir,
mais gente será Livre, e
mais gente será livre para ser Livre.Para teu próprio bem e
em solidariedade a todos,
escolhe a liberdade.Sê Livre!
Filed under: Linux | Tagged: FSFLA, kernel-libre, kernel-livre, Linux, sê livre |
.::Escovando Bits::. 
Meu.. que post da hora.
Parabéns, sinceramente. (=
Vou testar esse release.
Pena que meu wifi (Intel 3945ABG) requer um microcódigo a parte do kernel pra funcionar. =/
[ coisa da FCC: proibição de deixar o usuário ajustar freqüências arbitrárias. ]
Ler um post desse (e uma resposta dessa, do Alexandre Oliva) até anima a ser 100% livre.
Espero um dia conseguirmos. (=
Abração!
[…] por Mauro S. M. Rodrigues (maurus·rodriguesΘgmail·com) – referência […]
Legal o post, Pessoal. Sugiro mais números mesmo, mostrando que não se precisa de muito pra deixar o Kernel “livre”. Recomendo que o pessoal leia a discussão completa que rolou na lista, para verem os outros pontos de vista. Como disse para o Maluta, sou do time Linus/Cox, mais pragmático e menos fundamentalista. Os dois grupos, no entanto, são importantes e acabam se entendendo no final (ou fazendo um fork!). Entretanto, assusta-me a falta de entendimento da idéia do Oliva. Pra mim, não precisaria de discussão. Apenas um “show me the code” e uma análise para inclusão/branch.
Vai ter um post com contagens de “goto” no kernel também ? 😉
Não sei por que fazem tanta questão com relação a firmware.
Antes de tudo e mais importante: firmware não roda na CPU do seu computador! Firmware roda numa microcontroladora de um dispositivozinho embarcado vagabundo. Se tiver bugs não vai travar seu computador e se você não gosta disso, é só optar por dispositivos que não usem firmware (e.g.: os taiwaneses em geral)!
Não faz sentido pedir o código-fonte para a fabricante pois não sabemos em qual linguagem ele é escrito ou se temos o compilador certo para esse código. Tampouco faz sentido reescrevê-lo usando engenharia reversa, pois é provável que nossos compiladores não suportem a microcontroladora na qual roda esse firmware.
Firmware é totalmente diferente de “blobs” binários. Um “blob” roda diretamente na CPU do seu computador e pode travar o seu sistema operacional todo (vide problemas comuns que apresentam PCs rodando blobs da nvidia, ndiswrapper, etc.). É uma coisa abominável e realmente limita a sua liberdade.
Um firmware binário na pior das hipóteses não pode ser redistribuído, e nesse caso é só não redistribuir e evitar hardware dessa fabricante…
Legal isto, eu utilizo Linux e um bom tempo e nao sabia deste detalhe, mesmo gostando de saber como o kernel funciona sem saber programar C/C++.
Já abri e dei uma olhada no codigo… á assustador ! heheheheheh
Um abraço a todos e parabéns pela iniciativa !