Todo projeto de software carrega uma decisão que muitos desenvolvedores deixam para o final ou simplesmente ignoram: a licença. Aquele arquivo LICENSE na raiz do repositório pode parecer burocracia, mas define quem pode usar seu código, como pode usar e o que acontece se alguém criar algo a partir dele.

Se você já contribuiu com um projeto open source, usou uma dependência do npm ou publicou uma biblioteca no GitHub, já esbarrou nessa questão. A diferença entre escolher MIT ou GPL pode determinar se uma empresa vai adotar seu projeto ou descartá-lo na triagem jurídica.

O que define uma licença de software

Uma licença de software é um contrato legal entre quem cria o software e quem o utiliza. Ela estabelece três eixos:

  • Permissões definem o que o usuário pode fazer: uso comercial, modificação, distribuição, sublicenciamento, uso de patentes
  • Condições são obrigações que o usuário precisa cumprir para exercer essas permissões: manter avisos de copyright, divulgar código-fonte, usar a mesma licença em trabalhos derivados
  • Limitações protegem o autor: exclusão de garantia, isenção de responsabilidade, limitação de uso de marcas registradas

A combinação desses três eixos cria o espectro que vai de licenças permissivas (quase tudo permitido, poucas condições) até licenças copyleft (permissões amplas, mas com condições que propagam a licença para trabalhos derivados).

Existe ainda uma terceira categoria: licenças proprietárias, onde o código permanece fechado e o uso é regido por termos específicos definidos pelo fornecedor.

Licenças permissivas: MIT, BSD e Apache 2.0

Licenças permissivas permitem usar, modificar e redistribuir o código com poucas restrições. Quem recebe o código pode incorporá-lo em projetos proprietários sem obrigação de abrir o próprio código-fonte.

MIT

A MIT License nasceu no Massachusetts Institute of Technology e hoje é a licença open source mais usada no mundo. Segundo dados do GitHub Innovation Graph, cerca de 44% dos repositórios licenciados na plataforma usam MIT.

O texto cabe em um parágrafo. A essência: faça o que quiser com o código, desde que mantenha o aviso de copyright e a licença no projeto.

  • Permissões: uso comercial, modificação, distribuição, sublicenciamento
  • Condições: incluir cópia da licença e aviso de copyright
  • Limitações: sem garantia, sem responsabilidade do autor

Projetos como React, jQuery e Rails usam MIT. Funciona bem quando o objetivo é maximizar adoção sem burocracia.

BSD (2-clause e 3-clause)

A família BSD é parecida com a MIT. A versão de 2 cláusulas (Simplified BSD) é praticamente idêntica à MIT na prática. A de 3 cláusulas adiciona uma restrição: o nome do autor ou da organização não pode ser usado para promover produtos derivados sem permissão escrita.

  • Permissões: uso comercial, modificação, distribuição
  • Condições: incluir licença e copyright (3-clause: proibição de uso do nome para endosso)
  • Limitações: sem garantia, sem responsabilidade

FreeBSD e o sistema de build do Go usam BSD. A diferença prática para MIT é mínima.

Apache 2.0

A Apache License 2.0 é permissiva como a MIT, mas com dois diferenciais que importam para empresas:

  1. Concessão explícita de patentes. Quem contribui com código licenciado sob Apache 2.0 automaticamente concede uma licença de uso das patentes relacionadas àquele código. Se um contribuidor processar um usuário por violação de patente, a licença do contribuidor é revogada automaticamente
  2. Rastreabilidade de mudanças. Qualquer modificação feita no código original precisa ser documentada. Arquivos modificados devem conter um aviso indicando que foram alterados
  • Permissões: uso comercial, modificação, distribuição, sublicenciamento, uso de patentes
  • Condições: incluir licença e copyright, documentar mudanças, manter arquivo NOTICE se existir
  • Limitações: sem garantia, sem responsabilidade, sem uso de marcas registradas do projeto

