• Nenhum resultado encontrado

Arquitetura e Lei: Força

No documento II “Pirataria” 15 (páginas 150-164)

Uma vez que um vídeo fosse disponibilizado ao mercado, a “doutrina da primeira venda” tornava o vendedor livre para usar o vídeo como desejasse, inclusive para exibir partes dele como uma forma de gerar vendas do filme como um todo. Mas com a Internet, tornou possível à Disney centralizar o controle sobre o acesso a esse conteúdo. Como cada uso da Internet gera cópias do conteúdo, o uso da Internet torna-se sujeita ao controle do detentor do copyright. A tecnologia expande o escopo do controle efetivo, já que a tecnologia cria uma cópia do material a cada transação.

Sem sombra de dúvidas, um potencial não é ainda um abuso, e portanto um potencial de controle não é um abuso de controle. A Saraiva tem o di- reito de impedir você de tocar um livro em sua loja; a lei de propriedade lhes dá tal direito. Mas na prática o mercado protege o consumidor de tal abuso. Se a Saraiva impedir a leitura para escolha de um livro, então os consumidores procurarão outras livrarias. A competição protege o consum- idor de tais extremismos. E ela deveria muito bem (meu argumento sequer chega a questionar isso) proteger qualquer perigo semelhante quando ele vem docopyright. De fato, editores, ao exercerem os direitos que os autores lhes deram6, podem tentar restringir o número de vezes você leu um livro, ou ten- tar o impedir de compartilhar o livro com outras pessoas. Em um mercado competitivo como o de livros, os perigos de tal coisa acontecer são muito pequenos.

Novamente, meu objetivo até aqui é simplesmente o de mapear as mu- danças que essa mudança de arquitetura provocou. Permitir que a tecnologia amplie o controle exercido pelos detentores docopyright significa que o con- trole do copyright não é mais definido por políticas equilibradas. O controle do copyright agora é simplesmente aquele que os donos privados decidirem exercer. Em alguns contextos, ao menos, esse fato é inofensivo. Mas em outros contextos, ele é uma receita para o desastre.

na tradição da lei e consciente dos equilíbrios que tal trazia consigo, era quem dizia se e como você teria sua liberdade restrita pela lei.

Há uma história famosa envolvendo os Irmãos Marx e a Warner Brothers.

Os Marx queriam criar uma paródia de Casablanca. A Warner Brothers objetou, escrevendo uma carta ríspida a eles, avisando-os que haveriam sérios problemas legais se eles seguissem adiante com seu plano. [134]

Isso levou os irmãos Marx a responder na mesma moeda. Eles avisa- ram à Warner Brothers que os irmãos Marx “eram irmãos muito antes de vocês”. [135] Os irmãos Marx portanto detiam o uso da palavra brothers7, e se a Warner Brothers tentasse insistir no controle de Casablanca, então os irmãos Marx iriam insistir no controle de irmãos.

Uma ameaça absurda e vazia, claro, já que a Warner Brothers, assim como os irmãos Marx, sabiam que nenhuma corte iria impor uma queixa tão boba. Esse extremismo era irrelevante para as liberdades legítimas que qualquer um (incluindo a Warner Brothers) possuíam.

Na Internet, porém, não há checagem de regras tolas, porque na Internet, cada vez mais as regras são impostas não por pessoas, mas sim por máquinas.

Cada vez mais as regras da lei do copyright, como interpretadas pelo deten- tor do copyright, são embutidas na tecnologia que distribui o conteúdo sob copyright. É o código, ao invés das leis, quem manda. E o problema com regulamentações por código é que, diferentemente da lei, o código não tem vergonha ou senso de humor. O código não poderia entender a piadas dos irmãos Marx. As conseqüências disso não seriam nada engraçadas.

Considere a vida do meu Adobe eBook Reader.

Umebook é um livro distribuído em meio digital. UmeBook da Adobe não é um livro publicado pela Adobe; a Adobe simplesmente produz o software que os distribuidores usam para distribuir os ebooks. Ela fornece a tecnologia, e o distribuidor distribui o conteúdo usando a tecnologia.

A Figura 10.11, Página 134 mostra uma imagem de uma versão antiga de meuAdobe eBook Reader.

Como você pode ver, eu tenho uma pequena coleção de ebooks na minha biblioteca de ebooks. Alguns desses livros reproduzem conteúdo que está no domínio público: Middlemarch, por exemplo, está no domínio público.

