This is a good day. Today we celebrate the 18th birthday of the Debian project, the system that I’ve been using and loving for some years. Following the steps of some great people and influenced by Valessio, I’ve decided to give some love to the app used last year to aggregate congratulation messages for debian.

After some days working with Metal, we finally released an usable version of the “DAD” app. There’s a lot of work to do to improve it, but at least for this year, we’ll be able to receive pictures of people partying this great day!

So, I invite you to send your thanks to people that work on Debian to bring you the best operating system ever! If you find some debian volunteer, please pay him/her a beer and take a picture to share with our lovely community here: http://thank-you.debian.net

Logo depois do ocorrido, entrei no “modo espelho” e comecei a refletir. Não acho que deixar os detalhes de lado é a fórmula mágica para resolvermos grandes problemas. Além disso, tenho uma máxima que, pelo menos no que tange à metodologia de desenvolvimento de software livre, tem funcionado bem: Fazer bem feito não demora mais do que mal feito. Foi essa frase que me fez clamar pela ajuda de alguns profissionais da PROCERGS para fazermos com que o site do Gabinete Digital (lugar que trabalho hoje) tivesse sido liberado numa licença livre, e tivesse o código publicado.

Porém, a maioria dos espaços que frequento tentam me dissuadir do contrário. Me lembro, por exemplo, da hackparty que participei pra criar visualizações que exaltassem a falcatrua do ECAD durante a consulta da modernização da lei de direito autoral. O pessoal da transparência hacker priorizou a publicação dos gráficos que comprovavam o que todo mundo já imaginava, mas deixou pra um segundo momento a publicação de código. Mais um caso de “detalhe” deixado de lado. Documentei a passagem num email que enviei à lista do thacker que foi prontamente respondido pelo pessoal, mas pra mim teve gostinho de “Não vamos brigar por isso”

No que tange ao software livre então, a coisa piora. Se fosse por falta de opção, eu relevaria. Mas dizer que o “OSM é incompleto, por isso vamos Google Maps”, ou dizer que “Ninguém usa o Gitorious, prefiro o GitHub” só contribue com o crescimento e avanço de projetos proprietários e centralizados na mão de poucos em detrimento aos livres e desenvolvidos em comunidade.

E assim, a militância pelo Software Livre vai seguindo seu rumo ao grandioso, deixando esses detalhes “meramente operacionais” de lado, afinal vale mais saber que mais pessoas usam um software “meio” livre ou que simplesmente “roda no Linux” do que tocar em assuntos tão tão “radicais” quanto licenças de software.

O mais intrigante disso tudo é que ouço isso de outros militantes, de pessoas que, em tese, estão no mesmo barco que eu. O tão famigerado usuário não tem nem direito de entrar nessas discussões. Afinal de contas, na visão do “técnico” ou do “engajado”, “usuário quer sempre tudo fácil”.

Então é isso, seguimos com nossas grandes batalhas contra moinhos de vento, sem perceber que às vezes pequenas ações, pontuais e bem executadas, são mais efetivas do que os grandes projetos.

Acredito que uma reflexão sobre o que significa “implantar software livre” é necessária antes de ousar responder a pergunta acima.

Ao se falar de Software Livre no âmbito governamental, a ideia que se tem normalmente é de promover a instalação e o uso de programas como o Firefox, OpenOffice ou alguma distribuição GNU/Linux (como sistemas operacionais baseados no Debian, Ubuntu etc). Embora a promoção do uso de sistemas livres dentro dos governos seja importante, é fundamental ter a dimensão que esse passo não representa a real inovação que o Software Livre significa. E mesmo este passo “mais simples” parece estar longe de ser compreendido pela gestão pública.

Indo mais além, acredito ainda que a própria “comunidade de militantes e entusiastas” do software livre ainda não entendeu o que realmente significa implantá-lo em qualquer organização. Porém, por mais fundamental que seja a discussão sobre uso e contribuição para o desenvolvimento de Software Livre no Brasil, não pretendo discorrer muito sobre isso. Ainda mais depois que o Jomar sintetizou grande parte de tudo que havia pra ser dito sobre o tema num post muito bom.

