Toda negociación de renovación de software pasa por la misma frase, dicha con naturalidad en los dos lados de la mesa: nadie va a apagar un sistema en producción. La frase suele confirmarse. El problema no es la intención de quien la dice, es que la continuidad de tu operación se convirtió en una decisión que hay que volver a tomar cada año.
Esta pieza cierra la serie porque responde a la pregunta que la primera dejó abierta, qué sigue funcionando si el contrato termina. La pieza sobre precio se despidió diciendo que la otra mitad de la cuenta es el fin del contrato. Es esta mitad.
La diferencia entre funcionar, actualizarse y tener soporte
Casi todo el software corporativo deja de funcionar en una fecha que nadie discute al firmar. El servicio se ejecuta en la infraestructura del proveedor y sigue mientras se pague la factura. Si la renovación no ocurre, el sistema se detiene, no porque alguien haya decidido castigar al cliente, sino porque la arquitectura de suscripción convirtió la continuidad en una función del calendario. Eso mezcla tres cosas que se venden como una sola: seguir funcionando, seguir recibiendo actualizaciones y seguir teniendo a alguien del otro lado cuando algo se rompe son condiciones distintas, con riesgos distintos.
En el sector público la distinción es más dura: la continuidad de un servicio al ciudadano no debería depender de que el presupuesto aparezca en el ejercicio siguiente. La respuesta de Aptabit a esa restricción es contractual. Los organismos públicos pueden adquirir la línea en licenciamiento perpetuo, con derecho de uso definitivo y sin renovación anual. Sumado a la instalación en la infraestructura del propio organismo, el arreglo saca de la mesa las dos palancas más usadas para retener a un cliente, la renovación anual y la custodia del dato. No saca la tercera. La corrección, la versión nueva y la atención cuando algo se rompe siguen siendo contrato. Es la previsibilidad que defendió la pieza sobre precio, un paso más allá: la licencia fija hace que la cuenta se conozca mientras dura el contrato, y la perpetua le quita la fecha de vencimiento al derecho de uso, no al mantenimiento.
Qué sobrevive sin depender de nosotros
Parte de la respuesta se decide antes del vencimiento, y no depende del proveedor. Si las respuestas que usa tu operación vienen de un modelo abierto ejecutándose en tu infraestructura, ese modelo no llegó con nuestra licencia y no se va con ella. El sitio describe el arreglo: modelos locales ejecutados con Ollama, vLLM o LM Studio, intercambiables cuando quieras. Al día siguiente del fin del contrato, el modelo sigue en el servidor en el que ya estaba, y el acervo también.
Aquí se juntan dos piezas anteriores, la que preguntó si el modelo local alcanza para la tarea y la que preguntó dónde se ejecuta. Si el flujo apunta a la clave de un proveedor externo, el contrato que decide el día siguiente es el de ese proveedor, no el nuestro. Y los agentes, los flujos y los permisos que la plataforma agrega encima del modelo siguen sujetos a la licencia firmada.
Dónde la licencia perpetua no resuelve nada
Licencia perpetua no es sinónimo de sistema eterno, y cerrar la serie elogiando la propia decisión sería el peor uso posible de la última pieza. La modalidad perpetua se ofrece a organismos públicos, y el cliente del modelo comercial común no cuenta con ella. Hay al menos tres cosas que la licencia no resuelve por sí sola, y la tercera es la que le queda a quien contrata de ese modo.
Quién sabe operar. Un software que sigue ejecutándose necesita gente capaz de operarlo y de diagnosticarlo, y el derecho de uso definitivo no produce esa competencia. Para quien no tiene equipo de infraestructura, la suscripción es el modelo coherente. La pregunta a hacer es quién opera el sistema años después de la implantación, no si todavía se puede usar.
Corrección de seguridad. El derecho de uso es una cosa, el mantenimiento es otra. Lo que un contrato perpetuo incluye de actualización, de versión futura y de soporte varía, y no se deduce de la palabra perpetuo. Una organización que trata la licencia perpetua como exención de mantenimiento cambia un riesgo por otro, y el segundo aparece más tarde y más caro.
La licencia misma. La plataforma se instala en tu entorno, pero se instala con una licencia firmada, y nuestro sitio dice que existe un período de gracia. Es una palanca técnica ligada al contrato, del mismo tipo que este texto critica arriba. Lo que hacen el plazo y el período de gracia al vencer no se deduce de la arquitectura, y eso todavía no está publicado. El sitio dice que el período de gracia existe y ahí se detiene: la condición vive en el contrato. Sin eso en público, el cliente del modelo común no puede verificar lo que la primera pieza prometió que esta respondería. Vamos a publicar cuánto dura el período de gracia, qué sigue siendo ejecutable durante él y qué pasa con la instalación cuando termina. Nada más de esta serie sale antes que eso.
La prueba de salida que cabe antes de firmar
La salida de un proveedor es una propiedad del proyecto, no una cláusula del contrato, y se verifica antes de firmar. La pregunta a hacer es cómo documenta el proveedor la salida, no si dice que existe. Las preguntas de abajo caben en cualquier propuesta, lleve la respuesta a Aptabit o a otro lugar:
- Si dejo de pagar mañana, ¿el sistema sigue ejecutándose, deja de actualizarse o deja de funcionar?
- ¿Dónde quedan mis datos al día siguiente, y los índices y las representaciones derivadas salen junto con ellos?
- ¿Los flujos, las configuraciones y los permisos que construí son legibles fuera del producto?
- ¿El modelo que genera las respuestas sigue disponible para mí sin ese contrato?
- ¿Cuánto tiempo y cuánto costaría reconstruir esa operación en otro lugar, estimado por quien tendría que hacerlo?
La quinta es la que suele quedar sin respuesta, y es la que define el precio real de las cuatro anteriores.
Por qué esta pieza cierra la serie
La serie empezó por una frase de nuestro sitio, la de que los datos que más valen son justo los que no puedes enviar, y la decisión que esa frase impone es ir hasta el dato, en vez de pedir que venga hasta nosotros. Las piezas anteriores recorrieron dónde queda el dato, si el modelo local alcanza, dónde se ejecuta el software y quién lo opera, qué sigue exigiendo la ley y cuánto cuesta la cuenta cuando es de licencia y no de consumo. Lo que queda al final es el asunto de esta. Con la base de datos, los archivos y los vectores en el entorno del cliente, el cierre deja de preguntar dónde está el dato y pasa a preguntar en qué formato es legible sin el producto.
Nada de esto vuelve eterno al sistema, y esa es la parte incómoda de cerrar la serie aquí. Lo que la arquitectura saca de la mesa es la custodia del dato, una parte del problema y no el problema. El derecho de ejecutar el software y el mantenimiento siguen dependiendo de un contrato que alguien tiene que renovar u honrar. Un contrato sigue siendo negociación, aquí también.