[DE | EN | FR | IT | JA | ES | KO | PT]

Benvindo a mais um númer do Admirável Mundo GNU. Como prometido no final do número passado, neste mês apresentarei um projeto que fez com que minha vida ficasse muito mais fácil.

SpamAssassin

O SpamAssassin [5] permite assassinar o "SPAM", ou e-mail comercial não solicitado. Ou pelo menos marca o Spam, permitindo que o Procmail, ou o leitor de e-mail tratem o Spam da forma menos desagradável para o usuário.

No coração do SpamAssassin está um programa Perl distribuído sob a mesma licença dual GPL (Licença Pública Geral do GNU) e Licença Artística que o próprio Perl usa. Isto permite distribuir o SpamAssassin através do CPAN ("Comprehensive Perl Archive Network", ou "Rede de Arquivamento Abrangente do Perl") [6]. E também reusar código da CPAN sem nenhum problema legal.

Falando nisso, os problemas de licença foram cruciais no início deste projeto. Antes de ter escrito SpamAssassin, Justin usava outro filtro de e-mail escrito em Perl, que se tornou um problema devido a suas regras estáticas e sua licença pouco clara.

Deste projeto Justin adotou a idéia de trabalhar com pontuações ("scores"), um conceito similar ao de "Adaptive Scoring", ou "Pontuação Adaptativa", usado pelo GNU News- e Mailreader [7].

O SpamAssassin opera aplicando muitos testes diferentes aos e-mails que ele analisa. Existem testes para e-mails em HTML, se a mensagem de e-mail contém frases usadas com freqüência em Spam, se a mensagem afirma não ser Spam de acordo com certas leis e normas, se ele contém uma quantidade pouco usual de pontos de exclamação e de interrogação, se fala em "Milhões de Dólares" etc.

A cada teste disparado, uma mensagem de e-mail recebe pontos. A quantidade de pontos que cada teste vale pode ser especificada pelo usuário através de um arquivo de configuração muito simples, em ASCII. Se a soma dos pontos ultrapassa um certo valor, que o usuário também pode definir, o SpamAssassin considera que o e-mail é Spam.

Baseado nesta decisão, o SpamAssassin insere flags no header que informam o resultado dos testes. Se o usuário quiser, os emails de Spam passam a ter o valor "e;text/plain", ou "texto simples", no campo Content-Type, ou "tipo de conteúdo", o que torna muito mais fácil verificar o resultado dos testes. O SpamAssassin pode também inserir um relatório de teste mais detalhado no começo do e-mail, para que um usuário possa claramente ver porque um e-mail foi considerado Spam.

O maior risco de se usar SpamAssassin é claramente a possibilidade de resultados "falso positivos": mensagens normais de e-mail classificadas como Spam. Portanto, recomenda-se examinar regularmente a pasta de Spam, que normalmente é onde todos e-mails classificados como Spam normalmente são colocados, para corrigir resultados falso-positivos.

Também é possível baixar a sensibilidade do SpamAssassin, o que vai aumentar a quantidade de Spam não detectado. Para o administrador do SpamAssassin, o difícil é encontrar o ponto de equilíbrio necessário na sensibilidade das regras.

Para impedir que os enviadores de Spam consigam burlar o SpamAssassin, o projeto incorpora muitos testes diferentes, e também é facilmente extensível.

É claro que ele também suporta as listas negras online. A referência a listas negras de DNS, fontes e "relays" conhecidos de Spam são também suportados, assim como a Navalha de Vipul [8], um banco de dados de Spam que permite a identificação de Spams conhecidos.

Para permitir a filtragem de grandes quantidades de mensagens de e-mail e a conexão com tantas fontes de e-mail quanto possível, Craig Hughes escreveu o daemon "spamd", que acompanha o pacote SpamAssassin.

A maior fraqueza do SpamAssassin que ele parece ser voltado para o usuário tecnicamente experiente e não tem (ainda) uma interface gráfica com o usuário.

