De 18 a 25 de março de 2007, o professor e uma aluna mantiveram por e-mail o seguinte diálogo, cuja publicação a aluna consentiu sob anonimato:

            Pedro Rezende: Pelo que entendo, a lei de software Brasileira não anula esses direitos morais mas apenas restringe as possíveis causas, por parte do autor do software, pelas quais esses direitos poderiam amparar retratações unilaterais de contratos de licença de uso.

            PR: A GPL difere juridicamente de EULAs proprietárias, dentre outras razões, porque EULAs proprietárias cedem apenas direito (restrito) de uso, ao passo que a GPL cede direito irrestrito de cópia e de alteração, através de acesso ao código fonte, este com vistas a elaboração de trabalho derivativo, e também o direito de redistribuir cópias, inclusive de/com tais alterações, este restrito às condições dispostas nas sessões 2 a 7 (GPLv2).

            O direito (irrestrito) de uso de software sob GPL não é, conforme disposto na seção 0 da mesma, objeto da licença (como o é nas EULAs proprietárias) mas decorre indiretamente dos direitos cedidos pela licença. Por esta razão deve-se entender, especialmente numa jurisprudência que vê como contrato qualquer tipo de acordo (como a Brasileira), a GPL antes como um contrato social para desenvolvimento colaborativo -- portanto, como um contrato coletivo benéfico --, do que como um contrato de licença de uso, ao contrário das EULAs proprietárias (que ademais não poderiam ser outra coisa).

            Doutra feita, não sei a qual item da GPL voce poderia estar se referindo ao dizer que, sob ela, "quaisquer danos provocados pelas alterações de terceiros não é de responsabilidade do autor originário." Se for à seção 12 (GPLv2), esta obviamente delimita isenções desse tipo a situações e contextos explicitamente restritivos que desautorizam, peremptoriamente, interpretação tão absoluta e categórica como a que você aqui, tersamente, sugere.

            Estarias por acaso insinuando que o código penal prevê responsabilidade subsidiária para quem fabricou o aço, a pólvora ou mesmo a arma em assassinatos por arma de fogo, ou o código de trânsito para o fabricante de veículo envolvido em acidente por imprudência ou imperícia? Ou que essa responsabilização se aplica a software proprietário, a mais da devolução do valor da licença, garantia default nas EULAs desses softwares?

            Doutro lado, para acomodar o dever de ofertar garantias, conforme o que dispõe a citada lei para quem *comercializa* software, e o Código de Defesa do Consumidor para quem oferece serviços, a GPL faculta, a quem distribui software sob GPL, o direito de comercializar garantias e, para quem usa o software, o direito de escolher de quem comprá-las. Leia o parágrafo único da seção 1, que no texto da licença antecede a seção 12.

            PR: Entendo que os direitos morais de um autor de software, restritos em relação a outros tipos de obra autoral no seu poder de dar causa a retratações unilaterais da cessão de direitos de uso da obra licenciada, como entendo dispor a lei de software brasileira, são justificadamente restritos, diante do papel social que o software exerce, igualmente em jurisdições que contemplam direitos morais de autor (como a Brasieira) ou não (como as anglo-saxãs).

            A justeza dessas restrições, relativas aos direitos morais do autor do software, é uma questão de equilíbrio entre direitos público e privado. Para entender porque, imagine a situação em que um fornecedor monopolista chantageia um governo, sob a ameaça de que o Estado, cuja constituição diz ser soberano, poderia ter seu acervo digital remotamente implodido, bloqueado ou sabotado caso seu governo não faça negócios ou adote políticas convenientes a esse agente privado.

            Sem tais restrições esse tipo de chantagem, da qual a mais recente vítima (de que temos notícia) foi a Coréia do Sul, seria não apenas tecnicamente, mas também juridicamente eficaz.

            Tecnicamente eficaz, no modelo negocial proprietário, porque os softwares do fornecedor controlam, seja através do ofuscamento das codificações e formatos dos arquivos que compõem o acervo, seja através de restrições legais à manipulação dessas codificações e formatos (p.ex., patentárias) o acesso a este acervo; enquanto o fornecedor controla, remotamente, o funcionamento dos seus softwares (p.ex., via WGA).

            E juridicamente eficaz, se os direitos morais do fornecedor nos quais poderiam se abrigar causas para a retratabilidade unilateral de contratos forem irrestritos, porque isso legalizaria esse tipo de chantagem. Nesse caso e contexto, o absolutismo do direito moral do autor do software transformaria, dado o grau de dependência da sociedade às TIC, e dado a natureza monopolizante dos mercados dessas tecnologias, cláusulas constitucionais de soberania em letra morta (onde já não são por outras razões).

            Quanto mais se reza pela cartilha proprietária, mais fantasmas do software livre aparacem. Vamos então espantá-los lançando luz sobre algumas palavras.

            Primeiro, vamos ao seu exemplo. Sua afirmação deve estar incorreta pois, caso contrário, das mais de 200 distribuições de sistema operacional GNU/Linux, as que hoje empacotam junto o servidor Apache, ou seja praticamente todas, estariam violando a licença dos componentes sob GPL, inclusive a do kernel Linux. Se isso estivesse ocorrendo em tão larga escala, escala que se pode medir googlando a sigla LAMP (Linux + Apache + MySQL + PHP), certamente a Free Software Foundation (que gerencia o projeto GNU), o Open Source Development Labs (que gerencia o projeto do kernel Linux) ou a fundação Apache já teriam tentado impedir a violação.

            Segundo, vamos entender o que a Lei Brasileira quer dizer com "integração", o contexto em que o direito do usuário de integrar um software a outro é assegurado pelo dispositivo citado, e o que diz exatamente a GPL e outras licenças FOSS sobre isso. Terceiro, vamos entender de onde pode estar vindo a sua confusão.

            Pelo que foi citado, na Lei Brasileira esse direito se restringe a casos "tecnicamente indispensáve(is) às necessidades do usuário, desde que para o uso exclusivo de quem a promoveu" (a integração). Pois bem, quando o software é livre ou aberto, seja pela GPL ou seja por qualquer outra licença homologada pela Open Source Iniciative (dentre as mais de 60 que credenciam o software licenciado como "open source", e dentre as quais se inclui a própria GPL), é direito irrestrito assegurado ao licenciado, por qualquer dessas licenças, o de fazer alterações DE QUALQUER NATUREZA no objeto licenciado para uso próprio (primeiras duas sentenças no caput da seção 2 da GPLv2).

            Direito esse que, por óbvia sinonímia, extrapola aquele citado, já que o citado está restrito, quanto à finalidade da integração, a "para uso exclusivo de quem a promoveu", e quanto à natureza da integração, ao "tecnicamente indispensável às necessidades do usuário".

            Sim, mas não só do que está disposto na licença. Dependerá também da intenção do leitor de entender o que está escrito sem os preconceitos que poderiam impedir uma mínima compreensão. Conheço advogados que não entendem o que está escrito na GPL, não querem entender e querem continuar propagando seus desentendimentos, sob o pretexto de que são advogados e portanto têm o direito exclusivo de interpretar contratos.

            Vamos então tentar esclarecer sua dúvida sobre o exemplo do Apache + GNU/Linux. O que o restante da seção 2, e as cinco sessões seguintes na GPLv2, procura delimitar são as condições que dão ao licenciado o direito de REDISTRIBUIR cópias do programa licenciado, bem como o de DISTRIBUIR alterações nesse ou desse QUE CONSTITUAM TRABALHO DERIVADO BASEADO NO PROGRAMA LICENCIADO.

            Para ajudar a esclarecer, ao leitor da licença, o que o autor do software quer dizer com TRABALHO DERIVADO BASEADO NO PROGRAMA LICENCIADO, e quais restrições à distribuição deste trabalho derivado se refere a licença, consta dela os parágrafos 2, 3 e 4 da seção 2 (GPLv2).

            No par. 4 está dito que, para efeito da licença, "mera agregação de outra obra autoral que não seja baseada no objeto da licença" ("mere aggregation of another work not based on the program") não constitui trabalho derivado baseado neste, não estando, portanto, nesse caso o conjunto sujeito às restrições de redistribuição impostas no restante da licença.

            Daí porque as distros que configuram e empacotam a instalação conjunta do servidor Apache com sistema operacional GNU/Linux (p.ex., as que incluem LAMP) não sofrem restrição, pela GPL, quanto ao direito de redistribuição (desde que, é claro, as licenças das componentes agregadas sejam mantidas no empacotamento da distro)

            De onde vem, então, a tal incompatibilidade da GPL com outras licenças, e o que ela atinge? Ela vem das restrições na GPL relativas ao direito de se DISTRUBUIR TRABALHO DERIVADO BASEADO NO PROGRAMA LICENCIADO. Se algum autor de um módulo do servidor Apache, por exemplo, quiser incluir no seu módulo um trecho de código licenciado sob GPL o resultado poderia ser considerado, para efeito dos direitos cedidos pela GPL, como trabalho derivado, cabendo ainda aqui lembrar que, nesse caso, o dispositivo supracitado da Lei Brasileira não se aplica por não se tratar, quanto à finalidade, de "uso exclusivo de quem a promeveu" (a inclusão), e sim de distribuição.

