Modelos Abertos e Licenças

Visão geral: o que “aberto” significa na IA moderna

Em software, “código aberto (open source)” tem um significado relativamente preciso: o código-fonte fica disponível sob uma licença aprovada pela OSI (Open Source Initiative) que concede amplos direitos de usar, estudar, modificar e redistribuir. Em IA (AI), a palavra aberto é usada de forma mais flexível. Um lançamento de modelo pode incluir múltiplos artefatos — código, pesos (weights), dados, receita de treinamento (training recipe), resultados de avaliação (evaluation) — e cada um pode ser regido por uma licença ou política diferente.

Este artigo explica:

A diferença prática entre código aberto, pesos abertos (open weights) e acesso somente por API (API-only)
Como o licenciamento de modelos (model licensing) difere do licenciamento tradicional de software
Restrições e padrões comuns que você verá em lançamentos reais de modelos
Como escolher um modelo para um produto específico ou fluxo de trabalho de pesquisa

Para um mergulho mais profundo nas definições, veja Código Aberto vs Pesos Abertos vs API Aberta. Para uma discussão licença por licença, veja Licenças de Modelos.

Observação: este é um conteúdo educacional, não uma assessoria jurídica.

O que pode ser “aberto” em um lançamento de IA?

Um sistema moderno de aprendizado de máquina (machine learning) normalmente consiste em:

Código do modelo: definição da arquitetura, loop de treinamento (training loop), código de inferência (inference code)
Pesos: os parâmetros aprendidos (frequentemente o artefato mais valioso)
Dados de treinamento: conjuntos de dados brutos, dados sintéticos (synthetic data), regras de filtragem
Receita de treinamento: hiperparâmetros (hyperparameters), configuração de computação (compute), pipeline de pré-processamento (preprocessing pipeline)
Avaliação: scripts de benchmark (benchmark scripts), prompts, testes de segurança (safety tests)
Camada de implantação (deployment wrapper): servidor (server), quantização (quantization), kernels, código de aceleração (acceleration code)

“Modelo aberto (open model)” pode significar que qualquer subconjunto disso está disponível. Os padrões mais comuns são:

Código aberto (código): o código está sob uma licença padrão de código aberto (por exemplo, Apache-2.0, MIT).
Pesos abertos: os pesos são baixáveis, mas podem vir com termos personalizados (restrições de uso, limites de redistribuição, políticas de uso aceitável).
Dados abertos: o conjunto de dados está disponível, muitas vezes com termos estritos de atribuição, compartilhamento pela mesma licença (share-alike) ou não comercial.
API aberta: você pode chamar um modelo hospedado via uma API; nada é redistribuído para você.

Essas camadas importam porque determinam o que você pode fazer: reproduzir o treinamento, fazer ajuste fino (fine-tune), entregar no dispositivo (on-device), hospedar comercialmente ou redistribuir derivados (derivatives).

Código aberto vs pesos abertos vs API: que direitos você realmente obtém?

1) Código aberto (no sentido de software)

O que você obtém

Código-fonte que você pode inspecionar e modificar
Direitos de redistribuição (frequentemente incluindo uso comercial)
Em geral, termos claros de propriedade intelectual (PI) (IP) e avisos de isenção de responsabilidade (disclaimers)

O que você talvez não obtenha

Os pesos treinados
Os dados de treinamento
A capacidade de reproduzir resultados sem conjuntos de dados/capacidade de computação proprietários

Licenças típicas

MIT, BSD-3, Apache-2.0 (permissivas)
GPL/AGPL (copyleft; aciona obrigações ao distribuir ou oferecer um serviço de rede)

Exemplo

Um repositório contendo código de inferência, harness de avaliação (evaluation harness) e scripts de ajuste fino sob Apache-2.0, mas apontando para pesos lançados sob uma licença diferente (ou não lançados).

2) Pesos abertos (comum em modelos de fronteira (frontier) e quase de fronteira)

O que você obtém

Pesos baixáveis que você pode executar localmente
Muitas vezes, permissão para ajuste fino e implantação, às vezes comercialmente

O que varia bastante

Se você pode redistribuir os pesos ou derivados
Se o uso é restrito (por exemplo, “sem uso militar”, “sem vigilância”, “sem modelos fundacionais (foundation models) concorrentes”)
Se você deve incluir uma política de uso aceitável (Acceptable Use Policy, AUP)
Se você deve reportar uso acima de um limite (por exemplo, bases de usuários muito grandes)

Licenças típicas

Licenças padrão de software às vezes (Apache-2.0 ou MIT para pesos)
Variantes Creative Commons (comum para dados; às vezes usadas para pesos, com ressalvas)
Licenças personalizadas de “IA responsável (responsible AI)” (frequentemente incluem restrições de comportamento/uso)

Exemplos (padrões ilustrativos)

Algumas famílias de modelos lançam pesos sob licenças permissivas (por exemplo, Apache-2.0), viabilizando amplo uso comercial.
Outras usam licenças comunitárias personalizadas que permitem uso comercial, mas impõem condições (cláusulas de redistribuição, limites de uso ou restrições ao treinamento de modelos concorrentes).

3) API aberta (acesso hospedado)

O que você obtém

O direito de enviar entradas e receber saídas sob Termos de Serviço (Terms of Service)
Simplicidade operacional (sem GPUs, sem pilha de serving (serving stack))
Frequentemente maior qualidade para modelos proprietários de fronteira

O que você não obtém

Os pesos, o código de treinamento ou o direito de redistribuir o modelo
Reprodutibilidade forte (o provedor pode atualizar o modelo)
Controle total sobre retenção de dados (depende dos termos/configurações do provedor)

Restrições típicas

Limites de taxa (rate limits), políticas de registro/retenção (logging/retention), conformidade com políticas de uso, restrições de conteúdo
Limites para construir serviços concorrentes ou “extração de modelo (model extraction)”
Acordo de Nível de Serviço (Service Level Agreement, SLA), indenizações (indemnities) e obrigações regionais de conformidade (contratos corporativos)

Implicação prática

Uma API pode ser “aberta” no sentido de acessível, mas não é “aberta” no sentido de código aberto.

Tabela-resumo (direitos e trade-offs)

| Modo de acesso | Executar localmente | Ajuste fino | Redistribuir | Restrições típicas | Melhor para | |---|---:|---:|---:|---| | Código aberto (código) | Às vezes | Às vezes | Sim (código) | Copyleft pode se aplicar | Ferramentas, reprodutibilidade em pesquisa | | Pesos abertos | Sim | Geralmente | Às vezes | Cláusulas personalizadas de uso, limites de redistribuição | No local, na borda (edge), customização | | Somente API | Não | Às vezes via provedor | Não | Termos de Serviço, políticas de dados, limites de taxa | Iteração rápida de produto |

Por que o licenciamento de modelos é mais difícil do que o licenciamento de software

O licenciamento de modelos é complicado porque os modelos estão entrelaçados com:

Proveniência dos dados de treinamento (training data provenance): um modelo pode embutir rastros estatísticos de dados protegidos por direitos autorais, licenciados ou pessoais.
Comportamento a jusante (downstream behavior): alguns licenciadores tentam regular casos de uso (por exemplo, proibir certos domínios).
Múltiplos componentes: código sob Apache-2.0, pesos sob uma licença personalizada, conjunto de dados sob CC-BY — a conformidade exige atender a todos os termos aplicáveis.

Na prática, você deve tratar um sistema de aprendizado de máquina como um pacote de artefatos, cada um com sua própria “área de superfície” legal.

Os blocos de construção: famílias comuns de licenças e o que elas implicam

Licenças de software (para código)

MIT/BSD: obrigações mínimas (manter o aviso de direitos autorais).
Apache-2.0: permissiva, inclui uma concessão explícita de patente (patent grant) e cláusula de rescisão.
GPL/AGPL: licenças “copyleft”; se você distribui binários (GPL) ou oferece um serviço de rede (AGPL), pode precisar fornecer o código-fonte de obras derivadas.

Se o seu servidor de inferência faz link com código GPL, suas obrigações de distribuição podem mudar materialmente — isso é comum ao misturar pilhas de aprendizado de máquina e kernels de desempenho.

Licenças de dados (para conjuntos de dados)

Dados frequentemente são licenciados sob variantes Creative Commons, com restrições comuns:

CC-BY (atribuição obrigatória)
CC-BY-SA (compartilhamento pela mesma licença; derivados devem usar a mesma licença)
CC-BY-NC (não comercial)
CC0 (dedicação ao domínio público)

Importante: Algumas licenças Creative Commons não se encaixam bem em pesos de modelos, e licenciadores às vezes adicionam termos adicionais ou recorrem a contratos personalizados.

Para considerações de obtenção e distribuição de conjuntos de dados, veja Conjuntos de Dados e Hospedagem.

Licenças de pesos de modelos (onde ocorre a maior variação)

Pesos podem ser lançados sob:

Licenças permissivas (por exemplo, Apache-2.0/MIT aplicadas a pesos): mais simples para adoção comercial.
Licenças comunitárias personalizadas: permitem uso amplo, mas introduzem condições especiais (regras de redistribuição, formato de atribuição, políticas de uso aceitável, restrições ao treinamento de modelos concorrentes).
Licenças de IA responsável (RAIL-like): restringem explicitamente certos usos nocivos e podem exigir repasse do texto de política para usuários a jusante.

Como elas não são padronizadas como as licenças OSI, você precisa lê-las com cuidado e considerar exigibilidade e compatibilidade com o seu modelo de distribuição.

