Sem licença, MIT, GPL ou BUSL: como licenciar seu código

Já vi repositório público com 2 mil estrelas e nenhum arquivo LICENSE. O autor achava que estava "doando" o código. Na prática, ninguém podia usá-lo legalmente — e a primeira empresa que quis adotar a biblioteca abriu uma issue pedindo licença, porque o jurídico barrou. Do outro lado, já vi time colocar MIT num produto que depois precisou fechar, e descobrir que não dá para "desdoar" o que já foi publicado.

A escolha de licença não começa em "MIT ou Apache?". Começa antes: você quer que o código seja usado por terceiros, e em quais condições? Este post cobre essa decisão para o seu projeto — inclusive as opções que não são open source, como não licenciar, BUSL e SSPL. Se você já sabe que quer uma licença aberta e só precisa comparar as clássicas, o post MIT, Apache e GPL: o que cada licença realmente permite faz essa comparação cláusula por cláusula.

Repositório sem licença: o que os outros podem fazer

Quase nada. Sem licença, vale o copyright padrão: o código é seu com todos os direitos reservados, e ninguém pode copiar, modificar ou redistribuir sem sua permissão. O choosealicense.com, mantido pelo GitHub, diz isso com todas as letras.

O detalhe que confunde: ao publicar num repositório público, você aceita os Termos de Serviço do GitHub, que permitem a outros usuários ver e fazer fork do repositório dentro do GitHub. E só. O próprio choosealicense.com avisa que isso não significa permissão para usar, modificar ou compartilhar o software para qualquer fim.

Repositório público no GitHub sem LICENSE:
não: Usar em outro projeto (comercial ou não)
não: Copiar e redistribuir
não: Modificar e publicar a versão modificada
sim: Ver o código
sim: Fazer fork dentro do GitHub (Termos de Serviço)

Então "sem licença" é uma escolha legítima quando você quer mostrar o código (portfólio, transparência, estudo) sem autorizar uso. Só não chame isso de open source. Open source, pela Open Source Definition da OSI, exige uma licença que garanta livre redistribuição, acesso ao código, obras derivadas e ausência de discriminação de pessoas ou áreas de uso — são dez critérios, não um repositório público. A diferença entre open source, software livre e source available está em o que é open source.

A armadilha do "sem licença" é a contribuição externa. Se alguém abre um pull request e você aceita, o código dessa pessoa entra no repositório sem nenhum termo combinado. Se um dia você quiser abrir o projeto, vai precisar da autorização dela também.

Quer que usem? Permissiva ou copyleft (o resumo)

Se a resposta é "sim, quero que usem", a próxima pergunta é se você se importa com o que fazem depois.

• Permissiva (MIT, BSD, Apache 2.0): qualquer um usa, inclusive em produto fechado, desde que mantenha o aviso de copyright. Apache 2.0 acrescenta concessão explícita de patentes.
• Copyleft (GPL, LGPL, AGPL): quem distribui uma obra derivada precisa distribuí-la sob a mesma licença. A AGPL estende isso para software oferecido pela rede, que é o caso SaaS.

Os detalhes — compatibilidade entre GPLv2 e Apache 2.0, quando a LGPL basta, uso interno de AGPL — estão no comparativo de MIT, Apache e GPL. Aqui o ponto é só o eixo da decisão: permissiva maximiza adoção, copyleft maximiza a garantia de que melhorias voltem abertas. Exemplos de AGPL hoje: Grafana, Loki e Tempo, que trocaram Apache 2.0 por AGPLv3 em abril de 2021, além de Nextcloud e Mastodon.

Se o projeto é pessoal e você não tem um motivo concreto para copyleft, MIT continua sendo o caminho de menor atrito.

Quer o código público, mas sem concorrente revendendo? Source available

Aqui mora a categoria que mais cresceu nos últimos anos e que o "MIT vs GPL" não cobre: licenças source available. O código fica visível, você pode estudar e muitas vezes modificar, mas há restrição de uso. Nenhuma delas é aprovada pela OSI, então nenhuma é open source no sentido técnico. As principais:

A BUSL é a mais mal explicada por aí. O texto da BUSL 1.1 permite copiar, modificar e fazer uso não-produtivo — não é "uso não-comercial". O autor pode liberar parte do uso em produção via Additional Use Grant (a HashiCorp, por exemplo, libera produção desde que não seja produto concorrente). Na Change Date — que não pode passar de quatro anos após a publicação da versão — o código daquela versão converte para a Change License, que precisa ser GPLv2 ou compatível com ela. A HashiCorp adotou a BUSL 1.1 em agosto de 2023, saindo da MPL 2.0.

A FSL, criada pela Sentry, segue a mesma lógica com prazo mais curto: cada versão vira Apache 2.0 ou MIT dois anos depois.

Como ler uma "licença restrita" antes de usar

Se você vai consumir algo source available, leia três coisas: o que conta como produção ou uso concorrente, o que o grant adicional libera e quando cada versão converte. Se vai publicar, a BUSL ou a FSL são a forma honesta de dizer "pode olhar e testar, mas não pode revender" — bem mais clara do que publicar sem licença e torcer.

Quem trocou de licença (e quem voltou)

