Como escolher uma licença para seu projeto open source

Você criou um repositório, clicou em "Add a license" no GitHub, e ficou olhando para uma lista de onze opções sem saber qual marcar. Escolheu MIT porque todo mundo usa MIT. Talvez esteja certo. Talvez não.

O post sobre MIT, Apache e GPL detalha o que cada uma dessas licenças permite e proíbe. Este aqui é a etapa anterior: a árvore de decisão para chegar até lá. Porque a pergunta "MIT ou Apache?" já assume que você quer código aberto — e isso nem sempre é verdade.

A primeira pergunta não é "qual licença"

É: você quer que alguém além de você possa usar esse código?

Se a resposta for "não, por enquanto" — ou se você simplesmente não tiver certeza — deixar o repositório sem licença é uma opção deliberada, não um esquecimento. Um repositório público sem LICENSE no GitHub não é domínio público. É o contrário: o copyright padrão se aplica, o que significa que ninguém tem permissão legal de copiar, modificar ou distribuir o código além do que os termos de serviço do GitHub permitem (que é bem restrito — basicamente visualizar e fazer fork para contribuir de volta).

Sem licença = fechado por padrão. Isso pode ser exatamente o que você quer.

Repositório público no GitHub sem LICENSE:
✗ Uso comercial por terceiros
✗ Redistribuição
✗ Modificação e redistribuição
✓ Visualização
✓ Fork para abrir Pull Request (termos do GitHub)

O mito de que "código público no GitHub é open source" é perigoso. Não é. Open source requer uma licença que conceda explicitamente as quatro liberdades básicas: usar, estudar, modificar, distribuir.

Você quer que o código seja público mas fechado?

Isso existe. Alguns projetos ficam no GitHub para referência ou portfólio, mas sem intenção de permitir uso livre. Nesses casos, uma licença de "somente leitura" é mais clara do que ausência de licença.

A Creative Commons BY-NC-ND é usada dessa forma — permite visualizar e compartilhar com atribuição, mas proíbe modificação e uso comercial. Não é a escolha padrão para código (foi desenhada para conteúdo), mas aparece em projetos de design, documentação técnica e templates.

Para código proprietário que você quer publicar para fins de transparência ou auditoria de segurança, algumas empresas usam licenças de leitura customizadas (como a Business Source License, ou BUSL) que permitem uso não-comercial por um período e convertem para uma licença permissiva depois de N anos. HashiCorp fez isso com Terraform em 2023, o que gerou bastante discussão na comunidade.

Se você está numa empresa desenvolvendo software interno que ficará no GitHub privado, a questão de licença de terceiros ainda importa para o que você usa, não para o que você publica. Esse é um problema diferente.

Árvore de decisão: do zero à licença certa

A pergunta central é sobre o que você quer que aconteça com o código quando sair das suas mãos:

Ramo 1: Quero máxima adoção, sem restrições

Você quer que pessoas usem o código — em produtos comerciais, produtos fechados, outros projetos open source, em qualquer contexto. Você não quer atritar ninguém.

→ MIT se o projeto é pequeno e você não tem preocupações com patentes.
→ Apache 2.0 se há contribuidores corporativos, o projeto pode virar alvo de litígio de patentes, ou você trabalha em empresa onde o jurídico vai revisar as dependências.

A diferença entre MIT e Apache 2.0 é quase sempre irrelevante para projetos individuais. Para projetos com múltiplos contribuidores e potencial de escala (infraestrutura, ferramentas de build, protocolos), Apache 2.0 é mais defensivo.

Ramo 2: Quero que o código permaneça aberto

Você quer que quem usar seu código e distribuir derivados também tenha que deixar o código aberto. Não quer que uma empresa feche e monetize sem contribuir.

→ GPL v3 para software que é distribuído (instalado em computadores dos usuários).
→ AGPL v3 para software que roda como serviço na nuvem. O gap da GPL clássica é que você pode pegar código GPL, rodar num servidor SaaS, e nunca "distribuir" nada — o AGPL fecha esse buraco exigindo que usuários do serviço tenham acesso ao código.
→ LGPL se você está fazendo uma biblioteca que precisa rodar em produtos proprietários, mas quer que o código da biblioteca em si continue aberto.

A escolha entre GPL e AGPL depende de onde o software é executado. Se você está fazendo um banco de dados, um servidor web, um sistema de monitoramento — qualquer coisa que empresas tendem a rodar como serviço sem distribuir binários — AGPL é a licença que protege seu trabalho. MongoDB, Grafana e Nextcloud usam AGPL exatamente por isso.

Ramo 3: Quero monetizar, mas também ter comunidade open source

Esse é o caso de dual licensing, e é mais comum do que parece.

A estratégia: licenciar o projeto como GPL (ou AGPL) para uso open source gratuito, e vender uma licença comercial para empresas que precisam usar em produtos fechados. MySQL foi o caso mais famoso — Oracle ainda usa esse modelo. Qt faz o mesmo.

A condição para dual licensing funcionar: você precisa controlar 100% dos direitos do código. Se você aceitar contribuições externas sem CLA (Contributor License Agreement), os contribuidores mantêm copyright do que enviaram, e você não pode relicenciar o código deles para a versão comercial.

Dual licensing requer:
✓ Copyright centralizado (só você, ou CLA obrigatório)
✓ Capacidade de vender a licença comercial
✓ Usuários corporativos que preferem pagar a abrir código
✗ Funciona mal com contribuições comunitárias sem CLA

