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

Sexta Novembro 20 21:17:20 BRST 2015

Vou responder à publicação principal apenas por entender que esta
resposta deve ser lida pelos demais.

Penso que houve um ruído de comunicação por aqui, visto que a maioria
dos leitores parece estar em prol da decisão da Canonical.

A liberdade 1 (de estudar, e modificar o programa) não obriga o usuário
a ter "um mestre" ao qual deve submeter suas modificações. Na verdade,
em várias das apresentações onde se define o que é software livre,
deixa-se bem claro que o usuário do software livre tem o direito de
exercer QUALQUER UMA das liberdades essenciais "quando ele quiser".
Sendo assim, qualquer coisa que impeça o usuário de exercer suas
liberdades naquele EXATO momento não é caracterizado como "quando ele
quiser".

Vale lembrar todavia que, o movimento filosófico do software livre NÃO é
contra as trademarks. Na verdade, até mesmo o projeto GNU faz uso
delas[1]. O problema, como já foi descrito no artigo referenciado por
Anahuac, esta na forma com a qual a trademark interage com o resultado
do projeto em si e sob quais situações se aplica a restrição relacionada
à trademark.

Compreendendo e interpretando o que Matthew Garrett escreveu na
referência feita por Anahuac: A política de "propriedade intelectual"
(sic Canonical) da Canonical não deixa claro quando os nomes e logotipos
sob proteção de trademark devem ser removidos, ela simplesmente obriga
que eles sejam removidos em todos os casos caso seja feita uma simples
modificação em um dos diversos pacotes do sistema, E CASO o nome do
sistema resultante NÃO SEJA ALTERADO (permanecendo com o nome que esteja
sob tais trademarks mesmo após as modificações). Isto inclui os nomes e
logotipos sob trademark que estejam fortemente codificados dentro de um
programa/pacote, ou que contenham pastas e arquivos relacionados a estes
nomes, ou que tenham marcas de versão que contenham estes nomes, por
exemplo:

* "Tem a certeza que deseja abandonar este jogo e voltar ao Unix?".
(OpenTTD 1.5.2, rodando no GNU+Linux-libre Trisquel 7.0).

* Botão "Quit to Windows". (Seven Kingdoms: Ancient Adversaries, rodando
no GNU+Linux-libre Trisquel 7.0).

* Pacote "apt" (versões 1.0.1ubuntu2.6+7.0trisquel3 e
1.0.1ubuntu2.10+7.0trisquel3), disponível no repositório oficial do
GNU+Linux-libre Trisquel[2][3].

* Pacotes como "fonts-ubuntu-title".

Note que esta obrigatoriedade de remover os nomes e logotipos que
estejam sob trademark não é nada prática pois, usando dos exemplos dados
(e supondo que em cada um deles o Trisquel assuma o nome do sistema
referenciado, como Unix, Windows, e Ubuntu): para cada nova versão de
todos os exemplos, seria necessário uma releitura do código fonte, da
documentação, e dos dados não funcionais a fim de encontrar os nomes e
logotipos sob trademark.

Assim como notado por Matthew Garrett, o cenário muda nos casos em que
todas as referências aos nomes e logotipos sob trademark se encontram em
pacotes específicos (como no caso do projeto Fedora, também mencionado
por Matthew Garrett, que NÃO É software livre, mas que deixa bem claro
que, caso o usuário altere algo no sistema, a ÚNICA coisa que ele terá a
obrigação de alterar será aqueles pacotes específicos).

Como um adendo pessoal, ACHO que a situação também pode mudar tomando
uma das seguintes rotas:

* Caso seja ensinado aos programadores a importância de se usar o termo
"sistema operacional" ao invés de termos como "Windows", "GNU+Linux",
"Unix", "Linux", ou até mesmo "GNU+Linux", ao escreverem suas mensagens
de interação ao usuário ou ao nomearem seus pacotes. Ensinando-os também
a evitarem a inserção dos logotipos envolvidos em seus projetos.

