[PSL-Brasil] If it's not practical to redistribute free software, it's not free software in practice

[Alexandre Oliva]

On Nov 21, 2015, fabianne balvedi <fabs em estudiolivre.org> wrote:

> facilitar o fork tampouco está na definição do que seja SL

Não é só isso.  O problema era ainda pior, como você pode ver, se
quiser, nos artigos que acabo de citar em mensagem ao Patola, e noutras
citações a partir deles.  Parte foi corrigida, mas parte continua
criando empecilhos que vão muito além do "não facilitar" e chegam ao
"tornar praticamente inviável", com "praticamente" não no sentido de
quase, mas de efetivamente.  Um exemplo de que gosto é que respeitar a
liberdade de ir e vir não exige dar carona pra onde o sujeito quiser, é
só não colocar barreiras no caminho que visem dificultar o movimento.

É fácil de ver que, às vezes, respeitar a liberdade pode exigir algum
esforço mais que a mera inação.  Tipo assim, se não entreguei o código
fonte junto com o binário e agora não tenho mais pra entregar nem se
quisesse, o software não é Livre.  Deixar de entregar os fontes é
inação, mas é suficiente para constituir desrespeito à liberdade, se
houver recusa de entregá-los quando solicitados.

Da mesma forma, se não bastasse a exigência de recompilar os binários
não copyleft para ter permissão para distribuí-los, a exigência de
remover *todas* as marcas do Ubuntu de *todos* os pacotes onde eles
possam aparecer, na forma textual ou de logotipos, mesmo após
solicitação de esclarecimento se é isso mesmo, beira o "não deixo, não
deixo mesmo e se você tentar, sua vida será um inferno!"

Convenhamos, a defesa da marca não precisa ser feita desse jeito.  Temos
exemplos disso na comunidade.  Por que dificultar as coisas?  Por que
fazer algo a outrem que geraria grande insatisfação caso feito a nós
mesmos? (imagine se o Debian fizesse a mesma exigência!)

> Ambas as partes não querem risco jurídico

Se fosse só isso, o problema já estaria resolvido.  O suposto risco
jurídico é uma distração pra gerar confusão, porque a solução para esse
risco é bem conhecida.

> sobre isso dificultar ao EXTREMO, sério mesmo?

Sério mesmo.  O Matt está longe de ser um sujeito incompetente na
técnica, seja a programação de baixo nível, seja na automatização de
tarefas mecânicas, seja no encontrar soluções geniais para problemas
genuinamente complicados.  E ele queria basear um trabalho seu no
Ubuntu, e decidiu não fazer isso porque não dava pra fazer na prática e
o risco jurídico seria grande demais.  E não é o único exemplo: no
artigo de julho, há referência nos comentários a outras empresas que
tomaram medidas ainda mais cuidadosas para se proteger do risco jurídico
que a Canonical cria, ao que tudo indica justamente para inviabilizar
distros derivadas.  Imagine se o Debian fizesse isso com ela!

> uma vez que códigos bagunçados e não comentados também
> dificultam enormemente o fork e nunca vi alguém reclamar que
> eles eram gatos disfarçados.

Eu já vi Alan Cox reclamando do código do driver nv do X, a ponto de
dizer que não era Software Livre por causa justamente da falta de
comentários e da obscuridade do código.  Talvez ele não tenha razão, mas
alguém já reclamou, sim ;-)

Eu mesmo vivo me deparando com longas sequências de números que são
introduzidas em cada nova versão do Linux, e que preciso tentar
adivinhar se são código objeto ou se são só longas sequências de
inicialização e configuração sem comentários, ou porque o driver foi
feito no escuro, sem documentação, ou porque foi feito com documentação
sob NDA.

Dificultam a adaptação, sim, mas não é muito diferente de se escrever o
programa numa linguagem que ninguém mais conhece.  Falta informação,
sim, mas não chega a ser culpa do desenvolvedor que terceiros não a
tenham.  Isso é mais óbvio no caso do driver feito no escuro, mas a
imposição do NDA não é uma escolha do desenvolvedor (aceitá-lo é).

Já se alguém que criou o dispositivo escreve o código com trechos
obscuros e sem documentação, e o divulga como se fosse Software Livre,
talvez houvesse razão para considerá-lo não-Livre, pois há uma certa
privação de código fonte aí.  Mas, na prática, o código fonte não seria
diferente do caso anterior, então fica complicado argumentar que aquele
seja Livre e este não.  Talvez a linha não esteja traçada no lugar
certo.

Da mesma forma, o uso de marcas em Software Livre normalmente não é um
problema, pois não chegam a impedir o gozo das liberdades mesmo que
precisem ser removidos, mas em alguns casos, pode chegar a fazê-lo.  Meu
exemplo favorito é de um fonte de caracteres contendo logotipos.
Modificá-lo para remover os logotipos faz com que deixem de desempenhar
a função desejada; seria como um software privativo, em forma binária,
que só funciona se acompanhado de arquivo com o logo, e com exigência de
remoção do logo para redistribuição.  Com essa modificação, ele deixa de
cumprir a função original.

Outro caso, especulado há muitos anos, seria alguém colocar tantas
marcas em tantos lugares obscuros de um programa Livre que, ao exigir a
remoção da marca para redistribuição ou adaptação, tornar-se-lo-ia
(perdão :-) privativo.  Parece que a Canonical tomou isso como manual de
instruções, ou resolveu testar os limites, ou algo assim.  Fato é que
está, sem motivo (porque a questão de defesa de marcas tem solução
conhecida), criando dificuldades e riscos jurídicos para quem ouse
querer fazer com o Ubuntu o que ela fez com o Debian.  Não conheço linha
científica de ética em que essa assimetria seja considerada razoável.

> me parece meio óbvio que a estratégia do Mattew de trazer o assunto a
> público dessa forma, acusando deliberadamente a Canonical desse jeito,
> iria surtir algum efeito no sentido de faze-la finalmente facilitar o
> fork.

Você já tinha lido os artigos de julho que citei pro Patola?  Pelo que
escreveu acima, parece que não tinha conhecimento ou lembrança do teor
deles.  Quer refrasear?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer