Licenças de software: um guia para entender permissões e obrigações

Relato técnico. Outubro de 2026. Um mapa para ler licenças, entender integrações e reconhecer as questões que precisam de análise jurídica no caso concreto.

Você encontra uma biblioteca que resolve um problema difícil, adiciona a dependência e continua desenvolvendo. Meses depois, o produto está pronto para chegar ao cliente. Nesse momento aparece uma pergunta que deveria ter acompanhado a escolha: o que essa licença permite — e o que ela exige de quem entrega o software?

A resposta depende do texto, da versão e do que você faz com o componente. Executar uma ferramenta, modificar uma biblioteca, entregar um instalador e oferecer um serviço pela internet são situações diferentes.

Este guia percorre as principais famílias de licenças, com exemplos de onde essas diferenças aparecem. A pergunta central é prática: quais permissões e obrigações acompanham o software que você está construindo?

O que uma licença concede

Uma licença concede permissões sobre direitos que, de outra forma, permanecem reservados ao titular. Pode autorizar cópia, modificação e redistribuição, estabelecendo condições para esses atos. A licença de código também não resolve, por si só, todos os direitos sobre marcas, patentes ou materiais de terceiros presentes no projeto.

O enquadramento jurídico não cabe na frase “toda licença é um contrato”. Condições de uma autorização autoral e obrigações contratuais podem ter consequências diferentes. Em Jacobsen v. Katzer, em 2008, um tribunal federal de apelações dos Estados Unidos reconheceu que determinadas exigências da Artistic License podiam funcionar como condições da licença autoral. A decisão reformou a análise anterior e devolveu o caso à instância de origem; não estabeleceu que qualquer descumprimento de qualquer licença produz automaticamente a mesma condenação. Decisão oficial [1].

Por isso, o ponto de partida é o texto aplicável ao componente e à versão recebida. Um selo no README ajuda a localizar a informação; não substitui a leitura das condições.

Permissivas, copyleft e o significado de aberto

Licenças permissivas concedem ampla liberdade de reutilização, inclusive em produtos proprietários, com condições como preservação de avisos. Licenças copyleft acrescentam obrigações de reciprocidade sobre o código coberto. O alcance dessa reciprocidade varia: arquivos, bibliotecas ou uma obra combinada, conforme a licença e a integração.

As duas famílias permitem atividade comercial. A definição de open source inclui livre redistribuição e não admite proibição de uso em determinados setores de atividade. Código visível com restrições a certos usos pode ser source-available, sem ser open source nesse sentido. Open Source Definition [2].

Para quem desenvolve, a diferença aparece em três perguntas: o que foi incorporado, o que foi modificado e quem recebe uma cópia ou interage com a versão em execução?

Licenças permissivas

MIT: permissões amplas, avisos preservados

A MIT permite usar, copiar, modificar, distribuir, sublicenciar e vender o software. Exige incluir o aviso de copyright e o texto da permissão nas cópias ou porções substanciais do material. Também contém exclusão de garantias e limitação de responsabilidade. Texto da MIT [3].

Exemplo: incorporar uma biblioteca MIT em um aplicativo pago pode ser permitido sem abrir o código do aplicativo. Os avisos da biblioteca continuam acompanhando a distribuição; trocar o nome do produto não elimina essa condição.

A MIT não contém uma concessão expressa de licença de patentes. Isso é diferente de afirmar que nenhum direito implícito poderia existir em qualquer jurisdição. Também não permite concluir que a questão de patentes seja irrelevante apenas porque o projeto é pequeno.

BSD: confira o número de cláusulas

A BSD de duas cláusulas exige preservar avisos, condições e exclusões de responsabilidade. Na redistribuição binária, essas informações devem aparecer na documentação ou nos materiais que acompanham a distribuição. A BSD de três cláusulas acrescenta a restrição ao uso dos nomes dos titulares ou contribuidores para endossar ou promover derivados sem autorização prévia por escrito. BSD-2-Clause [4], BSD-3-Clause [5].

As duas variantes não trazem uma concessão expressa de patentes. Escrever apenas “BSD” no inventário perde uma informação necessária: qual texto está sendo usado?

