Entendendo a GPL

Muito se fala sobre a licença GPL, muitas vezes com intermináveis discussões sobre se uma determinada empresa, distribuição ou projeto está ou não respeitando os termos da licença.

É difícil superestimar a importância da GPL, pois ela é a licença usada não apenas no Kernel e a maioria dos softwares e bibliotecas que compõe as distribuições Linux, mas em um brutal número de softwares de código aberto, incluindo muitos programas para Windows e outras plataformas.

Apesar disso, poucas pessoas realmente entendem o significado dos termos da licença.

A licença GPL, pode ser resumida em 4 direitos básicos e uma obrigação:

1- Você tem o direito de usar o programa para qualquer fim. Não existe discriminação. Um exemplo é que ninguém pode impedir que um programa GPL seja usado numa clínica de aborto ou numa instalação militar, por exemplo.

2- Você tem o direito de tirar cópias do programa, distribuí-las ou até mesmo vendê-las a quem tiver interesse. Existe a possibilidade de ganhar algum dinheiro vendendo CDs gravados, por exemplo, mas como todo mundo pode fazer a mesma coisa, é preciso vender por um preço relativamente baixo, cobrando pelo trabalho de gravação e não pelo software em si, que está largamente disponível. A forma mais eficiente de ganhar dinheiro com software livre é vender suporte e serviços de personalização sobre os programas e distribuições que você domina. Para o cliente acaba sendo vantajoso, pois o custo de implantação será o gasto com a consultoria e treinamentos, enquanto ao implantar um software comercial qualquer ele gastaria também com as licenças de uso.

3- Direito de ter acesso ao código fonte do programa, fazer alterações e redistribuí-las. Para um programador este é o principal atrativo, pois você pode criar novos projetos usando como base o código fonte de programas já existentes ao invés de ter sempre que começar do zero, sem falar na grande oportunidade de aprendizado que examinar o código fonte dos programas disponíveis propicia.

4- Direito (e ao mesmo tempo a obrigação) de redistribuir as modificações feitas. Este é o ponto onde existem mais mal-entendidos. Se você desenvolve um software por hobby, ou por usá-lo internamente na sua empresa, e não possui interesse em explorá-lo comercialmente, você pode simplesmente divulgar o código fonte para todo mundo, o que é o caminho mais lógico se você pretende atrair outros interessados em ajudá-lo no desenvolvimento. Mas, caso você pretenda receber pelo seu trabalho de desenvolvimento, existem duas opções:

a) Você pode distribuir o software livremente para aumentar a base de usuários e ganhar vendendo suporte, treinamentos e personalizações ou:

b) Você só é obrigado a distribuir o código fonte a quem obtém o software, de forma que você pode trabalhar batendo de porta a porta, vendendo o software para alguns clientes específicos e fornecendo o código fonte apenas para eles. Não existe nada de errado com este modelo, mas você perde a possibilidade de ter contribuições de outros desenvolvedores, o que pode ser ruim a longo prazo.

5- Os softwares distribuídos sob a GPL não “contaminam” softwares comerciais ou de outras licenças no caso de distribuição conjunta. Por exemplo, uma revista pode distribuir alguns softwares GPL no meio de um monte de aplicativos fechados na mesma edição. Os softwares GPL continuam sendo GPL, com todas regras que vimos acima, enquanto os softwares comerciais continuam sendo fechados. A revista deve incluir o código fonte dos aplicativos GPL (ou pelo menos a informação de como obtê-los via internet), mas naturalmente não precisa fazer o mesmo com os outros aplicativos incluídos no CD.

Você pode também usar algum software GPL em conjunto com o seu aplicativo comercial, desenvolvendo um aplicativo qualquer que utiliza o Postgree SQL (um servidor de banco de dados), por exemplo. O Postgree SQL continua sendo GPL e o seu aplicativo continua sendo fechado; qualquer um pode usar e tirar cópias do Postgree SQL, mas você controla a distribuição do seu aplicativo. Uma coisa não interfere com a outra.