A GPL e a legislação Brasileira
Debate com uma aluna
sobre o Direito de Autor frente ao Software LivreProf. Pedro Antonio Dourado de Rezende
Departamento de Ciência da Computação
Universidade de Brasília
Março de 2007
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:
email 1:
Aluna: Eu tenho uma dúvida: embora a Lei do Software diga que o programador não faça jus aos direitos morais, eu entendo que há uma antinomia com a Lei 9.610/98, no sentido do programador ter o direito moral previsto na Lei Autoral.
Pedro Rezende: Pelo que entendo, a lei de software Brasileira não anula esses direitos morais, mas apenas restringe as possíveis causas, alegáveis por parte do autor do software, pelas quais esses direitos poderiam amparar retratações unilaterais de contratos de licença de uso do software em tela.
A: Lendo a licença GPL, verifiquei que há um item dizendo que quaisquer danos provocados pelas alterações de terceiros não é de responsabilidade do autor originário. O Sr. entende que o mesmo que é aplicado ao software poderia ser aplicado ao software livre, no que diz respeito a Lei 9.610/98 e 9.609/98?
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 do software, 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. Na GPL o direito de uso do software decorre indiretamente dos direitos cedidos pela licença. Por esta razão deve-se entender a GPL, especialmente em uma jurisprudência que vê como contrato qualquer tipo de acordo (como a Brasileira), 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, as quais, 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 sua tutela, "quaisquer danos provocados pelas alterações de terceiros não é de responsabilidade do autor originário." Se for à seção 12 (GPLv2), parece óbvio que tal cláusula delimita isenções desse tipo a situações e contextos explicitamente restritivos, os quais desautorizam, peremptoriamente, interpretação tão absoluta e categórica como esta que você, aqui, sugere tersamente.
Estarias por acaso insinuando que o código penal prevê, ou deveria prever, responsabilidade subsidiária para quem fabricou o aço, a pólvora ou mesmo a arma em assassinatos por arma de fogo? ou que o código de trânsito prevê, ou deveria prever, responsabilidade subsidiária para o fabricante de veículo envolvido em acidente por imprudência ou imperícia do condutor? Ou que essa responsabilização se aplica a software proprietário além da simples devolução do valor pago pela licença, garantia default nas EULAs desses softwares?
Doutro lado, para acomodar o dever de ofertar garantias, conforme o que dispõe a lei brasileira para quem comercializa software, bem como o Código de Defesa do Consumidor para quem oferece serviços, a GPL faculta, a quem distribui software licenciada através dela, o direito de comercializar garantias. Enquanto ao mesmo tempo também oferece, a quem usa o software, o direito de escolher de quem comprá-las. Leia o parágrafo único da seção 1 da GPL, que no texto da licença antecede a seção 12.
A: O que o Sr. acha da não aplicação dos direitos morais?
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, independentemente da jurisdição contemplar direitos morais de autor (como a Brasieira) ou não (como as anglo-saxãs), no ordenamento de fundo (direito autoral).
Entendo que a justeza dessas restrições, relativas aos direitos morais do autor do software, corresponde a uma questão de equilíbrio entre direitos público e privado. Para entender o porquê, 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, cuja mais recente vítima de que temos notícia foi a Coréia do Sul (em 2005), seria não apenas tecnicamente, mas também juridicamente eficaz.
Tecnicamente eficaz, contra quem se submete ao 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., restrições patentárias) o acesso a este acervo; enquanto o mesmo fornecedor controla, remotamente, o funcionamento dos softwares licenciados à vítima da chantagem (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, porque, sendo tais direitos morais irrestritos, eles legalizariam 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).
email 2:
A: Tenho mais uma dúvida:
Existem licenças de software livre que não são compatíveis entre si. O artigo sexto, inciso IV da Lei do Software dispõe que não constituem ofensa ao programador: a integração de um programa, mantendo-se suas características essenciais, a um sistema, aplicativo ou operacional tecnicamente indispensável às necessidades do usuário, desde que para o uso exclusivo de quem a promoveu. Eu não poderia aplicar este inciso ao SL, pois imaginemos que eu tenha um código fonte protegido pela GPL e outro protegido pela Licença Appache. São licenças incompatíveis, e portanto eu não poderia fazer a integração dos códigos. Está correta a afirmação?
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 tais violações.
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 o tema. 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 e extravasa aquele citado pela lei brasileira, 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".
A: Ou tudo dependerá do que estiver disposto na licença?
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 podem 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, direitos que também julgam vedados aos "leigos".
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 software 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 da mesma 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, o conjunto sujeito às restrições de redistribuição impostas no restante da licença neste caso.
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 a solução 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), pois o Apache está sendo meramente agregado ao restante da distribuição.
De onde vem, então, a tal incompatibilidade da GPL com outras licenças, e o que ela atinge? Tal incompatibilidade vem das restrições na GPL relativas ao direito de se DISTRUBUIR TRABALHO DERIVADO BASEADO NO PROGRAMA LICENCIADO.
Se o autor de um módulo do servidor Apache, por exemplo, quiser integrar 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. Cabe 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 integração), e sim de distribuição (uso não exclusivo).
Para o autor do módulo do Apache, entretanto, resta a questão do que a GPL considera trabalho derivado caso este autor 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, pelo parágrafo 4 da seção 2 (GPLv2), de enquadramento sob "trabalho derivado" os casos de "mera agregação". Resta saber se 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.
Esta questão, é o par. 2 da seção 2 (GPLv2) que esclarece: Pode ser excluído dessa caracterização (de trabalho derivado) 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). A questão se reduz, então, a saber 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 (para determinar se duas obras são por si mesmas independentes e separadas) tem sido a possibilidade das componentes poderem ser compiladas (traduzidas de 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, se a licença do código includente for GPL ou compatível com a GPL (no sentido de não abolir nenhum dos direitos que a GPL cede a licenciados).
Isso só poderia ser considerado uma incompatibilidade em contextos onde o projeto de desenvolvimento do software que inclui o módulo possui uma política de licença única, caso do Apache. Porém, no caso do Apache vale lembrar que a licença escolhida para o projeto, como a maioria das licenças homologadas pela OSI, não contempla essa restrição quanto a trabalhos derivativos (cláusula copyleft), o que permite, em quaisquer condições, a migração de código fonte do projeto Apache para projetos que licenciam suas obras sob GPL. Ou seja, a "incompatibilidade" surgida de uma política de licença única será de mão única se a licença única paro projeto não incluir clásula copyleft (como a do projeto Apache).
Doutra feita, mesmo que os direitos de "integração", outorgados pela lei brasileira ao licenciado, 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, calcados exclusivamente na forma de expressão da obra em código executável.
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 de computador), enquanto o outro discurso (o das licenças FOSS) se referisse a direitos ainda mais íntimos, como os da reprodução sexuada (contato com troca de material genético). Um bom exemplo para ilustrar o direito de "integração" protegido pela Lei brasileira pode ser encontrado na integração entre sistemas operacionais (GNU/Linux, Windows) e navegadores web (Internet Explorer, Mozilla Firefox).
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. Começam o surgir queixas na web de que Se outro navegador for instalado (por exemplo, o Firefox), o usuário leigo do Vista não conseguirá configurar esse navegador como "padrão", ficando "preso" ao Explorer).
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á, continuaria, nas circunstâncias descritas pelos queixosos, acionando o navegador 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 ou falhando.
Todavia, quem não é leigo intui que deve haver um chave no registry do Windows 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 (direito de integração segundo a Lei brasileira).
Mesmo se a licença de uso do Vista proibisse tal "intervenção cirúrgica" (isto é, alteração de registro não documentado publicamente) no Registry, trata-se da integração de um programa (Mozilla Firefox), mantendo-se suas características essenciais, a um sistema operacional (Windows Vista), tecnicamente indispensável às necessidades do usuário (que esteja interessado na 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 uma tal alteração 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 seus 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 licença determinada pelo(s) autor(es) (GNU GPL). Para os devotos da cartilha proprietária os fantasmas podem estar, afinal, onde menos esperam.
email 3: O leitor Hudson Lacerda escreveu:
L: Lendo esse debate, f iquei surpreso com a parte final, que discorre sobre a dificuldade em tornar padrão um navegador que não seja o IE. Você conclui que a distribuição de um programa que faz hacking do ``registry'' do Vista poderia ``muito provavelmente'' infringir os direitos autorais da Microsoft. Não entendo o porquê, mas suponho que isto se deva à minha ignorância do que seja ``registry''. O tal ``registry'' é um arquivo de configuração (que seria portanto sujeito a modificações pelo usuário) ou é um componente ``imexível'' do sistema, tal como os executáveis e bibliotecas?
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 cláusulas 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 de 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 alterada, o que seria bastante improvável. Entretanto, se esse alguém fizer um programa que executa esse ato, e distribuir esse programa, o mesmo programa 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 que permitiu ao infrator descobrir como alterar o Vista.
Ainda, se o programinha em questão executar tal alteração sem a intermediação do utilitário destinado pelo fornecedor do Vista para 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, de outra forma, o direito autoral do titular do sistema operacional, ao extrapolar as condições impostas pelo citado dispositivo da Lei brasileira (artigo sexto, inciso IV da Lei de Software), já que este programinha, se distribuído, estaria "integrando" outro navegador ao sistema mas não para uso próprio do autor do programinha, e sim para qualquer um que o receber e o executar em sua própria cópia do sistema Vista.
É claro que isso não significa que o titular dos direitos do Vista iria interpretar desta forma, ou processar o autor de um tal programinha caso tal programinha venha a circular. Mas significa que um tal possível enquadramento funciona como chilling effect, isto é, como fator de risco a ser considerado por quem almeje escrever e distribuir um tal programinha.
29.03.07: email 4: Outro leitor escreveu:
L: Se outro navegador for instalado (por exemplo, o Firefox), o usuário do Vista não conseguirá configurar esse navegador comoMentira tem pernas curtas. Da minha parte, cito abaixo algumas fontes de informação que usei para meu artigo. Da parte do leitor, sugiro e espero que entre nos blogs ou contate os jornalistas citados para contestá-los.
"padrão". (...)" A última frase do trecho é uma mentira. Sugiro que o senhor realize o teste antes de publicar informações equivocadas. Desinformação traz mais malefícios à você do que a quem você quer atacar: lhe tira créditos de confiança naquilo que você informa.
http://review.zdnet.com/Windows_Vista_Ultimate/4505-3672_16-32013603.html
http://forums.mozillazine.org/viewtopic.php?t=515829
http://www.43things.com/things/view/893
http://www.curiostudio.com/forum/viewtopic.php?p=9108&sid=af1ab7dd22065fadb1683544b4336b54
http://trout.snt.utwente.nl/ubbthreads/ubbthreads.php?ubb=showflat&Board=8&Number=173475&Searchpage=
1&Main=32312&Words=&topic=2&Search=true&PHPSESSID=ea97a9dbc3402eaa25309f5009253fea
http://www.zoliblog.com/blog/_archives/2007/3/16/2809817.html
http://www.moka5.com/node/457
01.04.07- Em atenção à detalhada réplica do leitor questionando a acurária das referências acima, reconheço a imprecisão da linguagem generalista empregada e reviso (em verde) a resposta referida, com o intuito de tornar a argumentação mais correta e precisa.
13.09.07 - Com relação a quem desinforma e quem quer atacar quem, atualizo a lista de referências acima com um post do analista Adrian Kinsley no renomado portal ZDNet:
"Confirmed: Microsoft is fiddling with system files without permission" http://blogs.zdnet.com/hardware/?p=774
30.03.07- email 5: Outro leitor escreveu:
L: Usar como referência sobre segurança um artigo de junho de 2004, sobre IE 6, quando o Vista vem com o IE 7, é no mínimo querer distorcer demaaaais a realidade. Eu até concordo com isso tudo aí, não usei o ruindows vista para saber se realmente é assim a questão do link, nem quero usar, para ser sincero, mas pelo menos que se pegue artigos corretos para referenciar, é o mínimo que se pede...O artigo citado no meu entender é correto, e essa crítica à citação do mesmo é precipitada. Se não ingênua: As razões para o CERT-US desqualificar o IE estão lá listadas, sendo a sua maioria inadequções estruturais, que portanto permanecem na versão 7 do IE. Para entender a relação entre causa e efeito das vulnerabilidades estruturais citadas no artigo, também presentes no IE 7, basta acompanhar o histórico dos incidentes de segurança desse software, que Peter Guttmann chama de "o mais perigoso na web", e comparar padrão e ritmo desses incidentes entre a versão 6 e a 7.
Praticamente o mesmo ritmo e o mesmo padrão, inclusive com divulgação de patches contendo novas vulnerabilidades ou destapando velhas vulnerabilidades exploráveis. Não é necessário ser desenvlovedor do IE para entender isso, só ter um mínimo de competência, como profissional ou docente, em segurança na informática.
30.03.07- email 6: Outro leitor escreveu:
L: É forçar a barra querer achar que alterar a configuração de softwares, seja manualmente ou através de programas que manipulem esses registros, seja ato de engenharia reversa ou hacking. Muito menos violação de direitos autorais. Praticamente qualquer programa que venha a ser instalado no Windows altera seu registro, seja para uma associação de arquivos, paths de execução, vínculos de bibliotecas, etc.
Posso alterar o regsitro para que o sistema não guarde algum histórico de execução de programas, abertura de arquivos, para que não seja exigido um ctrl+alt+del na hora de logar no sistema ou até para manter o numlock ligado. Personalizar a área de trabalho altera o registro.
Durante a instalação do OpenOffice, por exemplo, sou indagado se desejo associar ele à abertura de arquivos do Word, Excel e PowerPoint. Isso é feito mediante alteração no registro. Quer dizer que isso é "hacking" e engenharia reversa ? Que algo ou alguém está violando "direitos autorais" da Microsoft ?
A prórpia Microsoft publica livros e artigos sobre como manipular o registro. Façam uma busca por "windows regsitry" na Amazon Books e encontrarão mais de 1300 títulos, muitos deles publicados pela Microsoft Press. Programadores necessitam dessas informações para que seus softwares interajam adequadamente com o sistema, quem dá suporte e manutenção necessita dessas informações para solucionar problemas ou customizar o sistema.
O registro do Windows foi feito para ser alterado, assim como qualquer arquivo de configuração em um /etc. O correto funcionamento do sistema depende disso. Alterar dados do registry não é, definitivamente, engenharia reversa. Muito menos "hacking"... Meio xenófobo e paranóico isso....
A referência não é sobre alteração de chaves do Registry documentadas ou automáticas. A referência é sobre alterações manuais de registros não documentados, os quais têm sido uma constante nos produtos da empresa ao longo de sua história. Estava me referindo a fuçar em chaves com nomes cifrados, para tentar se descobrir um efeito não documentado. Repito, para o caso da omissão ter sido acidental, o que escrevi acima:
"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."
A hipótese aventada na resposta à última pergunta da debatedora, sobre violação do par. 2 do artigo sexto da Lei de Software Brasileira, era em relação a registros não documentados. E foi exatamente sobre essa hipótese a estratégia adotada pelos advogados da MS, em juízo, para argumentar que o IE é parte integral e inseparável do Sistema Operacional, durante os cinco anos da ação em que a empresa foi condenada por prática monopolista predatória, em úlima instância pela corte suprema dos EUA em outubro de 2003.