Licenças de Modelos

O que as “licenças de modelo” cobrem (e por que elas importam)

Uma licença de modelo (model license) é o conjunto de termos legais que rege como você pode acessar, usar, modificar, distribuir e implantar (deploy) um modelo de aprendizado de máquina (machine learning, ML) — mais importante: seus pesos (weights) (e, frequentemente, ativos relacionados como arquivos de tokenizador (tokenizer), configurações (configs) ou código de treinamento). Na prática, “a licença do modelo” costuma ser um pacote de documentos:

Um texto de licença (por exemplo, Apache-2.0, uma licença comunitária personalizada ou uma licença de IA Responsável)
Uma Política de Uso Aceitável (Acceptable Use Policy, AUP) ou “política de uso”
Termos de distribuição (por exemplo, bloqueio por aceite (click-through gating) em um hub de modelos)
Às vezes, licenças separadas para código, pesos, dados e documentação

O licenciamento de modelos tornou-se especialmente importante para Modelos de Fundação e grandes modelos de Arquitetura Transformer porque:

Modelos são caros para treinar e valiosos para distribuir
Modelos podem ser adaptados (ajustados finamente) e redistribuídos com facilidade
Publicadores de modelos querem, cada vez mais, restringir certos usos (por exemplo, vigilância, armas, domínios de alto risco)

Este artigo foca em padrões comuns de licença e restrições para pesos de modelos e uso, e como aplicá-los em implantações reais.

Para um contexto mais amplo sobre o que “aberto” significa em IA (e o que, de fato, está sendo compartilhado), veja: Código Aberto vs Pesos Abertos vs API Aberta.

O que exatamente está sendo licenciado?

Um único “lançamento de modelo” frequentemente inclui múltiplos artefatos que podem ter licenças diferentes:

Pesos / checkpoints (.safetensors, .bin, .pt)
Definição da arquitetura (código que define a classe do modelo)
Arquivos de tokenizador e vocabulário (merges BPE, modelos SentencePiece)
Configuração (config.json)
Código de inferência (inference) / treinamento (training)
Scripts de avaliação e benchmarks
Documentação, fichas de modelo (model cards) e exemplos
Opcional: dados de treinamento (frequentemente não são liberados, ou têm licenciamento de dataset separado)

Um repositório típico de pesos abertos pode conter algo como:

model/
  LICENSE               # license for weights (and sometimes other assets)
  NOTICE                # attribution / third-party notices (sometimes required)
  README.md
  model.safetensors
  config.json
  tokenizer.json
code/
  LICENSE               # license for code (often different)
  inference.py

Por que os pesos são legalmente “especiais”

Normas de licenciamento de software vieram do código-fonte. Pesos são diferentes:

Eles são parâmetros aprendidos a partir de dados, e não instruções escritas por humanos.
Eles podem embutir informações dos dados de treinamento (levantando preocupações de privacidade/PI).
O status legal dos pesos pode envolver direitos autorais (copyright), direitos sobre banco de dados (database rights), segredos comerciais (trade secrets) e direito contratual (contract law), dependendo da jurisdição e do método de distribuição.

Mesmo que o status de direitos autorais dos pesos seja debatido em alguns contextos, na prática você deve tratar a licença como termos vinculantes para acesso e uso lícitos — especialmente quando você baixa a partir de uma plataforma que exige concordância com esses termos.

Conceitos centrais e vocabulário

Direitos normalmente concedidos (ou negados)

Licenças de modelo comumente definem se você pode:

Usar o modelo (pesquisa, comercial, interno, externo)
Modificar (ajuste fino (fine-tuning), quantizar, podar, mesclar)
Distribuir (compartilhar pesos ou derivados)
Sublicenciar (repassar direitos adiante)
Implantar como um serviço (API/SaaS)
Usar saídas (outputs) (propriedade e restrições podem ser tratadas explicitamente)

Obrigações comuns

Atribuição (creditar os autores originais)
Incluir o texto da licença e avisos em redistribuições
Compartilhar modificações (condições de copyleft / compartilhamento nos mesmos termos (share-alike))
Publicar mudanças ou documentar ajustes finos
Restrições de repasse (pass-through) (usuários a jusante devem seguir a mesma AUP)
Marcar versões modificadas (evitar confusão com o original)

Restrições comuns

Uso apenas não comercial
Uso apenas para pesquisa
Sem uso militar / vigilância
Sem treinar concorrentes / sem usar saídas para treinar outros modelos
Sem domínios de alto risco sem etapas de conformidade (por exemplo, aconselhamento médico/jurídico)
Sem geração de conteúdo ilegal
Sem identificação biométrica / perfilamento