Restrições comuns que você encontrará (e o que elas significam operacionalmente)

1) Requisitos de atribuição e avisos

Você pode precisar:

Manter avisos de direitos autorais em distribuições
Incluir uma declaração específica de atribuição na documentação ou na interface
Preservar arquivos de licença no pacote do seu modelo

Exemplo prático Se você entrega um aplicativo móvel com um modelo de linguagem grande (large language model, LLM) no dispositivo, a tela “Sobre” do app ou os avisos incluídos no pacote podem precisar conter o texto de atribuição do modelo.

2) Limites de redistribuição (pesos e derivados)

Algumas licenças permitem:

Uso e implantação internos
Ajuste fino para uso interno …mas restringem:
Enviar pesos para um hub público
Redistribuir um derivado ajustado
Fornecer pesos para clientes baixarem

Isso importa se seu produto é “modelo como download”, um SDK no dispositivo ou uma instalação no local.

Para como a distribuição interage com hubs, veja Hubs e Registros de Modelos.

3) Obrigações de copyleft / compartilhamento pela mesma licença

Código copyleft (GPL/AGPL) pode exigir liberar o código-fonte de obras derivadas.
Dados com compartilhamento pela mesma licença (CC-BY-SA) podem impor condições sobre conjuntos de dados derivados e às vezes criam ambiguidade para modelos treinados.

Operacionalmente, isso pode afetar se você consegue manter seu pipeline de ajuste fino proprietário.

4) Restrições de não comercial (NC)

Uma cláusula de “não comercial” pode bloquear:

Ofertas SaaS
Suporte pago
Apps sustentados por anúncios
Muitos usos corporativos (mesmo internos)

NC frequentemente inviabiliza o uso para startups e equipes de produto, mesmo que o modelo seja tecnicamente ideal.

5) Restrições por campo de uso e políticas de uso aceitável

Restrições comuns incluem:

Sem diagnóstico médico, aconselhamento jurídico ou tomada de decisão regulada
Sem vigilância, identificação biométrica ou uso militar
Sem geração de certas categorias de conteúdo
Conformidade com uma AUP

Nuance importante: Restrições por campo de uso geralmente fazem com que uma licença não seja “código aberto” no sentido da OSI, mesmo que os pesos sejam baixáveis.

6) Cláusulas de “sem modelos concorrentes” / anti-extração

Algumas licenças personalizadas restringem:

Usar os pesos para treinar outros modelos fundacionais
Destilar o modelo para produzir um modelo concorrente
Usar saídas para construir um conjunto de treinamento competitivo (às vezes)

Essas cláusulas afetam diretamente:

Fluxos de trabalho de destilação (distillation)
Geração de dados sintéticos para treinamento
Pipelines de avaliação e testes adversariais (red-teaming)

Se você faz avaliação em larga escala, veja Harnesses de Avaliação.

7) Marcas registradas e branding

Mesmo licenças permissivas geralmente não concedem direitos de marca registrada. Você pode ser proibido de:

Usar o nome ou logo do modelo de um jeito que implique endosso
Nomear seu produto como “Modelo XYZ Oficial”

8) Patentes e indenização

Apache-2.0 fornece uma licença de patente de contribuidores; MIT normalmente não o faz explicitamente.
Muitas licenças de modelos isentam garantias e não oferecem indenização.
Contratos corporativos de API podem oferecer indenizações (frequentemente com condições rigorosas).

Exemplos práticos: escolhendo o nível certo de “abertura”

Exemplo A: um chatbot comercial para uma empresa regulada

Restrições

Deve rodar no local (residência de dados)
Precisa de auditabilidade e versionamento estável
O jurídico quer direitos comerciais claros

Provável encaixe

Pesos abertos sob uma licença permissiva ou claramente permissiva para uso comercial
Auto-hospedagem via uma pilha de inferência (frequentemente com Ferramentas para LLMs como bancos de dados vetoriais, gateways e monitoramento)

O que verificar

Redistribuição: você precisa enviar os pesos para o ambiente do cliente?
Retenção de dados: logs contêm dados sensíveis?
Ajuste fino: você pode publicar adaptadores (adapters) ou pesos mesclados?

Exemplo B: um app móvel de consumo com inferência no dispositivo

Restrições

Você está distribuindo pesos dentro do pacote do app (redistribuição!)
A revisão da loja de apps exige avisos claros de licenciamento
A quantização modifica os pesos

Provável encaixe

Pesos que permitem explicitamente redistribuição e formatos derivados (variantes quantizadas)

Checklist operacional

Manter arquivos license/NOTICE no pacote do app
Documentar atribuição em configurações/sobre
Confirmar que pesos quantizados contam como derivados permitidos

Exemplo C: prototipagem rápida para um hackathon ou ferramenta interna

Restrições

