AGPL explicado: obrigações para implantações internas

Você encontrou código sob AGPL que parece útil, mas não tem certeza do que isso implica ao rodá‑lo dentro da sua empresa. A ansiedade comum é prática: você será forçado a publicar código privado, expor sistemas internos ou abrir um campo minado jurídico se modificar o software e usá‑lo atrás do firewall? Este guia corta o juridiquês e mostra, em termos técnicos, o que a GNU Affero General Public License (AGPL) realmente obriga uma empresa que faz deploy do código internamente.

Visão rápida: o que é a AGPL e como ela difere da GPL

A AGPL é a GNU GPL com uma cláusula de rede. O GPLv3 cobre a distribuição de binários: se você distribuir um programa modificado, deve oferecer o código‑fonte correspondente. O AGPLv3 adiciona a seção 13: se você executar um programa AGPL modificado e permitir que outros interajam com ele pela rede, esses usuários remotos também devem ter acesso ao código‑fonte dessa versão modificada. Em resumo: o uso por rede aciona obrigações de oferta de fonte semelhantes às que a distribuição aciona sob o GPL.

Quando a AGPL se aplica dentro de uma empresa

A questão-chave é quem conta como "usuário" segundo a AGPL. A licença não distingue clientes públicos de empregados: qualquer pessoa que interaja com o programa coberto pela AGPL pela rede é um usuário com direito ao código‑fonte. Assim, há três cenários internos típicos a diferenciar:

• Implantações somente internas acessíveis apenas a funcionários atrás do firewall da empresa: as obrigações da AGPL se aplicam a esses usuários‑empregados — você deve fornecer a eles o código‑fonte correspondente para a versão em execução e quaisquer modificações.
• Implantações estilo SaaS ou serviços voltados a clientes: se clientes externos interagem com seu serviço, você deve tornar o código‑fonte disponível para esses clientes (publicar na Internet é o modo comum de cumprir isso).
• Uso estritamente offline (sem interface de rede): se o programa é executado apenas localmente em máquinas sem interação de rede, a cláusula de rede da AGPL não é acionada além dos gatilhos normais do GPL para distribuição.

Crucialmente, "uso interno" não significa automaticamente "sem obrigações." Se funcionários ou contratados usam o serviço, eles são usuários segundo a AGPL e têm direito ao código‑fonte. Em contraste, a obrigação de publicar código na Internet surge apenas se esses usuários forem externos (clientes, terceiros) ou se você optar por satisfazer a oferta tornando a fonte publicamente acessível.

O que você realmente deve fornecer aos usuários

Quando a AGPL é acionada, as obrigações práticas são concretas. Você deve fornecer o "Complete Corresponding Source" para a versão exata do programa que está executando. Isso normalmente inclui:

• A árvore completa de código‑fonte do programa, incluindo quaisquer modificações que você fez.
• Scripts de build, arquivos de configuração, scripts de empacotamento e quaisquer instruções de instalação e deploy necessárias para reproduzir o binário em execução.
• Quaisquer scripts ou fontes necessários para gerar ou buscar componentes não‑fonte que façam parte do sistema implantado (por exemplo, código usado em uma build de container).
• Preservação de avisos de licença, cabeçalhos de copyright e arquivos AUTHORS/NOTICE conforme presentes no projeto upstream.

A oferta pode ser feita diretamente aos usuários que interagem com o programa. Na prática, organizações cumprem isso colocando um link claramente rotulado na UI da aplicação ou em uma página About que apontem para um tarball ou um snapshot de repositório git e um README legível explicando os passos de build e deploy. A AGPL não prescreve um formato único de URL nem um provedor de hospedagem, mas a fonte deve ser acessível aos usuários autorizados de forma utilizável.

O que "fornecer a fonte" não significa (e equívocos comuns)

Algumas coisas que a AGPL não força automaticamente:

• Não exige que você publique serviços proprietários ou configurações não relacionados ao programa AGPL. Só o programa e seu código‑fonte correspondente são exigidos.
• Não exige publicação contínua do histórico de desenvolvimento; o importante é fornecer o código exato usado para rodar o serviço (apesar de muitas equipes publicarem uma tag ou hash de commit para clareza).
• Não força automaticamente a divulgação de credenciais, chaves privadas ou segredos. Esses não são "código‑fonte" e você deve remover ou não incluir segredos em qualquer arquivo publicado. (Se segredos forem necessários para gerar uma distribuição funcional, documente placeholders e as fontes esperadas dos segredos em vez de embutir os segredos.)