ISC: curta, com condições concretas

A ISC concede permissões amplas para uso, cópia, modificação e distribuição, com ou sem cobrança. Exige preservar os avisos de copyright e permissão e contém exclusões de garantia e responsabilidade. É uma licença concisa, mas seu texto ainda precisa acompanhar o uso conforme suas condições. Texto da ISC [6].

Apache 2.0: patentes e redistribuição mais detalhadas

A Apache 2.0 permite reutilização em software proprietário. Na redistribuição, exige fornecer a licença, identificar arquivos modificados e preservar os avisos pertinentes. Se houver NOTICE, os avisos de atribuição aplicáveis precisam ser reproduzidos em uma das formas permitidas pela seção 4. Não é uma obrigação de copiar indiscriminadamente qualquer arquivo com esse nome.

A seção 3 inclui uma concessão expressa de patentes dos contribuidores, limitada às reivindicações licenciáveis necessariamente infringidas pela contribuição, isoladamente ou combinada com a obra à qual foi submetida. Não cobre toda patente de todo contribuidor nem garante ausência de patentes de terceiros.

Há também término dessa licença de patentes quando o usuário inicia a ação patentária descrita na seção 3. A seção 6 não concede uma autorização geral de uso de marcas. Texto da Apache 2.0 [7].

Copyleft com alcance delimitado

MPL 2.0: a fronteira acompanha os arquivos cobertos

A MPL 2.0 é frequentemente descrita como copyleft no nível de arquivo. Ao distribuir executáveis que contenham software coberto, é preciso disponibilizar o respectivo código-fonte sob MPL e informar como obtê-lo. Isso inclui arquivos cobertos que você não modificou.

Arquivos separados que não sejam software coberto podem compor uma Larger Work sob outros termos, inclusive proprietários. Alterações mantidas apenas para uso privado não geram automaticamente uma obrigação de publicá-las. Texto da MPL 2.0 [8], FAQ da Mozilla [9].

Exemplo: se você modifica um arquivo MPL e distribui o resultado, esse arquivo continua sujeito à MPL. A licença não passa automaticamente a abranger cada arquivo independente do aplicativo.

LGPL: a biblioteca e a possibilidade de substituí-la

A LGPL permite determinadas combinações de bibliotecas livres com aplicações sob outras licenças. Na LGPLv3, a distribuição da obra combinada precisa atender condições que preservem a modificação da biblioteca e a recombinação com a aplicação. Isso envolve avisos e permissões, inclusive para engenharia reversa destinada a depurar essas modificações.

Uma possibilidade é um mecanismo adequado de biblioteca compartilhada. Outra envolve fornecer código objeto ou material suficiente da aplicação para permitir recombinação, além do código correspondente da biblioteca. Linkagem estática não obriga automaticamente a divulgar o fonte proprietário da aplicação; linkagem dinâmica não dispensa automaticamente as condições. LGPLv3, seção 4 [10].

A versão importa: LGPLv2.1 e LGPLv3 não são textos intercambiáveis. O empacotamento precisa ser examinado junto da licença efetivamente recebida.

EPL e CDDL: leia as definições da própria licença

A EPL 2.0 define o alcance do programa e das obras modificadas, incluindo distinções para trabalhos que apenas se ligam ou vinculam por nome às interfaces. Possui disposições próprias de patentes e de licenciamento secundário quando essa opção foi expressamente disponibilizada. Resumi-la a “copyleft de módulo” esconde essas condições. EPL 2.0 [11].

A CDDL também permite uma obra maior com código sob outros termos, mantendo obrigações sobre o software coberto. As versões 1.0 e 1.1 têm cláusulas de término relacionadas a patentes, com diferenças que exigem conferir o texto recebido. CDDL 1.0 [12], CDDL 1.1 [13].

GPL: distribuir uma obra coberta traz obrigações

GPLv2

Na GPLv2, distribuir uma obra coberta em forma binária exige cumprir as condições de disponibilização do código-fonte correspondente. Quando há uma obra derivada abrangida pela licença, a distribuição do conjunto deve observar a GPL. A própria licença distingue isso da mera agregação de programas independentes em um mesmo meio. GPLv2, seções 2 e 3 [14].

O alcance não é “tudo que está no mesmo computador”. É preciso entender a relação entre os componentes, as modificações e a forma de entrega. Executar um programa e desenvolver um programa derivado dele são atos distintos.

GPLv3

A GPLv3 define conveying como propagação que permite a terceiros fazer ou receber cópias. A mera interação pela rede, sem transferência de cópia, não se enquadra nessa definição. Mas um serviço web também pode entregar JavaScript, WebAssembly, aplicativos ou imagens de contêiner: cada artefato precisa ser examinado.

A versão 3 traz disposições expressas de patentes e, nas situações previstas para User Products, informações necessárias à instalação de versões modificadas. Também prevê mecanismos de restabelecimento de direitos após correção. Um deles envolve sanar a primeira violação notificada por determinado titular em até 30 dias; não é uma carência universal para qualquer descumprimento. GPLv3, seções 0, 6, 8 e 11 [15].

Fonte para quem? E pode cobrar?

Disponibilizar o fonte conforme a GPL não significa obrigatoriamente colocar tudo em um repositório público específico. A licença define destinatários e métodos de fornecimento ou oferta. Os destinatários, por sua vez, mantêm os direitos de redistribuição previstos nela. FAQ das licenças GNU [16].

Software sob GPL pode ser vendido. Pode haver receita com distribuição, suporte e serviços. O ponto a avaliar é a compatibilidade entre as obrigações e o modelo pretendido, especialmente quando se deseja restringir a redistribuição ou manter proprietária uma obra coberta. FSF: venda de software livre [17].

AGPL: uma condição adicional para interação em rede

A seção 13 da AGPLv3 estabelece uma obrigação específica: se você modificar o programa e a versão modificada permitir interação remota por rede, deve oferecer de forma destacada a todos esses usuários a possibilidade de obter, gratuitamente pela rede, o código-fonte correspondente dessa versão. AGPLv3, seção 13 [18].

“Usuários” não significa apenas clientes externos. Empregados que interagem remotamente com uma versão modificada também não estão categoricamente excluídos pelo texto. Chamar a instalação de interna não resolve a questão.

Executar uma versão sem modificações não aciona, por esse fato isolado, essa exigência específica de modificação. Isso não autoriza remover mecanismos existentes nem elimina outras condições aplicáveis, como as de distribuição de cópias. E a AGPL não é uma proibição de oferecer hospedagem comercial.

Exemplo: você modifica uma aplicação AGPL que as pessoas usam pelo navegador. É preciso examinar a oferta de fonte correspondente a quem interage com essa versão. A frase “ninguém baixou o servidor” não encerra a análise.

Mudanças de licença: o histórico precisa estar na direção certa

No caso da Grafana, a mudança de 2021 foi de Apache 2.0 para AGPLv3 nos projetos centrais Grafana, Loki e Tempo. Isso não descreve automaticamente todos os produtos e componentes da organização. Licenciamento da Grafana [19].

A Elastic anunciou em 2024 a AGPLv3 como opção adicional para as partes gratuitas do código-fonte de Elasticsearch e Kibana já disponíveis sob SSPL e Elastic License 2.0. As distribuições continuaram sob Elastic License. Não foi uma migração integral de todos os artefatos para AGPL. FAQ da Elastic [20].

No Redis 8 e posteriores, há escolha entre AGPLv3, SSPLv1 e RSALv2. Redis 7.2 e anteriores permanecem BSD-3-Clause; a faixa 7.4–7.8 está sob RSALv2 ou SSPLv1. O nome do produto sozinho não identifica a licença. Histórico oficial do Redis [21].

Domínio público, CC0, Unlicense e 0BSD

A Unlicense combina uma declaração de dedicação ao domínio público com permissões amplas e exclusão de garantias. O efeito jurídico dessa dedicação depende do direito aplicável; o texto não contém uma concessão expressa de patentes. Texto da Unlicense [22].

A CC0 procura renunciar a direitos autorais e conexos na medida permitida e contém uma licença de fallback quando a renúncia não produz o efeito pretendido. Exclui expressamente direitos de marcas e patentes do seu alcance. CC0 1.0, texto jurídico [23].

A 0BSD é uma licença permissiva sem condição de atribuição. Não depende de apresentar o software como domínio público e tampouco contém uma concessão expressa de patentes. Texto da 0BSD [24].

São instrumentos diferentes. A ausência de exigência de crédito não demonstra ausência de todos os demais direitos possíveis sobre o material.

Creative Commons: conteúdo e código exigem distinções

A Creative Commons recomenda licenças próprias de software para código, porque suas licenças de conteúdo não foram desenhadas para tratar questões como distribuição de fonte. Mas isso não autoriza dizer que toda licença CC é incompatível com software livre.

A própria organização considera a CC0 aceitável para software, com suas limitações, e explica uma compatibilidade específica e unidirecional entre CC BY-SA 4.0 e GPLv3 para certas adaptações. Essa exceção não torna qualquer combinação de licenças CC automaticamente compatível. FAQ oficial da Creative Commons [25].

Em um mesmo repositório, código, documentação e imagens podem ter licenças diferentes. Um README sob Creative Commons não significa necessariamente que a biblioteca também esteja sob ela.

Source-available: poder ler não é ter todas as liberdades

A SSPL da MongoDB contém uma condição de serviço mais ampla que a cláusula de rede da AGPL. Sua seção 13 alcança a disponibilização da funcionalidade do programa como serviço a terceiros e exige o Service Source Code, definido para incluir software de gerenciamento e operação necessário para executar uma instância do serviço. Não basta equipará-la a “AGPL com outro nome”. Texto da SSPL [26].

A SSPL não é aprovada pela OSI. A proposta de aprovação foi retirada; descrever o episódio como uma aprovação negada em decisão formal seria impreciso. Posição da OSI sobre a SSPL [27].

A Business Source License, frequentemente abreviada como BSL ou BUSL, foi criada pela MariaDB. Na versão 1.1, as permissões adicionais e a mudança futura para outra licença dependem dos parâmetros da obra: Additional Use Grant, Change Date e Change License. Durante a fase restrita, não é uma licença open source. Elastic License 2.0 é outro instrumento. Business Source License 1.1 [28].

O identificador SPDX dessa versão é BUSL-1.1. Não confundir com BSL-1.0, que identifica a Boost Software License, uma licença open source diferente. BUSL-1.1 na SPDX [29], Boost Software License 1.0 [30].

Examinar restrições de produção, hospedagem e concorrência faz parte da escolha. O fato de ser possível baixar o fonte não substitui essas condições.

Compatibilidade: versões e direção importam

Compatibilidade significa conseguir cumprir simultaneamente as condições aplicáveis à combinação pretendida. Não é apenas uma classificação entre licenças mais leves e mais fortes.

A Apache Software Foundation explica que Apache 2.0 é compatível com GPLv3, permitindo a combinação sob GPLv3, mas não com GPLv2. Se o componente admite uma versão posterior da GPL, essa opção pode mudar a análise. FAQ da Apache sobre compatibilidade [31].

Código permissivo pode participar de obras sob copyleft, preservados seus avisos e as condições pertinentes. O caminho inverso não é automático: receber código GPL não concede o direito de redistribuí-lo somente sob MIT. Exceções expressas, licenças alternativas e autorização de titulares podem mudar o resultado. FAQ GNU sobre combinações e compatibilidade [16].

Também importa distinguir GPL-2.0-only de GPL-2.0-or-later. “GPL” sem versão é informação insuficiente para decidir uma integração.

Dual licensing e open core

Em dual licensing, o mesmo código pode ser oferecido sob licenças alternativas. Uma delas pode ser copyleft; outra pode permitir determinadas integrações proprietárias mediante condições negociadas. Garantias e suporte dependem do acordo, não do nome da estratégia.

