Licencias flotantes (concurrentes) explicadas

Hace años trabajé con un proveedor que vendía una herramienta de análisis especializada a firmas de ingeniería. Un cliente tenía 200 ingenieros pero, en un día cualquiera, quizá 15 de ellos abrían de verdad la herramienta. El cliente se negó rotundamente a comprar 200 puestos de bloqueo por equipo para un software que el 92 % de su plantilla no tocaría esa semana, y, honestamente, tenía razón. La respuesta no era un descuento. Era un modelo de licenciamiento distinto: véndeles 20 puestos flotantes y deja que toda la firma los comparta. Ese único cambio convirtió un trato perdido en uno firmado.

Este artículo explica el licenciamiento flotante (también llamado concurrente) como es debido: qué es realmente el modelo, en qué se diferencia del bloqueo por equipo y del usuario nombrado, cómo se aplica un techo de concurrencia con check-in/check-out y leases, y, igual de importante, cuándo no usarlo.

Idea clave: una licencia flotante limita cuántas copias se ejecutan al mismo tiempo en un grupo compartido, en lugar de vincular la licencia a máquinas o personas concretas. Cambia la simplicidad sin conexión del bloqueo por equipo por un servidor que cuenta las sesiones vivas, y a cambio permite que un equipo grande comparta un número pequeño de puestos caros.

Los tres modelos, lado a lado

Toda conversación sobre licenciamiento acaba desembocando en una de tres formas de decidir quién puede ejecutar tu software:

• Bloqueo por equipo: la licencia está vinculada a una máquina mediante una huella de hardware. Ese dispositivo la ejecuta; nada más lo hace. Estupendo sin conexión, facilísimo de razonar, pero desperdicia puestos cuando la gente comparte hardware o rota.
• Usuario nombrado: la licencia está vinculada a una persona (una identidad), que normalmente puede ejecutarla en sus propios dispositivos. Bueno cuando el uso sigue a los individuos, habitual en herramientas de escritorio cercanas al SaaS.
• Flotante / concurrente: la licencia no está vinculada ni a una máquina fija ni a una persona fija. En su lugar, posees N usos simultáneos, y cualquiera de la organización puede tomar uno mientras esté libre.

Escribí una taxonomía más completa en tipos de licencia de software explicados, y cubrí la mecánica de vinculación a la máquina en bloqueo por equipo y gestión de puestos. El resumen de una línea: el bloqueo por equipo responde a “¿qué máquinas?”, el usuario nombrado responde a “¿qué personas?”, y el flotante responde a “¿cuántas a la vez?”.

Cómo funciona realmente un techo de concurrencia

El corazón del licenciamiento flotante es un ciclo de check-out / check-in contra un servidor que mantiene la cuenta viva.

1. Cuando tu app arranca (o cuando un usuario invoca una característica con licencia), le pide un hueco al servidor: check-out.
2. El servidor compara los huecos ocupados con el techo. Por debajo del límite, concede un hueco y devuelve un token de corta duración; en el límite, rechaza con un resultado de “no hay puestos disponibles”.
3. Cuando la app se cierra, devuelve el hueco: check-in. La cuenta baja en uno y la siguiente persona puede continuar.

Una versión ingenua de esto se rompe la primera vez que una app se cierra inesperadamente: el hueco nunca se devuelve y se fuga del grupo para siempre. La solución que usa toda implementación real es un lease: el hueco concedido solo es válido durante una ventana corta, y el cliente debe renovarlo periódicamente para conservarlo. Si el cliente muere, la renovación se detiene, el lease caduca y el servidor reclama el hueco automáticamente. Las fugas se curan solas.

En pseudocódigo con forma de SDK se lee más o menos así:

// Check out a concurrent slot at startup.
var slot = await license.CheckOutAsync(feature: "analysis");
if (!slot.Granted)
{
    // Ceiling reached — fail closed, tell the user to try again shortly.
    ShowMessage(slot.Message); // e.g. "All 20 concurrent seats are in use."
    return;
}

// Keep the slot alive while the app runs; the SDK renews the lease for you.
// On exit, return it to the pool.
await license.CheckInAsync(slot);

Fíjate en que la ruta de fallo no desbloquea nada. Como toda comprobación de licencia, un check-out flotante debería fallar en cerrado: un hueco rechazado, un servidor inalcanzable o un lease caducado se resuelven todos en sin licencia, nunca en un desbloqueo silencioso. Profundizo en ese principio en validación de licencias sin conexión explicada.

La concurrencia necesita un servidor, y ese es el intercambio