Kubernetes, Android (AOSP) e TensorFlow usam Apache 2.0. Se o projeto pode envolver patentes ou adoção corporativa, Apache 2.0 reduz risco jurídico em comparação com MIT.

Licenças copyleft: GPL, LGPL, AGPL e MPL

Licenças copyleft invertem a lógica do copyright: em vez de restringir cópias, exigem que trabalhos derivados mantenham as mesmas liberdades do original. O código fica livre e qualquer coisa construída a partir dele também precisa ser livre.

GPL

A GNU General Public License é a copyleft mais conhecida. Criada por Richard Stallman e pela Free Software Foundation, a GPL garante quatro liberdades: usar, estudar, modificar e distribuir o software. A versão mais recente é a GPL v3, mas nem todos os projetos a adotam.

A condição central: se você distribuir software que contém código GPL, precisa disponibilizar o código-fonte completo do trabalho derivado sob a mesma licença GPL.

  • Permissões: uso comercial, modificação, distribuição, uso de patentes
  • Condições: divulgar código-fonte, manter a mesma licença em trabalhos derivados, incluir avisos de copyright
  • Limitações: sem garantia, sem responsabilidade

O kernel Linux usa GPL v2 exclusivamente (Linus Torvalds rejeitou a v3). O WordPress usa GPLv2 or later, e o GCC usa GPL v3. Para projetos onde a prioridade é garantir que o código permaneça aberto para sempre, a GPL entrega essa garantia.

O efeito colateral: muitas empresas evitam dependências GPL em produtos proprietários porque a condição de copyleft pode se estender ao software inteiro.

LGPL v3

A Lesser GPL é um meio-termo. Ela permite que software proprietário use bibliotecas LGPL sem precisar abrir o código do programa principal. A condição de copyleft se aplica apenas à biblioteca em si.

Se você modifica a biblioteca LGPL e a distribui, precisa liberar o código da biblioteca modificada. Mas o programa que faz link com ela pode continuar proprietário.

  • Permissões: uso comercial, modificação, distribuição, uso de patentes
  • Condições: divulgar código-fonte da biblioteca modificada, manter a mesma licença na biblioteca, permitir que o usuário substitua a biblioteca
  • Limitações: sem garantia, sem responsabilidade

A glibc (biblioteca C do GNU) e o Qt (em parte) usam LGPL. Funciona bem para bibliotecas que querem adoção ampla sem forçar copyleft no software que as consome.

AGPL v3

A Affero GPL fecha uma brecha da GPL tradicional. Na GPL, a obrigação de divulgar código-fonte existe apenas quando o software é distribuído. Se uma empresa roda software GPL em seus servidores sem distribuí-lo (como um serviço SaaS), a GPL não exige nada.

A AGPL corrige isso: se o software roda em um servidor e usuários interagem com ele pela rede, o código-fonte precisa ser disponibilizado.

  • Permissões: uso comercial, modificação, distribuição, uso de patentes
  • Condições: divulgar código-fonte (incluindo uso via rede), manter a mesma licença, incluir avisos de copyright
  • Limitações: sem garantia, sem responsabilidade

O MongoDB (antes de mudar para SSPL) e o Grafana usam ou usaram AGPL. A licença é a mais restritiva da família GNU e muitas empresas a tratam com a mesma cautela que a GPL.

MPL 2.0

A Mozilla Public License 2.0 é a copyleft mais branda. A condição de copyleft se aplica arquivo por arquivo: se você modifica um arquivo MPL, precisa liberar aquele arquivo. Mas pode combinar arquivos MPL com arquivos proprietários no mesmo projeto sem problema.

  • Permissões: uso comercial, modificação, distribuição, uso de patentes
  • Condições: divulgar código-fonte dos arquivos MPL modificados, manter a licença nos arquivos MPL
  • Limitações: sem garantia, sem responsabilidade, sem uso de marcas registradas