Restrições são onde as “licenças de modelo” frequentemente divergem das normas de código aberto aprovadas pela OSI (Open Source Initiative) (que, em geral, proíbem restrições por campo de uso).

Principais padrões de licença que você encontrará

1) Licenças permissivas de código aberto aplicadas a artefatos de modelo (Apache/MIT/BSD)

Alguns publicadores de modelos liberam pesos sob licenças permissivas amplamente usadas (comumente usadas para código), como a Apache License 2.0 ou MIT.

Características típicas

Permite uso comercial
Permite modificação e redistribuição
Obrigações mínimas (atribuição, incluir licença)
Apache-2.0 inclui uma licença de patentes (patent license) explícita (frequentemente uma vantagem prática)

Exemplo prático

Uma empresa entrega um assistente no dispositivo usando pesos Apache-2.0. Ela deve:
- Incluir o texto da licença Apache-2.0
- Preservar avisos de direitos autorais
- Potencialmente incluir um arquivo NOTICE se exigido pelo upstream

Por que isso importa

É o mais próximo que lançamentos de modelos chegam do comportamento tradicional de “código aberto”.
Simplifica conformidade e adoção a jusante.

Armadilha comum

Confundir “pesos Apache-2.0” com “tudo no repositório é Apache-2.0”. Tokenizadores, código de treinamento e dados de avaliação ainda podem estar sob termos diferentes.

2) Licenças copyleft (estilo GPL/AGPL) — mais comuns para código de servimento do que para pesos

Licenças copyleft exigem que obras derivadas permaneçam sob os mesmos termos de licença. Em IA, você verá isso mais frequentemente para servidores de inferência (inference servers) ou ferramentas do que para pesos.

GPL: aciona obrigações quando você distribui o software.
AGPL: pode acionar obrigações quando você fornece o software pela rede (relevante para inferência em SaaS).

Exemplo prático

Se sua pilha de servimento (serving stack) de modelos inclui um componente AGPL, oferecer uma API hospedada pode exigir que você forneça o código-fonte aos usuários que interagem com o serviço — dependendo da integração exata e da interpretação jurídica.

Por que isso importa

Equipes às vezes focam na licença do modelo e deixam passar a licença da pilha de servimento, que pode impor obrigações mais fortes do que os pesos.

3) Licenças no estilo Creative Commons (CC-BY, CC-BY-SA, CC0, CC-BY-NC)

Licenças Creative Commons (CC) são projetadas para obras criativas e conteúdo, mas às vezes são usadas para datasets e ocasionalmente para artefatos de modelo.

Variantes comuns

CC0: dedicação semelhante a domínio público (muito permissiva)
CC-BY: atribuição obrigatória
CC-BY-SA: compartilhamento nos mesmos termos (derivados devem usar a mesma licença)
CC-BY-NC: restrição não comercial

Considerações práticas

Licenças CC podem ser ambíguas para artefatos tipo software (patentes, forma de código-fonte, etc.).
“Não comercial” pode ser surpreendentemente pouco claro para uso moderno:
- Uso interno em uma empresa com fins lucrativos é “comercial”?
- Um app gratuito sustentado por anúncios é “comercial”?
- Pesquisa financiada pela indústria é “comercial”?

Por causa dessas ambiguidades, muitas organizações preferem licenças de software (por exemplo, Apache-2.0) para código/pesos e reservam licenças CC para datasets — veja também Licenciamento de Datasets.

4) “Pesos abertos, mas uso restrito” (licenças comunitárias personalizadas)

Um padrão moderno muito comum é: os pesos são baixáveis, mas a licença inclui restrições de uso que não são consideradas código aberto pelas definições da OSI.

Exemplos de restrições que você pode ver:

Proibições para certos setores ou casos de uso
Limites para treinar modelos concorrentes
Exigências de conformidade com uma AUP separada
Termos especiais para bases de usuários muito grandes ou tipos específicos de implantação (varia por publicador e versão)

Por que esse padrão existe

Ele incentiva adoção ampla enquanto protege a posição competitiva do publicador ou aborda riscos de segurança percebidos.

Exemplo prático

Uma startup ajusta finamente um modelo-base com licença comunitária para suporte ao cliente. Ela pode implantá-lo, mas deve garantir:
- Que seu caso de uso é permitido pela AUP
- Que não está violando cláusulas de “não treinar concorrentes”
- Que, se redistribuir os pesos ajustados finamente, talvez precise repassar a mesma licença e restrições

