GPL, MIT ou Apache: o que cada licença exige

GPL vs MIT vs Apache: o que cada licença exige de si

GPL, MIT e Apache 2.0 respondem à mesma pergunta de formas diferentes: o que deve a outras pessoas quando distribui o software? A MIT exige um aviso de copyright e nada mais. A Apache 2.0 exige esse aviso e também um compromisso relativo a patentes com todas as pessoas que contribuem para o código. A GPL exige que publique o código-fonte do que criou sobre essa base, sob a mesma licença que recebeu.

Isto parece uma questão para advogados até ao dia em que um projeto que gere muda de licença e se divide em dois. A partir daí, passa a ser uma questão operacional. Tem de escolher entre dois repositórios de pacotes, e as bibliotecas cliente deixam de comunicar entre si. Este guia trata das licenças e dos seus mecanismos, não do movimento que as criou. Por isso, cada secção termina no ponto em que o assunto o afeta: a pessoa responsável por executar a atualização.

Por que a GPL existe: uma impressora que ninguém podia reparar

Por volta de 1980, o laboratório de Inteligência Artificial do MIT recebeu uma impressora laser Xerox 9700. O laboratório tinha corrigido o software de uma impressora anterior para que ela avisasse quando um trabalho ficava bloqueado. Para a nova impressora, não havia código-fonte, e o pedido de acesso foi recusado por causa de um acordo de confidencialidade. Richard Stallman, então programador do laboratório, interpretou essa recusa como um problema estrutural, e não como um incidente isolado, e anunciou o projeto GNU em 27 September 1983.

O copyleft é construído com base na legislação de direitos de autor, não contra ela. Por defeito, não tem qualquer direito de copiar o código de outra pessoa. A GPL concede esse direito sob uma condição: se fornecer o programa a outra pessoa, também terá de lhe fornecer o código-fonte, nos mesmos termos, para que ela possa fazer o que o laboratório não pôde fazer. A condição pode ser aplicada porque, sem a licença, não tinha autorização para copiar o programa.

Stallman escreveu primeiro uma licença para o GNU Emacs e depois generalizou-a na GPL version 1, em 25 February 1989. A GPL version 2 surgiu em June 1991 e continua a ser a licença da maior parte do software de sistema que utiliza. A Lesser GPL foi criada para bibliotecas, permitindo que uma biblioteca copyleft fosse ligada por um programa sob qualquer licença sem sujeitar esse programa à GPL.

Um detalhe determina como a GPL afeta quem aloja os próprios serviços. A obrigação é desencadeada pela distribuição, não pela utilização. Pode modificar um programa GPL, executá-lo no seu próprio servidor e disponibilizá-lo ao público sem dever nada a ninguém, porque nunca entregou uma cópia. Essa lacuna é a razão pela qual a AGPL existe.

A tradição permissiva: BSD e depois MIT

Berkeley seguiu um caminho diferente. O Computer Systems Research Group publicou o seu trabalho Unix sob uma licença que exigia a manutenção do aviso de copyright e excluía qualquer garantia. A versão original tinha quatro cláusulas. A terceira, a cláusula de publicidade, exigia o reconhecimento da Universidade em todo o material publicitário que mencionasse funcionalidades do software. Isso não escala. Stallman contou 75 reconhecimentos separados numa versão de NetBSD de 1997. A UC Berkeley retirou a cláusula em 22 July 1999, numa carta de William Hoskins, do seu Office of Technology Licensing.

O que resta é a licença BSD de 3 cláusulas, que mantém a proibição original de usar os nomes dos contribuidores para endossar o seu produto, e a versão de 2 cláusulas, que elimina até essa proibição. O texto da licença MIT surgiu no MIT na década de 1980, onde abrangia o X Window System. Na prática, desempenha a mesma função que a BSD de 2 cláusulas.

As motivações eram diferentes. Uma universidade financiada com dinheiro público queria que o seu trabalho fosse usado em todo o lado, incluindo por empresas. O projeto GNU queria um património comum que não pudesse ser fechado. Ambas as posições são legítimas e ambas têm uma forma de falhar. O código permissivo pode passar a ser privado, sem que nada seja devolvido. O código copyleft é recusado por empresas cujos advogados não aceitam essa condição.

