On Oct 28, 2006, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Obviamente se alguém quiser comprar uma televisão e substituir seus > componentes, assim o pode, assumindo, para si todos os riscos inerentes.
Esse é o ponto. > No entando, o fabricante também tem direito de tomar medidas para evitar > tais violações. Tem mesmo? Baseado em que lei? Da Constituição Federal de 1988: Art. 5º Todos são iguais perante a lei, sem distinção de qualquer natureza, garantindo-se aos brasileiros e aos estrangeiros residentes no País a inviolabilidade do direito à vida, à liberdade, à igualdade, à segurança e à propriedade, nos termos seguintes: [...] II - ninguém será obrigado a fazer ou deixar de fazer alguma coisa senão em virtude de lei; ^^^^^^^^^^^^^^^ >> Isso é um mito resultante de incompreensão do que a licença diz. > Para mim, o texto é claro e restritivo quanto a usos válidos de > criptografia em sistemas embarcados. Vamos ver se, depois dos pontos que apresentei hoje, você ainda mantém essa opinião. Se mantiver, seria bom justificar. >> >> > Além disso, a possibilidade de adicionar restrições na GPLv3 e >> > alterá-las ao longo do tempo é extremamente danosa, pois significaria >> > regressões no Kernel (alguém pode enviar uma feature interessante, com >> > restrições adicionais e posteriormente, propositadamente, removê-las). >> > Isto é muito ruim. >> > Além disso, como a v3 draft é mais restritiva que a v2, poderia gerar um >> > grande problema para as distribuições, abalando o ecossistema. >> Tipo assim, é um problema a v3 ser mais restritiva, mas alguém impor >> ainda mais restrições que podem ser removidas não é um problema? >> Que tipo de posicionamento é esse? > Não entendi. O que quis dizer é que as restrições adicionais abrem > brechas para que entidades maliciosas possam adicionar cláusulas, e > remove-las depois para gerar tumulto. Como é que remover cláusulas restritivas, estabelecidas dentro de uma gama muito restrita de possíveis restrições adicionais, pode gerar tumulto? FUD? > No kernel, uma regra que se tem é não quebrar compatibilidade binária > com executáveis antigos. Se alguém adiciona uma nova interface, sua > remoção posterior seria o caos, gerando a parada de diversos > aplicativos. Você estava falando da remoção do código, não das restrições? Se alguém oferece o código com restrições adicionais dentro das poucas permitidas no rascunho da GPLv3, elas permanecem, com as restrições, até que alguém as remova do todo. Não entendo qual a objeção. >> > Ao longo da existência do Linux, existe alguns que >> > não estão mais entre os vivos, >> Os herdeiros deles certamente podem ser convencidos se for por uma boa >> causa. > Ou acharem que irão lucrar muito, instruir um advogado e gerar problemas > para a comunidade. Pfff. Apresente-os aos advogados da SCO, da IBM, da Red Hat e da Novell. >> Agora a razão de esse problema existir é precisamente a estultície de >> não permitir o relicenciamento em outras licenças que preservem o >> mesmo espírito da anterior, corrigindo os bugs que a anterior deixou >> passar. > Ao restringir liberdades quanto ao uso em sistemas embarcados, > GPLv3Draft2 arranha a liberdade 0. Ela não restringe nem arranha essa liberdade. Ela nem pode. A lei de direito autoral na maior parte do mundo não regula o uso (entenda-se execução), apenas modificação e distribuição. O que ela arranha é a possibilidade de alguém usar de artifícios legais ou jurídicos para negar a liberdade de modificar ou distribuir a terceiros. >> > e outros que eventualmente mudaram de >> > idéia sobre FOSS e possam querer re-licenciar seu trabalho em uma >> > licença proprietária, se alguém lhes der oportunidade. >> >> Eles já podem fazer isso hoje, só que provavelmente não vai ser muito >> útil sem o restante. >> Sempre há a opção de remover o código dos que resistirem à evolução. > Quebrando todos os programas que dependem do kernel, se for em uma API. Ou reimplementando as mesmas APIs pra não precisar passar pela aprovação dos dissidentes. >> > O espírito da GPLv3 de combate incondicional ao DRM elimina a >> > possibilidade do uso válido da criptografia e do desenvolvimento de >> > sistemas imbutidos. >> DRM nem aparece no segundo rascunho. > Não com este nome. Mas as restrições de instalação/execução da sessão 1 > foram voltadas ao combate a DRM e a denominada "tivolização". Não há restrições a instalação/execução. Há um esclarecimento que quem tenta restringi-las por medidas técnicas está em violação da licença, mesmo da v2. >> GPLv3 não combate DRM. De fato, o uso para DRM é claramente permitido, >> pois não há restrições quanto >> ao que se pode fazer no software (rodar o software para qualquer >> propósito, liberdade #0). O que não pode é alguém usar justificativas >> baseadas em DRM para cercear as liberdades de terceiros que eles >> mesmos têm, como a de modificar o software e usá-lo para qualquer >> outro propósito. > GPLv2 já garante isto. Exatamente! Só que tem gente tentando se valer desse tipo de artifício, seja o técnico seja o jurídico, para cercear as liberdades dos outros. Então a GPLv3 deixa claro, com todas as letras, que não pode, pra não dar margem a dúvidas. Como isso pode ser ruim? >> Então que ponha o sistema em ROM! >> Se eles querem a vantagem de poder modificar o software, então devem >> oferecer a mesma vantagem aos que obtêm o software deles. > Colocar o sistema em ROM é uma clara restrição de liberdade do usuário. > Significaria ter um equipamento sem a possibilidade de aprimoramentos. Se o fabricante não tem a possibilidade de fazer os aprimoramentos, não precisa passá-la adiante para os usuários. Se tem, deve passá-la adiante. > Ou seja, para adicionar novas features, o usuário teria obrigatoriamente > que adquirir novo hardware. E o fabricante, projetar e fabricar novo hardware. Parece-me um balanço justo. Por certo é melhor para todos se todos puderem fazer as modificações que quiserem sem passar pelo custoso processo de manufatura de ROMs. >> Você não é *obrigado* a modificar o software. Mas, se você quiser, >> você deve poder. > Se eu posso, outros podem. Este é o problema: sem uma devida chave de > segurança, um hacker pode gerar uma versão "fake" do software e, com a > chave, instalar em meu celular. Se o telefone é meu, a chave deve estar sob meu controle. *Eu* devo determinar o que roda no *meu* telefone, ninguém mais, muito menos contra a *minha* vontade. >> > O uso de sistemas não assinados >> > pelo fabricante significaria que alguém pode estar escutando ilegalmente >> > minha comunicação ou derrubando propositadamente uma aeronave. >> >> O uso de sistemas assinados pode ser *garantia* disso ;-) > Por isso, é necessária a assinatura *do fabricante*. Pro fabricante poder ter certeza de que ninguém vai descobrir que ele introduziu essa porta dos fundos e poder se livrar dela? > Eu diria que 99,999% dos usuários de celulares, televisores ou > carros nunca geraram uma chave privada (e nunca irão querer > gerar). Se, para ter um aparelho confiável eles tiverem que usar > criptografia, isto é uma *obrigação* e não um direito. Eles não têm que usar. A chave do meu carro tem lá um sisteminha de autenticação, gerado pelo fabricante. O fabricante (supostamente) não tem mais as chaves, todas as cópias dela estão em meu poder. Eu as uso se quiser. Por que seria diferente com quaisquer outros dispositivos eletrônicos? >> > A GPLv3 mata este tipo de uso, ao impedir o uso de criptografia >> > para validação do sistema operacional. >> Ela não impede isso. Leia de novo e não acredito em boatos, muito >> menos nos falsos ;-) > Como já postado na lista: >> The Corresponding Source also includes any encryption or >> authorization keys necessary to install and/or execute modified >> versions from source code in the recommended or principal context of >> use, such that they can implement all the same functionality in the >> same range of circumstances. Onde está dizendo que não pode usar criptografia pra validar o sistema operacional? Tá dizendo que o usuário deve ter controle sobre o processo. Porque se não tiver, suas liberdades estão sendo cerceadas, o que viola o espírito da licença. >> O que há é apenas oposição ao abuso dessas técnicas (e muitas outras) >> com a finalidade de impedir o exercício das liberdades que a GPL >> precisa garantir. > "abuso" é uma palavra que remete a moral e a ética. Da mesma forma que liberdade, respeito às liberdades, o espírito da GPL e o fundamento do movimento pelo Software Livre. > O uso de criptografia para proteção quanto a execução de softwares > maliciosos não é abuso nem restrição da liberdade, na visão dos > profissionais de segurança (onde eu me enquadro, enquanto CISSP). No > entanto, GPLv3 condena tal uso (conforme acima), considerando como > abuso. De novo, segurança para quem? O objetivo da GPL não é garantir a segurança de quem cria o software ou o distribui. É garantir a segurança do usuário, de que ele não depende de ninguém mais para poder exercer as liberdades. Por certo há medidas de segurança para o autor e o distribuidor: a cláusula de ausência de garantia e a exigência de enumeração proeminente das modificações feitas. > Há de se notar que GPLv3, quando aplicada ao kernel, impõe > restrições quanto ao hardware onde o S. O. será rodado (que não é > trabalho derivado ou correlato ao kernel). Não vejo de onde vem essa suposição falsa. Pode esclarecer? > Enquanto desenvolvedor de software livre, não tenho nenhum problema em > ter meu código sendo usado em telefones celulares, televisores, > roteadores, sondas espaciais, etc, desde que respeitada a GPLv2. Nenhum > destes usos é abusivo, do meu ponto de vista. De fato. Desde que respeitada a GPL, o uso é abusivo. Desrespeitar a GPL significa negar aos usuários do software as liberdades que a GPL exige que sejam respeitadas. Entre elas, a liberdade de modificar o software e executá-lo para qualquer propósito. > Certamente algo que muitos desenvolvedores não gostariam é de ter seus > softwares rodando em armamentos (incluindo eu). Nem que fosse para a Venezuela ou o Brasil se defenderem de uma invasão dos EUA? De novo, segurança para quem contra quem? > Neste contexto, o uso em tais dispositivos estariam na categoria de > "abuso", do ponto de vista do desenvolvedor. Se você quer dizer que isso é abuso, não use a GPL, pois ela não admite esse tipo de restrição. > Em âmbos os casos, a GPLv3 pura não resolve os abusos, do ponto de vista > de restrições aos abusos na visão do autor do software, que, em última > instância, é quem cede os direitos e obrigações quanto ao uso. O autor do software licenciado sob a GPL não impõe quaisquer obrigações. Ele apenas respeita algumas liberdades, algumas delas de maneira restrita. Ela não cria nenhuma obrigação que já não existia antes, não limita nenhuma liberdade que o licenciante já tinha antes. É o que se chama de contrato benéfico. Eu deixo você fazer isso (como quiser) e isso outro (de uma maneira específica), sem qualquer contrapartida. É por isso que a GPL não precisa de assinatura. > Poder-se-iam pensar em diversos outros abusos a serem igualmente > condenados, tais como o uso de software livre para cometer crimes, Cometer crimes às vezes faz parte do processo legítimo de luta pela liberdade, a desobediência civil. Veja Gandhi, Mandela, Martin Luther King, ou mesmo quem tenha lutado contra a ditadura no Brasil, na Argentina, na China, etc. Restringir o uso de software livre para esses fins seria imoral. > Em outras palavras, ao deixar o campo puramente de licenciamento de > software e liberdade de uso do software, partindo para restringir usos > em elementos periféricos como o hardware ou o tipo de aplicação > executada pelo usuário, como nos exemplos acima, à partir de um certo > ponto de vista, é aplicar uma visão limitada ao problema. Concordo. Ainda bem que a GPL não faz nem tenta fazer isso. > Não estou dizendo que as intenções não sejam boas. No entanto, licença > de software não é o instrumento correto para combater tais abusos. A licença não está tentando fazer isso. Ela está apenas tentando garantir o respeito às liberdades no que tange ao software licenciado sob ela. Não restringe o hardware de forma alguma; apenas exige as chaves necessárias para modificar e executar o software. Imagine que alguém distribua tanto o binário quanto os fontes criptografados com a mesma chave pública. O hardware sabe decodificar o binário porque ele tem a chave privada correspondente. Mas e você, como vai fazer uso dos fontes? A licença explicitamente coíbe esse tipo de abuso. > Especificamente no caso do DRM e patentes, de uma forma geral, estas > pressões já estão ocorrendo. Certamente. Mas a GPL não é uma ferramenta para acabar com DRM ou patentes de software. Ela não tem esse poder. Ela é uma ferramenta para garantir o respeito às liberdades no que tange aos programas sob ela licenciados. E ela vinha falhando nesse sentido por causa de brechas relacionadas a DRM, tanto na técnica quanto na lei, e patentes de software. Algumas das brechas existem de fato; a maioria é fruto de interpretação não pretendida e discutível. Portanto a maioria das alterações corresponde a esclarecimentos. > Se você ver os resultados das principais gravadoras com DRM em CD, verá > que a sociedade as condenou, obrigando-as a fazer um recall de midias > com DRM, para os clientes pagantes. Além disso, mesmo com todo o gasto, > o uso de DRM não impediu os usuários de compartilhar suas músicas. Isso é ótimo, mas não invalida a iniciativa de esclarecer que o uso de medidas técnicas (como DRM) para impedir o exercício das liberdades sobre software GPL não é autorizado. Não importa quão sofisticada seja a explicação de por que você acha que pode restringir as liberdades dos outros sobre software GPL: não pode, nem perca seu tempo tentando. Se você o fizer, está violando a licença. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} _______________________________________________ PSL-Brasil mailing list [email protected] http://listas.softwarelivre.org/mailman/listinfo/psl-brasil Regras da lista: http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil
