[DE | EN | FR | JA | ES | KO | PT ]
Bem-vindo a mais um número da Admirável Mundo GNU. Neste mês, o pano de fundo filosófico é central: a questão do Software Livre comercial.

Mas antes disso, vou apresentar alguns projetos.

TuxFamily org

A idéia de Julien Ducros é que as comunidades européia e africana também necessitam de um serviço como este em seus continentes. É isto que o projeto francês TuxFamily quer oferecer.

O próprio TuxFamily é claramente voltado ao Software Livre. O software usado para hospedagem de páginas, ou hosting, o vhffs é publicado sob a GPL, ou Licença Geral Pública GNU. Além disso, a TuxFamily aceita apenas projetos que se qualifiquem como Software Livre.

Os projetos que estejam procurando uma nova casa podem pensar em se juntar à TuxFamily.

Servidor de CVS com SSH sob chroot: modo de usar

Na página Web Community da Idealx [7] há vários módulos e documentos interessantes sobre Software Livre. Eles resolvem vários problemas padrão, e é claro que tudo está disponível sob a GPL, Licença Pública Geral GNU; ou sob a FDL, ou Licença de Documentação Livre GNU.

Entre os pacotes está um módulo Python que permite a criação de calendários através de scripts de CGI. Pode também ser encontrado um script para notificação de CVS que automatiza as ações durante o check-in de novas versões. E ainda há uma ligação, ou binding de Python para Erlang.

Um documento significativamente interessante [8] é um howto, ou "como fazer", escrito por Olivier Berger e Olivier Tharan, que trata da configuração de um servidor de CVS muito seguro e bem isolado.

Os programadores normalmente conhecem as vantagens de um Concurrent Version System (CVS), ou "Sistema para Versões Concorrentes" [9], mas o CVS em particular é uma ferramenta que muitas pessoas subestimam. Por isto, darei uma breve introdução.

Como a maioria das pessoas já deve saber, o software é normalmente escrito na forma de código fonte. O código fonte é melhorado por um ou mais autores durante o processo de desenvolvimento. Quando isto é feito, surge o problema da coordenação de vários desenvolvedores, pois cada desenvolvedor normalmente trabalha em sua máquina pessoal e ali faz alterações. Isto significa que o código fonte muitas vezes é mudado simultaneamente em vários lugares.

Para resolver este problema, o CVS (como outros sistemas de controle de versões), tem uma área central de armazenamento, o chamado repositório. Cada desenvolvedor se comunica diretamente com o repositório, recebendo dele as atualizações feitas por outros, ou submetendo as próprias mudanças. É claro que pode ocorrer que dois autores alterem a mesma parte, mas as diferentes formas de resolver ou evitar tais conflitos não são importantes no momento.

O importante é que o repositório de CVS não contém apenas a versão atual: ele também guarda todas alterações. Deste modo o processo de desenvolvimento pode ser acompanhado passo a passo. Também é possível retroceder a versões anteriores, para bifurcar um projeto e ter diferentes processos de desenvolvimento executados em paralelo, com a opção de unir a todos mais adiante.

Isto não é relevante apenas para desenvolvedores. Considerando-se o fato de que o código fonte é, na maioria dos casos, composto de simples arquivos ASCII, é imediatamente óbvio que isto pode ser usado para qualquer tipo de dados, principalmente se eles puderem ser expressos através de simples arquivos de textos.

Sites na Web, documentos, arquivos de e-mail e muitos outros tipos de dados são áreas perfeitas para o uso do CVS.

O ponto nevrálgico de um servidor de CVS são seus direitos de acesso. Existem várias possibilidades para eles, com diferentes níveis de segurança. Na maioria dos casos, uma conta em servidor de CVS requer uma conta no sistema; e alguns métodos de autenticação transmitem senhas em texto simples; que por isso podem ser facilmente lidas por outros.

Mesmo quando seja evitado pelo uso de SSH, muitas vezes não é desejável dar a todos usuários de CVS o pleno acesso ao sistema.

O Howto [8] mencionado acima descreve muito bem como configurar vários servidores de CVS em paralelo em um servidor, garantindo aos usuários os necessários direitos de acesso a seus repositórios específicos. Ele deve permitir que a maioria dos usuários intermediários possa instalar um servidor seguro de CVS em suas máquinas, para obter as vantagens do CVS mencionadas acima.

AutoGen

Um exemplo clássico disso são laços, ou loops, de análise da linha de comando. No pior dos casos, o texto é repetido através da cópia e colagem de cada opção para colocar os valores em alguma área onde outras funções que vão precisar deles possam encontrá-los. Uma vez que este é um problema muito comum, AutoGen tem um molde, ou template, chamado AutoOpts para resolvê-lo.

AutoGen tem de fato certa similaridade com m4 [11], o processador de macros tradicional do Unix. Mas ele é superior ao m4 em muitos aspectos, tais como uma forma simplificada de se acrescentar novos parâmetros a funções. Além disso, AutoGen suporta coleções aninhadas de valores. Devido a isto, Gary V. Vaughan, o desenvolvedor mais ativo do AutoGen além de Bruce Korb, gostaria de ver autoconf usando AutoGen em vez de m4.

De acordo com Bruce, uma das melhores características do AutoGen é a clara separação de moldes e definições, pois isto faz com que os moldes sejam muito mais flexíveis. Além disso, todos dados são endereçados por nomes, não por posições, o que permite reestruturar e e reordenar arquivos. Além disso, as definições podem se tornar obsoletas sem que seja necessário alterar arquivos antigos, o que aumenta a compatibilidade. E, é claro que todas definições podem ser aninhadas.