Há uma segunda lição de Berkeley, e é aquela a que este texto regressa repetidamente. A AT&T's Unix System Laboratories processou a Berkeley Software Design em 1992 por causa do código BSD, e o caso foi resolvido no início de 1994. Durante 2 anos, ninguém podia ter a certeza de que era seguro criar software com base no BSD, e a adoção estagnou enquanto o Linux crescia. A incerteza jurídica trava a adoção mais depressa do que a ausência de uma funcionalidade.

Por que o Apache 2.0 adicionou uma concessão de patentes

A primeira licença do Apache Group era um derivado da BSD de 4 cláusulas, com o mesmo problema de publicidade. A versão 1.1, em 2000, removeu essa cláusula. A versão 2.0, publicada em janeiro de 2004, foi uma reescrita, não apenas uma correção.

A adição importante diz respeito às patentes. As licenças MIT e BSD não dizem absolutamente nada sobre elas. Um contribuidor pode conceder uma autorização clara de direitos de autor para o seu código e ainda deter uma patente aplicável ao que o código faz, podendo depois processar judicialmente as pessoas que o utilizam. O Apache 2.0 elimina essa lacuna: cada contribuidor concede uma licença de patente que abrange a sua contribuição, e qualquer pessoa que processe judicialmente alegando que o trabalho infringe as suas patentes perde a própria licença de patente sobre esse trabalho. A ameaça é mútua, portanto, na prática, ninguém a usa.

O restante da versão 2.0 é administrativo, e é por isso que as empresas gostam dela. Existe um ficheiro NOTICE definido, por isso a atribuição fica num único local, em vez de estar espalhada pela árvore de código. A licença pode ser aplicada por referência, em vez de ser colada em cada ficheiro de código-fonte. As contribuições são abrangidas por termos explícitos. As marcas comerciais ficam excluídas. Uma análise jurídica de uma dependência Apache 2.0 encontra no texto a resposta a todas as perguntas relevantes, pelo que a aprovação se torna rotineira, que é, em grande parte, o significado de "padrão corporativo".

O que a GPLv3 mudou e por que o Linux permaneceu na GPLv2

A TiVo lançou um gravador de vídeo com Linux e publicou o código-fonte do kernel, exatamente como a GPLv2 exige. Depois, o hardware verificava uma assinatura criptográfica durante o arranque e recusava executar um kernel que não reconhecesse. Era possível ler o código-fonte, alterá-lo e compilá-lo. Não era possível executá-lo no dispositivo de origem. A letra da licença era cumprida, mas a sua finalidade era anulada. Esta prática passou a ser conhecida como tivoização.

A versão 3 da GPL, publicada em 29 de June 2007, responde diretamente a este problema. Quando distribui o binário dentro de um dispositivo de consumo, também tem de fornecer as "Informações de instalação": as chaves ou as instruções necessárias para instalar uma versão modificada e fazê-la funcionar. A versão 3 também acrescentou uma concessão explícita de patentes, termos elaborados em resposta ao acordo de patentes entre a Microsoft e a Novell de November 2006 e compatibilidade unidirecional com a Apache 2.0.

O Linux não seguiu esse caminho. O kernel está apenas sob a GPL version 2, sem a cláusula de escape "ou qualquer versão posterior", e o seu ficheiro COPYING indica isso. Linus Torvalds opôs-se publicamente aos termos antitivoização aplicáveis a hardware assinado. A barreira prática é maior do que essa discordância: o kernel tem milhares de titulares de direitos de autor, pelo que ninguém poderia obter as autorizações necessárias para uma relicenciamento, mesmo que todos quisessem fazê-lo. Esse único facto é a proteção mais forte que um projeto pode ter, e vale a pena lembrá-lo quando analisar um projeto pertencente a uma única empresa.

A outra licença de 2007 é mais relevante para si. A GNU Affero GPL version 3, publicada em November do mesmo ano, estende a obrigação de disponibilizar o código-fonte às pessoas que interagem com o programa através de uma rede. Se executar um serviço AGPL modificado para o público, deve disponibilizar o código-fonte a esses utilizadores. É por isso que tanto software web self-hosted usa a AGPL. O Nextcloud é um exemplo. Se estiver a comparar as alternativas self-hosted ao Nextcloud, a linha da licença no repositório de cada candidato diz-lhe mais sobre os cinco anos seguintes do projeto do que a sua lista de funcionalidades.

Quais licenças podem ser combinadas efetivamente?

A compatibilidade funciona num único sentido, de licenças permissivas para licenças copyleft.