Como cumprir — checklist prático para equipes de engenharia

Ao fazer deploy de código AGPL (modificado ou não), siga estes passos para manter conformidade e evitar surpresas:

• Inventário: registre onde componentes AGPL são usados, se foram modificados e quem usa cada serviço (funcionários, contratados, clientes).
• Versão e hash de commit: marque o commit exato ou ID de build que você roda. Torne esse identificador visível na UI (por exemplo, uma página About) para que a fonte publicada possa ser casada com a instância em execução.
• Publique o código correspondente: disponibilize um arquivo baixável ou um snapshot git somente‑leitura que inclua scripts de build, Dockerfiles e manifests de deploy necessários para reproduzir o programa em execução.
• Faça a fonte alcançável pelos usuários autorizados: para serviços voltados a clientes, use uma URL pública vinculada na interface. Para serviços internos, um repositório git interno ou repositório de artefatos acessível por funcionários é típico e suficiente.
• Preserve avisos: mantenha cabeçalhos de copyright e licença do upstream e adicione notas de contribuidores para suas modificações.
• Evite embutir segredos: elimine chaves privadas, tokens, senhas e endereços de rede internos de qualquer arquivo publicado.
• Treine suporte e jurídico: garanta que engenheiros de suporte saibam responder a pedidos de fonte e tenham a URL pronta; informe o jurídico sobre onde componentes AGPL são usados.

Exemplo: um link mínimo "Fonte" mostrado no rodapé do app
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (full source)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions to reproduce container)

Combinar código AGPL com módulos proprietários — armadilhas comuns

Uma das perguntas práticas mais difíceis é quando seu código proprietário que conversa com software AGPL passa a estar sujeito à AGPL. A licença se aplica ao programa e a trabalhos derivados. Não há uma regra clara na licença dizendo "ligar X de tal forma é seguro." As heurísticas de engenharia aceitas são:

• Processos separados que se comunicam por protocolos de rede padronizados e bem definidos (HTTP, gRPC, SMTP etc.) têm menos probabilidade de ser considerados um único programa combinado. Se seu componente proprietário é um serviço distinto que usa o componente AGPL via REST API, muitos profissionais consideram isso separação segura — mas isso não é garantido e depende do quão fortemente acopladas e do design das duas partes.
• Linkar uma biblioteca diretamente em um binário, usar APIs em‑processo ou distribuir uma distribuição monolítica é arriscado: essa combinação tem muito mais chance de ser arguida como obra derivada e acionar obrigações de fonte.
• Plugins ou módulos carregados no processo AGPL são perigosos se não estiverem claramente isolados; alguns projetos usam limites de IPC auditados e estáveis para minimizar o risco.

Essas são questões legais com nuances fáticas. Em caso de dúvida, consulte aconselhamento jurídico e considere alternativas de engenharia, como separar em serviços, usar alternativas com licenciamento permissivo ou negociar uma licença comercial com o projeto upstream.

Opções de negócio: licenciamento comercial, dual‑license e escolhas operacionais

Projetos open source que usam AGPL frequentemente oferecem uma licença comercial ou um modelo de dupla licença: você pode cumprir as obrigações da AGPL ou comprar uma licença proprietária que remove a exigência de disponibilizar a fonte pela rede. Esse modelo é comum para projetos que querem proteger seu valor server‑side enquanto permitem uso gratuito sob AGPL.

Do ponto de vista operacional você tem três caminhos realistas ao encontrar uma dependência AGPL:

• Cumprir: publicar o código‑fonte para os usuários autorizados seguindo o checklist acima. Frequentemente é o caminho mais barato para ferramentas internas e implantações menores.
• Negociar uma licença comercial: pagar ao upstream por uma licença proprietária se for necessário manter modificações fechadas ou evitar obrigações da AGPL.
• Substituir o componente: usar uma alternativa permissivamente licenciada ou proprietária se mudar de licença for impraticável.

