Código Aberto

O que significa código aberto para ferramentas de IA

Software de código aberto publica o código-fonte sob licença que permite inspeção, modificação e (geralmente) redistribuição. Em ferramentas de IA você pode ler como prompts, logs e credenciais são tratados, adaptar o produto à sua stack e executá-lo sem esperar a região cloud do fornecedor.

Código aberto não é o mesmo que grátis de graça, nem o mesmo que self-hosted. Um projeto Apache ainda pode empurrar você a um plano de controle hospedado pago. Um appliance proprietário pode ser self-hosted com chave de licença. Leia o arquivo de licença e o caminho de telemetria padrão, não a palavra marketing "open".

Por que equipes de IA se importam

Auditabilidade. Engenheiros veem o código que toca conversas de clientes — importante em saúde, finanças e jurídico.

Personalização. Produtos fechados limitam patches. Ferramentas abertas permitem mudar auth, retenção, roteamento de modelos e integrações no seu calendário.

Sem kill switch de um único fornecedor. APIs proprietárias são descontinuadas. Você pode fixar uma tag git, fazer fork ou continuar uma release antiga.

Velocidade da comunidade. Projetos ativos costumam receber correções de segurança e adaptadores (LangChain, charts Kubernetes) mais rápido do que um roadmap fechado admite publicamente.

Licenças que você realmente encontrará

• MIT — Muito permissiva. Mantenha o aviso de copyright. Uso comercial normal.
• Apache 2.0 — Permissiva mais concessão expressa de patentes. Comum em infra de IA enterprise.
• GPL v3 — Copyleft: distribuir binário modificado geralmente exige compartilhar fonte sob GPL.
• AGPL v3 — Copyleft que alcança muitos deployments de rede/SaaS. Revisão legal antes de produto interno.
• Source-available / BSL / open core — Código legível; direitos talvez não os que você imagina. Não OSI-open até legal concordar.

Como avaliar uma ferramenta de IA open source

1. Compatibilidade de licença com como você entrega (interno, SaaS, on-prem).
2. Quem faz merge: empresa, fundação ou um mantenedor sem backup.
3. Cadência de releases, artefatos assinados, contato de segurança.
4. Docs de produção: Compose/Helm, backups, upgrades e o que liga para casa.
5. Se "open" inclui dados de treino, eval sets, runtime do agente ou só um cliente fino.
6. Dual licensing: quais recursos ficam atrás de SKU comercial.

Riscos

Repos sem manutenção apodrecem. AGPL em serviço productizado pode forçar divulgação de fonte não orçada. "Open weights" não é a mesma aplicação aberta. Relatórios de crash e checagens de licença podem exfiltrar traces. Forks sem plano de mantenedor viram seu plantão.

Perguntas frequentes

Se está no GitHub, é código aberto?

Só se o repositório tiver licença open source reconhecida e você usar os arquivos licenciados. "All rights reserved" não é open source.

Podemos usar código Apache 2.0 em produto comercial?

Geralmente sim, inclusive closed source, cumprindo avisos e NOTICE. Confirme patentes/marcas com legal.

Open source obriga a publicar modificações?

Não sob MIT ou Apache 2.0 para uso interno ou SaaS típico. GPL/AGPL são diferentes. Leia a licença antes de redistribuir ou oferecer serviço de rede.

Open source é automaticamente mais seguro?

Não. Visibilidade ajuda se alguém lê e corrige. Repo público abandonado pode ser pior que fornecedor com SLA de segurança.

Relação com self-hosted?

Open source torna self-hosting possível. Não opera o cluster por você. Veja a tag Self-Hosted.