Licenças de software de IA e open source explicadas: MIT vs Apache vs GPL vs AGPL vs proprietária

Fatos rápidos

• MIT é a licença permissiva mais curta e comum — cerca de 170 palavras, sem cláusula de patente.
• Apache-2.0 adiciona uma concessão explícita de patente que a MIT não tem, por isso muitas empresas a preferem para projetos de origem corporativa.
• A GPL exige divulgação de código-fonte apenas ao distribuir o software; a AGPL-3.0 estende essa exigência para a execução como serviço de rede.
• "Open source" aprovado pela OSI é uma certificação específica da Open Source Initiative; "source-available" e "fair-code" são termos de marketing para licenças que não atendem a essa definição.
• Licenças de modelos de IA são uma categoria separada das licenças de código. O código de uma ferramenta pode ser Apache-2.0 enquanto os pesos do modelo que ela baixa carregam termos completamente diferentes, muitas vezes mais restritivos.

O que são licenças permissivas? MIT, Apache-2.0 e BSD

• A licença MIT teve origem no Massachusetts Institute of Technology como forma de liberar software desenvolvido na universidade com restrição mínima. Tem cerca de 170 palavras, concede direitos quase ilimitados e exige apenas que o texto original de copyright e licença permaneça em qualquer cópia ou parte substancial redistribuída.
• A Apache License 2.0 vem da Apache Software Foundation, criada para dar a colaboradores corporativos e da comunidade uma estrutura jurídica comum para grandes projetos colaborativos. Diferente da MIT, ela inclui uma concessão explícita de patente — colaboradores licenciam suas reivindicações de patente sobre o código para os usuários — por isso muitas empresas com portfólios de patentes a preferem.
• As licenças BSD (2 cláusulas e 3 cláusulas) tiveram origem na University of California, Berkeley, para o sistema operacional Berkeley Software Distribution. A variante de 3 cláusulas adiciona uma cláusula de não endosso, impedindo o uso do nome dos autores originais para promover um produto derivado sem permissão.
• Efeito prático para quem adota: você pode fazer fork, modificar, incorporar e vender uma ferramenta com licença permissiva como parte de um produto fechado e nunca liberar seu próprio código-fonte — o único risco real é remover o aviso de copyright/licença exigido da sua distribuição.
• Exemplos reais das análises deste site: Ollama e llama.cpp usam MIT; vLLM usa Apache-2.0 — as três podem ser incorporadas em um produto comercial sem gerar qualquer obrigação de divulgação de código-fonte.

O que é copyleft? A família GPL e LGPL

• A GNU General Public License (GPL) foi escrita por Richard Stallman e a Free Software Foundation como a licença do Projeto GNU, baseada na ideia de que a liberdade do software deve ser preservada adiante — quem recebe uma cópia modificada deve ter os mesmos direitos que o autor original.
• GPL v2 e GPL v3 diferem principalmente na linguagem sobre patentes e nas disposições de compatibilidade; a v3 adicionou cláusulas explícitas de retaliação de patentes e anti-tivoização (impedindo hardware que bloqueie a execução de software modificado que você tem o direito legal de executar).
• A GNU Lesser General Public License (LGPL) relaxa a GPL especificamente para bibliotecas — você pode vincular uma biblioteca LGPL a uma aplicação proprietária sem abrir o código da aplicação em si, desde que o componente de biblioteca permaneça substituível e seu próprio código-fonte fique disponível.
• O que realmente ativa a obrigação: distribuir uma cópia modificada do código coberto pela GPL. Apenas usar internamente software GPL sem modificar, ou rodar software proprietário sobre um sistema operacional licenciado sob GPL, não coloca automaticamente seu próprio código sob GPL.
• Quem deve ter cuidado: uma startup planejando fazer fork e modificar uma ferramenta GPL como núcleo de um produto comercial precisa de um plano — abrir essas modificações ou evitar o fork; uma empresa que apenas roda internamente uma ferramenta GPL sem modificar não tem essa obrigação.