• Código MIT e BSD pode ser incluído em qualquer projeto, incluindo um produto fechado.
• Código Apache 2.0 pode ser incluído num projeto GPLv3, e a obra combinada fica sob GPLv3.
• Código Apache 2.0 não pode ser incluído num projeto apenas GPLv2. As cláusulas de cessação de patentes e indemnização são condições adicionais que a GPLv2 não permite acrescentar. A FSF e a ASF publicam ambas esta conclusão.
• Não pode mudar código GPL para uma licença permissiva. Apenas os detentores dos direitos de autor podem fazê-lo, o que leva novamente à questão de quem são eles.

A era das alterações de licença: SSPL, BUSL e o que não são

O motivo foi comercial. Uma empresa detém os direitos de autor de um produto, um fornecedor de cloud vende-o como serviço gerido em grande escala e contribui pouco para o projeto, e a empresa altera a licença para impedir isso. A Redis Labs tomou a primeira medida visível em agosto de 2018, ao adicionar a Commons Clause à Apache 2.0 para vários dos seus módulos. A MongoDB seguiu-se em 16 de outubro de 2018, passando da AGPLv3 para a Server Side Public License.

A SSPL é a AGPL com uma secção reescrita. Se oferecer o programa a terceiros como serviço, tem de publicar o código-fonte de tudo o que utiliza para o oferecer, incluindo o software de gestão e orquestração à sua volta. Essa obrigação não tem um limite claro e nenhum tribunal a testou. A OSI nunca aprovou a licença, e a MongoDB retirou o seu pedido em março de 2019. A Debian já tinha declarado, em dezembro de 2018, que o software SSPL não pertencia ao seu arquivo, e a Fedora decidiu em janeiro de 2019 que a licença não é livre. Depois disso, a Red Hat removeu a MongoDB da Fedora e do Red Hat Enterprise Linux. Esse é o resultado mecânico de uma alteração de licença: a distribuição deixa de empacotar o software, pelo que as atualizações passam a vir de um repositório do fornecedor, segundo o calendário do fornecedor.

A Business Source License é um mecanismo diferente. Foi criada pelos fundadores da MariaDB, e a versão 1.1 data de 2017. Não é copyleft nem open source. O código-fonte é público e a utilização não produtiva é gratuita. A utilização em produção só é permitida na medida prevista pela Additional Use Grant do fornecedor, e essa concessão normalmente impede a execução de um serviço alojado concorrente. Cada release converte-se automaticamente numa licença open source real numa data de alteração que ocorre, no máximo, quatro anos depois desse release. A licença para a qual converte tem de ser a GPL versão 2.0 ou posterior, ou uma licença compatível com uma delas. A HashiCorp passou o Terraform e os seus outros produtos para a BUSL 1.1 em 10 de agosto de 2023. A Outline também a utiliza, o que é importante saber se estiver a escolher entre alternativas self-hosted ao Notion: é permitido executá-la para a sua própria equipa, mas não é permitido criar um serviço baseado nela.

Nenhuma das licenças é desonesta. Ambas afirmam claramente que disponibilizam o código-fonte. Nenhuma é open source segundo a definição da OSI, e a diferença recai sobre si, não sobre o fornecedor de cloud a que a licença se destinava.

OpenSearch: o custo de uma mudança de licença para quem opera

A Elastic anunciou em 14 January 2021 que Elasticsearch e Kibana deixariam a Apache 2.0 para adotar a SSPL ou a Elastic License, a partir da release 7.11. A versão 7.10.2 foi a última release sob Apache 2.0. Cerca de uma semana depois, a AWS informou que criaria e manteria um fork Apache 2.0 de ambos. O fork recebeu o nome OpenSearch em 12 April 2021, e o Kibana passou a chamar-se OpenSearch Dashboards. O OpenSearch 1.0 ficou disponível em geral em 12 July 2021, baseado no Elasticsearch 7.10.2 e no Kibana 7.10.2.

Veja o custo disso para quem operava clusters. Os nomes dos pacotes e os repositórios mudaram. Todas as referências a Kibana num runbook passaram a referir-se a OpenSearch Dashboards. Os nomes dos plugins foram alterados. Depois, a separação chegou ao código das aplicações: a partir da versão 7.13 das bibliotecas oficiais de cliente da Elastic, o cliente verifica a que produto se ligou e recusa continuar quando o destino não é Elasticsearch, informando que o servidor é um produto desconhecido. Uma decisão de licenciamento tomada numa empresa onde não trabalha passou a manifestar-se como uma chamada com falha dentro da sua própria aplicação.

