Licenças MIT, Apache e GPL: diferenças práticas para devs

Na hora de abrir um repositório, a maioria dos devs escolhe a licença por eliminação: "MIT parece simples, vou de MIT." Funciona na maioria dos casos. Mas quem já trabalhou em empresa recebendo um contrato para integrar um projeto open source sabe que o jurídico para tudo quando aparece a palavra GPL no README — e eles não estão errados em parar.

Esse post não é introdução a open source. Se você ainda está entendendo o que é esse ecossistema, o post O que é open source cobre o contexto. Aqui o assunto é o que cada licença realmente permite, o que ela proíbe, e onde cada uma cria problema prático.

A divisão fundamental: permissiva versus copyleft

Antes de detalhar cada licença, o conceito que estrutura tudo:

Licenças permissivas (MIT, Apache 2.0, BSD) deixam você fazer basicamente o que quiser com o código — incluindo fechar o código-fonte do seu produto derivado. A única exigência é manter o aviso de copyright e, dependendo da licença, alguns outros créditos.

Licenças copyleft (GPL, AGPL, LGPL) impõem uma condição: se você distribuir software que usa código sob essa licença, o código do seu produto também precisa ser disponibilizado sob os mesmos termos. O nome "copyleft" é um trocadilho com copyright — em vez de proteger o direito exclusivo do autor, protege o direito de todos de continuar tendo acesso ao código.

Essa distinção determina se uma licença é "viável comercialmente" ou não para um projeto fechado. Não é questão de ética — é de viabilidade jurídica.

MIT: a licença do menor atrito

A licença MIT tem menos de 200 palavras. Você pode ler o texto completo em dois minutos e entender tudo.

O que ela permite: usar, copiar, modificar, mesclar, publicar, distribuir, sublicenciar, e vender cópias do software. Sem restrições de uso comercial. Sem obrigação de abrir código derivado.

O que ela exige: incluir o texto da licença MIT original e o aviso de copyright em toda distribuição do software, seja código-fonte ou binário.

O que ela não cobre: patentes. A licença MIT não menciona patentes em nenhum momento. Se um contribuidor do projeto possui uma patente cobrindo algo implementado no código, ele tecnicamente pode processar usuários por violação de patente mesmo que o código seja MIT. Na prática isso raramente acontece em projetos pequenos, mas em infraestrutura crítica ou em ambientes corporativos com muito dinheiro envolvido, essa ausência importa.

Uso comercial: ✓
Distribuição proprietária: ✓
Modificação privada: ✓
Exigência de abrir código derivado: ✗
Proteção explícita de patentes: ✗

MIT é a licença certa para bibliotecas que você quer que sejam usadas por todo mundo, sem fricção. React, Vue, Rails, Express — todos MIT por essa razão exata.

Apache 2.0: permissiva com proteção de patentes

Apache 2.0 funciona essencialmente como MIT com um acréscimo importante: concessão explícita de patentes.

Qualquer contribuidor que submete código ao projeto concede automaticamente uma licença de suas patentes para todos os usuários do software, cobrindo os direitos necessários para usar, fazer, vender, e distribuir o software. Além disso, se um usuário entrar com processo de patente contra o projeto, ele perde automaticamente essa concessão de patentes.

Isso protege tanto quem usa quanto quem contribui. Um conglomerado com centenas de patentes que contribui para um projeto Apache não pode usar as mesmas patentes para processar os usuários do projeto posteriormente.

A diferença prática em relação ao MIT é relevante em dois cenários: (1) seu projeto pode ser alvo de litígios de patentes — software de infraestrutura, protocolos, compressão de dados; (2) você trabalha em empresa que exige revisão jurídica de dependências, e Apache 2.0 passa por esse processo mais facilmente do que MIT por cobrir explicitamente o tema.

Uso comercial: ✓
Distribuição proprietária: ✓
Modificação privada: ✓
Exigência de abrir código derivado: ✗
Proteção explícita de patentes: ✓
Concessão de patente revogável se você processar: ✓