No puedes contar el uso concurrente en el cliente. Una sola máquina no tiene ni idea de cuántas otras máquinas de la organización están ocupando un hueco ahora mismo; eso es estado compartido en tiempo real, y el estado compartido vive en un servidor. Esta es la misma razón por la que los límites de puestos y la revocación necesitan un servidor, solo que subida de tono: los puestos se cuentan en el momento de la activación y cambian despacio, mientras que la concurrencia se cuenta de forma continua y cambia segundo a segundo.

La consecuencia práctica: el licenciamiento flotante puramente sin conexión es una contradicción. Puedes suavizar la dependencia (cachear un lease para que un breve corte de red no mate una sesión en curso, añadir una ventana de gracia para que una caída no le arranque la herramienta a alguien a mitad de tarea), pero el techo en sí solo es real mientras el servidor sea alcanzable. Ese es el coste honesto del modelo, y es por lo que el flotante encaja mucho mejor en entornos corporativos conectados que en los aislados (air-gapped).

Techos de dispositivos activos: el primo más fácil del flotante

El check-in/check-out a nivel de sesión completo es la forma más estricta de concurrencia, y es más maquinaria de la que la mayoría de los productos necesita. Una variante más ligera cubre muchos casos reales: limita el número de dispositivos activos en lugar de las sesiones simultáneas.

Aquí, cada máquina se activa contra el servidor y conserva una activación hasta que se desactiva explícitamente (o su lease caduca). Permites hasta N dispositivos activos a la vez; un dispositivo retirado libera su hueco para otro. No es la concurrencia verdadera de “quién lo está ejecutando en este segundo” (es “cuántas máquinas conservan actualmente una activación viva”), pero entrega la mayor parte del valor de negocio con mucha menos complejidad en el cliente, y se degrada con elegancia sin conexión porque un dispositivo conserva su hueco ya concedido sin una conexión viva. Si tu objetivo es “un equipo de 50 debería compartir 20 instalaciones”, un techo de dispositivos activos suele ser la opción pragmática correcta.

Cuándo recurrir al flotante, y cuándo no

El flotante es una herramienta especializada. Recurre a él cuando:

• El software es caro y lo usa ocasionalmente un grupo grande: la demanda concurrente es una fracción del número de personas. Esta es toda la razón por la que las herramientas de CAD, EDA e ingeniería/análisis pesado llevan décadas usando licenciamiento flotante.
• Tus clientes trabajan en un entorno conectado donde un servidor de licencias (tuyo o suyo) es alcanzable de forma fiable.
• Los compradores piden explícitamente “compartir puestos entre el equipo” en lugar de asignarlos.

Sáltatelo cuando:

• El uso es más o menos un usuario, todo el día: entonces estás manteniendo un servidor que cuenta sesiones para un beneficio que nunca materializas, y el simple bloqueo por equipo por puesto es más simple y barato de operar.
• Necesitas trabajar aislado (air-gapped) o con prioridad sin conexión: la concurrencia no puede aplicarse sin una cuenta viva. Para esos despliegues, los puestos de bloqueo por equipo más los archivos firmados sin conexión son el emparejamiento correcto.
• Tu precio es lo bastante bajo como para que la sobrecarga operativa de gestionar la concurrencia cueste más que los puestos que ahorra.

Sé honesto sobre los límites

Dos advertencias que vale la pena enunciar sin rodeos. Primera, como toda barrera del lado del cliente, la llamada de check-out se ejecuta en la máquina del usuario y puede ser parcheada por un atacante decidido con un decompilador, por eso el techo se aplica en un servidor que ellos no controlan, y por eso emparejas el cliente con ofuscación (consulta proteger tus comprobaciones de licencia). Segunda, el licenciamiento flotante puede frustrar a usuarios legítimos cuando el techo se fija demasiado bajo: a nadie le gusta un “todos los puestos en uso” a las 9 de la mañana. Dimensiona el grupo a la concurrencia pico real, no a la media, y da a los administradores visibilidad sobre quién está ocupando los huecos.

Haciendo esto con Keyright

Keyright es la infraestructura de licenciamiento que construimos en Delta1 Labs, y aplica la mitad del conteo de todo esto del lado del servidor para que tú no lo construyas. Modelas un producto con un techo de puestos o de dispositivos activos, incrustas el SDK (.NET, Node, Python o Java), y dejas que las activaciones, los leases y la autodesactivación gestionen el grupo, con un lease firmado de corta duración que mantiene a los usuarios trabajando durante un breve corte y reclama los huecos automáticamente cuando un cliente desaparece. La concurrencia es una decisión compartida y con estado, y esa es exactamente la parte que Keyright ejecuta por ti, ya sea en nuestra nube gestionada o autoalojada dentro de tu red.

El plan gratuito es suficiente para cablear la aplicación de puestos real de extremo a extremo antes de que pagues nada: empieza gratis, o lee la guía de integración con .NET para la superficie de activación exacta.