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
PSL-Brasil@listas.softwarelivre.org
http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
Regras da lista:
http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil

Responder a