modelo de negócio de código aberto: por que AGPL funciona para SaaS

Você mantém um projeto útil de acesso remoto de código aberto e teme que provedores em nuvem o copiem, ofereçam como serviço hospedado e não devolvam contribuições. Essa situação — a chamada brecha do SaaS — é por isso que algumas equipes escolhem a AGPL. Este artigo explica o que a AGPL realmente faz para um operador de SaaS, como ela influencia escolhas de monetização e as trocas operacionais reais, incluindo hospedagem de relays e implantações gerenciadas vs hospedagem própria.

O que a AGPL (Affero GPL v3) muda, em termos práticos

AGPLv3 é GPLv3 mais uma cláusula de uso em rede (frequentemente chamada de Section 13) que exige que você ofereça o código‑fonte a qualquer pessoa que interaja com o programa pela rede. Na prática isso significa: se você executa o lado servidor de um app AGPL e usuários interagem com ele via web ou API, você deve tornar suas modificações disponíveis a esses usuários. Fecha a clássica 'brecha do SaaS' da GPL onde uma empresa pode modificar o código, rodá‑lo como serviço hospedado e nunca publicar as alterações.

Esse efeito legal é estreito e concreto. Não evita magicamente que pessoas hospedem seu software, mas cria uma obrigação legal de compartilhar mudanças e dá aos licenciadores alavancagem quando um terceiro reempacota seu código como produto hospedado proprietário.

Como a AGPL apoia modelos de negócio SaaS

Existem três padrões práticos de negócio onde a AGPL faz sentido para um produto apoiado por SaaS:

Licenciamento duplo: Ofereça o código sob AGPL para a comunidade e venda licenças comerciais (proprietárias) a clientes que precisam embutir ou estender o código sem as obrigações da AGPL. Este é o modelo clássico de negócio open source para fornecedores de banco de dados e middleware.
Add‑ons hospedados e infraestrutura gerenciada: Mantenha o protocolo/núcleo aberto sob AGPL e venda serviços hospedados que são operacionalmente caros de replicar — relays multi‑região, analytics, backups ou orquestração. Clientes pagam pela conveniência, SLAs e redução do ônus operacional.
Suporte, SLAs e recursos enterprise: O código AGPL permanece aberto, mas você monetiza por suporte pago, treinamento, integrações customizadas ou plugins proprietários empresariais servidos a partir de uma fronteira de serviço separada.

Para software de desktop remoto especificamente, o relay hospedado é um produto natural: relays carregam largura de banda e exigem presença global para baixa latência. Vender um relay gerenciado faz sentido comercial enquanto o código do cliente e do servidor permanece AGPL.

Licenciamento duplo: mecânica e realidades

Licenciamento duplo é direto em conceito: você publica o projeto sob AGPL e também oferece uma licença comercial para clientes que não querem as obrigações da AGPL. Os dois pontos-chave de implementação são controle sobre contribuições e clareza legal.

Controle de contribuições: para vender licenças comerciais, você precisa de uma cessão limpa ou de um Contributor License Agreement (CLA) que lhe permita relicenciar o código dos contribuidores. Sem isso, você não pode legalmente vender uma licença proprietária que inclua contribuições de terceiros.

Precificação comercial: espere que licenças comerciais iniciais sejam negociadas em vez de listadas. Muitos projetos começam com um produto hospedado modesto (por exemplo, um serviço de relay) com preço transparente — a oferta de relay gerenciado da Tenvo é um exemplo de empacotar a peça operacional mantendo o código de protocolo aberto — e reservam preços negociados para integrações profundas ou instalações on‑premises.

Por que um relay gerenciado costuma ser a recomendação padrão

Complexidade operacional é o custo silencioso da hospedagem própria. Um cluster de relay precisa de gerenciamento de certificados TLS, monitoramento, proteção DDoS, failover multi‑região, faturamento de largura de banda e engenheiros de plantão. Para a maioria dos clientes comerciais, comprar um relay gerenciado reduz o tempo para obter valor e fornece custo previsível.