O Firefox e o Terraform (antes da mudança para BSL) usam MPL. Para quem quer copyleft leve sem contaminar o projeto inteiro, a MPL encontra esse equilíbrio.

Licenças proprietárias e modelos comerciais

Nem todo software é open source. Licenças proprietárias mantêm o código fechado e restringem o que o usuário pode fazer.

EULA (End-User License Agreement)

O EULA é o contrato que aparece quando você instala um software comercial. Ele define os termos de uso: quantas máquinas podem rodar o software, se é permitido fazer engenharia reversa, se o software pode ser redistribuído.

Diferente das licenças open source, o EULA não concede acesso ao código-fonte. O usuário recebe o software compilado e permissão de uso dentro dos termos definidos.

Modelos de licenciamento comercial

Softwares proprietários usam diferentes modelos de cobrança e permissão:

  • Licença perpétua concede uso indefinido por um pagamento único. Comum em software desktop tradicional. Atualizações podem ou não estar incluídas
  • Licença por assinatura cobra um valor recorrente (mensal ou anual) pelo acesso. Se a assinatura expira, o acesso cessa. Dominante em SaaS
  • Licença por usuário limita o uso a um número determinado de pessoas. Pode ser nominal (cada pessoa tem sua licença) ou concorrente (N pessoas podem usar simultaneamente)
  • Licença por dispositivo vincula o software a uma máquina específica

Dual licensing

Alguns projetos oferecem duas licenças: uma open source (geralmente copyleft) e uma comercial. Se a licença copyleft não funciona para o caso de uso da empresa, ela pode comprar a licença comercial que remove as restrições.

MySQL (GPL + licença comercial Oracle) e o Qt (LGPL + licença comercial) usam esse modelo. O dual licensing transforma o copyleft em vantagem comercial: quem pode cumprir as condições usa de graça, quem não pode paga.

Como escolher a licença certa para o seu projeto

A escolha depende de três perguntas:

1. O código pode ser usado em software proprietário?

Se sim, use uma licença permissiva (MIT, BSD ou Apache 2.0). Se não, use copyleft (GPL, AGPL).

2. Patentes são uma preocupação?

Se o projeto envolve tecnologia patenteável ou o público-alvo inclui grandes empresas, Apache 2.0 oferece proteção que MIT e BSD não oferecem.

3. O software vai rodar como serviço (SaaS)?

Se você quer que provedores de SaaS que usam seu código contribuam de volta, a AGPL fecha a brecha que a GPL deixa aberta.

Para a maioria dos projetos pessoais e bibliotecas open source, a MIT resolve. Para frameworks e projetos que precisam de proteção de patentes, Apache 2.0 é a escolha pragmática. Para software que precisa permanecer aberto a qualquer custo, GPL ou AGPL entregam essa garantia.

Não escolher licença nenhuma não significa que o código é livre. Pelo contrário. Sem licença, o copyright padrão se aplica e ninguém tem permissão legal para usar, copiar ou modificar o código. Se o projeto está no GitHub sem um arquivo LICENSE, ele está tecnicamente protegido por copyright restritivo.

Conclusão

Licenças de software parecem burocráticas até o dia em que importam. Uma startup que incorporou uma dependência GPL em seu produto fechado pode descobrir isso em uma due diligence. Um desenvolvedor que publicou código sem licença pode ver seu trabalho sendo usado sem crédito e sem recurso legal.

Na prática, a escolha se resume a: quer adoção máxima, vá de MIT. Precisa de proteção de patentes, escolha Apache 2.0. Quer garantir que o código permaneça aberto, use GPL ou AGPL. Para bibliotecas que precisam funcionar em contextos proprietários sem abrir mão do copyleft, LGPL e MPL ocupam esse espaço intermediário.

O site choosealicense.com do GitHub continua sendo o ponto de partida mais acessível para decidir. Mas entender o que cada licença faz e por que existe coloca você em posição de tomar essa decisão com consciência, não com base em qual template apareceu primeiro no GitHub.

Referências pesquisadas nesta publicação