Personal tools
You are here: Home Artigos Resposta (Póstuma) ao Morte ao Linux



 

Resposta (Póstuma) ao Morte ao Linux

by Ricardo Bánffy last modified Nov 19, 2008 08:29 PM

O que dizer ao pessoal do morteaolinux.com.br

Caros senhores,

Um amigo meu outro dia me mandou a URL do site (Nota aos leitores: o site atual aparece como em construção e a URL antiga, http://www.morteaolinux.com.br, morreu porque o domínio foi registrado com um CNPJ falso - coisa muito feia - e agora, depois de ter sido liberado novamente, é meu) de vocês. Eu li quase tudo o que vocês escreveram e gostaria de aclarar alguns pontos.

O primeiro: Eu não discuto religião. O Apple // era melhor que o MSX porque tinha o melhor software. O OS/2 era melhor que o Windows 3.1. O Macintosh é melhor para usar do que o PC. Programar em Python é mais fácil e produtivo do que programar em Java. Isso não vai ser discutido.

Outro: Vocês parecem acreditar que software livre (farei uma simplificação grosseira e usarei software livre como sinônimo de software licenciado sob a GNU GPL - GNU General Public License - e outras licenças similares e compatíveis) é feito com trabalho de pessoas que estão sendo iludidas e escravizadas. Ao contrário. Esses voluntários altamente capacitados estão doando seu tempo e habilidades para fazer um mundo melhor. Eu me lembro de uma época em que me angustiava o fato de que nada do que eu fazia tinha um impacto positivo no bem-estar geral das pessoas. Eu acredito que, ao divulgar esses ideais, sem extremismos ou fanatismos, eu esteja dando minha contribuição para um mundo melhor.

Por que eu chamei esse de um mundo melhor? Porque software livre não é apenas grátis (na realidade, ele não precisa, necessariamente, ser grátis, nem ao menos barato - eu explico isso depois), ele é livre. Não pode ser escondido, não pode ser corrompido (sobre software proprietário em atividades governamentais, eu gosto de citar que o espião americano mais produtivo durante a Guerra Fria foi uma câmera instalada dentro de copiadoras na embaixada da União Soviética em Washington - uma vez por mês ia o técnico limpar o cilindro, trocar o toner e colocar um filme novo para que mais documentos pudessem ser microfilmados à medida em que eram copiados) e pode, sempre, ser examinado ou auditado. Ao usar software-livre você tem uma garantia a mais de que ele fará aquilo a que se propõe, nem uma vírgula a mais, nem uma vírgula a menos. É software tão honesto quanto software pode ser.

Quando você recebe o código-fonte junto com o programa, você não depende do fornecedor original (alguns programadores podem se revoltar com essa condição - é: se você quer chantagear seu cliente com upgrades e atualizações em um esquema de assinatura ou manutenção, a maioria das licenças de software livre não é para você - elas libertam seu cliente desses comportamentos questionáveis - eles ficam com você só se quiserem). Você pode modificá-lo livremente e você pode até mesmo vender sua versão modificada, desde que obedeça, em geral, as seguintes regras:

  1. O software que você modificou deve ser licenciado com regras não mais restritivas que a licença original
  2. Você tem que dar o código-fonte do programa
  3. Você tem que deixar claro os termos em que o programa está sendo licenciado

E como você ganha dinheiro com isso?

Não é difícil: Seu cliente pode ter pedido uma modificação no produto original. Você cobra por incorporar essas mudanças e entrega a versão nova apenas para seu cliente. Ele tem, pelos termos da licença LGPL, por exemplo, o direito de distribuir livremente o produto pelo qual pagou. Se eles quiserem fazer isso, é com eles - eles têm o direito, não a obrigação de fazê-lo.

Você pode cobrar por essas alterações de quantos clientes quiser. Se nenhum deles quiser distribuir o programa derivado, você poderá vender muitas cópias.

Seu cliente pode pedir que você faça um produto novo. Você pode usar ferramentas de software livre para fazê-lo. O custo desprezível de aquisição dessas ferramentas elimina barreiras de entrada no mercado - o diferencial passa ser apenas a competência individual de cada um (isso pode assustar alguns).

Você pode também fazer um produto proprietário que dependa de software livre. Pode fazer um programa que use o Apache como servidor web ou o JBoss como container de EJBs. A IBM faz isso - o Websphere usa o Apache para lidar com solicitações de browsers. O OpenMFG (um ERP) usa o PostgreSQL para armazenar seus dados. Eu confio tanto numa base de dados PosgreSQL bem mantida quanto confio numa base Oracle bem mantida. Confio tanto numa base Oracle mal mantida quanto confio num macaco operando um transplante de fígado. Não é possível imaginar um Unix proprietário (Solaris, AIX, HP-UX, Irix) que não dependa de algo que esteja licenciado sob GPL. Dúzias de aplicações de administração de sistemas são escritas em Perl ou Python ou Tcl. Dúzias de programas usam Tk para gerar GUIs (em várias plataformas), muitos progrmas são compilados com GCC/G++ ou outros compiladores do EGCS (que são muito bons, obrigado).

Software livre também protege o programador.

Imagine o caso de um programador envolvido num projeto específico proprietário que precisa usar uma biblioteca para manipular algum hardware específico.

Há muito tempo atrás, eu usei uma biblioteca para PC que me permitia fazer imagens complexas em displays CGA e EGA (sou jovem apenas em espírito). Se eu quisesse usar hardware VGA, teria que comprar uma nova versão dela. Se ela tivesse algum bug que me impedisse de fazer um area-fill em um determinado modo gráfico, eu teria que esperar a solução. Se eu fosse o único cliente com aquele bug (quantos de vocês já tiveram problemas com seus notebooks Windows saindo de sleep?), ele pode levar muito tempo para ser consertado. Como desenvolvedor de software proprietário, eu não vou perder tempo com um único cliente pedindo para eu arrumar um feature velho enquanto muitos clientes novos estiverem pedindo features novos. É uma decisão administrativa. E, nessas condições, é uma decisão sensata. Ser proprietário não é nem nunca foi a resposta ao crônico problema da falta de qualidade do software que enfrentamos hoje em dia.

Se, por outro lado, a biblioteca tivesse vindo com o código-fonte, eu poderia localizar o problema e corrigí-lo eu mesmo muito antes dos criadores da biblioteca poderem até mesmo reproduzir o meu problema. A partir daí, é um problema meu se eu guardo essa modificação para mim ou se eu a ofereço aos criadores as minhas alterações. No caso de software livre, você oferece seu trabalho a toda a comunidade. Eu não perco nada com isso - ao contrário. Se eu guardar as modificações para mim, é quase certo que a próxima versão não vai resolver meu problema ou vai resolvê-lo de forma diferente. Nesse caso, ou eu abro mão da funcionalidade que eu arrumei, ou fico colando e enxertando minhas alterações em cada versão nova que eu for usar. Não perdi nada porque meu programa proprietário continua proprietário e eu continuo cobrando por ele. Se eu distribuo partes do código-fonte que foi usado nele, isso não entrega os meus segredos comerciais (afinal, o software em si continua fechado)

A maioria dos produtos GPL são subprodutos de outro projeto ou respostas a uma necessidade muito específica. São compiladores, bibliotecas, servidores de arquivos, impressão. Alguns dos melhores produtos são crias de grandes centros de pesquisa, como vários produtos debaixo do guarda-chuva AlphaWorks da IBM, outros começaram como brincadeiras (como a linguagem Python, que ganhou esse nome não por causa da cobra, mas por causa do Monty Python's Flying Circus). Há aqueles que são o resultado da frustração de alguém em não conseguir resolver um problema adequadamente (como Perl e PHP). Alguns são projetos para os quais grandes empresas doam mão-de-obra e recursos técnicos e financeiros (como o NetBeans/Forté/SunONE Studio). A IBM considera o Linux como estrategicamente importante para vender servidores - como resultado disso, investe rios de dinheiro em melhorias e aperfeiçoamentos.

A vantagem do software livre

Eu acredito, no entanto, que a grande força do software-livre não vem apenas disso. A internet teve (e tem) um impacto profundo na forma como as pessoas se organizam em grupos e trabalham em equipe. Eu sou um bissexto colaborador de uma meia-dúzia de projetos de software-livre e open-source (há uma diferença pequena) e meus interlocutores estão espalhados pelo mundo inteiro.

A indústria de software que se sente ameaçada por essa "invasão" é, predominantemente norte-americana, com uma tendência a se concentrar na costa Oeste dos Estados Unidos (embora negocie ações na costa Leste). Salvo uma ou outra exceção, a "Indústra de Software" se resume a essas empresas em um único país. A "Indústra de Software" no resto do mundo é, predominantemente, de serviços, não de bens (na verdade, a indústria de software não vende bens - vende direitos - direito de usar assim ou assado um determinado produto, por um tempo determinado e em determinadas condições). No Brasil, se formos comparar quanto fatura a indústria de caixinhas (vamos nos restringir a empresas brasileiras) contra o quanto fatura a indústria de serviços (desenvolvimento in-house, desenvolvimento contratado) veremos que esse segundo grupo é muito mais expressivo do que o primeiro. Se não me engano, mesmo numa das raras exceções (por ser alemã) na indústria de caixinhas, a SAP, ganha mais dinheiro com consultoria do que com venda de licenças (não achei os números). Pois é: o software-livre e a cooperação que a internet permite são recursos valiosíssimos.

Pois imagine o quanto uma empresa poderia economizar se, em vez de coprar um ERP de caixinha e gastar milhões na licença, depois milhões de consultoria para fazer com que o software funcione de fato (eles normalmente vêm "sem pilhas") ela gastasse bastante dinheiro e se baseasse em um produto como o ERP5 ou um OpenMFG para adaptá-lo às suas necessidades. O ecossistema gerado em torno disso faz muito sentido: Eu tiro proveito de contribuições de outros para construir as minhas contribuições, que eu devolvo à comunidade. Atualizações, consertos e extensões vêm de todos os lados, de todos os membros ativos da comunidade. Bug-reports são obtidos de uma base mais ampla e tratados abertamente (você sabe o que aconteceu com aquele bug do Oracle que você informou ano passado? Pois é - eu também não). Eu investi uns x milhares de reais, mas estou colhendo benefícios sobre os investimentos de um consórcio informal de empresas que tem, coletivamente, muito mais poder de investimento do que eu. Como efeito colateral, esse investimento no mercado local (onde eu contrato os meus programadores) fica aqui, gera empregos aqui e aquece a economia daqui, na nossa comunidade local. Faz sentido até mesmo quando pensamos na nossa balança comercial.

Outra coisa: Se eu tiver que gastar US$ 50 mil num servidor de aplicações Java, minha intranet provavelmente teria que ser feita usando ASP ou PHP.. Mas espera aí: PHP também é livre. Pois é, também: Nós, programadores, nos beneficiamos disso todo o tempo. Eu tenho no EGCS alguns dos melhores compiladores do mercado. Gosto deles e, se eu descobrir um problema em qualquer um deles, posso muito bem mandar um bug-report para os desenvolvedores e vê-lo ser consertado, ou ainda doar meu próprio tempo e perícia para consertá-lo eu mesmo, com ou sem ajuda dos meus parceiros. O mesmo acontece com PHP, Zope (meu servidor de aplicações preferido, mas isso é outra história) e com todo e qualquer produto "livre" de alguma expressão. Ao contrário dos "fabricantes" de software, que consideram bug-reports informação privilegiada e escondem da concorrência o quanto podem, bugs são tratados de forma aberta nesses projetos. Como eu uso Zope para viver, eu tenho todo o interesse de que ele funcione bem. Se eu descobrir um bug, eu vou tentar arrumá-lo e comunicar minha alteração aos mantenedores (uma espécie de "ditadores benevolentes") para que ela seja testada e incorporada à próxima versão. Isso é outro diferencial: o pessoal normalmente é muito neurótico com qualidade - quase todos os projetos em que eu dou palpites ou escrevo código têm procedimentos automáticos de teste que têm que ser satisfeitos sempre que uma alteração é proposta. Só posso torcer que o software que controla freios ABS seja feito assim.

Mas e quanto ao Linux?

Acho que vocês tiveram a necessidade de polarizar seu ódio em um produto específico. O Linux é um excelente sistema operacional. Leve e eficiente, pode ser adaptado a zilhões de situações diferentes (meu desktop do escritório roda Linux com GUI, meu firewall de casa nem monitor tem) em configurações de memória e disco as mais variadas.

Eu, por exemplo, odeio o Emacs

O Linux pode ser extremamente seguro sim. Simplesmente contar o número de reports é um erro injustificável: Vocês usaram o Windows como comparação. Bom... O universo de problemas que era englobado pelo Windows é muito mais restrito. Enquanto os bugs contabilizados para o Linux incluiam uma meia dúzia de servidores de web, uma boa dezena de servidores de e-mail, duas GUIs importantes e pelo menos dois gerenciadores de banco de dados relacional, o Windows estava restrito a um único servidor de web (o IIS), e um único servidor de e-mail (só SMTP, no caso do IIS, ou Exchange, que eu duvido muito tenha entrado nessa conta). Duvido que qualquer BD relacional tenha entrado nessa lista.

De novo, quanto à contagem de bugs, são raras as máquinas que tem todos os pacotes instalados (só no Debian são quase 9000). Os bugs de segurança do sendmail não se aplicam a mim (eu não uso sendmail), tanto quanto os do MySQL (eu uso PostgreSQL). Os bugs do Apache não me afetam porque eu uso Zope. Os bugs do thttpd não devem afetar quase ninguém. Isso é outro trunfo: a diversidade. Enquanto para atacar um servidor Windows me basta saber os buracos do IIS, isso simplesmente não é possível de se fazer quando se tem uma dúzia de servidores de web possíveis. Eu tenho um computador que é escaneado por worms todos os dias, "jogando um verde" contra meu servidor de web (que, claro, não é um IIS). Depois eu coloco o link aqui.

Segurança pode ser definida em termos de conhecimento (de você saber o que existe lá dentro, do que pode ser usado por um intruso, como pode ser usado pelo intruso) e controle (ser capaz de trocar versões, instalar alternativas, manipular permissões). No caso específico do Windows, você tem muito menos liberdade de configurar a máquina e muito menos capacidade de obter informações sobre o que está lá.

Não vou dizer que é mais fácil ou mais difícil construir uma máquina segura usando essa ou aquela plataforma. Construir uma máquina segura e mantê-la segura é difícil e requer cuidado e atenção.

De coração, torço que seus ódios juvenis se abrandem com o tempo e que vocês passem a colocar essa admirável energia em empreendimentos mais proveitosos a todos.

Um abraço

Este artigo também está disponível aqui.

© Ricardo L. A. Bánffy