Um detalhe de compatibilidade que aparece em projetos grandes: Apache 2.0 e GPL v2 são incompatíveis. Você não pode mesclar código Apache 2.0 em um projeto GPL v2. Apache 2.0 é compatível com GPL v3.

Kubernetes, Terraform, Elasticsearch (antes de mudar para SSPL), Android — todos Apache 2.0.

GPL: copyleft forte

GPL (GNU General Public License) é onde a conversa fica mais complexa.

A GPL v2 e v3 exigem que qualquer software que você distribua e que inclua ou seja derivado de código GPL também seja distribuído sob GPL — com código-fonte disponível para quem receber o binário. Essa propriedade é chamada de "copyleft forte" e é frequentemente descrita como "viral" ou "infecciosa", termos que carregam carga negativa mas descrevem o comportamento com precisão.

O que isso significa na prática: se você usa uma biblioteca GPL no seu produto fechado e distribui esse produto, você precisa disponibilizar o código-fonte completo do produto. Para software interno sem distribuição externa, não há problema — o copyleft se ativa apenas na distribuição.

Uso comercial: ✓ (desde que código seja aberto ao distribuir)
Distribuição proprietária: ✗
Modificação privada sem distribuir: ✓
Exigência de abrir código derivado ao distribuir: ✓ (todos os derivados)
Proteção de patentes: ✓ (v3)

GPL v3 adicionou proteções contra DRM e "tivoização" — a prática de distribuir hardware que usa software GPL mas impede fisicamente modificações no firmware. Devices de consumidor com firmware Linux patched às vezes entram nesse conflito. O projeto Linux usa GPL v2, deliberadamente, para evitar algumas cláusulas mais restritivas da v3.

Para bibliotecas que você quer que permaneçam open source mas que possam ser usadas em projetos proprietários, existe a LGPL (Lesser GPL). Ela permite que o código proprietário use a biblioteca dinamicamente sem precisar abrir o código — desde que a biblioteca em si continue LGPL. Qt (modo community), ffmpeg — LGPL resolve o caso de uso "quero que meu código seja open source mas não quero forçar isso em quem usa".

AGPL: copyleft para a era do SaaS

Há um gap que a GPL não cobre: você pode pegar código GPL, rodar num servidor como serviço, e nunca "distribuir" o software no sentido técnico. Seus usuários interagem com ele pela rede mas não recebem binário. GPL não exige que você abra código nesse caso.

A AGPL (Affero GPL) fecha esse gap. Se você rodar software AGPL como serviço acessível por rede, precisa disponibilizar o código-fonte para os usuários. Isso é o motivo pelo qual muitos projetos open source que competem com modelos SaaS escolhem AGPL — MongoDB (antes de mudar para SSPL), Grafana, Nextcloud.

Empresas que constroem produtos sobre código aberto geralmente evitam dependências AGPL com cuidado. Se o jurídico já pede licenças das suas dependências, AGPL vai aparecer com uma flag amarela.

A armadilha da compatibilidade

Licenças não são só documentos de termos — elas precisam ser compatíveis quando você combina código de múltiplas origens.

A regra básica:

• Código MIT pode entrar em projetos Apache 2.0, GPL, AGPL — sem problema.
• Código Apache 2.0 pode entrar em projetos GPL v3 e AGPL, mas não em GPL v2.
• Código GPL v2 pode entrar em projetos GPL v2, mas não em Apache 2.0 nem em projetos proprietários.
• Código GPL v3 pode entrar em projetos GPL v3 e AGPL.
• Código AGPL é o mais restritivo — infecta tudo com AGPL.

Isso importa quando você tem uma dependência transitiva. O package.json do seu projeto pode ter 300 dependências. Se uma delas for AGPL, você tem um problema jurídico se estiver rodando um SaaS sem abrir o código. A maioria das pessoas nunca olhou isso.

# Verificar licenças de todas as dependências npm
npx license-checker --summary

# Ou para Python
pip-licenses --order=license