Como a AGPL-3.0 fecha a brecha do SaaS

• A brecha que ela fecha: sob a GPL pura, rodar uma versão modificada como serviço web hospedado não conta como "distribuição" no sentido jurídico que a licença aciona — uma empresa podia pegar código GPL, modificá-lo, oferecê-lo apenas como produto SaaS, e nunca precisar liberar as modificações. Isso ficou conhecido informalmente como a "brecha ASP" (application service provider) ou "brecha SaaS".
• A AGPL-3.0 foi escrita especificamente para fechar essa brecha, adicionando uma cláusula de interação em rede: oferecer a funcionalidade do software modificado a usuários por rede conta como acionar a mesma obrigação de disponibilidade de código-fonte que distribuir uma cópia física.
• Por que isso importa para hospedagem e revenda: uma agência ou provedor de hospedagem que pega uma ferramenta sob AGPL, a modifica e a oferece a clientes como serviço hospedado precisa disponibilizar o código-fonte modificado a esses usuários — rodá-la sem modificação não gera essa obrigação.
• Exemplos reais das análises deste site: Jan, KoboldCpp, SillyTavern e text-generation-webui usam AGPL-3.0 — tranquilo para autoalojamento sem modificação para uso pessoal ou interno; a questão muda substancialmente no momento em que você modifica uma delas e revende acesso hospedado a ela.
• Isso é uma explicação geral de como o mecanismo da licença funciona, não aconselhamento jurídico — se uma implantação específica conta como "oferecer por rede" segundo o texto exato da AGPL-3.0 é uma questão para um advogado avaliar sua arquitetura específica.

O que são licenças source-available e "fair-code"?

• A Business Source License (BSL, também chamada BUSL) concede desde o início acesso ao código-fonte e amplos direitos de uso, com uma data futura definida em que a licença se converte em uma licença genuinamente open source (frequentemente Apache-2.0 ou licença permissiva semelhante) — até essa conversão, aplica-se uma restrição declarada de uso comercial, tipicamente voltada a impedir uma oferta hospedada concorrente.
• A Server Side Public License (SSPL), criada pela MongoDB, exige que quem oferece o software como serviço também abra como open source toda a pilha de serviço construída em torno dele — uma obrigação bem mais ampla que a da AGPL-3.0, deliberadamente escrita para tornar a hospedagem comercial impraticável para um provedor de nuvem rival.
• A Commons Clause é uma restrição adicional sobreposta a uma licença base, do contrário permissiva ou copyleft, proibindo especificamente vender o software ou oferecê-lo como serviço hospedado pago, ao mesmo tempo em que permite uso e modificação livres.
• Por que projetos migram para essas licenças: um projeto que começa sob uma licença totalmente aberta e depois adota uma source-available geralmente está respondendo a um grande provedor de nuvem que oferece o projeto como serviço hospedado sem contribuir de volta — migrar para uma licença source-available permite que o mantenedor preserve a maior parte da abertura enquanto bloqueia esse uso concorrente específico.
• Efeito prático para quem adota: normalmente você pode ler, autoalojar e modificar software source-available para uso interno sem problemas; a restrição entra em ação quando você tenta revendê-lo como produto hospedado que compete com a oferta do detentor da licença — leia a cláusula específica de uso comercial, já que a redação varia bastante entre projetos.

O que significam licenças proprietárias e freemium "gratuitas"?