Quem oferece a alternativa precisa ter direitos suficientes para fazê-lo. Isso pode decorrer de titularidade, cessão ou permissões de contribuição adequadas. Um CLA é um caminho possível; não é uma exigência universal nem permite relicenciar direitos de terceiros que nunca foram concedidos. FSF: cessão de copyright e venda de exceções [32].

Em open core, o núcleo aberto convive com extensões ou recursos sob outros termos. A arquitetura ajuda a organizar as fronteiras, mas as licenças das dependências e a relação entre os componentes continuam relevantes. Separar pastas ou processos não constitui, por si só, uma conclusão jurídica sobre independência.

Compliance na prática: acompanhar o que sai do build

Uma política útil começa pelo inventário do que o produto realmente contém. Isso inclui dependências transitivas, código copiado, binários, fontes tipográficas, imagens e materiais gerados ou incorporados durante o build.

Um fluxo operacional pode seguir esta sequência:

1. Identificar componente, origem e versão. Registrar também modificações locais e os artefatos em que ele aparece. 2. Guardar o texto aplicável. Conferir licença da raiz, avisos por arquivo, exceções e licenças de terceiros incluídos no pacote. 3. Mapear os atos. Diferenciar execução, modificação, entrega de cópias e interação remota; examinar o que chega ao navegador e ao cliente. 4. Preparar as obrigações antes da entrega. Incluir avisos e, quando exigidos, fonte correspondente, ofertas e materiais de recombinação ou instalação. 5. Automatizar a detecção de mudanças. Usar scanners e um inventário de componentes — uma SBOM — para apontar dependências novas e divergências que precisam de revisão. 6. Conferir o pacote final. O inventário do repositório e o conteúdo efetivamente distribuído podem divergir.

Scanners ajudam a encontrar evidências; seus resultados precisam ser interpretados. Um arquivo sem licença identificada exige investigação. Publicação em um repositório visível não equivale, por si só, a uma autorização geral de reutilização. GitHub: licenciamento de repositórios [33].

SPDX: expressar a licença sem perder condições

Os identificadores SPDX permitem registrar licenças de forma padronizada. Uma expressão como MIT OR Apache-2.0 indica alternativas; MIT AND Apache-2.0 indica obrigações cumulativas no escopo representado; WITH associa uma exceção identificada a uma licença.

Uma linha como SPDX-License-Identifier: MIT ajuda ferramentas e pessoas a reconhecer a declaração. Ela não comprova que o declarante possuía todos os direitos. E constar na lista SPDX não significa aprovação pela OSI: a lista identifica também licenças que não são open source. Lista SPDX [34], especificação de expressões [35].

Um mapa rápido para voltar ao texto certo

MIT, BSD e ISC — Ponto principal a conferir: Permissões amplas, com os avisos e demais condições da variante recebida.

Apache 2.0 — Ponto principal a conferir: Redistribuição, avisos pertinentes, arquivos modificados e alcance da concessão de patentes.

MPL 2.0 — Ponto principal a conferir: Fonte dos arquivos cobertos na distribuição, inclusive os não modificados.

LGPL — Ponto principal a conferir: Condições da biblioteca e da obra combinada, incluindo substituição ou recombinação.

GPL — Ponto principal a conferir: Alcance da obra coberta, entrega de cópias e fornecimento do fonte correspondente.

AGPLv3 — Ponto principal a conferir: Condições da GPL e oferta de fonte na interação remota com a versão modificada.

Unlicense, CC0 e 0BSD — Ponto principal a conferir: Instrumentos distintos; atenção aos direitos que não concedem expressamente.

SSPL e Business Source License — Ponto principal a conferir: Condições próprias de serviço ou uso; não classificá-las automaticamente como open source.

A tabela é um índice, não uma substituição dos textos. Um rótulo genérico de “baixo risco” ou “alto risco” diz menos que uma descrição concreta da integração e das obrigações que serão cumpridas.

A licença acompanha decisões de arquitetura, distribuição e negócio desde a primeira dependência. Entender essa relação permite escolher com mais clareza o que reutilizar, o que compartilhar e como sustentar o produto sem apagar os direitos de quem construiu suas partes.