Se você sempre quis saber o que é software livre, como funcionam as licenças de software e os cuidades que devemos ter em produtos comerciais com licenças copyleft como a GPL, este artigo é para você!

Antes de mais nada, um breve aviso legal (no sentido jurídico da palavra). Licença de software é um tema complicado e muitas vezes interpretativo. Eu não sou advogado, e o conteúdo deste artigo não tem nenhum valor jurídico ou legal. Portanto, caso tenha realmente uma dúvida sobre uma licença de software e precise de um apoio legal (novamente no sentido jurídico), procure um advogado!

E vamos começar com…

UM POUCO DE HISTÓRIA

O conceito de compartilhamento de idéias e informações é muito antigo, e no contexto da computação, o compartilhamento de código-fonte acontece desde a década de 50. Naquela época, a maioria dos sistemas computacionais eram vendidos com o código-fonte do produto incluso, possibilitando sua alteração conforme a necessidade. E existia de fato uma rede grande de troca de informações e compartilhamento de código-fonte, especialmente na área acadêmica. Naquela época, não existia o conceito de licenças de software como conhecemos hoje, e boa parte do código-fonte era aberto e de domínio público.

E foi assim até o início dos anos 70, quando a situação começou a mudar. Com o aumento da complexidade do hardware e dos sistemas computacionais, aumentou também o esforço para o desenvolvimento do software, e as empresas de hardware não conseguiram acompanhar este modelo de negócios onde vendia-se hardware com software incluso e código-fonte disponível. Foi neste período que começou a surgir toda uma nova indústria de empresas da área de software.

Naquela época, se você tivesse uma empresa e quisesse usar o Unix, precisava pagar pelo direito comprando uma licença com a AT&T. Se quisesse usar o Altair Basic, precisava comprar uma licença com a Microsoft. É lógico que, alguém com acesso ao código-fonte poderia distribuí-lo para quem quisesse. Mas isso poderia ser considerado pirataria, o que inclusive motivou em 1976 uma carta pública do Bill Gates com o título “Open Letter to Hobbyists“, direcionada à todos que utilizavam cópias “alternativas” do Altair Basic sem pagar uma licença comercial.

É neste contexto que, em 1983, Richard Stallman criou o projeto GNU, com o objetivo de escrever um sistema operacional livre. Diz a história que uma de suas principais motivações para a criação do projeto GNU foi o desejo de alterar o comportamento de uma impressora, porém ele não tinha acesso ao código-fonte. E o software, incluindo o código-fonte, deveria fazer parte do produto e ser disponibilizado pelo fabricante quando você adquire o hardware.

Em 1985, Richard Stallman publicou o Manifesto GNU para pedir apoio no desenvolvimento do sistema operacional GNU, e em 1986 foi criada a Free Software Foundation. Em 1989 a primeira versão da GNU GPL (General Public License) foi publicada, em 1991 foi publicada a GPLv2 (ainda uma das licenças de software livre mais utilizadas atualmente) e em 2007 foi publicada a GPLv3.

O fato é que o sistema operacional livre do GNU não decolou. Hoje até temos uma versão do sistema operacional baseada no kernel Hurd, porém nada muito funcional para as necessidades de um sistema computacional moderno. De qualquer forma, foi através do projeto GNU que surgiram as diversas ferramentas, bibliotecas e aplicações que utilizamos até hoje para, junto com o kernel Linux, compor o sistema operacional GNU/Linux. Foi também com o projeto GNU que surgiu o conceito de software livre. Mas o que é software livre?

SOFTWARE LIVRE

Segundo os conceitos e a filosofia do projeto GNU, um software pode ser considerado livre se der aos usuários 4 liberdades básicas:

0. Liberdade para executar o código, como quiser e para qualquer propósito.
1. Liberdade de estudar e adaptar o código-fonte às suas necessidades.
2. Liberdade de redistribuir cópias do código-fonte.
3. Liberdade de distribuir cópias das suas versões modificadas.

Existem então diferenças conceituais (e até filosóficas) entre software aberto (open source) e software livre (free software).

Um software livre sempre te dará as 4 liberdades descritas acima. E isso pode não ser o caso de um software aberto. Por exemplo, um software aberto (open source) pode te dar a permissão para executar, estudar e adaptar o código-fonte às suas necessidades (liberdades 0 e 1), mas pode não te dar a liberdade de distribuir o código-fonte e suas alterações (liberdades 2 e 3).

Uma descrição mais completa e abrangente de software livre está disponível no site do GNU.

CATEGORIAS DE SOFTWARE LIVRE

As licenças de software livre possuem basicamente duas categorias: copyleft e non-copyleft.

Em um software de licença copyleft, cópias modificadas devem ser distribuídas sob a mesma licença. A idéia é dar a mesma liberdade a novos usuários e incentivar a contribuição de volta à comunidade. Exemplos de licença copyleft são a GPLv2 e a LGPLv2. É por este motivo que você precisa liberar sob licença GPL qualquer trabalho derivado de um código GPL.

Já as licenças non-copyleft, também chamadas de licenças permissivas, não tem estes requisitos. Elas permitem que você licencie o código sob outra licença, inclusive para uma versão comercial. Ou seja, você pode alterar um código de licença permissiva e não liberar as suas alterações. Algumas licenças permissivas exigem apenas que você mantenha a atribuição de autoria do projeto. Algumas das principais licenças permissivas são MIT, BSD e Apache.

Como as licenças permissivas possibilitam o licenciamento do código sob uma outra licença, inclusive para uma versão comercial, elas são bastante amigáveis comercialmente.  Por exemplo, o Darwin, núcleo do sistema operacional Mac OS X da Apple, é derivado de algumas variantes do BSD, incluindo o FreeBSD, que por ser de licença BSD, permitiu com que a Apple mudasse para uma licença comercial, e por este motivo não temos acesso ao código-fonte do Darwin.