Ferramentas como license-checker (npm) e pip-licenses (Python) automatizam a auditoria. Em projetos comerciais, vale rodar isso no CI.

Qual licença escolher para o seu projeto

Se você vai abrir código, essa é a árvore de decisão direta:

Você quer máxima adoção e não se importa com quem usar comercialmente? → MIT. Sem discussão.

Você quer a mesma liberdade da MIT mas com proteção de patentes (empresa grande contribuindo, risco de litígio)? → Apache 2.0.

Você quer que todos que distribuam seu código também o mantenham aberto? → GPL v3.

Você quer impedir que SaaS rode seu código sem contribuir de volta? → AGPL.

Você quer que sua biblioteca seja usável em produtos proprietários, mas o código da biblioteca em si permaneça open source? → LGPL.

Para geração rápida de arquivos de licença prontos para usar, o Gerador de UUID não ajuda aqui, mas o choosealicense.com da GitHub tem templates limpos de MIT, Apache e GPL com o ano correto preenchido automaticamente.

Perguntas frequentes

Posso usar código MIT em um produto comercial sem abrir o código-fonte?

Sim. Licenças permissivas como MIT e Apache 2.0 permitem uso comercial e distribuição proprietária. A única exigência da MIT é incluir o aviso de copyright e o texto da licença no produto distribuído. Você pode vender o produto, fechar o código-fonte, sublicenciar — sem problema. O que você não pode fazer é remover o crédito ao autor original.

Qual é a diferença entre GPL v2 e GPL v3?

GPL v3 (2007) adicionou três proteções ausentes na v2: (1) cláusula anti-tivoização — proíbe que fabricantes de hardware impeçam modificações em software GPL rodando nos seus dispositivos; (2) compatibilidade explícita com Apache 2.0 — que a v2 bloqueava; (3) proteção mais robusta contra patentes. O kernel Linux usa deliberadamente GPL v2 (sem a opção "ou posterior") justamente para evitar as restrições adicionais da v3, o que gerou debate na comunidade. Para novos projetos, GPL v3 é a escolha padrão.

Uma licença MIT "vira" GPL se eu combinar com código GPL?

O código MIT em si continua MIT. O que acontece é que o projeto combinado precisa ser distribuído sob GPL, porque os termos da GPL se aplicam à distribuição do trabalho combinado. Você não está forçando o autor do código MIT a mudar sua licença — você está aceitando que sua combinação específica precisa seguir as regras mais restritivas. É por isso que copyleft é descrito como "infeccioso": ele se propaga para o projeto que incorpora, não para os projetos externos.

Posso usar código AGPL num serviço interno sem disponibilizar o código?

Sim, com uma ressalva importante: "interno" precisa ser realmente interno. Se o serviço é usado apenas por funcionários da empresa sem disponibilidade externa, você provavelmente não está "distribuindo pela rede" no sentido da AGPL. Se usuários externos (clientes, parceiros) interagem com o serviço via rede, a AGPL se ativa. A linha é: quem tem acesso ao serviço é o mesmo grupo jurídico que controla o software? Sim → sem obrigação. Não → código precisa ficar disponível.

MIT, Apache, GPL — a escolha certa depende do que você quer proteger

Não existe licença universalmente melhor. MIT facilita adoção. Apache 2.0 protege quem contribui de litígios de patentes. GPL garante que o código permaneça livre. AGPL fecha o buraco do SaaS.

O erro comum não é escolher a licença errada para si mesmo — é não verificar as licenças das dependências. A sua escolha de licença para o projeto tem que ser compatível com tudo que está no grafo de dependências. Em projetos pequenos isso raramente é problema. Em produtos comerciais com dezenas de dependências, vale a auditoria.

A segunda armadilha é assumir que "open source" implica "pode usar como quiser". MIT sim. GPL não — pelo menos não sem abrir o código. Ler o arquivo LICENSE de um repositório antes de usar em produção leva dois minutos. O custo de não ler pode ser uma conversa desconfortável com o jurídico seis meses depois.