Alguns reproduzem conteúdo que não está no domínio público: meu livro The Future of Ideas ainda não está no domínio público.

Consideremos primeiro Middlemarch. Se você clicar na minha cópia do ebook deMiddlemarch, você irá ver uma capa bonita e então um botão abaixo de tudo chamado Permissões.

Se você clicar no botão Permissões, você irá ver uma lista das permis-

7NT:em inglês,irmãos

Figura 10.11: Janela do Adobe eBook Reader

sões que o editor garante ao seu livro, como a apresentada na Figura 10.12, Página 135.

De acordo com meueBook Reader, eu tenho a permissão de copiar para a Área de Transferência do meu computador dez seleções de texto a cada dez dias. (Até agora, eu não copiei nenhum texto para a Área de Transferência.) Eu também tenho a permissão para imprimir dez páginas do livro a cada dez dias. Por último, posso usar o botão Read Aloud para ouvir Middlemarch sendo lido pelo meu computador8.

Agora vejamos o caso do ebook de outro trabalho no domínio público (inclusive sua tradução): APolíticade Aristóteles, mostrado na Figura 10.13, Página 135.

De acordo com essas permissões, apresentadas na Figura 10.14, Página 136, nenhuma impressão ou cópia é permitida. Mas felizmente, você pode usar o

8NT:Read Aloud, em inglês, significa “ler em voz alta”

Figura 10.12: Permissões para o livro Middlemarch

Figura 10.13: A Política de Aristóteles

botão Read Aloud para ouvir o livro.

Figura 10.14: Permissões para o livro A Política de Aristóteles

Finalmente (e de forma mais embaraçosa), veremos as permissões do ebook original do meu livro mais recente, The Future of Ideas, mostradas na Figura 10.15, Página 136:

Figura 10.15: Permissões para o livro The Future of Ideas

Sem cópia, sem impressão, e não se atreva a tentar escutar esse livro!

Agora, o Adobe eBook Reader chama a isso de “permissões” — como se o editor tivesse o poder de controlar como essa obra é usada. Para obras sob copyright, o detentor do copyright possui realmente tais poderes — até os limites da lei de copyright. Mas para obras que não estejam sob copyright, tal poder de copyright simplesmente não existe.9 Quando meu ebook de

9Em princípio, um contrato pode impor uma exigência a mim. Eu posso, por exemplo,

Middlemarch me diz que tenho a permissão para copiar apenas dez trechos de texto na memória a cada dez dias, o que ele realmente quer dizer é que o eBook Reader permitiu ao distribuidor controlar como eu uso o livro no meu computador, o que está muito além do controle que a lei daria a ele.

O controle vem ao invés disso do código — da tecnologia dentro da qual o ebook “vive”. Embora o ebook diga que tais permissões existem, elas não são o tipo de “permissões” com as quais a maioria de nós conseguimos lidar.

Quando um adolescente recebe “permissão” para sair de cada até a meia- noite, ele sabe (a não ser que ele seja Cinderela) que ele pode ficar fora até às duas da manhã, mas que ele irá sofrer um castigo se for pego. Mas quando oAdobe eBook Reader diz que eu tenho direito de fazer dez cópias de texto na memória do computador, isso quer dizer que após eu fazer essas dez cópias, o computador não irá fazer mais nenhuma. O mesmo com a restrição a impressão: após dez páginas, o eBook Reader não irá imprimir nenhuma mais. E o mesmo vale com a estúpida restrição que nos diz que não podemos usar o botãoRead Aloud para ler o meu livro — não é que a companhia o irá processar se você fizer isso; de fato, se você pressionar o botão Read Aloud com o meu livro, a máquina simplesmente não vai o ler!

Esses são controles, não permissões. Imagine um mundo aonde os ir- mãos Marx vendessem software de processamento de texto que, quando você tentasse digitar “Warner Brothers”, ele apagasse “Brothers” da sentença.

Esse é o futuro da lei do copyright: nem tanto da lei, mas sim do código docopyright. Os controles sobre o acesso ao conteúdo não serão controles ra- tificados pelas cortes; os controles sobre o acesso ao conteúdo serão controles codificados por programadores. E embora os controles que estão construídos na lei sejam sempre checados por um juiz, os controles que estão construídos na tecnologia não são checados.

Quão significativo é isso? Não é sempre possível contornar os controles embutidos na tecnologia? Software costumava ser vendido com tecnologias que limitavam as habilidades dos usuários de copiarem o software, mas tais proteções eram simples de serem contornadas. Porque não poderíamos con- tornar tais proteções também?

