Entre as licenças open source mais usadas, MIT, Apache e GPL autorizam outras pessoas a usar, modificar e redistribuir seu código, mas cada uma distribui as obrigações de um jeito diferente. A escolha entre MIT, Apache e GPL muda duas coisas na prática: o quanto você precisa preservar dos avisos do projeto original e se o seu próprio código precisa continuar aberto. Entender essas duas variáveis evita escolher por costume e descobrir o erro só quando o produto já está no ar — a distância entre manter uma linha de crédito num arquivo e publicar todo o seu código-fonte.
O que open source exige
Antes de comparar as três, vale separar dois rótulos que costumam se misturar. Open source é um critério de conformidade, não uma licença específica. A definição pública da Open Source Initiative lista dez critérios que uma licença precisa cumprir; entre eles, a licença não pode restringir a venda ou doação do software nem exigir royalty ou taxa por isso, e o programa precisa ser distribuído com código-fonte. MIT, Apache e GPL cumprem esses critérios de formas diferentes — e é justamente aí que a comparação começa.
A primeira divisão útil separa licenças permissivas de copyleft. Licenças permissivas — MIT e Apache — pedem pouco: mantenha os avisos e siga em frente, inclusive em produtos fechados. Copyleft — GPL — pede mais: quem distribui versões modificadas precisa distribuí-las sob os mesmos termos. A segunda divisão é o tamanho da obrigação documental, que vai de uma linha de copyright no MIT até o controle de avisos, marcações de alteração e arquivo NOTICE exigido pelo Apache.
MIT, Apache e GPL comparadas
MIT é a mais curta e a mais adotada. A licença permite usar, copiar, modificar, combinar, publicar, distribuir, sublicenciar e vender cópias do software, desde que o aviso de copyright original acompanhe as cópias. É a escolha natural quando o objetivo é máxima adoção com mínimo atrito: bibliotecas pequenas, exemplos de código, ferramentas que você quer ver espalhadas pela comunidade.
O Apache acrescenta duas camadas de proteção sobre essa mesma base permissiva: uma cláusula explícita de patentes e obrigações de redistribuição mais detalhadas — quem redistribui precisa entregar uma cópia da licença, marcar de forma visível os arquivos que modificou e preservar todos os avisos de copyright, patente e atribuição do projeto original. Em troca, o texto oficial da licença Apache, na versão 2.0, concede aos usuários uma licença de patentes dos contribuidores, algo que o MIT nem chega a mencionar. Para projetos com participação corporativa, essa previsão costuma pesar mais do que o texto mais longo.
A GPL é a única das três com copyleft forte: um programa liberado sob a GPL continua software livre não importa quem o modifique ou distribua, e quem distribui precisa repassar as mesmas liberdades aos destinatários. A versão atual, publicada em 29 de junho de 2007, também exige que quem distribua código objeto dê ao destinatário um caminho para obter o código-fonte. Se você mistura código GPL no seu produto e o distribui, o produto combinado precisa sair sob a GPL.
| Critério | MIT | Apache 2.0 | GPL v3 |
|---|---|---|---|
| Ver código e modificar | Sim | Sim | Sim |
| Usar em produto fechado | Sim | Sim | Não, se o combinado for distribuído |
| Obrigação principal | Manter aviso de copyright | Licença, marcações de alteração e avisos | Liberar o derivado sob a mesma licença |
| Cláusula de patentes | Não trata | Sim | Sim, com perda da licença em caso de processo |
| Uso típico | Bibliotecas e exemplos | Projetos corporativos e de fundação | Software que precisa permanecer livre |
Combinar licenças é onde a maioria dos erros acontece. O guia oficial do GNU registra que a GPL v3 passou a ser compatível com a licença Apache 2.0 — cita exatamente esse caso como exemplo de nova compatibilidade. O caminho inverso, porém, não existe: você não pode levar código GPL para dentro de um produto fechado sem liberar o combinado. Antes de misturar componentes, confirme a direção da compatibilidade na documentação de cada licença envolvida.
Como escolher em 5 passos
- Defina o objetivo do projeto: máxima adoção sugere licença permissiva; garantir que derivados permaneçam abertos sugere GPL.
- Verifique o que você está reaproveitando: código GPL recebido impõe copyleft ao combinado; código MIT ou Apache pode entrar em produto fechado se você mantiver os avisos.
- Cheque a cláusula de patentes: se o projeto tem risco de patente ou parceiros corporativos, o Apache 2.0 reduz incerteza que o MIT não cobre.
- Prepare os arquivos de conformidade antes de publicar: arquivo LICENSE com a licença completa, cabeçalho nos arquivos principais e, no Apache, o arquivo NOTICE com as atribuições.
- Documente a decisão: registre no README qual licença foi aplicada e por quê, para que futuros mantenedores não reabram a escolha sem motivo.
Se a decisão envolver consumir software aberto em vez de publicar, a lógica se inverte: prefira componentes com licença clara e compatível entre si. O mesmo vale para serviços públicos e dados abertos — o passo a passo da API do IBGE mostra como uma fonte documentada reduz a margem de erro em decisões com números, e o guia sobre agentes de IA segue a mesma regra para ferramentas: entender as condições de uso antes de depender do resultado.