[Legales] Ação de Inconstitucionalidadecontra lei do software livre no RS

[Alexandre Oliva]

On May  3, 2006, "Omar Kaminski" <omar en kaminski.adv.br> wrote:

> ----- Original Message ----- 
> From: "Federico Heinz" <fheinz en vialibre.org.ar>

> Por cierto, tenemos un problema serio: la ley de RS está mal redactada,
> su definición de Software Libre es deficiente, y por lo tanto contradice
> nuestros propios argumentos (entiendo, por ejemplo, que exige que el
> software sea gratuito...). En este sentido, me temo que lo mejor a lo
> que podemos aspirar es a que la corte declare que la ley efectivamente
> está mal, pero que eso se debe a su mala redacción, y no a que ese tipo
> de legislación esté fundamentalmente mal por su enfoque.

OK> Lembro que teríamos que sustentar a *constitucionalidade* de
> alguns ou de todos os dispositivos da lei. Perdê-la toda, ao meu ver,
> é uma derrota e tanto para quem ainda tem pouco.

Como tenho manifestado na psl-brasil, penso que, se fôssemos nos
posicionar, teríamos de nos posicionar contra a lei, pois ela fere
fatalmente a definição de software livre que tanto nos é cara.  Além
do quê, não vejo que a FSFLA possa se posicionar em relação à
constitucionalidade da lei.  É um tema completamente alheio ao nosso
conhecimento e compreensão.

Pela mensagem do Pedro Rezende à PSL-Brasil, copiada para os
conselheiros da FSFLA para pô-los a par de sua posição, revisei minha
posição, pois ele expôs o risco de, se não intervirmos no sentido de
contestar a definição errada de software livre presente na lei e usada
nos argumentos contra ela, corremos o risco de essa definição errada
prevalecer, incontestada, minando nossos esforços de divulgar a versão
correta, criando um perigoso precedente.

Parece-me agora que devemos, portanto, nos posicionar sim, mas não no
sentido de defender ou atacar a constitucionalidade da lei, como me
parecia que se pedia de nós, mas sim no sentido de defender a
definição correta de software livre, o que nos colocaria de fato
contra a lei (ainda que não a ponto de derrubá-la), mas também contra
os argumentos baseados na definição errada.

O resultado do julgamento pouco nos importa.  Nos dois casos, perdemos
um pouco e ganhamos um pouco:

- Se a lei for julgada inconstitucional, com base na exclusividade da
união para regular licitações, vários esforços similares (inclusive
com os mesmos erros) em instâncias estaduais e municipais serão
anulados, mas abre-se uma possibilidade de uma lei federal com a
definição correta.

- Se a lei for julgada constitucional, prevalecerá uma definição
errada de software livre, e a preferência manifestada na lei
continuará a recomendar o uso de software que não seja proprietário,
mas também que não seja por exemplo copyleft, colocando este e outros
tipos de software livre novamente em pé de igualdade, no que diz
respeito à preferência recomendada pela lei, com software
proprietário.  Teremos, porém, nos autos, uma argumentação sobre
melhores formas de redigir a definição, anulando argumentos colaterais
apresentados pelo outro amicus curiæ e até fornecendo uma linha guia
para revisão da lei e/ou para novas leis que busquem favorecer o
software livre.


Para enriquecer o debate, apresento aqui um rascunho de proposta que
enviei para psl-brasil ontem, numa discussão em que o advogado Pablo
Cerdeira se questionava se não seria melhor evitar o uso do termo
específico software livre nas leis, contratos, etc, concentrando-se,
ao contrário, em conceitos, ao invés de termos (se é que eu o entendi
direito :-)

Pablo e demais que já viram, fiz uma pequena revisão no primeiro
parágrafo, o restante está como já postei em psl-brasil

- Com base nos princípios da transparência, economicidade etc etc,
será dada preferência em licitações a software que ofereça todas as
seguintes permissões:

- permissão para executar o software para qualquer finalidade, em
quantos computadores e quando se desejar, sem ônus adicional,
garantindo que o erário público não seja subtraído a cada vez que se
fizer necessário usar o software num novo computador.

- permissão para estudar o software, e adaptá-lo às necessidades do
poder público e de seus cidadãos, sem ônus adicional, de modo a
garantir que o software seja auditável, para possibilitar a
verificação de que ele não tenha comportamento indevido, e que o
software possa ser modificado sem dependência exclusiva de um
fornecedor específico, que poderia se recusar a fazer as adaptações.
Para que essas permissões sejam gozadas em sua plenitude, é necessário
acesso ao código fonte completo do software (a forma preferível para
nele fazer modificações), portanto este deve estar disponível para o
poder público mesmo quando o software seja oferecido também na forma
de código objeto (qualquer forma distinta do código fonte completo).

- permissão para copiar e distribuir o software, da forma em que foi
recebido ou após sofrer adaptações, e para conceder aos receptores as
mesmas permissões de que trata este artigo, sem ônus adicional a
qualquer das partes, de modo a garantir que o poder público possa
reverter o fruto de seus investimentos a todos os seus cidadãos,
solicitar prestação de serviços sobre o software de fornecedores
diferentes dos que lhe ofereceram o software original, fomentar o
mercado de serviços relacionados ao software e oferecer transparência
plena a seus cidadãos no que diz respeito ao software.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}