Cómo licenciar tu software: una guía práctica

Para licenciar tu software, eliges un modelo de licenciamiento, emites a cada cliente una licencia firmada criptográficamente en lugar de una cadena de clave casera, la entregas en la compra, y la verificas dentro de tu aplicación — una comprobación de firma sin conexión, opcionalmente combinada con activación en línea para aplicar puestos y revocación — luego controlas las funciones según los derechos y gestionas pruebas, renovaciones y revocación en el servidor. Esta guía recorre todo ese camino de principio a fin, neutral en cuanto a producto en la mecánica, para que puedas montar un licenciamiento real tanto si lo construyes tú mismo como si adoptas un servicio.

Paso 1 — Elige un modelo de licenciamiento

Todo lo que viene después se deriva de esta elección, así que hazla primero. Los modelos comunes:

• Perpetuo — el cliente compra el software una vez y ejecuta esa versión para siempre. Sencillo, pero no hay ingresos recurrentes ni una razón intrínseca para que la licencia deje de funcionar alguna vez.
• Suscripción / por plazo — la licencia es válida durante una ventana fija (normalmente un año) y lleva un vencimiento que la aplicación hace cumplir. Este es el modelo por defecto para la mayoría del software moderno porque alinea los ingresos con el valor continuo.
• Por puestos — la licencia permite un número determinado de activaciones, una por máquina o usuario, y tú aplicas el tope. Estándar para ventas de equipo y empresa.
• Prueba / evaluación — una licencia con límite de tiempo que desbloquea la experiencia de pago durante un número fijo de días, y luego vence.

La mayoría de los productos reales combinan estos: una suscripción con un número de puestos, o una licencia perpetua con una ventana de soporte y actualizaciones. No tienes que elegir exactamente uno. (Para una referencia completa de cada modelo y cuándo usarlo, consulta nuestra entrada complementaria, los tipos de licencia de software explicados.)

Paso 2 — Emite una licencia firmada, no una cadena de clave

La decisión más importante es qué es una licencia sobre el cable. El atajo tentador — generar una cadena de clave aleatoria o con patrón y hacer que tu aplicación acepte cualquier cosa que coincida con ese patrón — falla estructuralmente: si tu aplicación puede decidir que una clave es válida mirando la clave, entonces todo lo necesario para acuñar una clave válida está dentro de tu aplicación, y un decompilador convierte tu código de validación en un generador de claves.

La unidad correcta es una licencia firmada: una pequeña carga de hechos — titular, producto, nivel, puestos, vencimiento, derechos — con una firma criptográfica sobre ella. Tu servidor firma la carga con una clave privada RSA que nunca sale del servidor; tu aplicación incrusta solo la clave pública correspondiente. Una clave pública puede verificar una firma pero nunca puede crear una, así que:

• Decompilar tu aplicación revela solo la clave pública, que es inútil para la falsificación.
• Cambiar un byte de la carga (subir tier de free a pro) rompe la firma, así que la validación falla.

Esta es la misma asimetría que hay detrás de TLS y la firma de código, apuntada al licenciamiento. En .NET las primitivas vienen en la caja, que es exactamente la trampa — la comprobación de firma son unas pocas líneas, así que la gente asume que todo el sistema es fácil, y no lo es (el trabajo real vive del Paso 5 en adelante).

Paso 3 — Entrega la licencia a tu cliente

Una vez que puedes firmar una licencia, necesitas hacérsela llegar al comprador sin un correo manual por cada venta. En la práctica hay tres vías de entrega, y un producto real usa más de una:

1. En la compra, automáticamente. Conecta el evento de “pagado” de tu pasarela de pago o de tu proveedor Merchant-of-Record a tu backend de licenciamiento para que un pago exitoso acuñe y envíe por correo la clave, y un reembolso o cancelación la revoque — sin humanos en el bucle.
2. Desde una consola de administración, para ventas manuales, revendedores y claves emitidas por soporte.
3. Autoservicio, donde el cliente inicia una prueba desde tu propio sitio y recibe una clave al instante (Paso 8).

La clave que entregas es la cadena que el cliente luego pega en tu aplicación para activar. Todo lo demás — los derechos, el vencimiento, el número de puestos — viaja dentro de la carga firmada, no en la clave visible.

Paso 4 — Verifica la licencia en tu aplicación

La verificación tiene dos mitades, y casi siempre quieres ambas.

Comprobación de firma sin conexión. Al arrancar, tu aplicación recalcula la comprobación de firma contra su clave pública incrustada y lee los campos ahora de confianza: coincidencia de producto, vencimiento, bloqueo por equipo. Esto no necesita red, así que funciona aislado (air-gapped) y sobrevive a las caídas. La regla cardinal es fallar cerrado — cualquier problema (firma incorrecta, producto equivocado, vencida, revocada, un reloj retrasado para hacer trampa con una prueba, un archivo que falta) debe resolverse al estado sin licencia, nunca lanzar una excepción ni desbloquear. Si una comprobación fallara abierto, el crackeo más fácil sería hacerla fallar a propósito.