Voltando à pergunta inicial, quando o assunto é discutido no “metiê técnico”, o tópico ganha maior abrangência. Ao invés de ficarmos restritos à migração de softwares proprietários para livres, começamos a falar de algo muito mais interessante para a gestão pública, a apropriação tecnológica. Com esse aprofundamento, podemos, além de usar as ferramentas, fazer parte da sua construção. Passamos a ter a capacidade de alterar o seu comportamento e de criar novas funcionalidades. Isso significa tomar o controle, ter autonomia sob as informações processadas pelos softwares e seu processo de gestão. Esse avanço traz ganhos imediatos, como a certeza de que as informações estão sendo processadas da maneira que gostaríamos, a independência de fornecedor e a possibilidade de inovação tecnológica, dentre outros.

Além disso, um ponto de vista interessante que projetos como o Portal do Software Público ressaltam, é a ideia de tratar o software desenvolvido pelo governo como um bem público, que deve estar disponível para o contribuinte de forma livre.

Mergulhando de vez no problema, esse é o primeiro passo objetivo para responder a pergunta que inicia esse post. Software livre é por definição transparente, pois se o “cliente” de um software que publica dados não tem a possibilidade de auditar as linhas de código e esse controle está na mão de uma empresa, seja ela pública ou privada, não há como garantir que esse dado não sofreu algum tipo de tratamento tendencioso, mesmo que por acidente.

Antes de continuar a reflexão, saliento que acredito profundamente na importância tanto da instalação quanto do desenvolvimento de softwares livres no governo. Porém, o assunto não acaba por aqui. Existe algo transversal a esses dois tópicos já levantados na discussão. Algo mais rico e, na gestão pública, mais poderoso: a metodologia profundamente baseada na colaboração.

Definitivamente, não afirmo que para ser livre na concepção definida pela Free Software Foundation, um software precise ser desenvolvido de forma colaborativa. Existem vários casos de softwares livres famosos são desenvolvidos por uma única pessoa, por falta de recursos, de interesse de outros colaboradores ou até mesmo pelo nível de arrogância do desenvolvedor. Mesmo que publicar o código-fonte não garanta que o processo vá ser colaborativo, é imprescindível que o código seja público para que a construção possa ser colaborativa.

Quando se trata de softwares desenvolvidos para a internet, a transparência é ainda mais frágil. Mesmo a escolha de uma licença livre, como a GPL, não garante que o código de um site “livre” seja público. A única licença que garante a publicação de uma cópia idêntica do código que faz o site funcionar é a AGPL. Mas o que quero descrever é algo que vai além desses casos. Chamo atenção para alguns pontos que são muito importantes para que um software possa desenvolvido de forma colaborativa:

• Código público desde o primeiro commit
• Rastreador de correções e modificações (Bug tracker) público
• Resposta do mantenedor aos patches e modificações submetidas pela comunidade

Grandes corporações e empresas de software proprietário já apostam nesse modelo. O governo precisa se apropriar da metodologia colaborativa e do ambiente de inovação decorrente desse processo. Por mais que inovação já seja motivação suficiente, desenvolver software de forma colaborativa é a melhor forma que Governos Democráticos tem de garantir que a sociedade esteja de fato participando da discussão, formulação e decisão a respeito dos processos que são materializados em código. Afinal, publicar um software com uma licença livre depois do seu desenvolvimento tem um efeito muito menor que o de agregar a sociedade à sua criação desde a primeira linha de código.

O conceito de governo colaborativo e que inclui a inteligência coletiva (“wisdom of the crowds”) em seus processos (que no jargão publicitário está sendo chamado de Governo 2.0) não poderá ser realizado se a produção da infraestrutura tecnológica que dá base a esse tipo de Governo não estiver pautada pelos mesmos princípios. É um contra-senso que um Governo que busque valorizar a democracia e a ação da soberania popular nos seus processos não estabeleça um ambiente colaborativo para a produção dos sistemas que colocarão tudo isso em prática.

Assim, “implantar software livre no governo” só vale a pena se formos além da mera migração – e mesmo do desenvolvimento de softwares próprios com licenças livres. Aplicar um processo colaborativo no desenvolvimento de soluções técnicas públicas, livres, agregando não só o governo como um todo, mas também cidadãos e cidadãs, é ao mesmo tempo o verdadeiro desafio e a maior contribuição que o Software Livre tem a dar a uma sociedade.

Agradeço imensamente ao Ricardo Poppi, pelas contribuições pontuais por todo o texto e por dois parágrafos épicos (12 e 13), sem dúvida vale a pena convidá-lo a vir ao meu lugar comum mais vezes. Agradeço também a Mariel Zasso pela sua revisão detalhada e paciente