A solução desse falta e a escrita de mais testes, e mais associações ("bindings") com fontes de e-mail são o ponto focal do desenvolvimento sendo realizado. Atualmente estão disponíveis associações com Procmail, Qmail, Postfix, SendMail através da biblioteca Milter, e um plugin Mail::Audit.

Espero que me desculpem por mencionar que o filtro Milter [9] para Sendmail foi escrito por mim depois de uma busca sem sucesso por soluções já xistentes; por isso pude usar SpamAssassin para filtrar todos e-mails que recebo. A falta de tempo me impede de manter o projeto adequadamente, por isso Michael Brown, cuja companhia o emprega/oferece em um ambiente comercial, assumiu como mantenedor, na melhor tradição do Software Livre.

Este é um bom exemplo de como o Software Livre pode harmonizar a abordagem clássica "coce sua própria coceira", com os interesses comerciais de uma companhia, para atender melhor a todos seus usuários.

Tendo que enfrentar uma crescente inundação de Spam ameaçando cobrir meu acesso à Internet, admito que guardo grande simpatia por projetos como SpamAssassin, que me livra de 60 mensagens de Spam por dia.

Voxximate

Os leitores regulares da Admirável Mundo GNU devem estar bastante familiarizados com muitos argumentos a favor do Software Livre no campo da ciência.

Em última instância, o Software Livre é, a longo prazo, a única solução de bom senso para todos tipos de trabalho científico, pois apenas o Software Livre pode oferecer a garantia de se manter útil para futuros projetos. Além disso, ele permite ser incluído junto com os próprios resultados científicos; isto é: ele permite ser publicado como parte do trabalho e ser distribuído quando necessário.

Voxximate [10] é um projeto científico assim, de Software Livre sob a GPL, Licença Pública Geral do GNU.

Voxximate significa "Simulação de vórtice de fluxo feito em casa". Ele é um programa para a simulação de correntes/vértices em fluidos. O programa trabalha a partir de posições iniciais. e usa passos concretos para calcular a influência de todos vórtices uns nos outros, acompanhando a evolução atrave do tempo.

O projeto é útil para todos estudantes que estejam enfrentando a dinâmica de fluidos em algum momento de seus estudos, e que se interessem em estudar como os vértices interagem e constróem estruturas.

Voxximate foi escrito em Java, o que causa os problemas usuais do Java, mas isto não deve impedir ninguém de auxiliar em seu desenvolvimento. Os próximos passos de Andreas serão incluir um editor gráfico para definir posições iniciais, bem como a capacidade de salvar os gráficos e as animações, para que possam ser publicadas na Web.

Monica

Monica [11] é um programa para calibração de monitores criado por Tila Riemer. Ele foi escrito em C++ e usa o Fast Light Toolkit (FLTK) [12], e o programa xgamma do XFree86 [13].

Uma correção gama errada para um monitor pode tornar impossível distingüir cores muito próximas, ou criar uma impressão insatisfatória dos esquemas de cores. Isso pode ser incômodo, particularmente se o computador for usado para trabalho gráfico.

A princípio, Tilo Riemer tentou usar o programa relacionado chamado KGamma [14], mas não conseguiu compilá-lo, pois ele dependia de várias bibliotecas KDE, e também porque KGamma parecia estar tão profundamente embutido no KDE que precisava de grandes partes do KDE para poder funcionar.

Por isso, em janeiro de 2002, Tilo começou a escrever Monica, que tem a vantagem de ser muito pequeno e muito rápido. Isto permitiu incluir um modo "on-the-fly", que possibilita o feedback dinâmico. Em um computador de 900MHz, isto ocupua entre 10 e 20% do tempo da CPU.

Outros pontos altos de Monica são a ausência de outras dependências que não o FLTK, e a política de gravar alterações no ".xinitrc" do usuário, tornando-as independentes de gerenciador de janelas e de "desktop", ou "ambiente de trabalho".

O lançamento recente da versão 1.0 indica que Tilo não planeja investir muito mais em Monica, apesar de que ele receberia bem qualquer esforço para internacionalizá-lo.

