Construir o comprar: licenciamiento de software para .NET (2026)

Constrúyelo tú mismo solo si tus necesidades de licenciamiento son genuinamente triviales y seguirán siéndolo; cómpralo en el momento en que necesites puestos, revocación, pruebas o un portal de cliente, porque en ese punto no estás añadiendo una función, estás construyendo y operando un producto de backend que no tiene nada que ver con lo que tus clientes realmente te pagan. Esta guía recorre el coste real y detallado de crear tu propio licenciamiento de .NET para que puedas tomar esa decisión con los ojos abiertos, y es honesta sobre los casos en los que el “hazlo tú mismo” es la respuesta correcta.

La parte que todos subestiman

La mayoría de los desarrolladores imaginan el licenciamiento como “genera una clave, comprueba la clave”. Esa parte sí es genuinamente fácil. .NET incluye System.Security.Cryptography.RSA de serie; puedes firmar un blob de JSON en un servidor y verificarlo en tu cliente en una tarde. Si ese fuera todo el trabajo, nadie vendería licenciamiento.

El trabajo es todo lo que envuelve esa firma. Abajo está la lista de verificación que separa una demo de algo que realmente puedes enviar a clientes de pago, y cada línea es una decisión de la que eres dueño para siempre una vez que la construyes.

Claves de firma y gestión de claves

Necesitas un par de claves asimétrico: una clave privada que firma licencias en el servidor y una clave pública que tu aplicación embebe para verificarlas. Bien. Ahora responde a las preguntas operativas. ¿Dónde vive la clave privada? ¿Cómo se cifra en reposo? ¿Quién puede acceder a ella? ¿Qué pasa cuando se filtra? ¿Puedes rotarla sin inutilizar cada copia ya enviada de tu aplicación? Si vendes a varios segmentos de clientes o revendes a través de socios, ¿comparten una sola clave (un único punto de fallo catastrófico) u obtienen claves aisladas que ahora tienes que gestionar a escala?

Una respuesta seria tiene el aspecto de un aislamiento de claves por cliente con la clave privada cifrada en reposo y una ruta de rotación documentada en la que una clave antigua y una nueva validan ambas durante la transición. Eso no es un concepto difícil, pero es código real, sensible a la seguridad, que ahora mantienes.

Un formato de archivo de licencia del que no te arrepientas

Tienes que decidir qué es una licencia sobre el cable: los campos (licenciatario, producto, nivel, puestos, caducidad, derechos), la serialización y cómo se adjunta la firma. Equivócate pronto y estarás manteniendo parches de formato durante años, porque nunca puedes romper un formato que ya está desplegado en las instalaciones de los clientes. Versionar un formato firmado que tanto los clientes antiguos como los nuevos acepten es su propio pequeño proyecto.

Bloqueo por equipo que no castigue a los usuarios honestos

Atar una licencia a una máquina suena simple hasta que construyes la huella. Haz hash de demasiados atributos de hardware y un cliente que cambia una NIC o actualiza un disco queda fuera y abre un ticket de soporte. Haz hash de muy pocos y el bloqueo se evita trivialmente. Necesitas una huella estable con tolerancia —suficiente deriva permitida para que los cambios de hardware ordinarios no la disparen— y una forma documentada de anular qué componentes identifican una máquina para entornos inusuales como VMs y CI.

El conteo de puestos, que te obliga a tener un servidor

Aquí está el muro contra el que el “hazlo tú mismo” choca más fuerte. No puedes contar puestos sin conexión. Una comprobación puramente del lado del cliente no tiene idea de cuántas otras máquinas están ejecutando la misma clave. En el momento en que prometes “3 puestos”, necesitas un servidor que registre activaciones, haga cumplir el tope de forma atómica (sin una carrera que deje a diez máquinas tomar tres puestos), haga idempotente la reactivación de una máquina ya vinculada y deje a un cliente liberar un puesto cuando retira un dispositivo. Eso es un servicio con estado, concurrente y siempre activo: justo lo que “simplemente comprueba una clave” se suponía que iba a evitar.

Validación sin conexión y comportamiento de fallo hacia el estado bloqueado

Mucho software debe ejecutarse aislado (air-gapped) o a través de cortes de red, así que también necesitas validación sin conexión: verificar la firma, la coincidencia de producto, el bloqueo por equipo y la caducidad sin ninguna llamada de red. Y necesitas que falle hacia el estado bloqueado: cualquier problema de verificación (firma incorrecta, producto equivocado, caducidad, un reloj retrasado para hacer trampa con una prueba) debe resolverse al estado sin licencia en lugar de lanzar una excepción no manejada o, peor, fallar hacia el estado abierto y desbloquearlo todo. Conseguir la semántica de fallo hacia bloqueado correcta en todas partes es delicado, y es la diferencia entre una comprobación de licencia y una sugerencia.

Revocación que alcance a los clientes sin conexión