A história mudou de direção mais duas vezes. A Elastic anunciou em 29 August 2024 que adicionaria a AGPLv3 como terceira opção de licença, e a FAQ de licenciamento indica September 2024 como o momento dessa adição. Assim, o Elasticsearch atual voltou a ser open source aprovado pela OSI. Em 16 September 2024, a AWS transferiu o OpenSearch para a OpenSearch Software Foundation, alojada pela Linux Foundation. Isso deu ao fork uma estrutura de governação que não depende de uma única empresa. Cinco anos depois da separação, ambos os projetos são open source e mantidos, e o OpenSearch está na série 3.x em October 2026.

A conclusão é esta. A licença voltou, mas o fork permaneceu. Quando um ecossistema passa a ter duas versões de tudo, corrigir a documentação legal não volta a unificá-lo.

O número que determina o impacto de uma relicença é o intervalo entre o anúncio e um fork estável que possa efetivamente implementar.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Cada intervalo é contado desde o anúncio público do fornecedor até à primeira release estável do fork, usando as datas indicadas abaixo. O OpenSearch 1.0 demorou 179 dias, porque o fork teve de ser renomeado e reconstruído sem existir um fork anterior que pudesse servir de base. O OpenTofu demorou 153 dias. O Valkey demorou 27 dias, porque foi criado a partir do Redis 7.2.4 e manteve o protocolo e o formato em disco idênticos. A tendência é o aspeto relevante: atualmente, um fork credível surge em poucas semanas, com uma fundação e maintainers pagos desde o primeiro dia.

Valkey e OpenTofu: o mesmo padrão, mais rápido

A Redis Ltd mudou a licença do Redis da BSD de 3 cláusulas para uma escolha entre RSALv2 e SSPLv1 em 20 March 2024. Oito dias depois, a Linux Foundation anunciou o Valkey, derivado do Redis 7.2.4 e mantido sob a BSD de 3 cláusulas. O Valkey 7.2.5 foi lançado em 16 April 2024 com o mesmo protocolo e os mesmos ficheiros de dados. Para a maioria dos operadores, a migração consistiu em mudar o nome do pacote. Em seguida, a Redis adicionou a AGPLv3 como terceira opção no Redis 8, em May 2025. Pela definição da OSI, isto voltou a tornar o Redis open source, enquanto o Valkey continua sob a sua própria governação. O padrão é muito semelhante ao do Elasticsearch.

O Terraform seguiu o mesmo percurso, com um capítulo adicional. O OpenTofu foi derivado da última versão lançada sob a Mozilla Public License 2.0, entrou para a Linux Foundation em September 2023 e lançou a versão 1.6.0 em 10 January 2024. Em 3 April 2024, os advogados da HashiCorp enviaram ao projeto uma carta de cease and desist, alegando que tinha sido copiado para o fork código de uma versão do Terraform licenciada sob a BUSL. O OpenTofu publicou uma resposta detalhada em 11 April 2024, negou a alegação e rastreou o código contestado até ao histórico licenciado sob a MPL que os dois projetos partilham. Não houve mais desenvolvimentos públicos. O risco real desse episódio é o que deve ser recordado: uma acusação, por si só, pode congelar a adoção durante um trimestre. Foi o mesmo efeito que o processo de Berkeley teve trinta anos antes.

Nem todos os forks começam com uma licença. O Forgejo foi derivado do Gitea em 2022, depois de o desenvolvimento do Gitea ter passado para uma empresa. Tratou-se de uma disputa de governação, não de licenciamento. O Forgejo manteve a licença MIT durante a série 8, mas mudou para GPLv3 ou posterior a partir da versão 9.0, em 2024, para impedir que o seu trabalho fosse incorporado novamente num produto sob controlo comercial. Se estiver a avaliar as opções de servidores Git autoalojados, esse par é o exemplo atual mais claro de uma base de código e duas filosofias.

O teste a executar antes de adotar qualquer solução

Quatro perguntas, a responder antes da primeira instalação e não depois.

