E-NOT?CIAS
SOFTWARES
Em 1986, eu visitava o Museu Nacional de Antropologia do México quando entrei na sala de exposição das relíquias sagradas da civilização asteca. Lá estavam perfilados os vasos sacrificiais usados no Templo do Sol, ao longo da sua história. Esses vasos recebiam os corações dos prisioneiros sacrificados ao deus Sol, em troca de boas chuvas e fartura nas suas colheitas. A seqüência começava com o primeiro vaso esculpido em pedra, do tamanho de uma tigela de batedeira de bolo, com um bico para escorrer o sangue.
O prisioneiro era levado ao topo da pirâmide, seu peito era aberto com uma faca cerimonial e seu coração era arrancado vivo, colocado ainda pulsando neste vaso. Não fica claro o porquê, mas o fato é que este vaso foi substituído depois pelo seguinte na seqüência. Este segundo era maior, do tamanho de uma bacia, e suponho que podia receber uns dez corações pulsando ao mesmo tempo. Parece que o alto clero teria determinado a troca dos vasos, pela necessidade de mais sacrifícios simultâneos.
A cena ia ganhando dramaticidade, porque este segundo vaso foi substituido por um maior, e este por um outro gigantesco, do tamanho de uma piscina redonda de jardim. A canaleta para correr o sangue neste último era parecida com a bica de um monjolo. A pirâmide do Sol dos astecas havia sofrido sucessivas expansões para poder receber mais gente em seu topo durante os rituais. O pensamento de tentar adivinhar quantos corações pulsantes eram arrancados para encher aquela maior me deixou estarrecido, mas o terror que me marcou para sempre eu senti quando tentei imaginar a lógica daquele processo.
Os astecas sacrificavam apenas prisioneiros de guerra. Alguma escassez deve tê-los convencido de que, para garantir a segurança tinham que se manter num permanente estado de guerra, conquistando povos, para poder suprir as necessidades imprevisíveis do deus Sol com a maior eficácia possível. Num estalo de horror perguntei a mim mesmo: será que, durante todo aquele tempo, nenhum asteca teria percebido que os esforços de guerra e de crescentes conquistas iam deslocando a linha que separa a escassez da fartura, e que aquela escalada sanguinolenta levava a um beco sem saída? Esta é uma constatação muito óbvia para ter escapado a um povo tão industrioso e formidável. Fiquei com a desagradável sensação de que talvez sim, eles viram esse fato, mas o tomaram como inevitável e natural. Não lhes poderia ocorrer que havia algo de errado com o dogma por trás de tudo.
Dogma é isso. Mito, é a religião do outro. E eu fiquei paralisado ao entender o poder do dogma.
E o que tem isso a ver com legislação e a segurança na informática? Parece que quanto mais o mundo investe na segurança dos bits, pior fica o cenário dos riscos e a sofisticação das fraudes e embustes, conforme costatam os especialistas em internet reunidos em setembro de 2000 em Berlim para discutir o assunto [veja <http://www2.uol.com.br/info/
aberto/infonews/102000/24102000-14.shl>]. E o que fazemos? A maioria se ocupa em tentar acompanhar e entender o que está acontecendo, mas tem gente na linha de frente tomando iniciativas.
E o que se ouve do front? A mim me parece que estou ouvindo um coro quase uníssono, clamando por leis mais severas para coibir os crimes digitais, por mais proteção e estímulo a quem investe em tecnologia, por mais investimentos, regulamentos, e iniciativas para garantir a segurança no ciberespaço, pois nele penetra cada vez mais nossa realidade. Alguém ainda discute a importância dos mercados financeiros no mundo globalizado?
O professor é pago para pensar, e feliz do professor que goza a sua liberdade para escolher em que pensar. O que vejo no cenário da segurança na informática me inquieta, e assim, senti-me atraído a refletir sobre a razão desta inquietude. Nelson Rodrigues dizia que toda unanimidade é burra, e o cenário da segurança talvez me inquiete por eu estar supondo que a quase unanimidade é quase burra. Devo então procurar pela quase burrice no lugar comum da segurança dos bits.
Um lugar comum que logo observo é o seguinte. Apesar de recentes, as leis sobre informática já apresentam um vício curioso. Quando se quer atingir um objetivo com tais leis, o mecanismo para atingi-lo tem trazido consigo, via de regra, efeitos indesejados ou imprevistos cuja gravidade e conseqüências não são abordadas durante o debate legislativo. Sempre há pressa em aprová-las, já que a evolução da tecnologia pode torná-las obsoletas antes que entrem em vigor.
Uma estratégia muito em voga para enfrentar essas dificuldades postula que essas leis devem ser neutras em relação à tecnologia, para evitar engessá-la. A tendência começou nos EUA com o DMCA, e ganhou quase unanimidade com a lei e-Sign, aprovada na Câmara por 426 votos a 4. Mas o que normalmente se consegue legislando sobre tecnologia da informação sem mencionar tecnologia é o efeito bode. Os objetivos escapam, e fica-se com os efeitos imprevistos e indesejados. Quando o mau cheiro se instala surgem dúvidas sobre a intenção do legislador, ou melhor, do lobby sobre o legislador.
Essas dúvidas ficam ainda mais inquietantes quando nos damos conta da sinergia possível entre os efeitos colaterais dessas leis combinadas. Em particular, das três leis da informática mais importantes, aprovadas nos EUA nos últimos dois anos: a DMCA, a e-Sign e a UCITA. Não quero ser alarmista, mas acho que o quadro ali desenhado tem algo a ver com a experiência asteca, a julgar pelos sintomas. Pode ser que estejamos presos a dogmas cuja utilidade está chegando ao fim.
Vejamos o caso da DMCA. O processo de replicação de representações simbólicas vem ganhando eficácia com a tecnologia, desde a invenção de Gutenberg. Com Hollywood na internet a situação ficou crítica, pois os estúdios precisam controlar a pirataria. O que fazer? O controle de cópias se dá em nível físico, e não sintático. A internet não pode ser controlada em nível físico. A solução foi dar ao controle de acesso sintático, cuja função é isolar conteúdos semânticos, o título de tecnologia anti-pirataria. Assim, a cifragem foi emoldurada na DMCA como tecnologia de proteção contra cópia. O efeito prático foi a introdução do direito do distribuidor de conteúdo digital para controlar mecanismos de acesso, sob o pretexto de ter que controlar cópias, que permanecem incontroláveis, numa lei que pretende ser milenar.
Já a e-Sign é a neutralidade tecnológica em seu ápice caprino. Outorga o direito de se substituir a assinatura de punho por qualquer mecanismo de autenticação digital aceito entre as partes, em contratos eletrônicos. Mas quem são as partes, os mecanismos e os contratos em questão? Os contratos representam, além das responsabilidades que descrevem, riscos opostos para as partes, na forma de possíveis fraudes e repúdios de má-fé. Os mecanismos não podem se valer da jurisprudência tradicional sobre contratos para equilibrar esses riscos e responsabilidades, devido à natureza e características técnicas dos autenticadores digitais. Dentre os mecanismos possíveis, os que se baseiam em biométrica colocam todos os riscos no lado de quem precisa se autenticar, enquanto os que mais se aproximam do equilíbrio da jurisprudência tradicional, aqueles baseados em criptografia assimétrica, não podem alcançá-lo de todo. Já as partes contratantes estarão, via de regra, separadas por várias ordens de grandeza no poder de barganha para negociarem entre si esse equilíbrio, a cada substituição da caneta, voluntária ou não. Como no caso de um consumidor e um monopólio, ou de um cidadão e o Estado. Para não engessar a tecnologia, a solução dada foi jogar fora o molde do objeto da lei.
Para os processos sociais anteriores à internet em que mecanismos desequilibram riscos ? tais como o trânsito, o comércio de alimentos, de medicamentos ou de armas ?, leis foram criadas buscando o equilíbrio de riscos e responsabilidades entre as partes. Essas leis contrapõem para isso liberdades e moldes para engessamentos. Ainda não está claro para mim por que a filosofia tem que ser diferente na esfera virtual, ou se estamos vivendo a ficção de Orwell, em que nos são oferecidas justificativas em novilíngua.
A UCITA completa o quadro, com uma proposta para uniformizar as leis estaduais que regulam o comércio em transações e processos informacionais nos EUA. Surgiu porque a Constituição do país atribui aos estados o poder de regular o comércio, o que é ineficiente na esfera virtual. Sob o pretexto da necessidade de uniformização, novos desequilíbrios são introduzidos. Em seu modelo de licença para o software há um truque para proteger o produtor contra códigos de defesa do consumidor: a licença passa a ser um contrato particular de prestação de serviço. As licenças exibidas na tela no ato da instalação do software são legitimadas, com as costumeiras cláusulas desequilibrantes e outras ainda mais draconianas, enquanto outros mecanismos de defesa do licenciado são neutralizados, com o foro jurídico do contrato sendo o estado do produtor, onde vigora a UCITA.
Segundo juristas que a criticam, a UCITA criminaliza a auditabilidade, a engenharia reversa, a comparação de performance e a divulgação de falhas ou engodos nas promessas de funcionalidade do software [veja <http://www.cnn.com/2000/TECH/computing/03/07/ucita.idg/index.html>]. Ela consente explícitamente que o produtor instale gatilhos para implosão remota no software, para o caso de suspeitas de quebra do contrato pelo licenciado, na qual o produtor é isento de qualquer responsabilidade por disparos acidentais ou maliciosos. Conta com forte lobby de grandes empresas e com o repúdio de todas as entidades jurídicas e organismos de defesa do consumidor que já a examinaram. Suas 350 páginas de hermetíssimo legalês estão em debate ou tramitação em 48 estados americanos, tendo sido aprovada nos dois onde já foi votada.
O grande esforço legislativo americano para aprovar e estender a jurisdição destas leis ao âmbito da OMC, da ALCA e da União Européia está parecendo uma corrida pela fartura através de um beco sem saída. Não é preciso muita imaginação para antever como a sinergia dessas três leis combinadas poderá operar. Eu peço apenas que me respondam o seguinte. Você comeria sardinhas se na lata em que vierem, ao invés da estampa do serviço de inspeção do Ministério da Agricultura, estiver impresso um disclaimer dizendo que, ao abrir a lata, o usuário assume qualquer risco pelos efeitos daquele conteúdo no seu trato digestivo, eximindo o produtor de qualquer responsabilidade pelos efeitos causados pela ingestão?
A França e a China levam tudo isso a sério e já aprovaram ou estão debatendo leis que buscam neutralizar este desequilíbrio, privilegiando o software que pode ser auditado. O município do Recife (PE) também. A França tem fortes suspeitas de que a falta de auditabilidade está por trás de casos de espionagem industrial que vitimaram suas indústrias. Por trás disso há o sentimento de que latas de sardinhas não devam ser negociadas da mesma forma que papelotes de cocaína.
No final dos anos 70, a IBM pagou caro pela sua relutância em perceber que uma fase na evolução da informática estava chegando ao fim, com a desagregação do modelo de controle sobre arquiteturas de hardware. Como ocorreu no nível dos circuitos, é possivel que tenhamos outra mudança, desta vez no modelo de controle sobre arquiteturas de software. A internet é uma experiência com padrões abertos, sobre a qual agora se luta em torno de dogmas. Acredito que qualquer reflexão séria sobre o tema, no momento que atravessamos, deve identificar e rever a utilidade dos vários dogmas que nos fornecem referenciais semânticos, e que agora se chocam no ciberespaço, onde enxergam uns aos outros como aberrações monstruosas.
Para ilustrar como os dogmas nos movem no ciberespa&ccccedil;o, vou relatar um episódio que me ocorreu recentemente. Recebi de um jornalista um e-mail contendo um ponteiro para um artigo cujo conteúdo, ele dizia, poderia me agradar. Ele sabia do meu empenho em advogar o software livre como saída do beco escuro em que estamos metidos. Creio nisso porque não pode existir segurança sem auditabilidade, e a auditabilidade é suprimida quando o acesso à lógica dos programas é bloqueada ao usuário, como ocorre no modelo de negócio do software proprietário. Muita gente culta entra em pânico quando se fala na outra alternativa, essa coisa do software com código fonte aberto e seus hackers encapetados. Acham, muitas vezes por ouvirem dizer, que isso significa devassidão, pois qualquer um poderia alterar o que vier a ser instalado no computador.
Este pânico é próprio de marionetes. O computador só executa código em binário. Em sistemas sem compiladores, o código fonte é inócuo. E o escrutínio do código fonte de um software só revelará vulnerabilidades óbvias, normalmente eliminadas antes da sua distribuição. As mais sérias só são descobertas com seu código binário em execução, e as piores só com o software já distribuído e usado em larga escala. Portanto, as probabilidades da descoberta dessas falhas são as mesmas no software proprietário e no livre, dependendo apenas da sua complexidade. Mas em relação à correção dessas falhas, ocorre o contrário. Elas só podem ser corrigidas, via de regra, através do código fonte.
O acesso aberto ao código fonte serve para agilizar e democratizar a compreensão sobre como e por que ocorrem essas falhas, e as iniciativas para corrigi-las. Mais programadores podem corrigir, e mais pessoas estarão dispostas a trocar opiniões sobre falhas e correções, quando o código fonte do software é franqueado a quem for usá-lo. O fator de escala, neste caso, favorece a qualidade. Existem hoje cerca de 100.000 programadores contribuindo para a evolução do software livre, a maioria voluntariamente, e dentre estes os melhores. Cerca de 20 milhões de plataformas no mundo rodam hoje sistemas livres, numa taxa de crescimento que é o dobro da média, com 140 distribuidoras agregando-lhes valor e serviços, estando a terceira maior delas sediada no Brasil.
Mas esta liberdade tem um valor ainda mais precioso. O de desestimular as vulnerabilidades intencionais do software, que são engodos e trapaças escondidas na sua lógica. Daquelas que podem ter vitimado a indústria francesa. O risco deste tipo de vulnerabilidade para o usuário só pode ser controlado com o acesso aberto ao código fonte, apesar de haver uma crença dogmática e disseminada de que este controle possa ser feito com propaganda. É a crença no obscurantismo, confundindo o palco de marionetes com o palco da vida. As empresas de software proprietário negam ou ignoram as vulnerabilidades intencionais, e relutam em corrigir as não intencionais descobertas em seus produtos, a menos que a divulgação de suas conseqüências torne-se verossímil e venha a ameaçar sua imagem. E é fácil entender por quê. Como diz George W. Bush, ao repudiar o protocolo de Kioto: "It doesn’t make economic sense".
A tecnologia não muda a natureza humana. A onipotência ainda atrai abusos e a complacência segue estimulando pilantragens. Fugir da devassidão no ciberespaço pelo obscurantismo pode ser tentador, mas é inútil. O sistema que você usa poderá ser mexido sem que voce saiba, remota ou localmente, seja ele livre ou proprietário, com código fonte aberto ou fechado. O conhecimento do seu código fonte não é necessário para se escolher meios ou se escrever programas para atacá-lo. Basta que se tenha, além de intenção e paciência, conhecimento sobre como os sistemas costumam falhar, e habilidades maiores do que a sua em se proteger. A questão da segurança para o usuário está em como se proteger, num cenário onde qualquer distribuição de software é livre de garantias, já que as licenças de uso isentam o produtor de qualquer responsabilidade por falhas ou surpresas desagradáveis na sua operação.
A situação fica particularmente perversa quando ninguém, além do produtor do software, souber ou tiver o direito de saber o que realmente ocorre dentro dele. Com o software proprietário você paga para abdicar do direito de conhecer as vulnerabilidades do intermediador da sua inteligência, e de troco recebe miçangas e tutelas. Não é à toa que, na história da humanidade, nunca um empreendimento amealhou tanto dinheiro em tão pouco tempo. Tais condições estimulam no produtor a letargia para corrigir vulnerabilidades, que só darão a ele despesas e aborrecimentos adicionais, e as conseqüências logo aparecem. A Conectiva afirma que, embora apenas 20% dos servidores http no mundo usem o software proprietário IIS, enquanto 60% usam o software livre Apache, cerca de 80% das invasões via internet tem ocorrido através do IIS.
Tais conseqüências se agravam quando uma caixa-preta alcança status de padrão de mercado, pois aí tenderemos a nos esquecer dos parâmetros comparativos de segurança e de TCO. A ilusão de que quem ganha mais dinheiro vende o melhor produto é poderosa e perigosa, por ser dogmática e simplista. Não se iluda com a interface, que é só uma embalagem a empacotar a lógica, pois a lógica é o que interessa para a segurança. O software proprietário é como uma lata de sardinhas bem vistosa, mas com um disclaimer mais apropriado a um papelote de cocaína.
Hoje, o software livre, amadurecido e bem instalado, é mais robusto e saudável que seu similar proprietário, por qualquer medida que se tome. Entretanto, certos dogmas e medos não permitem que se creia nisso. Levei duas semanas para conseguir colocar algumas linhas na grande imprensa sobre o que estava realmente por trás do vírus ILoveYou. Transparência não é devassidão, e ignorância não é proteção. Mas com a UCITA, esses esclarecimentos irão provocar, além de medo para quem ouvir, perigo para quem ousar.
Por outro lado, não se pode confundir software livre com software gratuito ou pirata. Software livre significa software com liberdade, software que lhe dá o direito de conhecê-lo, usá-lo, modificá-lo, adaptá-lo, redistribuí-lo, ou até vendê-lo, como lhe aprouver. É sardinha a granel, onde a gratuidade é apenas uma das liberdades, mas onde a responsabilidade pela escolha é de quem escolhe, e onde a coorperação é essencial para a interoperabilidade e para o controle da proliferação de versões. Quem valoriza a sua liberdade precisa estar alerta, porque o obscurantismo coloca a cooperação e a pirataria no mesmo saco de pancadas. Basta observar as charges da revista Veja, e a corrida por patentes de software.
Neste cenário, o que o jornalista acharia que pudesse me agradar? O artigo apontado por ele [<http://www.salon.com/tech/feature/2001/03/21/open_source_patents/index.html>] descreve uma proposta otimista. Uma empresa oferece um negócio aos programadores que queiram proteger suas idéias contra bloqueios decorrentes de patentes. Ela publica suas idéias na web, para que ninguém possa patenteá-las, com desconto de 80% para quem desenvolve software livre. Seria uma forma indireta de combater a avalancha de patentes que ameaça criminalizar o software livre. Esta oferta tem o otimismo típico de quem só consegue enxergar benefícios na globalização. Ela contém também o tipo de isca que lançariam os interessados em ganhar dinheiro às custas do movimento do software livre. É bem possível que a proposta seja bem intencionada, mas é também igualmente possível que seu verdadeiro objetivo seja desviar o debate para um beco sem saída.
A patenteabilidade de processos puramente informacionais tem problemas muito mais graves do que a elitização do acesso ao conhecimento, e uma estratégia band-aid não irá resolver nenhum deles. Além de ser inócua, esta estratégia pode ter o efeito de diluir e enfraquecer o argumento moral que realmente interessa à verdadeira segurança do usuário e à qualidade do software. O de que a patenteabilidade desse tipo de processo é nociva à evolução social do homem.
Esse argumento, de natureza moral, se harmoniza com a filosofia do software livre, cujo dogma considera a liberdade do homem mais importante que a do capital. É o único argumento que, no longo prazo, tem chance de evitar estrangulamentos e aberrações na sua evolução, sustentando que o software tem papel social importante demais para ser considerado juridicamente apenas no aspecto econômico de sua produção. Afinal, ele é intermediador da inteligência humana. Similar de certo modo à medicina, que é intermediadora da saúde.
Esse argumento sustenta que as idéias, recursos e técnicas permeando e compondo a produção do software são processos mentais, herdados e transformados por processos cognitivos e culturais, e que por isso não devem ser considerados propriedades individuais para efeito de proteção legal, na forma como o são as invenções destinadas à transformação de substâncias materiais. Processos puramente informacionais são basicamente traduções ou metáforas, e este deve ser o argumento central para quem queira promover a segurança do usuário e a qualidade do software, ou lutar contra a asfixia que criminaliza a sua livre produção. O que para mim dá no mesmo.
Tendo dito isto, antes que me ponham também dentro daquele obscuro saco de pancadas, devo pedir-lhes para não confundirem patente com direito autoral, duas coisas bem distintas. Confudi-las é corriqueiro, mas às vezes a confusão é proposital e obscurantista. Até mesmo o atual presidente da SBC, o prof. Silvio Meira, as confundiu em uma matéria no Jornal da Tarde (9/3/00).
O direito autoral protege uma obra intelectual em sua integridade, contra distribuição ou utilização não autorizadas. Um software em código binário como o Windows, por exemplo. Já a patente é um direito de monopólio para a exploração de um processo produtivo. Como a venda eletrônica em um clique pela Amazon, por exemplo. Um processo patenteável é qualquer processo que seja útil, novo e não óbvio. É uma invenção. As leis da natrueza, ou as fórmulas matemáticas, não podem ser patenteadas. Isto está escrito na constituição americana e brasileira, respectivamente, para que se dissipem dúvidas sobre a violação de requisitos de patenteabilidade nesses casos. E quanto às idéias?
A idéia por trás de um processo puramente informacional tem um nome científico: algoritmo. Um algoritmo é uma construção lógico-matemática. Uma decisão da Suprema Corte americana (Parker vs. Flook, 1978) estabeleceu que os algoritmos não são patenteáveis. Mas alguns advogados encontraram brechas nesta decisão e torceram sua interpretação como a dizer que, embora algoritmos não o sejam, suas aplicações podem ser (Diamond vs. Diehr, 1981). E aí temos outra vez o efeito bode. É que as aplicações de algoritmos são, em geral, noutros algoritmos. Tais patentes atuam então como uma bola de neve sobre a produção de software. São freqüentemente chamadas de patentes de software, pois criminalizam o uso livre de certas técnicas e recursos de programação. Um exemplo simples é a técnica de se programar o desenho dinâmico do cursor do mouse na tela do micro usando-se a função matemática XOR [U.S. pat. 4,197,590. Cadtrack inc.].
O argumento moral contra a patenteabilidade de processos puramante informacionais precisa justificar-se convincentemente. Esta justificativa é a de que a proteção de propriedade individual a coisas intersubjetivas e diáfanas, como são tais processos, prejudica, mais do que estimula e proteja, a evolução e o bem comum do homem e da sociedade. Isto porque o ganho na exploração desse tipo de patente pelo titular de uma é potencialmente maior do que a perda que a falta da sua proteção poderia lhe causar num mercado justo. Neste caso, a lógica que justificou a introdução da lei de patentes é aviltada. Dois pesquisadores do MIT publicaram uma análise a respeito, possivelmente encontrada a partir de <http://lpf.ai.mit.edu/>, onde estão as demais referências que cito aqui.
Para entendermos esta análise, precisamos por um instante deixar os dogmas de lado e nos concentrar na mais pura e elementar aritmética. Só podemos acumular materialmente aquilo que vem do nosso meio. O que a sociedade abre mão ao legitimar proteções a monopólios de tais processos é muito mais do que abriria mão se se protegesse contra quem reclama direitos a tais monopólios. E para agravar, quem pretende proclamar, em legalês e pela primeira vez, a utilidade de um tal processo, quase sempre investe mais nisso do que na descoberta e validação do processo em si. A legitimação desses monopólios promove assim a alocação de recursos para uma burocracia improdutiva, destinada a bloquear o livre uso de processos informacionais produtivos, inflacionando os custos da pesquisa para aprimoramento do software e dos seus resultados.
A proteção oferecida por este tipo de patente serve de estímulo apenas para quem pode arcar com o custo de acumulá-las para usá-las como colaterais, em negociações de licenças efêmeras para produção de software, já que um software, de complexidade e apelo similares aos de hoje, usará possivelmente centenas de técnicas e recursos tidos como patenteáveis ou patenteados. Esta prática, chamada cross patenting, inflaciona o custo das patentes e da produção do software, além de promover sua monopolização ? prejudicando a sociedade em favor de uma classe de advogados especializados, os novos candidatos ao sacerdócio asteca.
Existem hoje empresas de software nos EUA que empregam advogados em vez programadores, e vivem de negociar com patentes, licenças de patente e ameaças de litígio ? como a Refac International. Nada disso ocorre com as patentes clássicas, as de invenções cujas causas ou efeitos transformam a matéria, para as quais os investimentos que levam à descoberta e validação de novos processos são bem maiores do que no software. São também quase sempre maiores do que o custo da patente e proporcionais ao ganho que esta irá gerar, pois as chances de alguem conseguir reclamar patente sobre algo que todo mundo já usa, como ocorre com a suposta patente dos links, seriam desprezíveis.
A lógica que justifica as patentes clássicas funciona como a das apólices de seguro, onde a seguradora é a sociedade global. Já as patentes de software são como apólices cujos prêmios são sobrevalorizados, e que funcionam como se fosse vantajoso ao dono botar fogo no seu carro segurado. Se o argumento moral não prevalecer contra este tipo de esoterismo econômico, contra este esquema de pirâmide, poderemos desembocar numa reedição da Idade Média, onde as formas eficazes de se representar conhecimento, de se comunicar publicamente, de se fazer negócio e de se engendrar novos tipos de interação social, serão periodicamente sacramentadas como legítimos objetos de monopólio, obviamente controlados pelos agentes que estão fazendo lobby a favor das leis que comentei. Assim como o foram durante a Idade Média, pela Igreja, mas dessa vez com o capital substituindo a autoridade papal, e a "mão invisível" do mercado substituindo o dogma cristão. O que nos aguarda? Ou uma nova Idade Média ou um paraíso da fartura, já que a pirâmide desse esquema é vista por um dogma como da prosperidade, e por um outro como da onipotência gananciosa.
A lógica deste jogo de apólices sociais inflacionadas é como o sonho de Ícaro. Ele está mais visível ao leigo nos processos de produção de medicamentos ou de manipulação de material genético, pois ali fica exposto o choque entre o dogma do deus-mercado e o último a resisti-lo, o dogma da sacralidade da vida. No entanto, esta lógica é mais insidiosa e perigosa quando empregada no jogo da intermediação da nossa própria inteligência. Basta ver que ele alavanca todos esses outros cujas apólices sociais também caíram em espirais inflacionárias, sem entretanto despertar, contra si e por isso, a ira dos que protestaram em Seattle, Washington, Praga ou Davos.
Na sua palestra sobre "Copyright versus Sociedade", proferida no I Fórum Internacional do Software Livre de Brasília, em 20 de março de 2001, o presidente da Free Software Foundation, Richard Stallman, compara a produção atual de software com o que poderia ter ocorrido há 300 anos na Europa na produção musical, se o mesmo esoterismo econômico lá então imperasse. Técnicas usadas na composição sinfônica, como a de se combinar certas notas para efeito tonal, a de se tocar três determinados tipos de instrumentos em sincronia, a de se montar temas melódicos em fuga ou contraponto, e outras, estariam patenteadas quando Beethoven estivesse compondo em sua mente. Ele saberia que o ato de registrar, reger, distribuir ou divulgar suas sinfonias seria crime, pois os elementos que as compunham estariam protegidos para uso exclusivo de seus "inventores", para o bem e a prosperidade da humanidade.
Relatei este episódio para mostrar dois perigos que vejo nessa estratégia de proteção à livre produção do software que poderia me agradar. A saber, o perigo da desfocagem do que realmente está em jogo com respeito à segurança do usuário e à qualidade do software, e o perigo da ilusão da sua eficácia. Acabo de descrever o primeiro, onde a comparação com Beethoven serve para nos lembrar que a indústria de software nasceu e floresceu sem necessidade de qualquer proteção de patentes. Desde 1945, quando Von Neumann escreveu o primeiro programa de computador armazenável em memória para ordenar listas de registros, até a primeira patente de software concedida no início dos anos 80, quase dois terços da história da informática atual se passaram.
Resta-nos então identificar o verdadeiro motivo da corrida a esse tipo de patente, para entenderemos melhor os seus efeitos na segurança da informática. Para isso, vou agora descrever o segundo perigo. Vou comentar os motivos que me levam a ver aquela estratégia como uma quimera, uma ingênua esperança nutrida por dogmas que são ali inúteis. Esses motivos são quatro.
Primeiro:
Na legislação em vigor os pedidos de patente tramitam em sigilo, e o tempo de tramitação é considerado para a retroação das patentes concedidas. Mesmo que um programador publique a descrição de um processo puramente informacional que julga ser novo, útil e não óbvio, uma outra descrição que tenha sido submetida para patente antes desta publicação e aceita depois, poderá ter sua equivalência com a dele reclamada por advogados especialistas. Se a equivalência for declarada pela Justiça, todo o invesitmento que ele possa ter feito em produção, depuração e distribuição de um programa que use o tal processo estaria perdido, e mais ainda, pelo efeito retroativo daquela patente, mesmo havendo ele tido o cuidado de dar domínio público ao que, no melhor e mais sadio dos seus juízos e esforços, considerou ser uma invenção orginal sua. O espírito de cooperação é punido e a avareza recompensada.
Segundo:
As abelhas matam. Não se apenas uma picar, mas se toda a colméia atacar. Vamos então considerar os dados fornecidos por Stallman na sua palestra em Brasília. Suponha que eu deseje desenvolver um software cuja funcionalidade não encontro em nenhum outro disponível, ou que me seja vantajoso pagar alguém para fazê-lo. E que eu queira evitar, ao fazê-lo, conflitos com direitos de patente alheios. Terei então que saber se minhas idéias de como implementá-lo estarão cobertas por alguma patente de software. Acontece que existem hoje, em vigor só nos EUA, cerca de 100.000 patentes que impactam a produção de software. E pior, os programadores não entendem nada de patentes, já que elas estão escritas em linguagem cifrada, compreensível apenas para advogados especialistas, muito embora estes sejam pagos para discordarem uns dos outros sobre seus significados, após escrevê-las.
Evitar patentes de software é como atravessar um campo minado, como compara Stallman. Se começo a caminhar hoje, existirão pelo menos cem mil bombas enterradas. Posso evitar uma, duas, três, mas há grandes chances que alguma exploda sob meus pés se eu desejar fazer um programa minimamente interessante, mesmo que contrate um advogado para me ajudar a evitá-las. E mesmo que fosse absolutamente competente, nem ele nem ninguém poderá me livrar das patentes pendentes. Com um ano e meio em média para a concessão, ao ritmo médio de 5.000 concessões por ano, as minas que só estarão armadas depois que eu pisar, mas que mesmo assim poderão me arrebentar, serão em torno de 7.500, só nos EUA. Patentes de processos que são óbvios para os programadores, e que por isso não deveriam existir, mas que não são óbvios para advogados e burocratas nelas interessados, e que por isso existem, são as mais perigosas. Elas e eles abundam. Qualquer hora aparece alguém com a patente da venda em zero cliques, onde basta o internauta entrar na página da loja para receber a fatura. Sem falar nas patentes duplicadas, descrevendo o mesmo processo em distintos sotaques do legalês.
Terceiro:
Suponha então que eu pague um advogado para me aconselhar, avaliando com quais probabilidades meu programa estaria infringindo quais patentes. Em algumas situações, eu não saberei como fazer algo que precisa ser feito sem o risco de litígio, como por exemplo, na compactação de dados. Suponha que eu decida correr riscos distribuindo meu programa, talvez publicando minha técnica sobre como fazer algo, para proteger o direito de qualquer um poder fazer esse algo assim.
A publicação irá gerar riscos adicionais, pois advogados que ganham com isso estarão consultando periodicamente as fontes de bloqueios, infrações e inspirações a patentes, se forem competentes e quiserem serviço. E muitos são e querem. Alguém poderá até patentear para si a minha idéia, convencendo burocratas de que a técnica por ele proposta é diferente do que já foi publicado, e depois me processar por tê-la usado, como já tem ocorrido [MIT e pat 4,555,775 da AT&T]. Além disso, se o software for livre, o investimento nele não irá gerar recursos para bancar os riscos decorrentes. O software livre é particularmente vulnerável à corrida por patentes, já que sua produção não se baseia em fluxos de caixa e sim em necessidades sociais e cooperação, o que lhe dará tempo para competir, amadurecer e tornar-se robusto, se for mesmo bom e se seu ecossistema não for destruído.
Quarto:
Suponha agora o melhor dos mundos. Meu software se tornou popular, levantei recursos para bancar o litígio e ganhei a causa. Mas ao invés de publicar, eu tenha submetido minha técnica a patente, para licenciá-la a quem e como eu quiser, até mesmo de graça ao movimento do software livre. Então, com a visibilidade do caso, outras empresas irão me procurar dizendo. "Sua patente foi garantida na Justiça, mas das nossas 10.000 patentes (a IBM tem mais do que isto), seu produto provavelmente infringe estas 37 aqui. Por que você não negocia conosco, cedendo-nos ou vendendo-nos sua patente ou os direitos ao seu produto, para evitar litígios? Lembre-se de quanto ganham nossos advogados". Como produtor independente, armado da minha primeira patente, estarei em situação desvantajosa. E se fizer o acordo possível, terei um competidor em condições de me liquidar sem muito esforço.
As patentes de software se trasformam assim em moeda podre, circulando entre as grandes empresas de software proprietário para manterem vantagens competitivas sobre as pequenas, as emergentes, e as que atuam noutro modelo de negócio. Ao invés de inovarem através da criatividade saudável, podem então se concentrar na ação de combater esses outros modelos e inventar necessidades artificiais para o mercado de software que maximizem seus fluxos de caixa. Podem oferecer ao mundo os resultados daquilo que é obscuramente chamado, em uma recente campanha publicitária da maior delas, de freedom to innovate.
Elas querem a liberdade para continuar inovando, de preferência em regime monopolista, criando penduricalhos e badulaques que ninguém sabe porque estão ali, justificando mais uma versão de produto ou mais um "produto integrado", tornando tudo gradativamente mais complexo (você precisa de mais treinamento), lento (você precisa de novo hardware) e propenso a falhas, a configurações inseguras, a incompatibilidades desenhadas para forçar novas vendas etc. (você precisa de patches, upgrades, certificações, suporte…). Todos já sabem o que vai acontecer quando receberem um arquivo ponto doc numa versão posterior à sua. E mesmo assim a turba aceita e paga, pois nos é dito: "é isso o que o mercado pede". Também nos é dito que o software livre tornou-se uma ameaça à criatividade. Se esse mosaico nos parece familiar, falta completá-lo com duas peças.
Vamos lembrar como nasceu e evoluiu o software. O primeiro modelo de negócio do software foi cooperativo, artesanal e livre, entre os anos 40 e 60. Só com a barateamento do hardware e queda nas margens de lucro é que a indústria resolveu empacotar licenças de uso de software proprietário nos contratos de hardware e de suporte, bloqueando acesso aos seus fontes, para manterem seus fluxos de caixa. Isto funcionou dos anos 60 aos 80, até o downsizing. A partir daí o negócio do software proprietário teve que se apoiar no controle da sua arquitetura, já que o controle da arquitetura do hardware estava sendo diluído por um processo natural de padronização aberta, que na engenharia faz evoluir arquiteturas em direção à eficiência. É só aí então que surge a pressão irresistível para que os processos puramente informacionais fossem legitimados como objetos de proteção monopolista, bloqueando o livre curso evolutivo da arquitetura do software. Se a justificativa for a manutenção de empregos num modelo de negócio que quer se perpetuar, então o crime organizado também deveria merecer este tipo de liberdade para inovar.
Falta, finalmente, alguém dizer qual é a criatividade ameaçada pelo sofware livre. Só pode ser então a criatividade para se perpetuar um modelo de negócio que foi eficaz nos últimos vinte anos, mas que mostra sinais de instabilidade e fadiga, e cuja sobrevida faz mal à liberdade e ao bolso humanos. Estamos sendo tratados pelo mercado como sapos, que, por serem batráquios, podem ser cozinhados vivos pela lenta e gradual elevação da temperatura da água. Quando a pirâmide da prosperidade ou da ganância se fechar no seu cume, a água entrará em ebulição. Será que ferveremos no gozo coletivo da fartura, ou será que esta uma pirâmide é como a dos astecas?
(*) Professor do Departamento de Ciência da Computaçào da Universidade de Brasília, <http://www.cic.unb.br/docentes/pedro/segdadtop.htm>. MetaCertificate Group member <http://www.mcg.org.br>
e-Not?cias ? próximo texto