Assine a nossa newsletter! Seja o primeiro a receber nossas novidades exclusivas e recentes diretamente em sua caixa de entrada.

Inscrever

            Para o autor do módulo do Apache, entretanto, resta a questão do que a GPL considera trabalho derivado caso ele queira distribuir, sob uma outra licença, obra sua na qual tenha incluído um trecho de código sob GPL. Já sabemos que está excluído da consideração de "trabalho derivado", pelo parágrafo 4 da seção 2 (GPLv2), os casos de "mera agregação". Haveria casos em que a inclusão de código fonte alheio no código fonte de uma obra poderia ser excluído, pela GPL, da caracterização de trabalho derivado?

            Agora é o par. 2 da seção 2 (GPLv2) que esclarece: Pode ser excluído dessa caracterização se as componentes que incluem o trecho de código sob GPL forem "identificáveis e puderem ser razoavelmente consideradas por si mesmas obras independentes e separadas" (podendo ser distribuídas, portanto, cada componente com sua licença).

            E o que constitui, na prática, "obras por si mesmas independentes e separadas"? Ao lidar, na prática jurídica, com a interpretação de autores de software sob GPL e autores da GPL, o teste decisivo tem sido a possibilidade das componentes poderem ser compiladas (traduzidas por outro programa do código fonte para código executável) separadamente. Se o código incluído tivesse que ser compilado junto com o código includente, neste caso o autor do módulo do Apache só poderia distribuir o conjunto, ainda segundo o par. 2 da seção 2 (v2), sob GPL.

            Isso poderia ser considerado uma incompatibilidade no contexto de uma política de licença única no projeto que inclui o módulo, que é o caso do Apache. Vale lembrar que a licença do Apache, como a maioria das licenças homologadas pela OSI, não tem essa restrição quanto a trabalhos derivativos (copyleft), o que permite a migração de código fonte, em quaisquer condições, do projeto Apache para projetos que licenciam suas obras sob GPL (a "incompatibilidade" é de mão única).

            Doutra feita, mesmo que os direitos de "integração" da Lei Brasileira não se restringissem ao "uso exclusivo de quem a promoveu", é seguro inferir que as questões postas pela GPL passavam ao largo do horizonte hermenêutico do legislador Brasileiro, já que essa lei trata de código fonte apenas indiretamente, onde define o que é software, estando os dispositivos referentes à sua comercialização e uso calcados na noção de produto executável em computador, ou seja, em sua expressão em código binário.

            Se, para ajudar a compreensão do leigo, recorrermos a uma metáfora biológica, seria como se um discurso (o da lei Brasileira) se referisse a direitos para práticas íntimas como o beijo e a dança (entre programas), enquanto o outro (o das licenças FOSS) se referisse a direitos para reprodução sexuada. Um bom exemplo para ilustrar o direito de "integração" protegido pela Lei Brasileira pode ser encontrado na integração entre sistemas operacionais e navegadores web.

            Até recentemente, as interfaces gráficas de usuários finais de sistemas operacionais permitiam a esses escolher um navegador web "padrão". Ou seja, aquele dentre os navegadores instalados (havendo mais de um) que seria acionado quando se clica em um link com endereço web no sistema.

            Mas eis que sai o Windows Vista, mantendo a interface de usuário dos Windows anteriores, que permitia ao usuário escolher seu navegador padrão, só que com um detalhe. Se outro navegador for instalado (por exemplo, o Firefox), o usuário do Vista não conseguirá configurar esse navegador como "padrão".

            Não importa quantas vezes o usuário escolha o Firefox como padrão, quando ele clicar em um link web no sistema o Vista continuará acionando o navegador Internet Explorer, navegador que por sinal já foi condenado, por sua insegurança, até pelo CERT-US (Computer Emergency Readiness Team: http://www.internetnews.com/security/article.php/3374931).

            O leigo poderá se frustar, até pensar que o problema é com o Firefox, quando na verdade a interface de usuário, que lhe leva a crer que ele pode escolher, como nos outros Windows, o navegador padrão de sua escolha, está lhe enganando.

            Todavia, quem não é leigo intui que deve haver um chave no registry do Vista que, com conhecimento, paciência e disposição suficientes, inclusive para correr o risco de detonar a instalação do sistema, poderá ser editada cirurgicamente, para que o Firefox se torne o navegador padrão naquele sistema (como de fato existe). Se alguém se dispuser a tentar, e tiver sucesso, essa situação se enquadraria, a meu ver, no dispositivo citado.

            Mesmo se a licença de uso do Vista proibisse tal "intervenção cirúrgica" no registry, trata-se da integração de um programa (Firefox) mantendo-se suas características essenciais, a um sistema operacional (Vista), tecnicamente indispensável às necessidades do usuário (que esteja preocupado com a sua segurança digital), para o uso exclusivo de quem a promoveu (na sua própria instalação do Vista).

            Entretanto, se um tal usuário, tendo aprendido com sua experiência, decidir fazer um programinha que automatiza a "mexida" no registry do Vista para tornar o Firefox (ou outro) o navegador padrão, e quiser distribuir esse programinha livremente, já que ele não pode distribuir cópias modificadas do Windows Vista, ele estaria, com muita probabilidade, infringindo os direitos autorais do titular do sistema operacional e/ou a licença da cópia do Vista onde aprendeu o truque.

            Coisa que absolutamente não aconteceria num sistema operacional livre, se por acaso um sistema operacional livre pregasse uma peça desse tipo em usuários: sistemas operacionais livres podem ser modificados e terem suas modificações distribuídas, seja com licença escolhida pelo redistribuidor (p.ex., o sistema FreeBSD) ou, no caso do GNU/Linux, sob a devida licença (GNU GPLv2). Para os devotos da cartilha proprietária os fantasmas podem estar, afinal, onde menos esperam.

            PR: O registry é um banco de dados de configuração do sistemas operacionais Windows. Não é imexível, é editável pelo usuário. Editável inclusive com utilitário (o RegEdit) que, até a versão XP, era fornecido junto com o sistema (que não sei se vem também no Vista)

            Doutra parte, segundo o que me consta, é padrão nas EULA de versões do Windows a existência de clausulas proibindo a engenharia reversa. Assim, se houve intenção do autor do Vista em ofuscar a chave do registry que impede a mudança na configuração do navegador padrão, como me parece ser o caso, o processo de DESCOBERTA de qual chave ou chaves são essas, de qual ou quais valores teriam que ser nela(s) escrito(s) para causar a mudança desejada (de configuração de navegador padrão), e não o ato de edição propriamente, poderia ser interpretado, dada a latitude e liberdade que os autores da licença se dão para interpretar os seus termos, como um ato de engenharia reversa.

            Se alguém descobrir qual(is) e como, e modificar aproriadamente a(s) chave(s) do regsitry na sua cópia do Vista, esse ato, não sendo de conhecimento ou verificação pública, não vai fazer prova contra quem o praticou. A menos, é claro, que haja denúncia, seguida de esforço do titular do Vista para apurá-la, e mandado judicial para busca e apreensão da cópia mexida, o que seria bastante improvável. Entretanto, se esse alguém fizer um programa que executa esse ato, e distribui esse programa, o mesmo passa a constituir prova da prática de algo que o titular do Vista poderia interpretar como engenharia reversa, em violação da EULA da cópia onde esta descoberta ocorreu.

            Ainda, se o programa em questão executar esse ato sem a intermediação do utilitário destinado a manipular o registry, isso poderia ser considerado uma modificação não autorizada do binário do Vista (que diz respeito aos direitos de autor do Vista), independentemente da questão da engenharia reversa (que diz respeito à EULA de uma cópia do Vista). O programa em questão poderia, assim, ser interpretado como algo que viola o direito autoral do titular do sistema operacional ao extrapolar as condições impostas pelo dispositivo citado (artigo sexto, inciso IV da Lei do Software Brasileira), já que estaria "integrando" outro navegador ao sistema não para uso próprio do autor do programa em questão, e sim para qualquer um que o receber e o executar em sua própria cópia do sistema.

            É claro que isso não significa que o titular dos direitos do Vista iria interpretar desta forma, ou processar o autor de um tal programa caso um tal programa venha a circular. Mas significa um tal possível enquadramento funciona como chilling effect, como fator de risco a ser considerado por quem almeje escrever e distribuir um tal programa.