Una clave reembolsada, con contracargo o filtrada tiene que morir. En línea, eso es un flag de servidor comprobado en el siguiente refresco de activación. Sin conexión, es más difícil: necesitas una lista de revocación firmada que puedas enviar con una actualización para que incluso un cliente desconectado la respete. Construye ambas rutas, o tu único remedio para una clave filtrada es una nueva versión.

Pruebas, sin regalar gratis para siempre

Las pruebas de autoservicio significan acuñar claves con límite de tiempo bajo demanda, y lidiar de inmediato con el abuso. Una prueba por correo electrónico por producto, idempotente para que un refresco no resetee el reloj, que caduca sola, revocable e idealmente que se convierta a una licencia de pago sin reinstalar. Cada una de esas es una regla que tienes que diseñar y hacer cumplir.

Un portal de cliente, o una cola de soporte

Finalmente, la parte que nunca entra en la estimación: los clientes querrán ver sus claves, mover un puesto entre máquinas y re-descargar un archivo de licencia sin enviarte un correo. Sáltate el portal y cada una de esas se convierte en un ticket de soporte manual. Construye el portal y tienes una pequeña aplicación web autenticada que mantener encima de todo lo anterior.

Entonces, ¿cuándo es construirlo tú mismo la decisión correcta?

El “hazlo tú mismo” está genuinamente bien cuando se cumple todo esto: vendes una sola licencia perpetua sin límite de puestos, nunca necesitas revocar una clave sobre el terreno, no ofreces pruebas ni un portal de cliente, y te sientes cómodo siendo dueño de código criptográfico sensible a la seguridad indefinidamente. Un archivo de licencia firmado verificado sin conexión contra una clave pública embebida es una compilación razonable de fin de semana bajo esas restricciones, y no deberías pagar una suscripción para evitarlo.

El cálculo cambia en el instante en que cualquiera de esas suposiciones se rompe, y para la mayoría del software comercial, al menos una se rompe en el primer año. Las suscripciones necesitan caducidad y renovación. Los equipos necesitan puestos. El crecimiento necesita pruebas. La carga de soporte fuerza un portal. Una vez que estás construyendo tres o cuatro de esas casillas, estás operando un backend de licenciamiento, y el mantenimiento nunca termina.

La opción de comprar: qué te da un servicio de licenciamiento

Keyright es el servicio de licenciamiento que construimos en Delta1 Labs, y existe precisamente para entregarte toda esa lista de verificación como infraestructura. Emite archivos de licencia offline firmados criptográficamente y leases de activación en línea de vida corta, así que obtienes validación aislada (air-gapped) y puestos impuestos por el servidor desde el mismo sistema. Cada tenant obtiene su propia clave de firma RSA aislada, con la mitad privada almacenada cifrada con AES-256-GCM en el servidor y nunca expuesta. El bloqueo por equipo usa una huella con tolerancia integrada. La revocación es un clic y alcanza tanto a los clientes en línea (siguiente refresco) como a los sin conexión (una lista de revocación firmada que tú envías). Los derechos te dejan limitar funciones por nivel para que un binario desbloquee capacidades distintas por plan. Las pruebas son de autoservicio y resistentes al abuso. Y hay un portal de cliente alojado para que los movimientos de puestos y las re-descargas nunca lleguen a tu bandeja de entrada.

El SDK de .NET hace la mitad del cliente con honestidad: Validate() verifica todo sin conexión y nunca lanza una excepción, ActivateAsync() gestiona los puestos en línea con una ventana de gracia sin conexión, y todo el conjunto falla hacia el estado bloqueado a la edición gratuita por diseño. Apunta a múltiples destinos desde .NET Framework 4.8 hasta el .NET actual, con SDK hermanos para Node, Python y Java que comparten un tenant y una clave pública.

Keyright es hoy un SaaS totalmente alojado, con una opción de autoalojamiento en la hoja de ruta para equipos que necesitan el servicio de emisión dentro de su propia infraestructura. Hay un plan genuinamente gratuito —hasta 50 licencias activas en un producto, sin tarjeta— para que puedas enviar licenciamiento real antes de pagar nada.

La conclusión

La decisión de construir o comprar no trata de si puedes escribir una verificación RSA; por supuesto que puedes. Trata de si quieres ser dueño de un backend con estado y sensible a la seguridad (gestión de claves, conteo de puestos, revocación, pruebas, un portal) que ningún cliente te agradecerá jamás. Si tus necesidades son triviales y fijas, construye la versión de fin de semana y pasa página. Cualquier cosa más, y un servicio se amortiza la primera vez que esquivas un incidente de rotación de claves o una cola de soporte llena de solicitudes de movimiento de puestos.

Si quieres probar la vía de comprar, empieza con la guía de primeros pasos de Keyright o consulta los planes: el nivel gratuito basta para cablear licenciamiento real de principio a fin antes de decidir.