Essa é apenas a ponta do iceberg. Vamos voltar ao Adobe eBook Reader.

No começo da vida doAdobe eBook Reader, a Adobe acabou se envolvendo em um pesadelo de relações públicas. Entre os livros que você poderia baixar de graça do site da Adobe estava uma cópia deAlice no País das Maravilhas.

comprar um livro de você que inclua um contrato que diga que eu posso o ler apenas três vezes, ou que eu prometo ler ele apenas três vezes. Mas essa obrigação (e os limites para criar tais obrigações) viriam do contrato, não da lei docopyright, e as obrigações do con- trato não precisam serem necessariamente passadas a alguém que adquira posteriormente o livro.

Esse livro maravilho está no domínio público. Mas quando você apertava o botão Permissões para esse livro, você obtinha no relatório mostrado na Figura 138, Página 138.

Figura 10.16: Permissões para o livro Alice no País das Maravilhas

Aqui temos um livro infantil de domínio público que não pode ser copiado, emprestado, dado, e, como as “permissões” indicam, sequer “lido em voz alta”!

O pesadelo de relações públicas apareceu na última permissão. Porque o texto não queria dizer que você não poderia usar o botão Read Aloud; está escrito que você não tinha a permissão para ler o livro em voz alta. Isso levou várias pessoas a pensarem que a Adobe estava restringindo o direito dos pais, por exemplo, lerem o livro para suas crianças, o que parecia, para dizer o mínimo, absurdo.

A Adobe respondeu rapidamente que parecia absurdo imaginar que ela estaria tentando restringir o direito de ler em voz alta. Obviamente, ela estava apenas restringindo a habilidade de usar o botão Read Aloud para que o computador lesse o livro em voz alta. Mas a questão que a Adobe nunca respondeu foi a seguinte: então a Adobe aceitaria que um consumidor fosse livre para usar programas que violassem as restrições embutidas no eBook Reader? Se alguma companhia (chame-a Elcomsoft) desenvolvesse um programa que desabilitasse a proteção tecnológica embutida em um eBook da Adobe de forma que uma pessoa cega, por exemplo, pudesse fazer com que o computador lesse o livro em voz alta, a Adobe iria considerar tal uso de

um eBook Reader como justo? A Adobe não respondeu porque a resposta, por mais absurda que seja, é não.

A idéia aqui não é culpar a Adobe. De fato, a Adobe está entre as empresas mais inovadoras que estão procurando desenvolver estratégias que equilibrem o acesso livre ao conteúdo com incentivos às companhias para inovação. Mas a tecnologia da Adobe permite controle, e a Adobe tem um incentivo para defender tal controle. Tal incentivo é compreensível, embora o que ele cria é freqüentemente loucura.

Para entender a idéia desse contexto particularmente absurdo, considere uma das minhas histórias favoritas sobre tal assunto.

Considere o cão robô criado pela Sony chamado “Aibo”. O Aibo aprende truques, afaga e segue você por aí. Ele come apenas eletricidade e não faz bagunça, ao menos na sua casa.

O Aibo é caro e popular. Fãs de todo o mundo criaram clubes para trocar histórias. Um fã em particular criou um site na Web para permitir que informações sobre o Aibo fossem compartilhadas. Esse fã criou o aibopet.com (e também o aibohack.com, que na prática levam ao mesmo site), e nesse site forneceu informações sobre como ensinar um Aibo a fazer outros truques além dos que a Sony ensinou originalmente.

“Ensinar” aqui possui um significado todo especial. Cães robôs como o Aibo são apenas computadores bonitinhos. Você pode ensinar a um com- putador como fazer alguma coisa programando-o de maneira diferente. Então dizer que o aibopet.com estava fornecendo informação sobre como ensinar ao cão novos truques é o mesmo que dizer que a aibopet.com estava fornecendo informações para os usuários do cão Aibo sobre como hackearem seu “cão- putador” para fazer novos truques (por isso do aibohack.com).

Se você não é ou não conhece muitos programadores, a palavra hack possui uma conotação particularmente não-amigável. Não-programadores cortam gramas ou raízes10. Não-programadores em filmes de terror fazem coisas piores. Mas para programadores, ou codificadores, como eu os chamo, hack11 é uma palavra muito mais positiva. Um hack é apenas código que permite a um programa fazer algo que ele não podia ou não era permitido originalmente fazer. Se você compra uma nova impressora para um com- putador velho, você pode acabar descobrindo que o seu velho computador não consegue usar a impressora por não ter “drivers” 12compatíveis com ele.

