[OLPC Brasil] Especificação dos laptops educacionais do pregão 59/2007?

[Jaime Balbino]

Repassem por favor para as listas na qual não sou assinante, (como a PSL)

Em 10/01/08, Alexandre Oliva<lxoliva at fsfla.org> escreveu:
> Não vejo como argumentar que plugins e firmwares "instalados no
> equipamento" não se enquadrem nessa definição, sendo assim não vejo
> como possam escapar à cláusula 4.8 do edital:
>
> Até que dá pra engolir essa possibilidade, mas "fornecer códigos
> fontes" e "repasse tecnológico de toda a solução" não deixam muita
> margem a escape ao significado real de Software Livre.

Num mundo perfeito eu concordo com você, mas a burocracia não costuma
"saber de cor" (e muito menos pesquisar) os detalhes fundamentais que
lhe são pertinentes. Vide como exemplo o próprio fato do pregoeiro do
presente leilão não ter lido (ou ter sido informado) que o Diário
Oficial já havia liberado de carga tributária federal, estadual e
municipal os laptops. Pelas pequenas contradições aparentes do edital
eu deduzo que qualquer definição oficial de "software livre" ou está
mal escrita ou não tenha sido consultada.

Um significa mais genérico de "software livre" compatível com a FSL eu
até acho que eles tenham, mas é nos detalhes que a coisa desanda (no
caso, quando se fala em plugins e flash principalmente).

> Não seria o caso, da mesma maneira, de informar os fiscais e agentes
> decisórios a respeito dos diversos pontos em que concorrentes que
> alegam atender ao edital não o fazem?  Não só nas dependências
> monopolísticas mais óbvias, como do sistema operacional e dos
> aplicativos mais visíveis, mas também de plugins, drivers, firmwares
> de placas de rede sem fio, microcódigo do processador e até o projeto
> do hardware, que, se pode argumentar, está contemplado no mesmo item
> 4.8: "repasse tecnológico de toda a solução".

Este é que é o ponto chave da questão burocrática. Como o governo não
define claramente o que deseja e dá várias brejas, cabe somente o
artifício da denúncia para enquadrar corretamente as suas definições e
superar os buracos e contradições. Isto é: se a burocracia é
ineficiente, cabe ao cidadão correr atrás para fazer valer a intenção
da licitação - e não "a letra" do edital.
>
> > O Flash e o Java aparecem como elementos externos ao sistema
> > operacional e aplicativos;
>
> Não entendo a motivação por detrás do silogismo.  Que importa se estão
> no sistema operacional ou no aplicativo?  O edital fala "sistema
> operacional e demais softwares instalados no equipamento".  plugins
> por acaso não atendem à definição de software na lei brasileira ou, se
> preferir, ao significado do dicionário?  Pode querer dizer que são uma
> classe específica de software, posso concordar com isso, mas esse
> argumento não ajuda em nada a excluir essa classe das exigências de
> 4.8 do edital.

Concordo com todas as suas colocações, mas lembro que estava fazendo o
jogo da lógica do inimigo, quer dizer, do cara não-compentente em SL
que escreveu o edital. Pelo que está escrito e pela contradição
imposta (nas exigências técnicas e nos exemplos de sites) dá para
deduzir como esse cara pensou, e foi isso que eu fiz. Seus argumentos
estão corretos e concordo com eles, mas não parece ser essa a linha de
pensamento que a organização seguiu.

> > Apesar do edital não exigir padrões proprietários (apesar de "indicar"
> > a compatibilidade com Flash e Java) ele parece preocupado com o legado
> > de conteúdos educacionais em diversos formatos. E o fato deste
> > conteúdo estar em Flash, MP3, entre outros, escreve uma "cláusula
> > oculta" no edital que termina por exigir essa compatibilidade sem
> > explicitá-la.
>
> Sinto um cheiro esquisito aí, mas não se deve atribuir à malícia o que
> pode ser explicado por ignorância, né? :-)