1. Quem detém os direitos de autor? A relicenciamento requer autorização de todos os titulares dos direitos de autor. Por isso, um projeto com centenas de colaboradores independentes e sem cessão de direitos não pode, na prática, ser relicenciado. Um projeto pertencente integralmente a uma empresa pode ser relicenciado numa reunião do conselho de administração.
2. Existe um CLA e o que é que ele concede? Um acordo de licença de colaborador que permita à empresa relicenciar a sua contribuição nos termos que entender é o mecanismo exato por trás de todos os relicenciamentos referidos acima. Um DCO (developer certificate of origin), a linha de assinatura adotada pelo kernel Linux em 2004, não transfere quaisquer direitos. Um CLA detido por uma fundação é mais seguro do que um detido por uma empresa, porque uma empresa pode ser vendida.
3. Quem detém a marca comercial? A Elastic manteve o nome Elasticsearch, por isso o fork teve de mudar de nome e todos os runbooks que mencionavam Kibana tiveram de ser reescritos.
4. Quanto lhe custaria, em particular, um relicenciamento? Tenha em conta o formato dos dados, as bibliotecas cliente, a configuração que teria de reescrever e se já existe um fork compatível.

Dois comandos respondem a parte destas perguntas em poucos segundos.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Todos os pacotes Debian e Ubuntu incluem um ficheiro em /usr/share/doc/<package>/copyright. Esse ficheiro regista a licença da versão que instalou, não a licença que o projeto utiliza atualmente. Para bash no Ubuntu 24.04, esse ficheiro indica a GNU General Public License version 3. Execute o segundo comando dentro de um checkout do código-fonte para obter o histórico do próprio ficheiro de licença. Vale a pena ler um commit desse ficheiro dos últimos dois anos antes de criar qualquer solução baseada no projeto. Se o comando não apresentar nada, o repositório dá outro nome ao ficheiro de licença. Nesse caso, liste o diretório raiz e procure.

Nenhuma licença o protege de todos os resultados possíveis, e escolher com base na ideologia é uma forma de acabar surpreendido. Prefira projetos cujos direitos de autor estejam distribuídos por muitas pessoas ou sejam detidos por uma fundação, e mantenha os dados num formato que possa exportar. Depois, descubra para que fork migraria e anote o nome antes de precisar dele. Aplicar esta verificação a cada candidato demora menos de uma hora e é isso que distingue uma atualização de uma migração quando decide o que alojar por conta própria em 2026.

FAQ

A licença MIT é igual à licença BSD?

Na prática, a MIT corresponde à licença BSD de 2 cláusulas: mantenha o aviso de copyright e a isenção de garantia e, depois, faça o que quiser, incluindo criar um produto proprietário. A licença BSD de 3 cláusulas acrescenta uma condição: proíbe usar os nomes dos contribuidores para recomendar o seu produto sem autorização. A versão mais antiga, com 4 cláusulas, também exigia um reconhecimento no material publicitário. A UC Berkeley removeu essa cláusula em 22 July 1999, pelo que quase nada atual ainda a inclui.

Posso incluir código Apache 2.0 num projeto GPLv2?

Não. A Apache 2.0 acrescenta condições que a GPLv2 não permite acrescentar, sobretudo a cláusula de cessação de direitos de patente. Por isso, uma obra combinada não pode cumprir ambas as licenças ao mesmo tempo. A FSF e a ASF publicam esta conclusão. A relação inversa funciona: o código Apache 2.0 pode ser incluído num projeto GPLv3, e o resultado fica sob GPLv3. É também por isso que o código Apache 2.0 não pode ser integrado no kernel Linux, que usa apenas a GPL version 2.

A SSPL é uma licença de código aberto?

Não, e a resposta tem consequências práticas. A OSI nunca a aprovou, e a MongoDB retirou o pedido em March 2019. A Debian afirmou em December 2018 que o software SSPL não pertencia ao seu arquivo. Em January 2019, a Fedora decidiu que a licença não era livre. Depois disso, a Red Hat removeu o MongoDB da Fedora e do Red Hat Enterprise Linux. Para si, isto significa que um pacote anteriormente mantido pela sua distribuição passa a vir de um repositório do fornecedor, seguindo o calendário de suporte do fornecedor. A Business Source License também disponibiliza o código-fonte sem ser uma licença de código aberto, embora cada release seja convertida numa licença de código aberto no prazo de four years.

Uma alteração da licença aplica-se à versão que já tenho em execução?

Não. Uma licença concedida com uma release não pode ser retirada das cópias já publicadas. É exatamente por isso que os forks são possíveis. O OpenSearch foi criado a partir do Elasticsearch 7.10.2, a última release que a Elastic publicou sob Apache 2.0. O que perde é o futuro, porque a próxima correção de segurança será disponibilizada sob os novos termos. Fixar a última versão com uma licença permissiva pode comprar alguns meses, mas não é um plano.