• "Gratuito (fechado)" em uma tabela comparativa significa software proprietário sem custo. Você pode usar o aplicativo compilado sob os termos de serviço do fornecedor, mas não tem acesso ao código-fonte nem direito de modificá-lo, auditá-lo ou fazer fork.
• A principal contrapartida frente a alternativas open source: um app gratuito proprietário costuma ser mais polido e fácil de instalar, já que um único fornecedor controla toda a experiência do usuário — mas você depende inteiramente da disposição contínua desse fornecedor em mantê-lo gratuito, seguro e atualizado.
• Risco de dependência de fornecedor (vendor lock-in): sem acesso ao código-fonte, você não pode autoalojar uma versão modificada, auditar exatamente o que o aplicativo faz com seus dados, nem continuar o desenvolvimento se o fornecedor parar de mantê-lo, mudar o modelo de preços ou encerrar.
• Quem deve se preocupar mais: qualquer pessoa que construa um fluxo de trabalho ou processo de negócio em torno de uma ferramenta gratuita proprietária deveria ter um plano de contingência documentado — a mesma diligência que você aplicaria a qualquer dependência de fornecedor, já que "gratuito" não significa "permanente" nem "garantido".
• Não é o mesmo que source-available: licenças source-available (BSL, SSPL) pelo menos permitem ler e auditar o código mesmo que o uso comercial seja restrito; uma ferramenta totalmente proprietária não oferece nem o código nem essas garantias.

Como funcionam as licenças de modelos de IA? Open weights, RAIL e restrições de uso

• Pesos totalmente permissivos: algumas famílias de modelos liberam seus pesos sob uma licença de software permissiva padrão (geralmente Apache-2.0), concedendo os mesmos amplos direitos de uso que essa licença dá ao código, incluindo uso comercial sem restrição de finalidade.
• As licenças RAIL e OpenRAIL (Responsible AI License) surgiram com o lançamento do modelo BLOOM pela BigScience e foram projetadas junto com pesquisadores jurídicos para combinar acesso aberto com uma lista específica de usos proibidos — normalmente vetando geração de desinformação, tomada de decisão discriminatória ou conteúdo que viole a lei, enquanto permitem amplo uso comercial no restante.
• Licenças "comunitárias" ou "open-weight" personalizadas: vários grandes provedores de modelos liberam pesos sob uma licença sob medida que se lê como uma licença aberta, mas adiciona condições de finalidade de uso. O exemplo mais citado é a licença comunitária que a Meta anexa aos pesos de modelo que libera abertamente, que concede amplo uso gratuito mas adiciona um limite de escala de uso acima do qual um acordo comercial separado é exigido, junto com restrições de uso aceitável.
• O que verificar especificamente: se o uso comercial é permitido de forma geral, se há um limite de escala de uso ou receita que muda os termos, o que a política de uso aceitável proíbe, e se a licença restringe usar as saídas do modelo para treinar um modelo concorrente — uma restrição que apareceu em várias licenças específicas de modelos e não tem equivalente em licenças de software padrão.
• Isso não é aconselhamento jurídico — os termos de licença de modelos mudam entre lançamentos do mesmo fornecedor, então verifique o texto exato de licença anexado aos pesos de modelo específicos que você planeja implantar, em vez de presumir continuidade com um lançamento anterior da mesma organização.

Quem deve se importar com qual licença?

Checklist antes de adotar uma ferramenta: 7 pontos a verificar

1. 1
   Leia o arquivo LICENSE real no repositório
   Why it matters: A afirmação "open source" de uma landing page pode ser marketing, não um fato jurídico — o arquivo LICENSE (ou NOTICE/COPYING) no repositório-fonte é o documento com autoridade, não um selo ou página de preços.
2. 2
   Verifique se a licença mudou recentemente
   Why it matters: Alguns projetos migram de uma licença permissiva ou copyleft para uma source-available depois de ganhar tração comercial — esse padrão tem se repetido na indústria de software conforme provedores de nuvem passaram a hospedar projetos open source populares sem contribuir de volta. Verifique o histórico de licença do repositório, não só o arquivo atual.
3. 3
   Verifique se a licença é realmente aprovada pela OSI, se isso importa para você
   Why it matters: Licenças source-available como BSL e SSPL costumam ser divulgadas como open source, mas não estão na lista aprovada pela Open Source Initiative — se a aprovação da OSI é um requisito para o seu caso de uso, verifique a lista diretamente em vez de confiar na descrição do próprio projeto.
4. 4
   Leia as cláusulas de uso comercial e finalidade de uso específicas de modelos de IA
   Why it matters: A licença de um modelo pode permitir amplamente o uso comercial, restringi-lo acima de um limite de escala de uso, ou proibir aplicações específicas por completo — essas cláusulas ficam fora da linguagem padrão de licenças de software e são fáceis de passar despercebidas se você só verificar a licença do código.
5. 5
   Determine se autoalojar versus hospedar como SaaS muda suas obrigações
   Why it matters: Sob AGPL-3.0, oferecer software modificado por rede aciona a mesma obrigação de divulgação que distribuir uma cópia aciona sob GPL — confirme em qual categoria sua implantação planejada se enquadra antes de modificar o código.
6. 6
   Verifique se há um acordo de licença de colaborador (CLA) caso planeje contribuir
   Why it matters: Um CLA pode conceder ao mantenedor do projeto direitos mais amplos sobre sua contribuição do que a própria licença do projeto concede aos usuários — relevante principalmente se você pretende enviar código de volta ao projeto, não se apenas o consome.
7. 7
   Verifique restrições de marca separadamente da licença do código
   Why it matters: Uma licença de código permissiva ou copyleft não concede automaticamente direitos sobre o nome ou logotipo do projeto — fazer fork e rebatizar uma ferramenta pode ser bloqueado por direito de marca mesmo quando a licença do código de outra forma permitiria o fork.

Erros comuns

• Confiar na afirmação "open source" de uma página de marketing em vez de ler o arquivo LICENSE real no repositório.
• Presumir que AGPL-3.0 só importa se você distribuir uma cópia do software — ela também se aplica a oferecer código modificado como serviço hospedado.
• Tratar a licença de código de um modelo e a licença de seus pesos como o mesmo documento — frequentemente não são.
• Fazer fork e rebatizar uma ferramenta sem verificar restrições de marca separadamente da licença do código.
• Presumir que uma licença permissiva no início de um projeto ainda se aplica após uma relicenciação posterior — verifique a licença atual, não a que você lembra.
• Pular a revisão jurídica de uma ferramenta copyleft ou source-available porque "é gratuita" — gratuito para usar e livre de obrigações não são a mesma coisa.

Fontes

• Open Source Initiative — The Open Source Definition — a definição formal que uma licença deve cumprir para ser certificada como open source pela OSI.
• Projeto GNU — Free Software Licenses — as próprias explicações da Free Software Foundation sobre GPL, LGPL e AGPL.
• Apache Software Foundation — Apache License 2.0 — texto completo da licença.
• Texto da licença MIT (Open Source Initiative) — texto completo da licença.
• MongoDB — Server Side Public License — termos e justificativa próprios da SSPL.
• FAQ da Business Source License — explicação de como funciona a conversão de BSL/BUSL, de uma adotante amplamente citada da licença.

Perguntas frequentes

Leituras relacionadas

• O diretório completo de software de LLM local — mais de 160 ferramentas de LLM local com a licença listada em cada entrada.
• Análise do Dify AI Workflow Builder — uma análise que nomeia sua licença; use este guia para entender o que essa licença significa para sua implantação.
• Conteúdo gerado por IA e risco de propriedade intelectual — as questões de propriedade intelectual que acompanham o licenciamento quando você implanta comercialmente saídas geradas por IA.
• Segurança de IA agêntica: identidade e acesso — considerações de segurança e governança para implantações de IA autoalojadas, uma preocupação complementar à conformidade de licenças.
• RAG local compatível com LGPD para documentos sensíveis — risco de licença e risco de residência de dados/conformidade são checklists separadas; este guia cobre o lado da conformidade.