10NT:um dos significados dehack é cortar alguma coisa

11NT:mais a diante, como fiz anteriormente, estarei usando a palavrahack como verbo aportuguesado para dizer sobre as ações de umhacker, no sentido original da palavra, o de uma pessoa que procura explorar todas as possibilidades do sistema e utilizar todos os seus recursos, inclusive mediante programação do sistema

12NT: drivers são programas que fazem a ligação entre um software e um periférico

Se você descobrir isso, você poderá então depois ficar contente de descobrir um hack na Internet de alguém que escreveu um “driver” que permitem que o seu computador interaja com a impressora que você comprou.

Algunshacks são fáceis de serem criados. Outros são incrivelmente difíceis de serem criados. Os hackers como uma comunidade adoram serem desafiados por si próprios e por outros com tarefas cada vez mais difíceis. Existe um certo respeito por aqueles com o talento para hackear bem, e um respeito ainda mais por aqueles que conseguem hackear de forma eticamente correta.

O fã do Aibo estava mostrando um pouco de ambos quando ele hackeou ou programa e ofereceu ao mundo alguns códigos que permitiriam ao Aibo dançar jazz. O cão não era programado originalmente para dançar jazz.

Esse foi um achado interessante que transformou o cão em uma criatura mais talentosa do que a Sony havia a construído.

Eu contei essa história nos mais variados contextos, dentro e fora dos Estados Unidos. Uma vez fui questionado por um membro estarrecido da platéia se era proibido que um cachorro dançasse jazz nos Estados Unidos?

Nós perdoamos essas histórias como vindas de locais longínquos que ainda não apareceram para a maior parte do mundo. Portanto deixe-me esclarecer antes de continuarmos: não é crime em lugar nenhum (de forma alguma) dançar jazz. Nem é um crime ensinar um cão a dançar jazz. Nem deveria ser um crime (embora não tenhamos muito disso por aqui) ensinar seu cão robô a dançar jazz. Dançar jazz é uma atividade completamente legal. As pessoas imaginariam o que o dono do aibopet.com imaginou: qual é o problema que posso ter por ensinar um cão robô a dançar?

Vamos por o cachorro na casinha um pouco, e vamos transformar isso em um circo de cavalinhos — não literalmente em um circo de cavalinhos, mas de fato em um artigo que um acadêmico da Princeton chamado Ed Felten preparou para uma conferência. Esse acadêmico da Princeton é muito conhecido e respeitado. Ele foi contratado pelo governo no caso da Microsoft para testar as queixas da Microsoft sobre o que poderia ou não ser feito com seus códigos. Naquele caso, ele demonstrou tanto o seu brilhantismo quanto a sua frieza. Sob grande pressão dos advogados da Microsoft, Ed Felten manteve-se centrado. Ele não pode ser ameaçado para permanecer quieto sobre as coisas que ele sabia bem.

Mas a bravura de Felten foi realmente testada em Abril de 2001. [136]

Ele e um grupo de colegas estavam trabalhando em um artigo para ser sub- metido a uma conferência sobre as fraquezas em um sistema de criptografia que estava sendo desenvolvido pela Iniciativa de Música Digital Segura (Se-

qualquer, como uma impressora ou scanner, permitindo que o software — e todos os software baseados nele — acessem seus recursos

cure Digital Music Initiative — SDMI) como uma técnica para controlar a distribuição da música.

A coalizão da SDMI tinha como objetivo uma tecnologia permitir que os donos de conteúdo exercerem um controle mais efetivo sobre seus conteúdos do que a Internet, como originalmente projetada, oferecia-lhes. Usando en- criptação, a SDMI esperava desenvolver um padrão que permitisse ao dono de conteúdo dizer “essa música não pode ser copiada”, e ter o respeito do com- putador quanto a esse comando. Essa tecnologia seria parte de um “sistema confiável” de controle que iria dar aos donos de conteúdo mais confiança no sistema da Internet.

Quando a SDMI acreditou que estava próxima de um padrão, ela criou uma competição. Ela forneceu um trecho de conteúdo encriptado pelo sis- tema da SDMI ao competidores, que tentavam o violar e, se conseguissem, relatarem os problemas ao consórcio.