O tempo até o primeiro demo importa
Qualidade do modelo importa mais do que controle

Provável encaixe

Acesso somente por API com Termos de Serviço simples

O que observar

Políticas do provedor sobre armazenar prompts/saídas
Se as saídas podem ser usadas para treinar seus próprios modelos depois
Risco de dependência (preço, indisponibilidades, atualizações de modelo)

Fluxo de trabalho prático de conformidade (o que times realmente fazem)

1) Identifique todos os artefatos e suas licenças

Uma única página de modelo pode referenciar:

Uma licença do repositório de código
Uma licença de pesos
Uma licença de conjunto de dados
Documentos de política adicionais (AUP)

2) Capture obrigações como requisitos de engenharia

Traduza termos legais em tarefas concretas:

“Incluir atribuição” → adicionar avisos na UI e nos docs
“Sem redistribuição” → bloquear downloads públicos; restringir acesso ao modelo
“Termos de repasse (pass-through terms)” → incluir texto de licença em contratos com clientes ou EULA
“Reportar uso acima do limite” → adicionar telemetria/métricas e processo de escalonamento

3) Automatize o que puder

Se você usa hubs de modelos, muitas vezes é possível obter metadados de licença programaticamente.

from huggingface_hub import model_info

info = model_info("org/model-name")
print("License:", info.license)
print("Tags:", info.tags)

Metadados ajudam, mas não são suficientes — sempre leia o texto de licença real com link no cartão do modelo (model card).

4) Acompanhe versões como dependências de software

Trate modelos como dependências de terceiros:

Fixe versões/hashes exatos
Arquive o texto de licença junto do artefato
Registre a proveniência em um registro interno (veja Hubs e Registros de Modelos)

Armadilhas e equívocos

“Os pesos estão disponíveis, então é código aberto”

Pesos baixáveis não implicam código aberto conforme a OSI. Muitos lançamentos populares usam licenças personalizadas que limitam campos de uso, redistribuição ou competição.

“O código é Apache-2.0, então o modelo é Apache-2.0”

É comum que o código seja permissivo enquanto os pesos estão sob termos diferentes. Você deve cumprir ambos.

“Se eu fizer ajuste fino, eu sou dono”

Pesos ajustados geralmente são um trabalho derivado sob os termos de licença do modelo (os detalhes exatos dependem da jurisdição e da linguagem contratual). Muitas licenças definem explicitamente “modelos derivados” e impõem condições sobre eles.

“Usar API evita licenciamento”

Acesso por API troca conformidade com licença por conformidade contratual (Termos de Serviço). Você pode ter menos obrigações de redistribuição, mas restrições mais fortes sobre uso aceitável, tratamento de dados e competição.

Como a abertura afeta escolhas de pesquisa e engenharia

Abertura não é apenas filosófica; ela muda o que é viável:

Reprodutibilidade: sem dados e receita de treinamento, “pesos abertos” podem não ser cientificamente reprodutíveis.
Segurança e auditorias: código aberto melhora a capacidade de inspeção, mas pesos ainda podem carregar riscos (memorização, suscetibilidade à injeção de prompt (prompt injection), comportamentos inseguros).
Flexibilidade de implantação: pesos abertos permitem implantações no dispositivo e no local; APIs otimizam conveniência.
Ferramentas do ecossistema: lançamentos abertos aceleram ajustes finos, quantizações e avaliações comunitárias — frequentemente distribuídos via hubs e integrados a Ferramentas para LLMs.

Olhando adiante: rumo a padrões mais claros

A comunidade de IA está debatendo ativamente o que “aberto” deveria significar para modelos, incluindo propostas que consideram:

Disponibilidade de pesos e proveniência dos dados de treinamento
Receitas de treinamento reprodutíveis
Avaliações de segurança e documentação
Licenças padronizadas e interoperáveis para pesos e derivados

Até que os padrões converjam, trate “modelo aberto” como uma abreviação de marketing e verifique os direitos e obrigações reais.

Checklist rápido: escolhendo uma postura de licença para o modelo

Ao decidir entre código aberto, pesos abertos e acesso por API, pergunte:

Implantação: precisamos de inferência local/no local/no dispositivo?
Redistribuição: vamos enviar pesos a clientes ou embuti-los em um produto?
Uso comercial: há cláusulas NC ou limites de receita/base de usuários?
Derivados: podemos fazer ajuste fino, quantizar, destilar ou mesclar adaptadores — e podemos publicar o resultado?
Restrições de uso: AUP ou cláusulas de campo de uso conflitam com o nosso domínio?
Governança de dados: Termos de Serviço ou termos de licença se alinham com requisitos de privacidade/segurança?
Versionamento: podemos fixar uma versão específica do modelo e mantê-la estável?

Se você precisa de orientação mais detalhada para interpretar esses termos, continue para Licenças de Modelos.