Em Sex, 2006-10-27 às 19:50 -0300, Alexandre Oliva escreveu:
> On Oct 27, 2006, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
>
> > A licença GPLv3Draft2, pelo menos se olhada sob a ótica do Kernel,
> > restringe diversas liberdades importantes da GPLv2
>
> Liberdades para quem? Lembre que o foco da GPL é o usuário.
A v3 (draft 2) restringe ao usuário o uso de sistemas embarcados. O
fabricante de uma TV ou de um roteador está vendendo um produto, e não
um equipamento de uso geral ("computador"). Quem compra uma TV não está
interessado nos componentes internos que a fazem funcionar (sejam
hardware ou software), mas nas suas funcionalidades, sujeitas a
garantias do fornecedor. Ainda que utilizando componentes padrões de
mercado (memórias, chips, etc), todo fornecedor consciente adiciona
medidas de proteção contra violação do seu produto, especialmente se a
violação possa incorrer em riscos para a vida humana.
Obviamente se alguém quiser comprar uma televisão e substituir seus
componentes, assim o pode, assumindo, para si todos os riscos inerentes.
No entando, o fabricante também tem direito de tomar medidas para evitar
tais violações.
> > quanto ao uso de criptografia.
>
> 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.
>
> > 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.
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.
> > 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.
> 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.
>
> > 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.
>
> > 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".
> 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.
> Ou seja, pode fazer DRM, sim, mas não pode reclamar
> se alguém corrigir o bug que DRM representa.
>
> > Por exemplo, uma demanda válida de usuários de sistemas embutidos é não
> > ter o sistema operacional do seu dispositivo alterado por terceiros.
>
> 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.
Ou seja, para adicionar novas features, o usuário teria obrigatoriamente
que adquirir novo hardware.
> Esse é o
> espírito: todos os que obtêm o software têm as mesmas liberdades.
> > Eu não gostaria de ter, no meu telefone móvel, no meu roteador da
> > internet ou no transponder de um sistema de vôo de aeronaves, uma
> > eventual cópia não assinada do sistema em execução.
>
> 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.
> > 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*. 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.
>
> > 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.
> > Na prática, usar a GPLv3 com as restrições à criptografia impede seu
> > uso em sistemas embarcados.
>
> Você (e muitos outros) estão vendo pêlo em ovo.
>
> Não há oposição ao uso de chaves criptográficas em software livre.
>
> 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. Este conceito merece
uma consideração especial.
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.
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).
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.
Certamente algo que muitos desenvolvedores não gostariam é de ter seus
softwares rodando em armamentos (incluindo eu).
Pior ainda se o usuário do armamento tivesse a liberdade de alterar e
executar um novo software nesta arma, tornando-a ainda mais cruel.
Neste contexto, o uso em tais dispositivos estariam na categoria de
"abuso", do ponto de vista do desenvolvedor.
Provavelmente, as forças policiais não concordariam com o conceito de
"abuso", alegando que armas servem para proteger o cidadão. Para eles,
abuso seria deixar tal software ser utilizado por forças inimigas ou
pelo crime organizado.
Da mesma forma, um torcedor doente certamente consideraria "abuso" ter
seu software utilizado pela torcida do time adversário (ai se essa moda
pega!).
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.
Poder-se-iam pensar em diversos outros abusos a serem igualmente
condenados, tais como o uso de software livre para cometer crimes,
pedofilia, abusos sexuais, racismo, crime organizado, ou em hardware
utilizadoss para tortura, para pesquisas atômicas, para apoiar campanhas
de candidados do partido X, ...
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.
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. Estes
problemas são melhor endereçados por meio de pressões da sociedade,
junto a própria sociedade, à midia e aos poderes públicos constituídos,
nas esferas executivas, legislativas e judiciárias.
Especificamente no caso do DRM e patentes, de uma forma geral, estas
pressões já estão ocorrendo. Basta ver alguns fatos do cotidiano:
"compartilhamento" de músicas, redes p2p, quebra de patentes de
medicamentos, medicamentos genéricos, uso de software livre ao invés de
proprietários.
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.
Cheers,
Mauro.
_______________________________________________
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