O histórico recente mostra que licença não é decisão eterna — e que trocar tem custo de comunidade:

• MongoDB: saiu da AGPLv3 para a SSPL nas versões lançadas a partir de 16 de outubro de 2018.
• Elasticsearch e Kibana: trocaram Apache 2.0 por SSPL/Elastic License em 2021 e, em 29 de agosto de 2024, anunciaram a AGPL como opção adicional.
• HashiCorp (Terraform, Vault etc.): MPL 2.0 para BUSL 1.1 em agosto de 2023. A comunidade respondeu com o fork OpenTofu.
• Redis: passou para RSALv2/SSPL em março de 2024 e adicionou a AGPLv3 no Redis 8, em maio de 2025. Nesse meio-tempo nasceu o fork Valkey, na Linux Foundation, com apoio de AWS e Google.

O padrão: empresa troca para source available para se proteger de cloud provider, comunidade faz fork, empresa volta para uma licença aprovada pela OSI — e a AGPL virou o meio-termo preferido.

Quer vender licença comercial? Dual licensing exige CLA

Dual licensing é publicar sob GPL ou AGPL e vender uma licença comercial para quem não quer cumprir o copyleft. MySQL e Qt são os casos clássicos.

A condição é controlar todo o copyright. Quem contribui mantém o direito autoral do que escreveu; sem um CLA (Contributor License Agreement) que lhe dê o direito de relicenciar, você não pode vender a contribuição dessa pessoa sob outra licença. Por isso o CLA precisa estar no CONTRIBUTING.md antes do primeiro pull request externo, não depois do quinquagésimo. O lado de quem contribui — e por que alguns devs se recusam a assinar CLA — está em como contribuir com open source.

Mudar de licença depois: possível, mas caro

Se você é o único autor, relicenciar é trivial: publique a próxima versão sob a nova licença. As versões antigas continuam valendo sob a licença original para quem já as tem.

Com contribuidores externos sem CLA, você precisa da autorização de cada um. O kernel Linux é o exemplo citado, mas a história real é outra: o kernel nunca tentou migrar para a GPLv3. O arquivo COPYING declara "GPL version 2 only", e Linus Torvalds rejeitou publicamente a GPLv3 em 2006, durante a redação dela. O ponto prático é que, sem a cláusula "or later" e com milhares de detentores de copyright, uma mudança dessas seria inviável mesmo que alguém quisesse.

Antes de publicar, audite o que você usa

Sua licença não pode ser mais permissiva do que as dependências permitem. Uma biblioteca GPL dentro de um app distribuído sob MIT é problema seu, não do autor da biblioteca. Rodar um relatório de licenças no CI é barato:

# npm: resumo das licenças das dependências instaladas
npx license-checker --summary --excludePrivatePackages

# Python: tabela das licenças dos pacotes do ambiente
pip install pip-licenses
pip-licenses --order=license --format=markdown

Testei os dois em novembro de 2026: o license-checker ainda funciona, mas não recebe release desde 2022 — sirva-se, sabendo disso. Licença é um dos critérios do checklist de como avaliar se uma biblioteca é confiável, e o histórico acima mostra por que vale reconferir a cada atualização grande: Redis e Elasticsearch mudaram de licença entre uma versão e outra.

Perguntas frequentes

Posso usar código de um repositório sem licença?

Não, sem autorização do autor. Sem licença, o código está sob copyright com todos os direitos reservados; os Termos de Serviço do GitHub só permitem ver e fazer fork dentro da plataforma. Se precisa usar, abra uma issue pedindo que o autor adicione uma licença.

BUSL e SSPL são open source?

Não. Nenhuma das duas é aprovada pela OSI, porque restringem campos de uso — produção na BUSL, oferta como serviço na SSPL. A BUSL tem a particularidade de converter cada versão para uma licença compatível com GPL em até quatro anos; a SSPL não converte.

MIT é suficiente para a maioria dos projetos?

Para projeto pessoal, biblioteca ou ferramenta que você quer ver adotada, sim. Considere Apache 2.0 se patentes importam, GPL ou AGPL se quer que derivados continuem abertos, e BUSL ou FSL se quer impedir revenda por concorrente.

Posso ter partes do projeto com licenças diferentes?

Sim. É comum documentação em Creative Commons e código em MIT, ou core aberto e módulos comerciais fechados. Deixe explícito qual arquivo tem qual licença, com cabeçalhos SPDX (SPDX-License-Identifier: MIT) e uma pasta LICENSES/ com os textos.

Decida a intenção primeiro, a licença vem depois

Quatro perguntas resolvem quase todo caso: quero que usem? Me importo se fecharem o código derivado? Preciso impedir que um concorrente revenda? Vou vender licença comercial? As respostas apontam, nessa ordem, para sem licença, permissiva, copyleft, source available e dual licensing com CLA.

Decida antes do primeiro pull request externo, porque depois disso a licença fica bem mais difícil de mudar. E use o texto canônico da licença: um LICENSE editado à mão pode deixar de ser reconhecido pelo GitHub e pelas ferramentas de auditoria. Quando herdo um repositório, colo o arquivo e o texto oficial no Diff Checker para ver se alguém mexeu em alguma cláusula.