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 redistribui o software? A MIT exige apenas um aviso de copyright. A Apache 2.0 exige esse aviso e também um acordo sobre patentes entre todas as pessoas que alteram o código. A GPL exige que publique o código-fonte do que criou com base no software, 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 dois repositórios de pacotes à sua escolha e bibliotecas cliente que 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 relacionado com Unix sob uma licença que exigia a manutenção do aviso de copyright e excluía todas as garantias. A versão original tinha quatro cláusulas. A quarta, conhecida como 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 distintos numa versão de 1997 do NetBSD. 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 acrescenta a proibição de usar os nomes dos contribuidores para endossar o seu produto, e a versão de 2 cláusulas, que elimina até essa restrição. O texto da licença MIT surgiu no MIT na década de 1980, onde abrangia o X Window System, e, na prática, cumpre 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 bem comum que não pudesse ser fechado. Ambas as posições são legítimas e ambas têm um modo de falhar. O código permissivo pode tornar-se privado e não se recebe nada em troca. 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 artigo 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 desenvolver sobre BSD, e a adoção estagnou enquanto o Linux crescia. A incerteza jurídica trava a adoção mais depressa do que uma funcionalidade em falta.

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 do relicenciamento: SSPL, BUSL e o que não são

O gatilho 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 essa utilização. 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, ao mudar 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, terá de publicar o código-fonte de tudo o que usar para o oferecer, incluindo o software de gestão e orquestração associado. Essa obrigação não tem um limite claro e nenhum tribunal a avaliou. 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 devia fazer parte do 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 um relicenciamento: 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 é gratuita, exceto a utilização que o fornecedor exclui, normalmente 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 dessa release. A licença para a qual se converte tem de ser compatível com a GPLv2. A HashiCorp mudou 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 é relevante se estiver a escolher entre as alternativas self-hosted ao Notion: é permitido executá-la para a sua própria equipa, mas não criar um serviço baseado nela.

Nenhuma das licenças é desonesta. Ambas afirmam claramente que o código-fonte está disponível. Nenhuma é open source segundo a definição da OSI, e a diferença afeta-o a si, não o fornecedor de cloud que a licença pretendia atingir.

OpenSearch: o custo operacional de um fork de licença

A Elastic anunciou em 14 January 2021 que Elasticsearch e Kibana deixariam a Apache 2.0 para passar a oferecer uma escolha entre a SSPL e 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 os projetos. O fork recebeu o nome OpenSearch em 12 April 2021, e o Kibana foi renomeado para OpenSearch Dashboards. O OpenSearch 1.0 ficou geralmente disponível em 12 July 2021, com base no Elasticsearch 7.10.2 e no Kibana 7.10.2.

Veja o custo disso para quem administrava os clusters. Os nomes dos pacotes e dos repositórios mudaram. Cada referência ao Kibana num runbook passou a referir-se ao OpenSearch Dashboards. Os nomes dos plugins mudaram. Depois, a separação chegou ao código das aplicações: a partir da versão 7.13 das bibliotecas cliente oficiais da Elastic, o cliente verifica a que produto se ligou e recusa continuar se não for Elasticsearch, informando que o servidor é um produto desconhecido. Uma decisão de licença tomada numa empresa onde você não trabalha passou a causar uma falha dentro da sua própria aplicação.

A história teve mais duas mudanças. A Elastic adicionou a AGPLv3 como terceira opção de licença em 29 August 2024, por isso o Elasticsearch atual voltou a ser software 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 governança que não pertence a uma única empresa. Cinco anos depois da separação, os dois projetos são open source, ambos são mantidos, e o OpenSearch está na série 3.x em August 2026.

A conclusão é a lição. A licença voltou, mas o fork permaneceu. Quando um ecossistema passa a ter duas versões de tudo, desfazer a alteração documental não volta a uni-las.

O número que determina o impacto de uma relicenciamento é o intervalo entre o anúncio e um fork estável que você possa realmente 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é a primeira release estável do fork, usando as datas indicadas abaixo. O OpenSearch 1.0 levou 179 dias, porque o fork teve de ser renomeado e reconstruído sem um fork anterior que pudesse copiar. O OpenTofu levou 153 dias. O Valkey levou 27 dias, porque foi criado a partir do Redis 7.2.4 e manteve o protocolo e o formato em disco idênticos. A direção é a parte importante: um fork credível agora surge em semanas, com uma fundação e maintainers remunerados associados 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.