5) Licenças de IA Responsável (RAIL / semelhantes a OpenRAIL)

Licenças de IA Responsável (Responsible AI) (muitas vezes inspiradas em “Responsible AI Licenses”, às vezes com marcações de variantes específicas) tentam codificar restrições de segurança e ética na própria licença.

Recursos comuns:

Permissões amplas para usar/modificar/distribuir
Usos explicitamente proibidos (por exemplo, gerar malware, assédio, certa vigilância)
Exigências de repasse (pass-through): usuários a jusante devem seguir as mesmas restrições
Às vezes, exigências de reporte ou obrigações adicionais

Exemplo prático

Um desenvolvedor libera um modelo de imagem ajustado finamente sob uma licença no estilo RAIL. Ele deve:
- Incluir a licença e os termos de uso restrito
- Garantir que redistribuidores também incluam os termos
- Possivelmente incluir documentação sobre uso pretendido e limitações

Nuance importante

Exequibilidade e interpretação podem depender da jurisdição e de se os termos funcionam como condição de licença, contrato, ou ambos.

6) Licenças “somente pesquisa” e “não comercial”

São comuns em lançamentos acadêmicos ou em estágios iniciais.

Restrições típicas

Uso apenas para pesquisa não comercial
Sem implantação em produtos
Às vezes, sem redistribuição

Exemplo prático

Se você constrói um protótipo usando um modelo somente para pesquisa, talvez precise retreinar ou trocar de modelo antes de lançar comercialmente.

Orientação operacional

Trate esses modelos como “somente avaliação” a menos que você tenha um plano claro de comercialização.

7) Acesso somente via API (Termos de Serviço em vez de licenças de pesos)

Se você acessa um modelo apenas via uma API hospedada, normalmente você não recebe direitos sobre pesos. Em vez disso, você concorda com:

Termos de Serviço (Terms of Service) da API
Políticas de uso
Termos de retenção de dados / logging
Limites de taxa (rate limits) e termos de preços

Isso não é uma “licença de pesos de modelo”, mas afeta fortemente:

O que você pode fazer com saídas
Se você pode armazenar entradas/saídas
Se você pode usar saídas para treinar outros modelos
Obrigações de conformidade (por exemplo, políticas de conteúdo)

Para a distinção conceitual, veja Código Aberto vs Pesos Abertos vs API Aberta.

Restrições comuns e como elas impactam fluxos de trabalho reais

Uso comercial, distribuição e sublicenciamento

Perguntas-chave para responder a partir do texto da licença:

Posso usar comercialmente?
Posso redistribuir os pesos originais?
Posso redistribuir uma versão ajustada finamente ou quantizada?
Preciso incluir a licença original e avisos?
Meus clientes podem redistribuir ainda mais?

Um problema frequente no mundo real: uma licença pode permitir uso mas restringir redistribuição. Isso importa se você entrega:

Pesos no dispositivo em um app
Um pacote empresarial implantado em VPCs de clientes
Um “arquivo de modelo” baixável para inferência local

Ajuste fino, mesclagem e “modelos derivados”

A maioria das técnicas de adaptação em aprendizado de máquina cria artefatos que são, arguivelmente, derivados:

Ajuste fino supervisionado e instruction tuning (Ajuste Fino)
Adaptadores LoRA (LoRA adapters) (deltas de pesos separados)
Quantização (quantization) (nova representação numérica dos pesos)
Mesclagens de modelos (model merges) (combinação de pesos de múltiplas fontes)

Licenças variam quanto a exigir que pesos derivados:

Mantenham a mesma licença (compartilhamento nos mesmos termos / estilo copyleft)
Incluam atribuição
Preservem restrições de uso
Sejam marcados como modificados

Exemplo prático

Se você publica um adaptador LoRA treinado em cima de um modelo-base restrito, você ainda pode estar vinculado às restrições do modelo-base, mesmo que o arquivo do adaptador seja pequeno e “apenas deltas”.

Cláusulas de “não treinar outros modelos” / “sem concorrentes”

Algumas licenças comunitárias e termos de API restringem o uso do modelo (ou de suas saídas) para treinar ou melhorar outros modelos.

A interpretação pode ser difícil:

Ela proíbe treinar qualquer modelo, ou apenas grandes modelos de linguagem?
Ela proíbe destilação (distillation)? Geração de dados sintéticos para treinamento?
Ela proíbe usar o modelo para rotular dados?