Neste ponto eu chego a imaginar uma briga de bastidores para não
incluir cláusulas que deixassem explícita a compatibilidade com
padrões não-livres, ao mesmo tempo que outro grupo queria exigir
compatibilidade com projetos já existentes. É uma coisa que realmente
acontece em política, e não tem nada a ver com ingenuidade...

> Excelente!  Obrigado por fazer o teste.  Eu só ontem consegui colocar
> o software do OLPC pra rodar (ainda de forma meio precária) no laptop
> da minha filha de menos de 4 anos.  Ela está adorando!
>
> Estou pra publicar a receita de que usei pra fazer a instalação sem
> substituir o GNU/Linux que ela já se acostumou a usar.

Há agora um CD live com o software do XO para PC. Não testei ainda,
mas parece melhor e mais fácil que outras opções. Procure no buscador
do wiki do projeto.

>
> > Pelo que foi dito acima, acredito que a distribuição que incluir o
> > plugin Flash da Adobe NÃO será desclassificada sob o argumento de que
> > este não é software livre/código aberto.
>
> E agora, que fica claro que seu argumento estava baseado numa leitura
> incorreta do requisito do edital, você ainda acha isso?

Eu acho que se o plugin livre não ler com 100% de precisão os sites
indicados, o plugin proprietário só será desclassificado mediante
denúncia de outro concorrente prejudicado E QUE também tenha um plugin
livre que faça a leitura corretamente. A homologação é um processo de
negociação e o interesse maior é garantir a finalização de acordo com
o interesse público, para isso pode ser necessário justificar alguns
descumprimentos de cláusulas alegando que o mercado (os concorrentes)
não ofereceram solução completamente à altura do edital.

Eu pessoalmente concordo que firmwares e plugins devem se enquadrar
como software livre, mas sei também que não há explicitamente
exigência de uma BIOS livre e que os plugins livres não rodam com
precisão os sites do edital (o OLPC aidna se sai melhor com sua versão
do Gnash, em comparação com o Ubuntu, pelo menos). Eu sofro desse
dilema, pelo qual passam muitos desenvolvedores e envolvidos com SL,
estou envolvido em projetos com o Red5 e OpenLazlo para
video-conferência e não tenho como sugerir um plugin flash que não
seja o proprietário para meus clientes. Como não programo em linguagem
de baixo nível e sei que os plugins livres simplesmente não possuem o
código necessário e que precisaria desenvolvê-lo, fico no dilema de
criar servidores livres para operarem obrigatoriamente em sistemas
não-livres.
>
> Qual o raciocínio pra dizer que o firmware não seria software?

Eu não disse que o firmware não é software, mas que não há histórico
de se exigir firmwares livres. O OpenFirmware é um projeto recente e
até há alguns anos atrás exigir isso sem abrir excessões (para a BIOS
e placas de vídeo 3D, por exemplo) seria mesmo impossível.
>
> Ou só oferecem os fontes para seus clientes diretos?  Isso estaria
> perfeitamente de acordo com licenças de software livre, inclusive as
> copyleft.  Software Livre não significa ter que entregar o código para
> qualquer um que peça, ou ter de publicá-lo, significa apenas que os
> usuários tenham as 4 liberdades respeitadas, e isso inclui a
> necessidade de que eles, os usuários, tenham acesso ao código fonte.
> Mas se você não tem acesso ao software, não é usuário, portanto não
> faz sentido sequer especular se você tem as 4 liberdades respeitadas.

Pera aí! Tudo bem que você é o especialista aqui, mas pelo que sei os
fontes devem estar disponíveis de alguma forma: seja sendo
distribuídos junto com o software compilado; seja em um repositório
on-line; seja mediante envio direto, com pagamento do transporte e da
mídia. Eu não tenho notícia de que alguma distribuição nacional tenha
intencionalmente apagado as informações de autoria e licença do código
fonte.

Você tem informações de alguma outra distribuição nacional que siga os
procedimentos da Insgine GNU/Linux? Por favor, esclareça como os
fontes devem ser distribuídos quando em GPL 2.x e 3, fiquei com dúvida
agora.

Um abraço,
Jaime Balbino