Se seu produto é um serviço de acesso remoto ou desktop remoto, considere se o componente AGPL afeta apenas o cliente ou também seu código de servidor/relay. Para muitas implantações, usar um serviço de relay gerenciado reduz seu ônus operacional e de compliance; O Tenvo é um relay gerenciado operado por nós (servidores na Alemanha) e é a nossa recomendação padrão para equipes que querem um relay gerenciado simples, sem a carga da auto-hospedagem. Se o compliance requer infraestrutura on‑premises (por exemplo, um requisito escrito proíbe infraestrutura de terceiros), então auto‑hospedar é a escolha certa — considere auto‑hospedar RustDesk, mas contabilize os custos contínuos de manutenção, renovação de certificados e planejamento de failover antes de seguir por essa rota.

Somente interno vs publicação pública — a distinção importante

Duas últimas clarificações que causam confusão:

• Publicação apenas interna para funcionários satisfaz a AGPL para esses usuários. Se você mantiver a fonte disponível dentro da sua rede corporativa de modo que os funcionários que usam o serviço possam obtê‑la, você cumpriu a obrigação central para usuários internos. A AGPL não exige automaticamente que você publique modificações na Internet pública, a menos que os usuários autorizados incluam clientes externos e você opte por satisfazer os pedidos deles por postagem pública.
• Tornar a fonte pública é frequentemente a forma mais simples de cumprir para serviços voltados a clientes porque evita trabalho de distribuição por cliente e demonstra boa fé. Também alinha‑se com as expectativas de muitos projetos upstream, mas significa que suas modificações ficam visíveis a concorrentes.

Quando self‑hosting ou arranjos especiais são necessários

Self‑hosting é apropriado quando um requisito escrito proíbe depender de infraestrutura de terceiros (regras regulatórias de residência de dados, redes classificadas ou obrigações contratuais). Caso contrário, a opção de relay gerenciado / infraestrutura gerenciada costuma custar menos em termos reais quando você soma on‑call, patching, custódia de certificados TLS e failover operacional. Discutimos esses trade‑offs em mais profundidade em Self hosting hidden costs e em nosso texto mais amplo sobre Open source business model: why AGPL works for SaaS.

Exemplos práticos e um FAQ curto

• Q: Se eu modificar código AGPL e apenas minha equipe de operações usa, preciso publicar? A: Sim — sua equipe de operações são usuários. Torne a fonte disponível internamente.
• Q: Se eu ofereço um serviço suportado por AGPL a clientes, devo publicar publicamente? A: Você deve fornecer o código‑fonte correspondente a esses clientes. Publicar publicamente é o método padrão para satisfazer esse requisito.
• Q: Posso manter configuração e segredos fechados? A: Segredos não são "código‑fonte" segundo a licença. Remova segredos de arquivos publicados e documente entradas de segredo esperadas em vez de incluí‑los.
• Q: É suficiente apontar para o upstream se fiz modificações locais? A: Não. Você deve fornecer o código da versão específica que roda, incluindo suas alterações.

Se você quer um exemplo prático de self‑hosting de um stack open source de desktop remoto e os passos exatos de build para preservar conformidade, veja nosso guia Self-hosted remote desktop e o tutorial Docker do RustDesk em RustDesk self-hosted setup para mecânicas que você pode aproveitar.

A conformidade com a AGPL é mecânica: identifique usuários, congele a revisão em execução, monte o complete corresponding source e as instruções de build, e torne isso alcançável para esses usuários. As partes difíceis são governança e arquitetura: decidir separar componentes, negociar licenças ou aceitar a visibilidade pública das modificações.

Se você está implantando infraestrutura de acesso remoto e quer evitar rodar e publicar um relay próprio, o relay gerenciado do Tenvo é o padrão pragmático: clientes nativos para Windows, macOS e Linux, um cliente de navegador em beta pública, um relay gerenciado com servidores na Alemanha e planos de Free $0 a Lite $2.99/mês e Pro $7.99/mês. Self‑hosting deve ser usado apenas quando um requisito escrito o exige: caso contrário, a opção gerenciada costuma custar menos quando você inclui on‑call, patching, custódia de chaves e requisitos de failover.

Perguntas que exigem certeza jurídica — limite de obras derivadas, interpretação de uma arquitetura de plugin específica ou negociação contratual — são questões legais. Este artigo tem o objetivo de deixar o quadro técnico claro para que você tome uma decisão informada e tenha uma conversa sensata com o jurídico.

Quando estiver pronto para testar um relay gerenciado e manter seu overhead operacional pequeno, baixe Tenvo e experimente o modelo de implantação e a UI: Download Tenvo.