Inicialmente, Tilo planejava lançar Monica como "Domínio Público", pois ele parecia pequeno e insignificante para se pensar sobre licenças. No código fonte ele escreveu "Copyright © Tilo Riemer", mesmo sem pensar mais sobre isso.

Contudo, a moção de Domínio Públio tem seus problemas na Europa continental. Na Alemanha, a interpretação jurídica padrão do termo é livre de pedidos de autoria e copyright -- que em geral significa que o autor é desconhecido ou morreu há mais de 70 anos. Claramente, nenhum dos casos se aplica.

Por isso, Tilo decidiu lançar Monica sob uma licença semelhante à do BSD, resolvendo os problemas imediatos e fazendo Monica um Software Livre.

Esta estória não é muito rara e demonstra que os desenvolvedores obviamente não gostam muito de pensar sobre licenças -- apesar de que isto torna muito fácil criar inseguranças. Portanto, tentarei fazer uma introdução compreensível à possibilidade de manutenção legal do Software Livre.

Possibilidade de manutenção legal do Software Livre

A maior parte das pessoas está consciente de que todo software requer manutenção técnica permanente, ou ele vai rapidamente perder sua utilidade. Em geral, apenas software que receba permanente manutenção pode ser empregado por períodos de tempo mais longos.

Esse procedimento técnico depende do acesso ao código fonte e o direito -- isto é: a liberdade -- de realizar a manutenção. Em termos gerais, o que o sistema político-jurídico faz é definir os direitos e os deveres de cada membro da sociedade.

O ponto importante aqui não é discutir se o sistema jurídico funciona bem ou não. O que se deve perceber é que alguns dos pré-requisitos para a possibilidade de manutenção técnica são de natureza legal.

Particularmente em um ambiente comercial, a garantia da possibiliade de manutenção permanente e duradoura é uma das vantagens seminais do Software Livre. Essa vantagem depende fortemente da possibilidade legal de manutenção do Software Livre.

As liberdades, direitos e deveres do Software Livre são garantidos e algumas vezes protegidos através de licenças, que são "ancorados" ao software através do copyright do autor. O Software Livre não depende estritamente da lei de copyright para funcionar, mas uma vez que a lei do copyright existe, temos de lidar com ela.

O que significa nesse contexto a possibilidade legal de manutenção?

Mesmo se não é assim que a maioria das pessoas intuitivamente o perceba, o sistema jurídico não é estático, ele está em permanente mudança.

As alterações à lei do copyright podem, como recentemente foi o caso na Alemanha, enfraquecer ou até mesmo tornar ilegal o Software Livre. Neste caso específico, a iFross [15] e a FSF Europa [16] foram capazes de sugerir uma alteração a uma emenda proposta para a lei de copyright, introduzindo uma exceção para o Software Livre. Esta alteração foi incorporada à lei aprovada em 25/01/2002, que vai passar a vigorar em breve.

Uma das tarefas da FSF Europa é se manter atenta a tais desenvolvimentos e influenciá-los de forma positiva ao Software Livre. Sem a cooperação de organizações como a ifrOSS, que é claramente legal em sua natureza, fazer isto seria muito mais difícil. É por isso que a FSF Europa trabalha para estabelecer cooperações através da Europa, e para fortalecê-las.

Também teria sido possível que as alterações em outros parâmetros jurídicos tivessem requerido uma adaptação nas licenças. Mudanças legais ou novos conceitos como os ASP ("Application Service Providers", ou "Servidores de Aplicativos") podem chegar a burlar a proteção da liberdade em algumas áreas, ou até mesmo torná-la ineficaz, efetivamente violando o espírito das licenças.

A maior parte dos desenvolvedores publica seus softwares sob a GPL, Licença Pública Geral do GNU, certos de que com isso eles asseguraram e protegeram a liberdade de seu software. Quando o fazem, foi tomado o passo mais importante na direção de proteger o Software Livre. Através do emprego da cláusula "ou qualquer outra versão posterior", a FSF ganha parcialmente o poder de proteger, defender e manter globalmente o licenciamento sobre a GPL e a LGPL.