O relay gerenciado da Tenvo é oferecido multi‑região por padrão e incluso em nossos planos comerciais: Free $0, Lite $2.99/mo e Pro $7.99/mo. Para equipes que querem simplicidade e SLA, um relay gerenciado geralmente custa menos do que contratar uma pessoa de operações quando você considera patching, resposta a incidentes e ciclo de vida de certificados.

Hospedagem própria: quando faz sentido

Hospedagem própria é a escolha correta quando um requisito escrito a determina: regulamentações proibindo infraestrutura de terceiros, uma rede isolada sem saída para a internet, ou restrições rígidas de residência de dados que seu relay gerenciado não consegue atender. Nesses casos a AGPL ainda funciona — e pode até ser preferível — mas você deve aceitar os custos operacionais: provisionamento, HA, resposta a incidentes, custódia de chaves e renovação de certificados TLS.

Se você está ponderando hospedagem própria, leia as trocas práticas em nosso Self-hosted remote desktop: the honest 2026 guide — ele percorre DNS, automação de certificados e monitoramento básico que você não pode pular.

Segurança e criptografia: o que a licença não muda

Licenciamento não altera a segurança de transporte. Arquiteturalmente, uma conexão direta ponto a ponto é end‑to‑end entre os dois dispositivos. Se uma sessão recorre a um relay, o TLS precisa terminar naquele relay, portanto o operador do relay fica em posição de observar o tráfego da sessão. Isso é um fato operacional que você deve considerar ao vender infraestrutura hospedada ou quando clientes perguntam sobre exposição de dados.

Seja explícito sobre isso na documentação do produto: descreva quando conexões diretas são possíveis, o que o fallback para relay implica e o que o operador do relay pode e não pode acessar. Para um tratamento mais aprofundado das ameaças ao desktop remoto, veja Remote Desktop Security: What You Need to Know.

Arquitetura prática: mantenha as partes monetizáveis distintas

Quando você escolhe AGPL, estruture o projeto para separar os componentes que pretende monetizar do núcleo licenciado sob AGPL. Padrões típicos de separação:

Open core: Cliente e protocolo centrais sob AGPL; componentes opcionais proprietários do servidor (por exemplo, uma API de orquestração avançada) entregues sob licença comercial ou SaaS.
Service boundary: Coloque o relay hospedado e serviços operacionais em um serviço separado que interaja com o core aberto por APIs documentadas. O relay pode ser proprietário ou cobrado como serviço enquanto o core permanece AGPL.
Plugins vs core: Mantenha tempo de execução, protocolo e transporte de baixo nível em AGPL; exponha pontos de extensão onde plugins empresariais (licenciados comercialmente) possam rodar em um ambiente controlado.

A separação arquitetural reduz a ambiguidade legal e facilita explicar aos clientes quais partes são abertas e quais são serviços comerciais.

Trocas para desenvolvedores e comunidade

AGPL atrai contribuintes que querem copyleft forte e melhorias comunitárias, mas pode afastar corporações que se recusam a aceitar obrigações de uso em rede. Espere menos pull requests de empresas que constroem SaaS proprietários — mas contribuições da comunidade por desenvolvedores individuais e instituições costumam ser maiores porque veem que o código permanecerá aberto.

Para manter contribuições saudáveis, tenha documentação clara de contribuição, um CLA se você planeja licenciar duplamente, e governança transparente. Muitos projetos adotam uma política de Transparência na Governança, cadência de lançamentos regular (por exemplo, uma estável mensal + builds noturnos) e processos claros de divulgação de segurança para reduzir atritos com usuários enterprise.

Aplicação e reputação — a alavanca indireta