Felten e sua equipe venceu o sistema de criptografia rapidamente. Ele e sua equipe viram a fraqueza desses sistema como um problema geral de um tipo de encriptação: muitos sistemas sofriam do mesmo problema, e Felten e sua equipe acreditaram que seria interessante mostrar isso para aqueles que estudam a criptografia.

Vamos rever tudo o que Felten fez. Novamente, vivemos nos Estados Unidos. Temos um princípio de liberdade de expressão não apenas porque ele está na lei, mas também porque é uma idéia realmente boa. Uma tradição de proteção à liberdade de expressão tem grandes chances de encorajar uma grande gama de pensamento crítico. Esse pensamento crítico tem grandes chances, por sua vez, de melhorar os sistemas, idéias, e pessoas criticadas.

O que Felten e seus colegas fizeram foi publicar um artigo descrevendo as fraquezas de uma tecnologia. Eles não estavam distribuído música de graça, e nem construindo e disponibilizando tecnologia que o fizesse. O artigo era um estudo acadêmico, ininteligível para a maioria das pessoas. Mas ele mostrava de maneira clara a fraqueza no sistema da SDMI, e porque a SDMI não seria, da maneira como estava construída naquele momento, ser bem-sucedida.

O que liga os dois casos, o do aibopet.com e o de Felten, são as cartas que eles receberam. O aibopet.com recebeu uma carta da Sony sobre o hack disponibilizado. Embora seja legal ensinar um cachorro a dançar jazz, a Sony escreveu:

“Seu site contêm informações que fornecem os meios para con- tornarem o protocolo de proteção contra cópias do software do AIBO, o que constitui uma violação das leis que impedem tal contorno descritas na Digital Millennium Copyright Act (Lei de Copyright do Milênio Digital, DMCA)”

E embora escrever um artigo acadêmico descrevendo as fraquezas de um sistema de encriptação de dados deveria ser algo perfeitamente legal também, Felten recebeu uma carta de um advogado da RIAA que dizia:

“A disponibilização de qualquer informação obtida com a participação no Desafio Público está fora do escopo das ativi- dades permitidas pelo Acordo e tornam você e sua equipe de pesquisa alvo de ações segundo o Digital Millennium Copyright Act (‘DMCA’)”

Em ambos os casos, essa lei estranha e Orwelliana foi invocada para con- trolar a difusão da informação. A Digital Millennium Copyright Acttornou a divulgação de tais informações um crime.

A DMCA foi passada como uma resposta ao principal medo dos deten- tores de copyright quanto ao ciberespaço. Esse medo era de que o controle pelocopyright tivesse se tornado efetivamente morto; a resposta foi encontrar tecnologias que repusessem essa “perda”. Essas novas tecnologias seriam tec- nologias protetoras do copyright — tecnologias para controlar a replicação e distribuição de material sob copyright. Elas foram desenvolvidas como códi- gos para modificarem o código original da Internet e com isso restabelecer alguma proteção aos detentores do copyright.

A DMCA foi uma lei criada para salvaguardar as proteções de tais códigos desenvolvidos para protegerem materiais sob copyright. Ela era, podemos dizer, umcódigo legal que visava apoiarcódigos de computador, eles próprios criados para apoiarem ocódigo legal do copyright.

Mas a DMCA não foi desenvolvida meramente para proteger os trabalhos sob copyright dentro dos limites que a lei de copyright os protegia. Essa proteção, de fato, não iria terminar nos limites criados pela lei docopyright.

A DMCA regulamentava os dispositivos que eram criados com medidas de contorno de sistemas de proteção decopyright, os proibindo, sem se importar se o uso de material sob copyright que era possibilitado por tais contornos eram realmente violações à lei de copyright.

O aibopet.com e Felten fizeram exatamente isso. O hack do Aibo con- tornava o sistema de proteção de copyright com o objetivo de permitir que o cachorro dançasse jazz. Essa possibilidade envolvia o uso de material sob copyright, claro. Mas como o site aibopet.com era não-comercial, e o uso não permitia outras violações decopyright, não havia dúvidas de que o hack disponibilizado pela aibopet.com era uso justo do material sob copyright da Sony. Mas uso justo não é uma defesa aplicável à DMCA. A questão não é se o uso do material sobcopyright era uma violação do copyright. A questão é que um sistema de proteção de copyright foi contornado.

No documento II “Pirataria” 15 (páginas 150-164)