Nossa, faz tempo que não escrevo por aqui! Depois que virei fã de microblogging, minhas expressões mais longas acabam indo todas pra Revista Espírito Livre, com ocasionais comentários em blogs ou sites de terceiros.
Nesse caso, escrevi um comentário sobre questões de direito autoral envolvendo Apache OpenOffice e LibreOffice. Não sei se o sistema de lá não está propriamente configurado para mostrar comentários ou se os moderadores estão ocupados demais, mas por enquanto o comentário não apareceu. Então, pra não correr o risco de esquecer, vou postar aqui uma cópia do que escrevi em resposta ao artigo de lá.
É meu primeiro envolvimento com essa discussão, e estou notando muita tensão no debate AOOxTDF também a nível nacional, mas é importante que essa tensão não contamine questões jurídicas que podem até colocar o projeto e a Fundação Apache em risco. Não escondo que tenho antipatia pelo jeito como IBM e Oracle tomaram as contribuições sob licença copyleft de uma baita comunidade e cooptaram a Fundação Apache para dar legitimidade ao “golpe de estado”, mas isso é conversa pra depois.
Quero antes falar sobre direito autoral, um assunto complicado pacas. Não interessa muito se digitar dois caracteres de comentário constitui ou não uma cópia, porque cópia não é bem o critério do direito autoral. A questão importante é se um juiz ou um júri vai considerar que uma obra é derivativa de outra, a ponto de acionar os requisitos que a GNU GPL e outras licenças copyleft estabelecem para obras derivativas. Isso é uma questão complicadíssima, que poucos advogados se atreveriam a responder categoricamente, porque no fim das contas vai depender de um tribunal. Sem maldade alguma de minha parte, um advogado responsável questionado sobre uma questão como essas provavelmente vai dizer “depende”
A Fundação Apache esclarece:
Even if you change every single line of the Apache code you're
using, the result is still based on the Foundation's licensed code
O mecanismo de derivação que faz com que se exijam permissões dos titulares do original, e portanto sujeição às suas condições, é similar para qualquer obra autoral, livre ou privativa. De fato, mesmo que você remova cada linha do programa original e adicione outras, ainda assim terá uma obra derivada, conforme a lei, a doutrina e a jurisprudência do direito autoral.
Até mesmo olhar para um programa (código fonte), memorizar como ele funciona, e depois escrever algo parecido com o que você memorizou dá boa margem para que o programa seja considerado obra derivada. É por isso mesmo que a IBM (a mesma que conspirou com a Oracle para tirar o copyleft do código contribuído pela comunidade) e a Apple proíbem seus funcionários de sequer olharem para código fonte de certos programas, como o GCC, se pretende que eles trabalhem em outros compiladores que não estejam sob a mesma licença. Tudo isso porque desenvolvedores (como eu) não são advogados para avaliar o risco de que um tribunal venha a considerar o resultado uma derivação; para ficar do lado seguro ao invés de voltar para o “depende” default
Há quem creia que dá pra resolver caso a caso, bastando consultar o autor de um patch e pedindo-lhe permissões adicionais para incluir o código sob licença mais permissiva. Isso pode ser um engano: o patch pode muito bem ser considerado uma obra derivativa do original copyleft, caso em que o (portanto co)autor do patch, por força das condições estabelecidas na licença copyleft, só pode distribuir e licenciar sob os mesmos termos copyleft.
A forma mais simples de evitar eventuais futuros problemas judiciais para a Fundação Apache e seus contribuidores é, lamentavelmente, que os contribuidores do AOO nem olhem para a base de código que evoluiu sob copyleft. A forma mais complicada é seguir os procedimentos de engenharia reversa e redesenvolvimento clean-room, em que uma pessoa estuda o código e documenta o que ele faz, de formas cuidadosas especificamente projetadas para evitar que essa documentação seja considerada uma obra derivada, para que em seguida outra pessoa, usando somente essa documentação, implemente o código na outra base. É burocrático, complicado e, para pessoas não treinadas nesse tipo de técnica clean-room, ainda juridicamente arriscado.
Essa é a lamentável consequência da divisão da comunidade que IBM e Oracle engenhosa e ardilosamente introduziram ao alterar as regras de licenciamento do que a comunidade original havia aceito, aproveitando-se da mecânica de operação da Fundação Apache. Nessa altura, o melhor caminho a seguir é o proposto na thread: consultar o restante da comunidade internacional do AOO e, se o assunto não houver sido fechado, ao departamento jurídico da Fundação Apache, sobre medidas que têm sido e devem ser tomadas para evitar que se descubra, daqui a meses ou anos, que a base de código mantida pela Fundação Apache não pode mais ser distribuída sob os termos da Licença Apache, mas sim sob copyleft.
Hmm.. (-: Pensando bem, talvez seja melhor não falar nada e ir em frente até que isso aconteça, pra dar uma lição na IBM e na Oracle. Vai sujar o nome da Fundação Apache, o que seria lamentável, mas quem sabe aí ela estabeleça regras para evitar ser usada novamente da forma que foi.
Agora, voltando à minha antipatia, por mais que possa haver gente de má índole e supostos interesses puramente comerciais ligada à TDF (não duvido, mas vai saber se não estão sendo usados pela IBM e Oracle pra enfraquecer a TDF e fortalecer o AOO permissivo que elas queriam? /conspiracytheory), não entendo como é que alguém pode usar a existência dessas pessoas como razão para pular para o lado de duas empresas que deixaram bem claros seus interesses e sua índole ao (se não bem antes de) aniquilarem o copyleft que protegia de abusos os usuários do OpenOffice.org original e do saudoso BROffice. Vai entender!
/me resmunga alguma coisa sobre frigideira e fogo, e gesticula convidando as pessoas de boa índole a contribuir para o lado copyleft da força, mesmo que isso exija mais um fork. Pelo menos seria um fork com possibilidade de cooperação de duas mãos, ao invés de ficar do lado errado (porque não aceita contribuições do outro) da lamentável mão única que IBM e Oracle criaram.
Até blogo...