Licenças só são úteis na medida em que você pode aplicá‑las. A aplicação pode ser legal, mas frequentemente é reputacional: exposições públicas, contatos formais e pressão da comunidade importam. Mudanças de alto perfil no ecossistema open source (por exemplo, fornecedores de banco de dados que mudaram para SSPL ou licenças source‑available) mostram que escolhas de licença influenciam comportamento — mas aplicar a licença exige recursos e disposição para litigar ou para ações próximas a litígio.

Se a aplicação for central ao seu modelo, prepare‑se: mantenha históricos de contribuições, rastreie deployers (na medida legalmente possível) e reserve orçamento para suporte jurídico. Para muitos projetos, o valor prático da AGPL é dissuasão e uma rota clara para negociação, em vez de batalhas judiciais frequentes.

Preço e exemplos de custo: contabilidade realista

Números reais variam, mas considere estes exemplos aproximados ao escolher entre modelos de relay gerenciado e hospedagem própria:

Equipe pequena usando uma única região de relay com largura de banda leve: relay gerenciado por menos de $100/month frequentemente sai mais barato do que o tempo de ops para executar e proteger.
Serviço em produção exigindo HA multi‑região e plantão 24/7: replicação, proteção DDoS e egress de banda podem levar custos de hospedagem própria para centenas ou baixos milhares por mês. Um relay gerenciado com SLAs pode ser mais custo‑efetivo incluindo custos de equipe.

Essas são faixas aproximadas — capacidade, volumes de egress e requisitos de compliance mudam a conta rapidamente — mas o ponto é que o custo operacional de um relay global confiável não é trivial, o que torna economicamente racional empacotá‑lo como um serviço pago.

Checklist: lançar um SaaS baseado em AGPL de forma responsável

Escolha explicitamente a versão da licença (AGPLv3 recomendado para a maioria das equipes) e documente o que ela cobre.
Use um CLA ou cessão de contribuições se planeja vender licenças comerciais.
Separe infraestrutura monetizável (relays, orquestração, analytics) atrás de uma fronteira de serviço clara.
Documente quando sessões passam por relays e as implicações de segurança (terminação TLS no relay).
Publique documentação clara de upgrade, instalação e hardening para reduzir atrito para quem hospeda por conta própria.
Decida postura de aplicação e orce recursos jurídicos ou uma política de mediação.
Precifique serviços hospedados com tiers transparentes; o modelo Free $0 / Lite $2.99/mo / Pro $7.99/mo da Tenvo é um exemplo de funil simples que escala para planos enterprise com SLA.

Quando escolher outra coisa

AGPL não é a escolha certa se seu objetivo é máxima adoção por fornecedores de SaaS terceiros ou se você quer reuso permissivo em sistemas fechados sem negociação. Para bibliotecas destinadas a serem embutidas em produtos proprietários, licenças permissivas (MIT/BSD/Apache 2.0) costumam ser melhores.

Considere também abordagens híbridas: uma biblioteca cliente permissiva com um servidor AGPL, ou core permissivo com um servidor de referência AGPL. Cada escolha sinaliza claramente os tipos de reuso que você quer incentivar ou impedir.

Leituras adicionais e comparações

Se você quer comparar as trocas para projetos de desktop remoto especificamente, nossa comparação fork‑and‑host é uma leitura útil: RustDesk vs Tenvo: fork comparison for self-hosters. E se você está decidindo o custo/benefício da hospedagem própria, reveja os passos operacionais em Self-hosted remote desktop: the honest 2026 guide.

Licenciamento é uma alavanca entre muitas. Escolha AGPL quando precisar de garantias legais de que usuários em rede podem acessar o código‑fonte e quando pretender monetizar serviços operacionais, mas seja explícito com clientes sobre o que AGPL resolve e o que não resolve: ela trata de contribuições de código e divulgação, não de segurança de transporte ou erros de configuração.

Pronto para testar uma stack de acesso remoto com base em AGPL e opção de relay gerenciado? Baixe o cliente e experimente, ou veja detalhes de preços e planos gerenciados em our pricing page. Quando quiser colocar as mãos na massa, download e teste um setup com relay em minutos.