Acredito que evoluímos, crescemos e encontramos o nosso lugar, nosso lugar comum. Ele diz da nossa vida, da nossa experiência, do que acreditamos e principalmente do abusos e absurdos que assistimos muitas vezes de mãos amarradas.

Como já disse no inicio queríamos mudar o mundo, mas foi lendo uma frase do Dalai lama que o projeto tomou um novo rumo e encontrou seu lugar.

“Se você quer transformar o mundo, experimente primeiro promover o seu aperfeiçoamento pessoal e realizar inovações no seu próprio interior. Estas atitudes se refletirão em mudanças positivas no seu ambiente familiar. Deste ponto em diante, as mudanças se expandirão em proporções cada vez maiores. Tudo o que fazemos produz efeito, causa algum impacto.”

Decidido em praticar a essa mensagem o comum inaugura uma nova fase.
E para marcar essa transformação inauguramos o blog para postar o que pensamos, o que estamos fazendo e compartilhar algumas coisas que achamos que pode ser de interesse comum.

“Quando eu vivo esse encontro,
Eu digo adeus
Refaço os meus planos
Pra rimar com os seus

Abandono o que é pronto
E digo adeus
Eu trago os meus sonhos
Pra somar aos seus”

Adeus – Móveis Coloniais de Acaju

E faço das palavras do Móveis o convite para todos que se interessarem ou compartilharem desse nosso lugar comum.

Sejam bem vindo(a)s!

ps: Aos que se perguntam da origem do nome, escutem “lugar comum” do João Donato / Gilberto Gil

Porém, nem todos os usuários se sentem confortáveis com esta prática. Eu, por exemplo, prefiro usar um programa específico pra ler emails (mutt), outro para mensagens instantâneas (gajim), outro para bate-papo (xchat) e assim por diante. Infelizmente, por esta prática ser, atualmente, menos comum, vários administradores de rede espalhados pelos mais diversos lugares, preferem bloquear todos os outros serviços e deixar disponível somente o bom e velho HTTP.

Além disso, a disponibilização do HTTP pode estar sendo moderada. Ou seja, quem provê a conexão com a internet pode colocar um programa intermediário entre o utilizador e o servidor de conexão para restringir o acesso a certos sites. Ou pior, para coletar dados de quem usa aquela conexão. Por mais que exista o HTTPS, protocolo que criptografa a conexão entre o cliente (o navegador) e o servidor HTTP, existe a possibilidade de haver a quebra dessa segurança no momento do handshake (quando o navegador troca chaves com o servidor).

Para a minha infelicidade, nos três últimos lugares que trabalhei (no atual, inclusive), a conexão com a internet era muito restrita. Como não tenho serviço de webmail instalado no meu servidor de emails, nem uma interface web para chat no meu servidor de mensagens instantâneas, tive que encontrar uma  maneira de usar esses serviços.

Das várias vantagens de se alugar um servidor, digo que poder escolher qual em porta o serviço de conexão remota (SSH) vai escutar é, sem dúvida, uma das que mais me ajudou nessa iniciativa. Vamos a um rápido passeio sobre como consegui acessar meus serviços de comunicação vitais através das  terríveis redes bloqueadas nos lugares em que trabalhei.

Primeiro passo

Configurei meu servidor SSH externo para responder na porta 443, porta normalmente usada para prover o serviço HTTPS.

Para este passo, você precisa de poderes administrativos no servidor externo em questão (vulgo root). Depois de autenticado como root,
basta adicionar a seguinte linha ao arquivo /etc/ssh/sshd_config:

Port 443

Lembrando que provavelmente você vai encontrar algo como Port 22. Não é necessário remover esta linha, você pode adicionar a linha sugerida à cima perto desta para manter seu arquivo de configuração organizado.

Outro detalhe importante. Você provavelmente não vai conseguir se conectar ao seu servidor se estiver numa internet bloqueada. Faça isso de casa ou de uma conexão 3g.

Segundo passo

Depois de se certificar de que seu servidor SSH já responde na porta 443, o próximo passo é poder se conectar a este servidor de dentro da
rede fechada.

Para finalizar esse passo, baixe o script ssh-https-tunnel e vamos configurá-lo. Apesar de estar mais do que clara a documentação do mesmo, vamos repeti-la aqui:

Crie ou edite o arquivo $HOME/.ssh/config com o editor de textos de sua preferência. Após abrir o arquivo, insira as seguintes linhas no mesmo:

host <servidor>
  ProxyCommand </caminho/para/o/script/ssh-https-tunnel>  %h %p
  Port 443
  ServerAliveInterval 10

Substitua o <servidor> pelo endereço do seu servidor de SSH externo e preencha o caminho correto para o script ssh-https-tunnel. O meu arquivo, na íntegra, fica da seguinte maneira:

host nina.comum.org
ProxyCommand /home/lincoln/Bin/ssh-https-tunnel %h %p
Port 443
ServerAliveInterval 10

Além disso, certifique-se de que o script ssh-https-tunnel tenha permissão de execução. Para ter certeza, execute o seguinte comando:

chmod +x /caminho/para/o/script/ssh-https-tunnel

Vamos agora configurar o próprio ssh-https-tunnel. Abra o arquivo com o editor de textos de sua preferência e altere as seguintes linhas:

# Proxy details
my $host = "localhost";
my $port = 8080;

# Basic Proxy Authentication - leave empty if you don't need it
my $user = "";
my $pass = "";

Nesse arquivo você deve preencher no mínimo as duas primeiras variáveis: $hosts e $port que determinam o endereço do servidor e a porta em que o proxy da sua rede está configurado.

Pronto, agora é só testar a conexão. Faça isso com o seguinte comando:

ssh <servidor>

Substitua pelo endereço que você informou no arquivo .ssh/config. No meu caso, o nina.comum.org.

Se a conexão aconteceu com sucesso, você pode passar para o próximo passo. Porém, infelizmente, esta solução serve apenas para um caso específico. Existem outras milhares de maneiras de restringir o acesso a uma rede. Estou mapeando apenas a mais comum e a que eu precisei me ver livre.

Noutro post, talvez, eu possa relatar minha experiência com um proxy NTLM que precisei me conectar para alcançar o mundo externo.

Se você não conseguiu sair desse passo, entre em contato com uma pessoa comum, é bem provável que ela possa te ajudar

Terceiro passo

O SSH é sem dúvida uma das maiores motivações técnicas que tenho para usar um sistema operacional livre. No meu caso, o Debian. Além de permitir que você se conecte a outro computador que suporte o mesmo protocolo, e de várias outras funcionalidades que, um dia ou outro você vai precisar, o ssh implementa o protocolo SOCKS5 que foi desenvolvido justamente para facilitar o roteamento de pacotes entre aplicações cliente-servidor através de um proxy.

Para começar a brincadeira, execute o ssh de modo que um proxy SOCKS5 seja levantado:

ssh -D localhost:1080 <servidor>  # no meu caso, nina.comum.org

Se tudo ocorreu bem, ótimo, você já tem um proxy para suas conexões com a internet. Siga feliz para o próximo passo.

Quarto passo

Você precisa saber se a aplicação que pretende usar é compatível com o protocolo SOCKS. Uma dica objetiva é usar o Firefox (ou iceweasel, se você está no Debian). Vá até a configuração de conexão do navegador pelo caminho Editar > Preferências > Configurações > Rede e escolha o protocolo SOCKS5 e preencha o servidor com localhost e a porta com 1080. Dai é só tentar acessar algum site. Se funcionou, comemore

Se a sua aplicação não suportar o proxies que usem o protocolo SOCKS5, não se preocupe, você pode usar uma ferramenta maravilhosa, chamada tsocks que sobrescreve a chamada connect() da libc e força a requisição da aplicação executada pelo tsocks a usar seu proxy ao invés de se conectar direto.

Para instalar o tsocks, use algo como

sudo aptitude install tsocks

A configuração do tsocks é muito simples. Como root, abra o arquivo /etc/tsocks.conf e preencha da seguinte maneira:

local = 192.168.1.0/255.255.255.0
server = 127.0.0.1
server_type = 5
server_port = 1080

O único detalhe a se tomar cuidado é o preenchimento da variável local. Esta variável especifica a faixa de IP da rede em que você está. Se não configurada corretamente, o tsocks tentará passar pelo proxy sem necessidade e os serviços da sua rede local estão inacessíveis.

Eu dedico este posta ao amigo Guerrinha, afinal de contas, ele foi quem me motivou a escrevê-lo