* Caso seja providenciado aos programadores uma forma independente de
sistema operacional para saber em que sistema se encontram. Por exemplo,
ao menos no GNU Bash, existe uma variável chamada OSTYPE, que resulta na
frase "linux-gnu", porém, não se sabe se sistemas como Windows, Unix,
Mac OS, Android, e Replicant possuem esta variável, e não se sabe se ela
tem comportamento similar. Ademais, o Dash (geralmente usado como
substituto do shell do Unix, sh) não tem a variável OSTYPE definida, e
assim, retorna uma frase nula.

Adicionalmente, ACHO que o problema dos nomes nas versões dos pacotes
também pode ser resolvido tomando uma das seguintes rotas:

* Usando marcações com sufixo "-adapt" (de "adaptado(a)", cuja
abreviatura creio ser independente de idioma) nas versões dos pacotes
adaptados, e "-orig" (de "original", que creio também não variar muito
de idioma para idioma) para os casos em que o projeto originário já
tenha modificado o pacote (considerando que o responsável usou o sufixo
"-adapt"). No último caso, uma simples tarefa de substituição do sufixo
"-adapt" pelo "-orig" resolveria o problema caso alguém quisesse
redistribuir suas modificações junto do projeto original, independente
do sistema operacional. Já aquelas versões sem os sufixos especiais
seriam as providenciadas realmente pelos desenvolvedores do projeto
específico.

* Usando um sistema de gerenciamento de pacotes funcional com
compilações reproduzíveis, como o GNU Guix, e a distribuição
GNU+Linux-libre GuixSD, que além de serem software livre[4][5], resolve
vários outros problemas como:

** Pesadelos com dependências. Apenas como um exemplo FICTÍCIO:
situações onde um programa a ser instalado dependem da versão 3 do
Python, sendo que o sistema operacional inteiro depende da versão 2, e
que a versão 3 conflita com a versão 2.

** Bugs/falhas reproduzíveis apenas em alguns computadores, mesmo que os
computadores de teste apresentem EXATAMENTE as mesmas especificações
técnicas. O que é geralmente causado por uma alteração no ambiente de
execução do programa[6][7].

** "Bundling" de dados (fugiu-me o nome da palavra em português). Onde o
pacote possui vários conjuntos de dados dentro do pacote apenas para
satisfazer as dependências do programa principal do pacote. Seria como
colocar a interface GTK dentro do pacote do LibreOffice. O "bundling"
pode causar problemas futuros com a atualização de toda a estrutura[8].
O "bundling" é equiparado por ALGUNS desenvolvedores como uma forma de
dizer "vou copiar, e depois dizer adeus à comunidade do GTK" (se
levarmos em consideração o exemplo FICTÍCIO do GTK com o
LibreOffice)[9]. O ideal seria uma participação no projeto principal[10].

REFERÊNCIAS

[1] https://www.gnu.org/graphics/heckert_gnu.en.html#license

[2]
http://archive.trisquel.info/trisquel/pool/main/a/apt/apt_1.0.1ubuntu2.6+7.0trisquel3.tar.gz

[3]
http://archive.trisquel.info/trisquel/pool/main/a/apt/apt_1.0.1ubuntu2.10+7.0trisquel3.tar.gz

[4] https://directory.fsf.org/wiki/Guix

[5] https://gnu.org/distros/free-distros.html.en

[6] https://gnunet.org/guix2015video

[7] https://savannah.gnu.org/forum/forum.php?forum_id=8407

[8]
https://wingolog.org/archives/2015/11/09/embracing-conways-law#da87979ab71a149b7cea5f738f130101f7cff23c

[9]
https://wingolog.org/archives/2015/11/09/embracing-conways-law#dd28fd5e853813a7732de828fca5655b3a6e8951

[10] https://wingolog.org/archives/2015/11/09/embracing-conways-law

Respeitosamente, Adonay.
Tenham um bom dia.