Graças ao uso de variáveis para indicar as localizações para substituição de texto, é possível determinar, através de palavras-chave, partes do texto que serão deixadas de fora ou nas quais as substituições serão realizadas repetidas vezes. AutoGen também tem formas muito melhores de controlar a saída que o preprocessador do C.

Quando perguntado sobre as desvantagens do AutoGen, Bruce Korb disse que ele é muito pouco conhecido, e que é também muito fácil criar moldes que pareçam hieróglifos. A maior limitação do AutoGen é atualmente a avaliação estática de definições, mas planeja-se torná-la dinâmica nas próximas versões.

Apesar disso, AutoGen está basicamente finalizado, e por isso a maior necessidade, para aumentar a portabilidade, está no feedback dos usuários. Até aqui, sabe-se que ele pode ser executado em GNU/Linux, BSD, HPUX, SCO OpenServer, Solaris, e, desde que o CygWin tenha sido instalado, também no Windows NT.

Apesar do próprio AutoGen ser licenciado sob a GPL (Licença Geral Pública GNU), alguns de seus acessórios estão sob a LGPL, a licença do FreeBSD, ou sob domínio público.

Software Livre e Comercialização

Para que a questão sob comércio e a interação com a interação com a indústria possa ser entendida, é mandatório examinar a definição de Software Livre. O primeiro passo é sempre entender que a palavra "Livre" em Software Livre tem a ver com liberdade, não com preço.

Mas o que a liberdade tem a ver com isto? A definição mais precisa de Software Livre são as quatro liberdades da Free Software Foundation, ou "Fundação para o Software Livre". As Debian Free Software Guidelines (DFSG) [13], ou "Diretrizes Debian para o Software Livre", foram derivadas delas, e por sua vez deram a base para a Open Source Definition (OSD) [14], ou "Definição do Código Aberto". Tecnicamente, todas três definições foram criadas para descrever as mesmas licenças. Contudo, como as quatro liberdades são a definição mais compacta, falarei apenas sobre elas.

A primeira liberdade é poder usar um programa para qualquer finalidade. Qualquer forma de restrição do uso significaria que um programa não se qualifica como software livre.

A segunda liberdade permite estudar um programa para aprender como ele funciona, e alterá-lo de acordo com as próprias necessidades. O acesso ao código fonte é uma pré-condição para isto.

A Liberdade no. 3 permite fazer cópias e distribuí-las, enquanto que a Liberdade no. 4 é a soma das Liberdades 2 e 3. Ela afirma que se deve ter a liberdade de passar adiante as melhorias para beneficiar a outros. Assim como a Liberdade 2, esta requer acesso ao código fonte.

É importante saber que a liberdade de fazer algo é também a liberdade de não fazê-lo -- o que se aplica especialmente às Liberdades 2, 3 e 4. Não há obrigação de copiar e modificar um programa, e também não há obrigação de distribuí-lo. De fato, a exigência de tornar públicas as alterações foi o que fez com que a Apple Public Source License (APSL), ou "Licença Apple de Fonte Público", não se qualificasse como uma licença de Software Livre.

Um software é Software Livre ou não de acordo com sua licença. Entre todas licenças de Software Livre [15], a Licença Geral Pública GNU (GPL) é a mais usada. Além dela, a Licença Pública Menos Geral (LGPL), uma variação da GPL, e a Licença FreeBSD têm a maior importância prática.

E quanto à comercialização? O Software Livre deliberadamente não faz diferença entre o uso comercial e o não comercial. Uma limitação do propósito comercial violaria a Liberdade no. 1 - por isto o Software Livre é sempre também comercial. Combinado com o conhecimento de que não há exigências para distribui-lo, torna-se claro que o Software Livre pode também ser vendido.

Agora deve estar claro que o Software Livre pode ser comercial, apesar de que não tenha de sê-lo.

O modelo comercial atualmente predominante para o software na indústria é o proprietário, no qual o preço é artificialmente elevado pela limitação dessas propriedades. Assim, uma companhia pode ser tentada a retirar as liberdades para aumentar sua receita em um curto intervalo de tempo.

Isto acontece de duas formas. As licenças como a FreeBSD se baseiam na premissa de que ninguém colocaria seus interesses pessoais acima dos interesses do público. Eles deliberadamente permitem que seja feita uma nova licença, desta vez proprietária.

As licenças GNU têm uma proteção contra tornar o software proprietário para evitar isso. Se você basear diretamente seu sucesso no trabalho de outros, não pode distribuir esse resultado sob uma licença proprietária.

A única forma de criar programas que retornem ao esquema proprietário, neste caso é escrever módulos que sejam tecnicamente isolados do programa original, o que requer trabalho adicional e nem sempre é possível.

Em ambos casos, o produto final proprietarizado é vendido normalmente como software de "valor agregado", com o objetivo de convencer o usuário a abdicar de suas liberdades. Isto pode ocorrer comercialmente ou não.

Assim, a despeito da proteção oferecida pela GPL, no final de contas, apenas a atenção dos usuários pode impedir o retorno ao modelo proprietário.

Para resumir: sem dúvida existe um Software Livre comercial do mesmo modo que existe um Software Livre não comercial. É uma questão de escolha. Em vez de se distrair com essa questão, devemos em vez disso não perder o foco sobre a liberdade, pois este é o fundamento de todo movimento.

por hoje chega

Como de hábito, solicito que enviem comentários, perguntas, idéias, inspirações e apresentações de projeto para o endereço habitual [1].