De início ele disse que a legislação brasileira permite a utilização de partes de obras alheias na criação de outra, o que lhe dava o direito de fazer o que fez. Seu argumento é que há coisas que a legislação permite explicitamente e coisas que ela proíbe explicitamente. O problema é a fronteira que não fica muito bem definida. Segundo ele, muitas vezes quando temos vontade de fazer alguma coisa que parece estar na fronteira acabamos desistindo por medo de que alguém possa nos questionar. O resultado desta atitude é que a fronteira vai lentamente ficando cada vez mais pro nosso lado. A atitude dele é a oposta, i.e., ele tenta forçar a fronteira do que é permitido a se expandir. Muito bom mesmo. No final ele foi ovacionado de pé por muita gente.
A seguir assisti à palestra sobre Neutralidade na Rede, do Carlos Afonso, membro do Conselho Gestor da Internet no Brasil. Estou ciente da questão mas não a tenho acompanhado em detalhe. A sala estava lotada e ele também foi muito aplaudido.
Como exemplo do que os grandes provedores de hoje estão fazendo ele citou o caso da Brasil Telecom, que estaria usando um sniffer especializado para detectar e restringir o tráfego de VoIP na sua rede. A questão, segundo ele, não é usar o sniffer, pois há razões técnicas para manter estatísticas de utilização da rede. A questão é se a empresa poderia usar estas informações para priorizar tráfego que lhe interessa ao mesmo tempo em que bloqueia ou restringe tráfego que não lhe interessa. No caso específico, a empresa estaria reduzindo a banda efetiva de pacotes de tráfego VoIP que não fossem providos pela própria provedora. Parafraseando a declaração universal dos direitos humanos, ele disse que deveria haver uma outra declaração para a Internet dizendo que "Todos os datagramas são iguais perante a rede".
Outro exemplo indo na mesma linha é o caso da AT&T que foi denunciada por um funcionário por estar usando um sniffer para capturar pacotes em algum entroncamento de sua rede e repassando as informações coletadas para a própria NSA!
Outra questão que ele levantou é a da eventual obsolescência da UIT como organização. O problema é que a convergência das telecomunicações tradicionais com a Internet deverá obsoletar todos os protocolos padronizados pela UIT a longo prazo. Por isso, haveria um movimento dentro daquela organização vizando trazer pra ela a responsabilidade pela governança da própria Internet.
Por fim, ele comentou sobre a recente reunião do Fórum Internacional de Governança da Internet de que ele participou em Genebra. O assunto de neutralidade da rede estava em pauta quando um representante chinês se levantou e disse que dado o que ele estava vendo ser discutido ele não via razão para que o mundo todo criticasse a censura que o governo Chinês impõe ao acesso à Internet pelos seus cidadãos. Houve uma gritaria geral, criticando o pronunciamento do chinês, mas o Carlos se levantou e disse que o colega tinha um ponto. Afinal, a censura chinesa existe mas é explícita. O governo chinês não a esconde. Já as ações de empresas como a Brasil Telecom e a AT&T são feitas na surdina e têm o efeito de censurar determinado tráfego. Em última instância, a diferença é apenas que são grandes empresas e não governos que estão realizando a censura neste caso.
Depois desta palestra fui ao YAPC::SA::2007, encontro da comunidade Perl. Não havia muita gente. Acho que umas 20. Antes de começar fui abordado por um rapaz que me reconheceu pelo nome. Ele ouviu minhas entrevistas no Papotech e me cumprimentou. Fiquei lisonjeado. O nome dele eu não me lembro, mas ele é conhecido como Lorn, na comunidade Perl. Acabou fazendo uma apresentação rápida e bem interessante sobre o Catalyst. Até dá vontade de brincar com isso.
Antes do Lorn, o Flávio Glock, líder da comunidade Perl no Brasil, apresentou o projeto em que está atualmente envolvido: o MiniPerl6. Trata-se de um compilador que converte miniperl para várias coisas, como Perl5, Perl6 e Parrot. O conceito é interessante e a descrição do processo de bootstrap mais ainda. Miniperl é um Perl em miniatura. O suficiente para escrever um compilador nele próprio. A idéia seria escrever o compilador Perl6 em miniperl pra poder usá-lo no bootstrap de um futuro compilador Perl6-Perl6. Depois da palestra conversei mais um pouco com ele e perguntei sobre o relacionamento entre os projetos Pugs e Parrot com o dele. O projeto MiniPerl6 está sendo tocado dentro do Pugs, com a benção do próprio Larry Wall. Parece que houve um stress no passado quando o Glock participou do projeto Parrot e não se sentiu bem recebido. Agora parece que isso são águas passadas e que os vários projetos estão trocando figurinhas. Mas quanto à questão de qual a expectativa dele para termos finalmente um compilador Perl6 oficial, ele desconversou. :-)
Saí no meio do YAPC pra assistir à apresentação do Randal Schwartz sobre o git, a ferramenta de controle de versão que o Linus Torvalds começou a desenvolver depois que não pode mais usar o BitKeeper. Foi uma apresentação excelente, se bem que foi tanta informação que no final eu estava meio tonto. Acho que todo desenvolvedor deveria assistir a uma apresentação assim pra ver quanta funcionalidade uma ferramenta moderna como o git oferece para suportar o desenvolvimento de software de modo distribuído.
Em relação à arquitetura, o git se parece mais com o BitKeeper e com o SVK e é bem diferente do CVS, do SVN ou do ClearCase, pois não há um repositório central no qual todos os desenvolvedores mantêm seus objetos. Cada desenvolvedor cria um repositório local e interage com os repositórios alheios através de cópias e de merges.
O git é otimizado para:
- Desenvolvimento distribuído
- Grandes conjuntos de arquivos (o Linux kernel tem aproximadamente 25.000 arquivos)
- Merges complexos
- Criação de branches
- Ser extremamente eficiente
- Ser robusto
- Manter metadados dos arquivos. De fato, ele lembra apenas se o arquivo é executável ou não. Permissões de leitura e de escrita, usuário e grupo são coisas que ele simplesmente não guarda. O Linus Torvalds argumenta que estas informações são irrelevantes para o tipo de arquivos para o qual o git é feito, i.e., para arquivos fonte de programas.
- Manter o histórico de um único arquivo.
- Tornar as coisas difíceis. :-)
Ele falou bastante e fez uma demonstração básica. Foi muita coisa e não me lembro de tudo. Uma das coisas que mais me impressionou foi a facilidade para a criação e descarte de branches. Eles são realmente baratos. Um novo branch gasta apenas 41 bytes! E quanto você resolve que um branch não deu em nada, pode mandar destruí-lo e ele realmente vai embora, ao contrário do que acontece com a maioria dos outros sistemas de controle de versão.
Achei fantástico que toda a demonstração foi feita dentro do Emacs. O Randal disse que: "I live inside Emacs". Mas, a certa altura, ele se pegou criando arquivos usando comandos como "echo something >file1". Mas como a shell dele estava dentro do Emacs ele disse: "isn't it increadible that I'm using echo to create a file inside Emacs?" :-)
Perguntei-lhe sobre outros projetos que já estejam usando o git e ele me disse que a entrada sobre o git no Wikipedia mantém uma lista. Mas citou o X.org e o Wine.
Do git acabei pegando o final da palestra " Designing Efficient APIs for Long Lived Open Source Projects" de um cara da Sun. Era tudo Java e fiquei boiando. :-)
Na seqüência eu fui assistir à palestra "As Ações mais Legais da FSFLA", apresentada pelo Oliva, pela Fernanda Weiden e pelo professor Pedro Resende, todos conselheiros da FSFLA. Eles fizeram um rápido relato das questões mais relevantes em que a FSFLA se envolveu no último ano em defesa da liberdade dos usuários de software. Começando pelo estudo que fizeram sobre os requisitos que a própria Constituição Federal impõe sobre as tecnologias empregadas na implementação dos sistemas informação do governo e dos meios de comunicação com o cidadão. Eles demonstram que estes requisitos acabam exigindo que as quatro liberdades que definem o software livre sejam resguardadas, o que implica em que estas tecnologias só poderiam ser implementada usando software livre. Esses requititos vêm de princípios básicos, como soberania nacional, transparência e isonomia na prestação de serviços e no investimento responsável dos recursos públicos. Eu não poderia fazer melhor do que referenciar o artigo em que tudo isso é explicado convincentemente.
Outro assunto foi o dos softwares impostos, como o programa para declaração de imposto de renda. Não é meramente o fato de ele ser feito em Java que ainda não (mas quase) é software livre. Outro problema é que o parágrafo terceiro do artigo primeiro da Instrução Normativa SRF nº 616, de 31 de janeiro de 2006, da Receita Federal define alguns critérios que proíbem quem quer que os satizfaça de declarar sua renda no formulário em papel. O próprio Alexandre Oliva cai num destes critérios e é obrigado a fazer a declaração com o programa da Receita. Incomodado com isso (eufemismo meu), por considerar que utilizar um programa prietário é imoral, ele tentou argumentar com a Receita Federal solicitando que pudesse fazer sua declaração e papel. Sem sucesso. Mesmo alegando que é um direito constitucional recusar-se a fazer alguma coisa que vá contra suas convicções morais (ou mesmo religiosas), desde que esta coisa não seja imposta a todos. Como nem todos são obrigados a declarar com o uso do programa, ele estaria mais que justificado em se recusar por motivos morais. É o que diz o inciso VIII, do artigo quinto, da Constituição Federal.
Mas isso não é tudo. A Lei de Software, em seu artigo nono, diz que um programa só pode ser usado mediante uma licença de uso de seu autor. Acontece que o programa da Receita Federal não tem uma licença, daquelas que a gente não lê e clica OK. O Oliva questionou o pessoal da Receita e o máximo que conseguiu foi uma resposta na linha de "pode baixar e usar sim". Ou seja, ao pé da letra da lei, o uso do programa da Receita é ilegal.
E ainda tem mais. Decompilando o binário Java do programa da Receita (que, diga-se de passagem, vem com os símbolos de depuração), o Oliva descobriu que ele usa mais de 10 programas livres, a maioria deles licenciado com licenças sem copyleft, o que permite que sejam incorporados ao código proprietário do programa da Receita. Mas essas licenças exigem que o uso dos programas regidos por elas seja declarado na documentação do programa que os incorpora e que uma cópia das licenças seja fornecida. Mas também há componentes LGPL no programa. Neste caso, a Receita deveria fornecer os fontes deste componente. A esta altura você já deve ter adivinhado que o Oliva pediu os fontes e não os obteve. Disseram a ele que ele os poderia obter do site do componente original. Mas isso não vale. A licença obriga o distribuidor a fornecer os fontes quando solicitados. E além disso, não dá pra saber que versão do componente foi usada e menos ainda foi modificada.
Mas nem tudo está perdido. O Oliva conseguiu um documento especificando o formato do arquivo que programa da Receita gera e foi capaz de gerá-lo sem precisar usar o programa. Mas falta ainda um detalhe. Parece que o arquivo precisa conter um hash, calculado sobre o seu próprio conteúdo, de modo que a Receita possa saber que ele foi gerado com o programa que ela fornece e não por um outro. Por isso, eles não forneceram o algoritmo de cálculo do hash, mas o Oliva está trabalhando no código decompilado do programa pra ver se consegue reconstruí-lo. Ele ainda tem uns quinze dias pra poder entregar sua receita sem cometer uma imoralidade.
As conseqüências do seu eventual sucesso são importantes. Em última análise, ele estará criando uma ferramenta capaz de produzir declarações que a Receita não poderá distingüir de uma gerada pelo seu programa. Em tese, isso não devia ser um problema pra Receita, pois de qualquer modo ela deveria realizar verificações de consistência interna da declaração além de cruzar os dados de cada declaração com os das declarações dos fornecedores referidos por ela. Por que será, então, que a Receita reluta em fornecer as informações necessárias para que alguém possa criar um software alternativo ao seu? Não quero especular, mas não consigo imaginar uma razão moralmente justificável.
Depois deste assunto fascinante, eles comentaram um pouco sobre DRM e como isso pode restringir as liberdades dos consumidores de dispositivos eletrônicos que o implemente. Quem quiser saber mais sobre isso pode ler também sobre a tal Trusted Computing.
Por fim, eles anunciaram que uma nova constituição havia sido adotada hoje pela FSFLA. A partir de hoje a FSFLA não é mais uma entidade jurídica própria, mas apenas um grupo de pessoas físicas. Todos os membros passam a ser conselheiros e não há mais uma estrutura formal. A razão para isso é evitar que a FSFLA tenha que ser formalizada num dos países da América Latina em detrimento de todos os outros. Podem haver "braços" nacionais formalizados como pessoas jurídicas, mas a própria FSFLA não será mais assim.
A palestra seguinte foi a do Dan Ravicher sobre "Patents and Free/Open Source Software: Introduction and Analysis". Dan é advogado do Software Freedom Law Center e fez uma palestra brilhante e muito didática. Ele mostrou os problemas causados pelas patentes de software mas argumentou que eles acabam sendo mais impactantes para empresas de software proprietário. Uma razão é o fato de que nos EUA, cada parte envolvida numa ação sobre infração de patentes, paga, em média, uns três milhões de dólares. E lá não existe o princípio de que quem perde a ação arca com as custas advocatícias da parte vencedora. Deste modo, uma empresa detentora de patente só entraria com uma ação de infração se tivesse a expectativa de obter um ressarcimeno financeiro que pelo menos cobrisse seus custos com advogados. Portanto, somente empresas com algum porte seriam vítimas deste tipo de ação e o desenvolvedor de software livre comum não precisaria ficar preocupado.
Faz sentido, mas nem toda ação visa obter ganho financeiro direto. Um risco que independe do tamanho do bolso do desenvolvedor é o caso em que um software livre faz sucesso e começa a atrapalhar os planos de negócio de uma empresa produtora de um similar proprietário. Neste caso, a empresa pode julgar que os custos de uma ação seriam menores que o impacto que o software livre poderia lhe causar em termos de competição por clientes. E eu já ouvi falar de casos assim.
Um outro ponto que ele citou como argumento para justificar o menor risco que o software livre sofre com as patentes está relaciado ao tamanho do canal de distribuição. Se uma empresa que produz um software proprietário é processada por infração de patentes, o juiz pode demandar que o software em questão tenha sua distribuição interrompida. Mas o mesmo não poderia ocorrer caso a empresa processada produzisse software livre. A razão é que quando o software é proprietário, só a empresa que o produz é que tem o direito de distribuí-lo. Já no caso do software livre, se o juíz impedisse a empresa de distribuí-lo ele estaria ferindo um outro princípio jurídico que diz que o cerceamento de direitos não pode ser seletivo. A questão é que quando o software é livre, qualquer outra pessoa ou empresa poderia continuar a distribuí-lo e a empresa processada estaria tendo seus direitos restringidos de maneira inócua.
A próxima palestra foi do Jono Bacon, gerente de comunidade na Canonical, sobre "How to Herd Cats and Influence People". O cara é extremamente elétrico e sabe como cativar o público. Bastante apropriado para a função que ele exerce na empresa. Ele disse que atualmente, principalmente depois que a Canonical fez sucesso com o Ubuntu, todas as empresas de software livre estão bastante preocupadas em cativar uma comunidade fiel. E a Canonical tem conseguido fazer isso como ninguém. Pelo que eu vi, o Ubuntu é, de longe, a distro mais usada neste FISL. Os pontos são os seguintes:
- Encontrar pessoas de qualidade
- Promover a integração das pessoas com interesses comuns
- Promover a comunicação entre esses grupos
- Facilitar a integração de novatos
A última palestra do dia foi do Jon 'maddog' Hall sobre "Why Free Software is Like a Pianola". Ele falou sobre a história dos instrumentos musicais, em particular da do cravo, do piano e dos órgãos. Toda essa história é cheia de paralelos com a história do software. Acho que a idéia é usar esta analogia pra vermos por outra perspectiva as questões prementes sobre tecnologia e direito sobre o software à luz da história dos instrumentos musicais.
Saí da FIERGS e fui ao Shopping Lindóia. Parece que é o mais perto daqui, mas mesmo assim eu achei longe. Era pequeno e eu quase não consegui encontrar as lembranças pra família. Acabou dando tempo e eu jantei num rodízio de pizza. (Estou comendo tão mal que semana que vem vai ser só salada.)
Na volta peguei um táxi. Mal entrei e percebi que o motorista estava ouvindo algum tipo de pregação evangélica. Não deu outra... no caminho ele começou a falar sobre violência, sobre como o diabo veio ao mundo para destruí-lo e sobre como as mulheres deviam permanecer em casa cuidando dos filhos. Neste ponto eu não agüentei e perguntei por que é que nós não trocávamos de lugar com elas, deixando-as trabalhar e ficando em casa cuidando das crianças? Pra quê, né? Ele disse que há um princípio básico de que deus teria feito tudo certo e que o que ele diz ninguém desdiz e que tudo isso estava na Bíblia. Eu contra-argumentei que isso estaria certo desde que todos concordassem com este princípio, mas que minha condição de ateu nos colocava em bases diferentes.
Resultado... ficamos discutindo por mais uns 15 minutos dentro do carro na frente do Hotel. O cara tem uma leitura fundamenntalista da Bíblia. Eu consegui responder a alguns dos seus argumentos tentando mostrar que eles se baseavam ou em uma premissa questionável ou em uma simples falácia lógica. Mas realmente não dá pra levar uma discussão destas com base na razão. Um dos seus argumentos é o de que a Bíblia não deve ser lida com a razão, mas sim com o coração... não sei como levar uma discussão racional a partir disto. Mas tudo bem, quer dizer, nós nos despedimos cordialmente, ele me abençoou e eu o agradeci. Penso que poderia ter sido bem pior.
Amanhã é o último dia.
Nenhum comentário:
Postar um comentário