On Oct 27, 2006, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Sim. Se um grande fabricante de celulares ou de aviões ou de roteadores > usam o Kernel do Linux, e desenvolvem inovações (por exemplo, melhorias > na pilha TCP/IP), pela GPLv2, eles devem disponibilizar suas alterações. > Isto permite que toda a comunidade ganhe com estas melhorias.
BZZT. Melhor estudar melhor a GPLv2. Você vai perceber que em lugar nenhum ela exige disponibilização das alterações para a comunidade. Veja a cláusula 3 para entender quem pode obter os fontes quando o programa é distribuído em forma binária. > A análise que realizamos está intimamente ligada ao Kernel e ao seu > ecossistema (leia-se aqui as distros). Uma incompatibilidade entre GPLv2 > e GPLv3 poderia inviabilizar a distribuição comercial de distribuições > Linux. Bah. FUD. Há incompatibilidades entre a GPLv2 e tantas outras licenças nas distros que falar que a GPLv3 pode causar esse tipo de problemas só pode ser justificado por ingenuidade ou malícia. > Do meu ponto de vista, e o da maioria dos demais mantenedores do Kernel, > quanto mais usuários utilizarem nossos softwares, mais contribuições > teremos para o kernel, significando um melhor sistema para todos. Isso só é verdade se eles puderem exercer as liberdades. Se todos forem obrigados a usar versões certificadas do kernel, sem poderem experimentar, como você espera que consigam contribuir? Não se iluda, a ameaça de Treacherous Computing está aí. Se não lutarmos por nossas liberdades, as perderemos. > Impossível é uma palavra muito forte. A troca de licença do kernel só se > justificaria em casos extremos, pois teria um custo muito alto de > identificar e re-convocar dezenas de milhares de pessoas e, em alguns > casos, de seus sucessores, oferecendo risco de problemas. O risco de problemas não existe, é FUD. Veja os inúmeros casos de gente que quis mudar de idéia e revogar a licença de software sob a GPLv2. O resultado mais comum é linchamento verbal público, e o efeito legal do relicenciamento retroativo é nulo. O custo por certo existe, e foi uma armadilha que os desenvolvedores do kernel criaram para si mesmos. Fecharam a porta para a correção de bugs na licença, e agora ficam buscando maneiras de justificar e racionalizar por que não queriam correções mesmo. As uvas estão verdes. > Um caso prático: com GPLv3, os usuários de notebooks com algumas placas > WiFi internas não poderão utilizar Linux, visto que o FCC > norte-americano exigiu uma proteção para as placas WiFi não interferirem > em certas freqüências. É só implementar a proteção em hardware. Alguns o fazem através de firmware carregado a partir do computador principal. Não há razão técnica para que o tal firmware não fosse gravado numa ROM ou outra memória não volátil do equipamento. São razões mercadológicas: colocar essas memórias tem custo. Agora explica pra mim o que é que a GPLv3 tem que ver com isso, onde é que entra a diferença entre a GPLv2 e a GPLv3 que conflita com o que está acima? > Como os chips possibilitam o uso destas > freqüências na Europa, a solução dada foi um software impedindo a > violação da lei. À luz da GPLv3, isto violaria a licença de software. A GPL não precisa impor restrições para impedir alguém de violar a lei porque a lei já se sobrepõe a isso. Portanto, mesmo que a GPL não diga que você não pode modificar o software de maneira que contrarie a lei, a própria lei já impõe essa restrição. Ou seja, o software não precisa de medidas adicionais para isso. Agora, se alguém quiser colocar uma tabela de informações externa, a ser consultada pelo software a fim de decidir que freqüências pode usar, e determinar que essa tabela não é parte integrante do software, não há empecilho algum. > Não. O espírito da GPLv2 nunca foi restringir em qual hardware um > software seria executado, mas sim, de tornar livre o acesso ao código. Você está deturpando o espírito da GPL. O espírito é o respeito às 4 liberdades. Restringir artificialmente a possibilidade de modificar o software e executar a versão modificada é um desrespeito às liberdades, portanto viola o espírito da licença. > GPLv3, de fato, está dizendo que, se o hardware tiver algum mecanismo de > proteção contra códigos espúrios, o hardware rejeitará o software. Em > muitos casos, isto é uma medida de *segurança* contra crackers. E se o cracker for o próprio fabricante do equipamento, tentando impor novas restrições ao que se pode fazer usando o equipamento que eu comprei dele? Não posso me defender? > Se de um lado GPLv3 *tenta* evitar DRM BZZT, errado. Ela não tenta evitar DRM coisa nenhuma. Ela apenas exige o respeito às liberdades no que tange ao software licenciado sob ela. Isso implica evitar restrições à modificação, entre elas o uso de legislação abusiva e medidas técnicas para desrespeitar as liberdades que, pela letra da licença, devem ser respeitadas. > por outro, mata uma série de ferramentas de segurança. Segurança é sempre de alguém contra alguém. De que segurança você está falando? > Note que, para fugir das restrições anti-DRM da GPLv3 é tão simples como > não vender equipamentos, mas, ao invés, alugá-los. Se a Tivo mudar seu > modelo de negócio para locação de equipamentos + serviços, ela atenderá > GPLv3. BZZZT. Há precedentes legais pelo menos nos EUA que tratam aluguel de computador com software como distribuição também. > Na prática, cairia a zero. Nenhum cliente de hardware embarcado > aceitaria um equipamento que não tivesse proteção contra códigos > indesejados, fabricados por terceiros. BZZT. Tenho um roteador wireless que, no Brasil, é comercializado com firmware fabricados por terceiros no Brasil. Usando Linux (o kernel), inclusive. > O cliente quer, sim, garantias de > que o produto que adquiriu tenha proteções de segurança, que proteja o > usuário e que tenha garantias. De novo, onde isso conflita com a *possibilidade* de o cliente querer adicionar suas próprias proteções, modificações, etc? Quem fizer questão de deixar tudo como está, pode. Quem quiser modificar, também deve poder. E se a modificação causar estragos, responde por eles quem a fez. Da mesma forma que o fabricante do meu carro não responde se eu atropelar alguém porque dirigia distraído. Ou se eu trocasse as rodas do carro e isso tornasse o carro muitíssimo mais propenso a capotar. Eu mexi, eu arco com a responsabilidade e as conseqüências dos meus atos. > Na prática, a empresa que compra aviões/equipamentos medicos/roteadores > *exigem* dos seus fornecedores as assinaturas digitais e demais medidas > de proteção contra estes riscos, para sua proteção e para obediência a > normas internacionais voltadas para a minimização do risco do negócio, > tais como o Acordo de Basileia 2, o Ato de Sarbanes-Oxley, e outros. Isso de forma alguma as impediria de formar um consórcio para menter o código caso o fornecedor original saísse do mercado ou passasse a oferecer um serviço porco. > Como você garantiria que o software não foi violado no meio do caminho? > As chaves existem para proteção do usuário. Há dois casos completamente distintos de uso de chaves. Um é o uso de assinaturas para autenticar a origem. Nesse caso, se o usuário pode decidir se quer aceitar o software cuja assinatura não bate, e isso não faz qualquer outra diferença com relação à possibilidade de instalar ou usar o software, pode-se entender que a assinatura é um mero agregado. Outro é o uso de assinaturas para impedir a execução de versões modificadas. Nesse caso, o usuário pode não conseguir instalar o software, ou não conseguir executá-lo da mesma forma que o original o faria, mesmo que tenha partido dos mesmíssimos fontes, usando as mesmíssimas ferramentas para gerar o executável. A diferença é a assinatura, e é uma diferença funcional, pois altera o comportamento do programa. Portanto, a chave, os scripts e os programas necessários para gerar a assinatura a partir da chave e do executável são parte da definição de código fonte correspondente e precisam ser distribuídas. Isso já está na GPLv2, embora não esteja claro para todo mundo, daí o esclarecimento na GPLv3. -- 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