Se seu roadmap inclui destilação ou bootstrap de dados sintéticos (synthetic-data bootstrapping), trate essas cláusulas como de alto risco e peça revisão jurídica.

Direitos sobre saídas: quem é dono das saídas do modelo?

Muitas licenças no estilo de código aberto não tratam explicitamente de direitos sobre saídas; em geral, você trata as saídas como suas, sujeitas a outras leis (privacidade, PI, difamação, etc.). Algumas licenças personalizadas e termos de API tratam disso:

Se você é dono das saídas
Se você pode usar saídas comercialmente
Se você pode usar saídas para treinar modelos
Se o provedor pode usar suas entradas/saídas para melhorias

Dica operacional

Se a propriedade das saídas importa (por exemplo, você vende conteúdo gerado), leia as cláusulas de saída com cuidado e verifique se elas se alinham aos termos do seu produto.

Marcas registradas e restrições de nomenclatura

Mesmo licenças permissivas podem não conceder direitos de marca registrada. Publicadores de modelos frequentemente restringem:

Usar o nome ou o logo do modelo em marketing
Implicar endosso
Nomear modelos ajustados finamente de forma confusa

Isso muitas vezes aparece fora do texto principal da licença (diretrizes de marca). Ainda assim, afeta como você publica derivados.

Patentes e indenização

Licenças de modelo raramente incluem indenizações fortes (promessas de cobrir seu risco jurídico). Licenças permissivas normalmente fazem isenção de garantias. Apache-2.0 fornece uma licença de patentes de contribuidores, mas:

Ela pode não cobrir todas as patentes relevantes de terceiros
Licenças de modelo personalizadas podem não incluir concessões de patentes

Para adoção empresarial, essas cláusulas podem ser decisivas.

Como ler uma licença de modelo: um checklist prático

Ao avaliar um modelo para um projeto, extraia respostas para um conjunto curto de perguntas e salve-as na sua documentação interna (por exemplo, um “BOM de AM (ML BOM)” ou uma entrada no registro de modelos):

Quais artefatos estão cobertos? Pesos, tokenizador, código, docs?
Uso comercial é permitido? Qualquer receita, qualquer contexto de negócio?
Implantação é permitida? No dispositivo, SaaS, embutido, enterprise?
Redistribuição é permitida? Original e modificado?
Ajustes finos são permitidos e distribuíveis? Sob quais termos?
Há restrições por campo de uso? Militar, vigilância, saúde etc.?
Há cláusulas de “não treinar modelos concorrentes”?
Requisitos de atribuição/NOTICE?
Concessão de patentes incluída? (por exemplo, Apache-2.0)
Obrigações de repasse a jusante? Você precisa fazer cumprir uma AUP?
Obrigações de dados e privacidade? Logging, consentimento do usuário, retenção?
Restrições de exportação/sanções ou geográficas? Às vezes nos termos de distribuição
Há termos separados na página do hub de modelos? (download com bloqueio por aceite)

Um registro interno simples pode parecer com:

model: example-llm-8b
base_license: "Custom Community License vX"
commercial_use: allowed
redistribution: restricted
fine_tune: allowed
publish_fine_tune: allowed_with_pass_through_terms
prohibited_uses: ["surveillance", "weapons", "illegal activity"]
no_train_other_llms: true
attribution_required: true
notes: "Gated download requires click-through on host platform."
reviewed_by: "legal@company"
date: "2026-01-01"

Combinando licenças: cenários comuns de “empilhamento de licenças”

Implantações reais frequentemente envolvem múltiplos componentes em camadas:

Pesos do modelo-base (Licença A)
Dataset de ajuste fino (Licença B)
Código de treinamento (Licença C)
Framework de servimento (serving framework) (Licença D)
Um modelo classificador de segurança (safety classifier model) (Licença E)

Suas obrigações geralmente são a união dos requisitos aplicáveis, e os termos mais restritivos podem se tornar o gargalo (por exemplo, uma licença de dataset não comercial pode limitar a implantação comercial do ajuste fino resultante).

Duas armadilhas particularmente comuns:

Restrições do dataset “vazam” para o modelo. Se você ajusta finamente com dados que proíbem uso comercial, você pode não conseguir comercializar os pesos ajustados finamente.
Restrições do código de servimento se aplicam ao seu SaaS. Um servidor AGPL pode impor obrigações de compartilhamento de código-fonte mesmo se os pesos estiverem sob licença permissiva.

Exemplos práticos

Exemplo 1: Entregar um app móvel com pesos embutidos

Você quer incluir um arquivo de modelo no download do app.

Você deve confirmar:

Que a licença permite redistribuição (não apenas uso)
Que você consegue cumprir atribuição dentro do app (por exemplo, tela de “Licenças de código aberto”)
Que quaisquer termos de repasse (AUP) podem ser apresentados aos usuários finais, se exigido
Que a licença não proíbe seu caso de uso (por exemplo, certos domínios regulados)

Se redistribuição não for permitida, uma alternativa é:

Hospedar o modelo nos seus servidores e entregar apenas o cliente, ou
Escolher um modelo com direitos permissivos de redistribuição

Exemplo 2: Ajuste fino e publicação em um hub de modelos

Você ajusta finamente um modelo-base e quer publicar o resultado.

Verifique:

Derivados podem ser distribuídos?
Você deve manter a mesma licença?
Você precisa incluir um arquivo NOTICE?
Você precisa incluir restrições de uso na ficha do modelo?

Boa prática:

Incluir uma atribuição clara do tipo “Baseado em …”
Fornecer o identificador exato do modelo-base e a licença
Documentar o que mudou (dados, etapas de treinamento, filtros de segurança)

Melhor prática relacionada: publicar uma entrada completa de Fichas de Modelo.

Exemplo 3: Usar um modelo com licença restrita para gerar dados sintéticos de treinamento

Você usa um modelo para gerar pares de perguntas e respostas, e então treina um novo modelo com esses pares.

É exatamente aqui que cláusulas de “não treinar outros modelos” (ou Termos de Serviço de API) podem se aplicar. Trate pipelines de dados sintéticos como potencial “melhoria de modelo” ou “destilação”, a menos que a licença permita explicitamente.

Escolhendo uma licença ao lançar seu próprio modelo

Se você é o publicador (ou está liberando um ajuste fino que tem direitos de distribuir), escolher uma licença é tanto uma decisão de produto quanto jurídica.

Objetivos comuns e padrões correspondentes

Máxima adoção (incluindo comercial): permissiva (estilo Apache-2.0/MIT)
Garantir que melhorias permaneçam abertas: abordagem de compartilhamento nos mesmos termos / estilo copyleft (menos comum para pesos)
Prevenir certos usos: licença de IA Responsável / uso restrito (reduz compatibilidade com “aberto”)
Intenção acadêmica: somente pesquisa (limita impacto fora da pesquisa)

Evite erros comuns

Não aplique uma licença somente de dataset a pesos sem entender sua adequação.
Não ignore restrições de terceiros (modelo-base + dataset + código).
Não confie em uma frase no README como “gratuito para uso comercial” sem um texto de licença apropriado.

Dicas operacionais de conformidade para equipes

Mantenha um inventário de modelos com metadados de licenças (como uma lista de materiais de software (Software Bill of Materials, SBOM), mas para modelos).
Armazene a versão exata do texto de licença usada no momento do download (licenças podem mudar entre releases).
Espelhe arquivos exigidos (LICENSE, NOTICE) na distribuição do seu produto.
Adicione verificações de integração contínua (CI) para:
- Presença de arquivos de licença em artefatos empacotados
- Strings de atribuição em saídas de UI/CLI quando exigido
Para licenças de uso restrito, documente:
- O caso de uso pretendido
- As mitigações de filtragem/segurança que você aplica (IA Responsável)
- Como você garante que usuários a jusante cumpram (se você redistribuir)

Limitações e “isto não é aconselhamento jurídico”

O licenciamento de modelos fica na interseção entre direito de software, dados e conteúdo. Este artigo fornece orientação com foco em engenharia, mas não é aconselhamento jurídico. Para implantações de alto risco (domínios regulados, grande distribuição ou licenças personalizadas com restrições incomuns), envolva assessoria jurídica cedo — especialmente quando cláusulas afetam concorrência, redistribuição ou treinamento de outros modelos.

Principais conclusões

Uma “licença de modelo” muitas vezes rege mais do que pesos: código, tokenizadores e políticas de uso também podem se aplicar.
Os padrões mais comuns são licenças permissivas no estilo de código aberto, licenças comunitárias personalizadas com restrições e licenças de IA Responsável com usos proibidos.
Os maiores riscos práticos são entender errado redistribuição, direitos sobre modelos derivados e restrições sobre treinar outros modelos.
Trate conformidade como um processo de engenharia: rastreie artefatos, termos e obrigações a jusante assim como você rastreia dependências.

Se você é novo nas distinções do ecossistema que direcionam muitas escolhas de licenciamento, comece por: Código Aberto vs Pesos Abertos vs API Aberta.