Se você planeja dual licensing desde o início, a decisão de licença inicial precisa incluir a política de CLA. Não é algo para adicionar depois de 50 contribuidores.

Ramo 4: Quero usar código de outros no meu projeto fechado

Essa é a perspectiva inversa — não sobre o que você publica, mas sobre o que você usa.

Aqui a regra é simples: verifique as licenças de todas as dependências antes de construir sobre elas.

• MIT e BSD: sem problema para projetos fechados.
• Apache 2.0: sem problema, com caveat de incompatibilidade com GPL v2.
• GPL v2 / v3: não usar em produto fechado distribuído. Uso interno sem distribuição é geralmente seguro.
• AGPL: não usar em SaaS sem abrir código. O critério é se usuários externos acessam o serviço via rede.
• LGPL: pode usar em produto fechado se o link for dinâmico e você não modificar a biblioteca. Leia a seção 4 da licença.

# Auditar licenças de dependências npm
npx license-checker --summary --excludePrivatePackages

# Python
pip-licenses --order=license --format=table

Rodar isso no CI antes de cada release é prática razoável em qualquer projeto comercial. Dependências mudam de licença — aconteceu com Elasticsearch, HashiCorp Vault, Redis, e outros projetos grandes nos últimos anos.

O caso especial das licenças "source available"

Nos últimos cinco anos cresceu uma categoria intermediária que não é nem open source nem software proprietário clássico: source available.

Business Source License (BUSL), Server Side Public License (SSPL, MongoDB), Elastic License — todas permitem ver e estudar o código, mas restringem uso competitivo ou produção. A OSI (Open Source Initiative) não considera nenhuma delas open source de verdade, porque restringem usos específicos.

Se você trabalha numa empresa e seu repositório de dependências tem alguma dessas, vale confirmar se o uso que você faz é permitido pelos termos. "Código no GitHub" não implica permissão de uso em produção.

Mudando de licença depois

Possível, mas com uma condição: você precisa de permissão de todos os detentores de copyright.

Se o projeto tem só você como autor, é simples — você pode relicenciar. Se tem contribuidores externos que enviaram código sem CLA, cada um deles mantém copyright do que escreveu. Você precisaria do consentimento de todos para mudar a licença.

O Linux tentou mover de GPL v2 para GPL v3 e não conseguiu por exatamente isso — Linus Torvalds tem copyright de parte do código, mas há décadas de contribuições de milhares de pessoas sem CLA centralizado. A mudança seria operacionalmente inviável.

Isso reforça a importância de decidir antes de aceitar as primeiras contribuições externas. Depois que a comunidade cresce, a licença fica engessada.

Perguntas frequentes

Projeto sem licença pode ser usado por qualquer pessoa?

Não. Sem licença, o copyright padrão se aplica: ninguém pode usar, copiar, modificar ou distribuir sem permissão explícita do autor. Um repositório público no GitHub sem LICENSE é código com copyright "todos os direitos reservados". As pessoas podem ver o código, mas não têm permissão legal de usá-lo. Se você quer que outros usem, precisa de uma licença.

MIT é suficiente para a maioria dos projetos?

Sim, na maioria dos casos. MIT funciona bem para bibliotecas, ferramentas de linha de comando, frameworks e componentes que você quer que sejam amplamente adotados. A situação em que MIT não é suficiente: (1) você quer proteção explícita de patentes — use Apache 2.0; (2) você quer garantir que derivados permaneçam abertos — use GPL; (3) você quer impedir que serviços SaaS usem sem contribuir — use AGPL. Se nenhum desses casos se aplica, MIT é a escolha certa.

Posso ter partes do projeto com licenças diferentes?

Sim, é um padrão chamado "licenciamento multi-tier" ou simplesmente arquivos com cabeçalhos de licença diferentes. Documentação frequentemente usa Creative Commons enquanto o código usa MIT ou Apache. SDKs podem ter o core em MIT e plugins comerciais em licença proprietária. O requisito é deixar claro qual parte tem qual licença — geralmente com cabeçalhos nos arquivos ou um diretório LICENSES/ com os textos relevantes.

Como licenciar um projeto de portfólio que não pretendo distribuir ativamente?

Três opções comuns: (1) MIT, porque você não se importa o que fazem — é portfólio, quer que as pessoas vejam e usem; (2) sem licença, se você quer que seja só para visualização e não quer que copiem; (3) CC BY-NC se o projeto é mais conteúdo do que código e quer crédito. Para a maioria dos casos de portfólio técnico, MIT é o caminho de menor atrito.

A licença certa é a que corresponde à sua intenção, não à mais popular

MIT ganhou o mindshare porque é simples e funciona para o caso mais comum. Mas "todo mundo usa MIT" não é razão suficiente se você tem intenções específicas para o projeto.

O fluxo é direto: decida se quer código aberto. Se sim, decida se quer copyleft ou permissiva. Se permissiva, MIT vs Apache 2.0 depende do contexto de patentes. Se copyleft, GPL vs AGPL depende de como o software é executado. Se você quer monetizar, considere dual licensing com CLA.

Para entender o que cada uma dessas licenças implica em detalhe — o texto real, as implicações de compatibilidade, os casos-limite — o post MIT, Apache e GPL: o que cada licença realmente permite cobre isso linha a linha.