Já as licenças copyleft possuem alguns detalhes que devemos tomar cuidado durante o desenvolvimento de um produto comercial. É por isso que precisamos estudar com um pouco mais de detalhes como funciona a licença GPL e suas principais variantes.

GPL E LGPL

A GNU GPLv2 (General Public License) cobre boa parte dos projetos de software livre como o U-Boot, o kernel Linux, o Busybox e muitas outras aplicações. É uma licença copyleft, e isso significa que um trabalho derivado de GPLv2 precisa ser liberado sob a mesma licença. Ou seja, se você alterar o BusyBox, precisa liberar suas alterações também sob licença GPLv2. Inclusive, um programa linkado com uma biblioteca GPL também é considerado um trabalho derivado e precisa ser liberado sob a mesma licença.

É por este motivo que existe a GNU LGPL (Lesser General Public Licence), uma licença específica para bibliotecas. A LGPL permite com que você faça a linkagem da sua aplicação com bibliotecas sem precisar liberar o código-fonte, desde que a linkagem seja feita de forma dinâmica. Por exemplo, podemos utilizar normalmente a biblioteca SDL (licença LGPLv2), desde que façamos a linkagem com a nossa aplicação de forma dinâmica.

Boa parte dos programas e bibliotecas são cobertos pela versão 2 da GPL (GPLv2 e LGPLv2), mas alguns programas estão migrando para a versão 3 (GPLv3 e LGPLv3), que possui algumas restrições adicionais.

Na versão 3 da GPL, o usuário tem o direito não só de receber o código-fonte e utilizá-lo para qualquer propósito, mas também a possibilidade de compilar o código e atualizá-lo na plataforma-alvo. Essa é uma restrição que pode invalidar muitas soluções e normalmente é evitada em produtos comerciais. Por exemplo, a maioria dos módulos da última versão do Qt5 são LGPLv3, e se você decidir utilizá-los em seu produto, precisará fornecer ferramentas para seu cliente atualizar as bibliotecas do Qt no dispositivo de hardware!

Em resumo, estes são os cuidados que você precisa tomar para proteger a propriedade intelectual da empresa em produtos comerciais que utilizam software livre:

1. Não implementar em software GPL ou LGPL algum código que contenha propriedade intelectual da sua empresa.
2. Não linkar seu código com biblioteca GPL.
3. Não linkar estaticamente com biblioteca LGPL.
4. Não utilizar a versão 3 da GPL (GPLv3, LGPLv3).

É importante ressaltar também que a liberação do código-fonte é apenas necessária para o usuário final do seu produto. Por exemplo, se eu desenvolver um produto que utiliza o kernel Linux (licença GPLv2), preciso liberar o código-fonte do kernel Linux apenas para os usuários do meu produto. E se for um produto ou projeto de uso interno ou pessoal, não é necessário liberar o código-fonte.

BUILD SYSTEMS

Durante o desenvolvimento de um projeto baseado em software livre, é importante ter uma lista de todos os softwares utilizados e suas respectivas licenças. As ferramentas de build como o Buildroot e o OpenEmbedded/Yocto são capazes de gerar esta lista.

Um tempo atrás escrevi um artigo sobre como gerenciar as licenças de software com o Buildroot.

O manual do Yocto Project também possui uma documentação bem completa sobre o gerenciamento de licenças de software.

APLICANDO LICENÇAS

Hoje em dia, uma conta no GitHub com projetos pessoais é parte integrante do currículo de qualquer desenvolvedor de software. E tão importante quanto publicar o código-fonte dos seus projetos pessoais é definir uma licença para ele. Porque, desta forma, outros desenvolvedores saberão se podem utilizar o seu código, que direito eles têm e o que podem fazer com ele.

Não existe uma regra única para aplicar licenças em software, mas o processo básico para licenciar seu código-fonte envolve:

• Uma indicação da licença utilizada e uma cópia completa desta licença no site do projeto (se o projeto tiver um site).
• Uma cópia completa da licença utilizada no diretório principal do código-fonte do projeto. Normalmente este arquivo é nomeado como LICENCE, LICENCE.TXT, COPYRIGHT ou COPYING.
• Um descritivo da licença utilizada no cabeçalho de cada arquivo-fonte do projeto. O conteúdo deste descritivo depende da licença utilizada.

Inclusive, alguns sites de hospedagem de código-fonte como o GitHub já permitem com que você defina a licença do código durante a criação de um projeto, automaticamente inserindo uma cópia da licença na raiz do código-fonte.

PALAVRAS FINAIS

Sim, são muitos detalhes envolvidos. Mas se tomarmos alguns cuidados básicos, podemos evitar muitos problemas com licenças de software em projetos que utilizam software livre.

Para fechar, gostaria de deixar bem claro que eu sou um defensor do software livre, e acredito ser a maneira correta de desenvolver produtos e inovar. Software livre evita duplicação de esforços e reduz custos de desenvolvimento. O ser humano foi feito para criar e compartilhar, e com software livre entramos em um fluxo crescente de desenvolvimento e inovação.

Ao mesmo tempo que devemos nos preocupar com a propriedade intelectual da empresa em um produto comercial, devemos também nos esforçar para, sempre que possível, contribuir de volta à comunidade.

Porque não publicar o código-fonte daquela biblioteca criada para determinado projeto, ou então submeter à comunidade o código-fonte de um device driver que foi implementado para o kernel Linux do seu produto?

Já que estamos nos beneficiando de literalmente milhões de linhas de código-fonte de projetos desenvolvidos e mantidos por milhares de pessoas ao redor do mundo, contribuir de volta à comunidade é o mínimo que podemos fazer!

Um abraço,

Sergio Prado