Algumas vezes, contudo, pode ser importante alterar explicitamente uma licença. Os projetos que não estabeleceram uma manutenção central de seus direitos legais podem cair em sérios problemas, particularmente quando a cláusula "ou qualquer outra versão posterior" da GPL é retirada.

Em tal caso, todos desenvolvedores -- asumindo que eles possam ser encontrados -- tem de concordar com a mudança. Dado o amplo espectro de interesses e opiniões dos desenvolvedores trabalhando em alguns projetos, isso não parece muito provável.

Além disso, em muitos casos, apenas quem mantém os assim chamados "direitos exclusivos de exploração"; isto é: o "proprietário do copyright" é quem tem o direito legal de fazer valer a licença no tribunal. Assim, os participantes de um projeto podem incorrer em grandes dificuldades se tentarem representar os interesses do projeto em tribunal.

Dado que muitos autores trabalham em um projeto, eles vão ter de se congregar e agir conjuntamente para proteger seus interesses individuais. Isto exige muita coordenação, tempo e esforço. Também nem todos autores desejam ou são capazes de acompanhar até o fim uma batalha legal que possivelmente vai demorar muito tempo.

Seria bom se mais projetos tomassem consciência dessas relações e tomassem as precauções necessárias. Quando apontam um fiduciário, os autores podem voltar a se dedicar a melhorar o próprio software.

No futuro, parece provável que os projetos com situação legal clara e bem resolvida vão ganhar popularidade mais facilmente, pois os usuários vão provavelmente passar a dar mais atenção a isso.

Para assegurar a possibilidade legal de manutenção do Software Livre -- particularmente na área mais interna do Projeto GNU, mas não apenas nela -- a FSF ("Free Software Foundation", ou "Fundação para o Software Livre"), começou há muito tempo a trabalhar com as assim chamadas "Atribuições de Copyright", que dão poder a ela para defender os direitos do Software Livre, até mesmo em tribunal, se necessário, e a adaptar o licenciamento às circunstâncias sempre em mudança.

Uma vez que a lei de Autoria da Europa continental tem bases diferentes do Copyright anglo-americano, a FSF Europa tem trabalhado com Axel Metzger, Carsten Schulz e Till Jaeger, da ifrOSS, em um "Acordo de Licença Fiduciária", que permite que a FSF Europa atue como o fiduciário dos autores.

O autor retém uma quantidade ilimitada de "direitos únicos de exploração", que podem ser usados pelo autor para licenciar o software de modo dual, sob outras licenças, possivelmente proprietárias.

Ao mesmo tempo, a FSF Europa garante que vai usar apenas os direitos transferidos no interesse do Software Livre e que vai apenas publicar o software sob uma licença Livre -- de forma que todos os outros direitos sejam do autor.

Este acordo está em sua "fase de revisão" interna e final, e será apresentado ao público em um futuro não muito distante.

Como presidente da FSF Europa, considero que as Fundações para o Softwre Livre sejam as mais capacitadas para esta tarefa, pois elas continuarão a atender a esses desafios com a confiabilidade pela qual a FSF foi por muitos anos conhecida.

Como ninguém conhece mais a Licença Pública Geral do GNU (GPL) ou a Licença Pública Menos Geral do GNU (LGPL), e nem tem mais experiência do que elas, elas podem atuar no mundo todo e tem uma reputação justifica de terem meios de defender os interesses do Software Livre. Se necessário através de meios jurídicos.

Por hoje é só

Isso basta por hoje. Na última parte espero ter conseguido deixar mais claro qual o background, as tarefas e o trabalho da FSF, Fundação para o Software Livre.

Como de hábito, gostaria de receber muitos e-mails [1] que tragam idéias, comentários, questões e novos projetos.

As usual, I'd like to ask for loads of Email [1] containing ideas, comments, questions and new projects.