Activación en línea. Cuando necesitas aplicar puestos o revocar claves con prontitud, añade un paso en línea: la aplicación intercambia la clave de licencia más un id de máquina estable por un préstamo firmado y de corta duración vinculado a esa máquina. El préstamo se verifica sin conexión y se cachea localmente, así que tras una única activación la aplicación sigue funcionando sin conexión hasta que el préstamo se acerca a su vencimiento — momento en el que reconcilia puestos y revocación con el servidor. Una breve caída queda cubierta por el préstamo cacheado aún válido, una ventana de gracia, para que no dejes fuera a un cliente de pago por una conexión inestable.

Paso 5 — Aplica puestos y bloqueo por equipo

No puedes contar puestos sin conexión — un cliente solitario no tiene ni idea de cuántas otras máquinas ejecutan la misma clave. En cuanto prometes “3 puestos”, necesitas un servidor que registre las activaciones, aplique el tope de forma atómica, haga idempotente la reactivación de una máquina ya vinculada, y permita a un cliente liberar un puesto cuando retira un dispositivo. Combina eso con el bloqueo por equipo: vincula cada puesto a una huella de máquina derivada de atributos estables de hardware y sistema operativo — con tolerancia, para que una tarjeta de red cambiada o un disco actualizado no deje fuera a un usuario honesto y genere un ticket de soporte.

Paso 6 — Controla funciones con derechos y niveles

Distribuye un binario y desbloquea distintas capacidades por plan poniendo las capacidades en la licencia. Define un nivel (p. ej. pro, enterprise) cuya plantilla de derechos lleve banderas con nombre ("export": "true") y límites numéricos ("max-projects": "10"), y controla las funciones según esos derechos en lugar de una comprobación de nivel codificada a fuego — IsEnabled("export"), GetLimit("max-projects", fallback: 1). Entonces cambiar lo que incluye un plan es una edición en el panel, no una nueva versión. Cada lectura de derechos debería fallar cerrada también: una bandera que falta se lee como apagada, un límite que falta devuelve tu valor por defecto.

Paso 7 — Gestiona pruebas, renovaciones y revocación

Estas tres son lo que convierte una comprobación de licencia en un negocio:

• Las pruebas son claves con límite de tiempo que desbloquean la experiencia de pago y vencen automáticamente. Hazlas de una por correo electrónico y por producto, e idempotentes para que un refresco nunca reinicie el contador, y permite que una prueba se convierta en una licencia de pago sin reinstalar.
• Las renovaciones extienden el vencimiento de una suscripción existente (y pueden ajustar los puestos) sin emitir una nueva clave — el cliente conserva la misma licencia.
• La revocación mata una clave reembolsada, con contracargo o filtrada. En línea, surte efecto en el siguiente refresco del préstamo; sin conexión, distribuyes una lista de revocación firmada que tu aplicación respeta sin llamada de red.

Constrúyelo, o cómpralo

La comprobación de firma es una tarde de trabajo. Todo lo que va del Paso 3 en adelante — gestión y rotación de claves, recuento de puestos en el servidor, revocación que llega a clientes sin conexión, pruebas con controles contra el abuso, un portal de cliente para que los movimientos de puestos y las redescargas no se conviertan en tickets de soporte — es un backend con estado y sensible a la seguridad que ningún cliente te agradecerá jamás. Esa es la verdadera pregunta de construir frente a comprar, y desglosamos el coste detallado en construir frente a comprar: licenciamiento de software para .NET.

Dónde encaja Keyright

Keyright es la infraestructura de licenciamiento que construimos en Delta1 Labs, y te entrega toda esta guía como servicio. Emite archivos de licencia sin conexión firmados y préstamos de activación en línea de corta duración desde un solo sistema; aplica bloqueo por equipo y puestos en el servidor con liberación de puestos en autoservicio; lleva derechos y niveles para que un binario desbloquee por plan; admite licencias perpetuas y por plazo, pruebas en autoservicio, renovaciones, transferencias, y revocación de un clic que llega tanto a clientes en línea como sin conexión. Cada inquilino obtiene su propia clave de firma RSA aislada — la mitad privada almacenada cifrada en el servidor y nunca expuesta — más un portal de cliente alojado y SDKs para .NET, Node, Python y Java que todos fallan cerrado por diseño.

Para montarlo de principio a fin, empieza con la guía de primeros pasos de Keyright; el plan gratuito cubre licenciamiento real antes de pagar un céntimo, y puedes ver los planes aquí.