Toda negociação de renovação de software passa pela mesma frase, dita com naturalidade dos dois lados da mesa: ninguém vai desligar um sistema em produção. A frase costuma se confirmar. O problema não é a intenção de quem fala, é que a continuidade da sua operação virou uma decisão que precisa ser tomada de novo todo ano.
Esta peça fecha a série porque responde à pergunta que a primeira deixou em aberto, o que continua funcionando se o contrato terminar. A peça sobre preço encerrou dizendo que a outra metade da conta é o fim do contrato. É esta metade.
A diferença entre funcionar, atualizar e ter suporte
Quase todo software corporativo para de funcionar em uma data que ninguém discute na assinatura. O serviço roda na infraestrutura do fornecedor e continua enquanto a fatura é paga. Se a renovação não acontece, o sistema para, não porque alguém decidiu punir o cliente, mas porque a arquitetura de assinatura transformou a continuidade em função do calendário. Isso embaralha três coisas vendidas como uma só: continuar funcionando, continuar recebendo atualização e continuar tendo alguém do outro lado quando algo quebra são condições distintas, com riscos distintos.
No setor público a distinção fica mais dura: a continuidade de um serviço ao cidadão não deveria depender de o orçamento aparecer no exercício seguinte. A resposta da Aptabit a essa restrição é contratual: órgãos públicos podem adquirir a linha em licenciamento perpétuo, com direito de uso definitivo e sem renovação anual. Somado à instalação no ambiente do próprio órgão, o arranjo tira da mesa as duas alavancas mais usadas para segurar um cliente, a renovação anual e a custódia do dado. Não tira a terceira. Correção, versão nova e atendimento continuam sendo contrato. É a previsibilidade defendida na peça sobre preço, levada um passo adiante: a licença fixa torna a conta conhecida enquanto o contrato dura, e a perpétua tira a data do direito de uso, não da manutenção.
O que sobrevive sem depender de nós
Parte da resposta é decidida antes do vencimento, e não depende do fornecedor. Se as respostas que a sua operação usa vêm de um modelo aberto rodando na sua infraestrutura, esse modelo não veio da nossa licença e não sai com ela. O site descreve o arranjo: modelos locais com Ollama, vLLM ou LM Studio, trocáveis quando você quiser. No dia seguinte ao fim do contrato, o modelo continua no servidor em que estava, e o acervo também.
É aqui que se juntam duas peças anteriores, a que discutiu se o modelo local dá conta da tarefa e a que discutiu onde ele roda. Se o fluxo aponta para a chave de um provedor externo, o contrato que decide o dia seguinte é o daquele provedor, não o nosso. E agentes, fluxos e permissões, que a plataforma acrescenta em cima do modelo, continuam sujeitos à licença assinada.
Onde a licença perpétua não resolve nada
Licença perpétua não é sinônimo de sistema eterno, e fechar a série elogiando a própria escolha seria o pior uso possível da última peça. A modalidade perpétua é oferecida a órgãos públicos, e o cliente do modelo comum não conta com ela. Há pelo menos três coisas que a licença não resolve sozinha, e a terceira é a que sobra para quem contrata desse jeito.
Quem sabe operar. Software que continua rodando precisa de gente capaz de operá-lo e diagnosticá-lo, e direito de uso definitivo não produz essa competência. Para quem não tem equipe de infraestrutura, a assinatura é o modelo coerente. A pergunta a fazer é quem opera o sistema anos depois da implantação, não se ele ainda pode ser usado.
Correção de segurança. Direito de uso é uma coisa, manutenção é outra. O que um contrato perpétuo inclui de atualização, de versão futura e de suporte varia, e não se deduz da palavra perpétuo. Quem trata licença perpétua como isenção de manutenção troca um risco por outro, e o segundo aparece mais tarde e mais caro.
A própria licença. A plataforma sobe no seu ambiente, mas sobe com uma licença assinada, e o nosso site diz que existe período de carência. É uma alavanca técnica ligada ao contrato, do mesmo tipo que este texto critica acima. O que prazo e carência fazem no vencimento não se deduz da arquitetura, e isso ainda não está publicado. O site diz que a carência existe e para aí: a condição vive no contrato. Sem isso público, o cliente do modelo comum não consegue conferir o que a primeira peça prometeu que esta responderia. Vamos publicar quanto dura a carência, o que continua executável durante ela e o que acontece com a instalação depois. Nada mais desta série sai antes disso.
O teste de saída que cabe antes da assinatura
A saída de um fornecedor é uma propriedade do projeto, não uma cláusula do contrato, e se verifica antes de assinar. A pergunta a fazer é como o fornecedor documenta a saída, não se ele diz que ela existe. As perguntas abaixo cabem em qualquer proposta, leve a resposta à Aptabit ou a outro lugar:
- Se eu parar de pagar amanhã, o sistema continua executando, para de ser atualizado ou para de funcionar?
- Onde ficam os meus dados no dia seguinte, e os índices e as representações derivadas saem junto?
- Os fluxos, as configurações e as permissões que eu construí são legíveis fora do produto?
- O modelo que gera as respostas continua disponível para mim sem esse contrato?
- Quanto tempo e quanto custaria reconstruir essa operação em outro lugar, estimado por quem faria isso?
A quinta é a que costuma ficar sem resposta, e é ela que define o preço real das quatro anteriores.
Por que esta peça fecha a série
A série começou por uma frase do nosso site, a de que os dados que mais valem são exatamente os que você não pode enviar, e a decisão que ela impõe é ir até o dado, em vez de pedir que o dado venha até nós. As peças anteriores percorreram onde o dado fica, se o modelo local basta, onde o software roda e quem o opera, o que a lei ainda cobra e quanto a conta custa quando é de licença e não de consumo. O que sobra no fim é o assunto desta. Com banco, arquivos e vetores no ambiente do cliente, o encerramento deixa de perguntar onde o dado está e passa a perguntar em que formato ele é legível sem o produto.
Nada disso torna o sistema eterno, e essa é a parte inconveniente de fechar a série aqui. O que a arquitetura tira da mesa é a custódia do dado, uma parte do problema e não o problema. O direito de executar o software e a manutenção continuam dependendo de um contrato que alguém precisa renovar ou honrar. Contrato continua sendo negociação, aqui também.