Licencias para estrategias como binario compilado: el espacio de diseño

Estado a 2026-09-30: esto es una exploración de diseño. El marketplace, el servidor de licencias y las herramientas para vendedores que describe están previstos pero no construidos, y no hay fecha de lanzamiento. El motor y el transpilador sobre los que se apoyaría existen hoy.

Los creadores de estrategias quieren monetizarlas sin regalar el código fuente. Los compradores quieren hacer backtests con sus propios datos y operar con su propio broker. Esas dos exigencias chocan de verdad, y la mayoría de las soluciones actuales resuelven mal el conflicto. Este artículo describe el espacio de diseño que exploramos antes de decidirnos por las licencias sobre binario compilado como base del marketplace de PineForge.

El problema en términos sencillos

Un creador ha construido algo que funciona. Ha pasado meses afinando parámetros, corrigiendo casos límite y validando fuera de muestra. Quiere venderlo. El comprador quiere ejecutarlo con sus propios datos, comprobar que el backtest sale como afirma el creador e integrarlo en su propio pipeline de ejecución.

En el momento en que el creador entrega el código fuente, la monetización se acaba. El comprador puede ejecutarlo indefinidamente, modificarlo con libertad y revenderlo a otros. El creador ha cobrado exactamente una venta. Cada comprador posterior es un cliente potencial perdido.

En el momento en que el creador retiene el código fuente, el comprador pierde la capacidad de verificar la estrategia, ajustarla o confiar en ella. Se suscribe a una caja negra. Si el servidor del creador se cae, su trading se detiene.

Dos soluciones habituales intentan resolver esto. Ambas tienen modos de fallo bien documentados.

Patrón 1: vender el código fuente

El creador vende el script Pine directamente. Una compra única entrega al comprador el archivo .pine.

La ventaja para el comprador es real: acceso total, verificabilidad total, control total. Puede hacer backtests con cualquier dato, ajustar parámetros y ejecutarla con independencia del vendedor para siempre.

La desventaja para el vendedor también es real. Una vez transferido el código, el vendedor no conserva ninguna palanca. La protección contra la piratería es tan fuerte como la buena fe del comprador. La estrategia puede volver a publicarse en otras plataformas, modificarse y venderse como derivada, o simplemente compartirse gratis. Los ingresos quedan limitados al número de compradores honestos que compran por primera vez.

Este modelo sirve a los creadores que prefieren la simplicidad a los ingresos recurrentes. No sirve a los creadores cuyas estrategias son lo bastante valiosas como para querer protegerlas durante varios años.

Patrón 2: vender señales

El creador ejecuta la estrategia por su cuenta y publica señales (entrada, salida y tamaño de posición) en un feed que consumen los suscriptores. El código fuente nunca sale del control del creador.

La ventaja para el vendedor: protección total del código fuente, ingresos recurrentes por suscripción y ninguna transacción única que transfiera todo el valor.

La desventaja para el comprador es seria. No puede hacer backtests de la estrategia con sus propios datos. Tiene que fiarse del rendimiento histórico que declara el creador. Depende por completo de la infraestructura del creador: si el creador se va de vacaciones, sufre una caída del servidor o decide cerrar, el comprador se queda sin nada. Tampoco puede ajustar parámetros; recibe lo que el creador configuró.

Los servicios de señales funcionan para compradores sin capacidad técnica para ejecutar estrategias por su cuenta. Para compradores técnicos que quieren entender lo que ejecutan y verificarlo de forma independiente, el modelo no es una opción.

Patrón 3: vender el binario compilado

El tercer patrón es aquel en torno al cual está diseñado el marketplace previsto de PineForge. La estrategia Pine se compila a una biblioteca compartida (.so en Linux, .dylib en macOS). El creador distribuye el binario, no el código fuente. El comprador ejecuta el binario con sus propios datos OHLCV en su propia máquina, a través del runtime de código abierto de PineForge.

Esto resuelve los dos lados de la tensión:

Para el creador: el código fuente nunca sale de su máquina. El binario se compila a partir de su script Pine, pero revertir un .so compilado a Pine legible exige un esfuerzo considerable, y aun así el resultado es código a nivel de ensamblador, no Pine idiomático. La lógica central de la estrategia queda protegida en la práctica.

Para el comprador: el backtest se ejecuta en local, con sus propios datos. La ejecución usa su propia integración con el broker. El runtime de código abierto es auditable: un comprador preocupado por la seguridad puede leer el código que mueve su dinero, aunque no pueda leer la estrategia en sí. El backtest en sí no depende del servidor del vendedor.

El patrón no es una novedad de PineForge. El ecosistema MetaTrader funciona así desde que MetaQuotes abrió MQL5 Market en 2011. Las estrategias de MetaTrader se compilan a binarios .ex4 o .ex5; el Market vincula cada compra a la máquina del comprador, con un número de activaciones que fija el vendedor, y los vendedores también pueden ofrecer sus productos en alquiler. Los compradores hacen los backtests en local, en el probador de estrategias de MetaTrader; el código fuente se queda con el desarrollador. Es un modelo probado.

Aplicamos la misma receta a Pine, con dos añadidos: más granularidad en los controles de la licencia (más abajo) y un runtime de código abierto para que cualquiera pueda auditar la parte que ejecuta sus operaciones.

Las dimensiones de la licencia

Un binario compilado sin un marco de licencias es solo un archivo que cualquiera puede copiar. La capa de licencias es lo que hace viable el modelo de negocio.

El diseño contempla seis dimensiones de licencia:

Limitada en el tiempo. La licencia tiene fecha de caducidad: días, semanas o meses desde la compra. Cuando caduca, el binario deja de ejecutar estrategias. El comprador puede renovarla. El vendedor obtiene ingresos recurrentes. Es la dimensión más habitual; casi todas las estrategias del marketplace la usarán.

Vinculada a la máquina. La licencia está ligada a una huella de hardware. El comprador puede ejecutar la estrategia en la máquina que registró, pero no en una segunda máquina ni en una instancia en la nube. Esto limita el valor de compartir el binario: la máquina de quien lo recibe no tendrá una licencia válida. Los vendedores más preocupados por la piratería a gran escala que por el intercambio ocasional pueden activarla.

Vinculada al broker. La licencia especifica contra qué integraciones de broker se permite ejecutar la estrategia. Un vendedor que se ha asociado con APIs de brokers concretos puede limitar la ejecución a esas integraciones, lo que impide usar la estrategia en un destino de ejecución no soportado o no deseado.

Vinculada al símbolo. La licencia restringe los tickers con los que puede operar la estrategia. Un creador que construyó y validó su estrategia en BTC/USDT puede distribuir una licencia que solo permita ese símbolo. Así se evita que un comprador use una estrategia optimizada para un activo en otro completamente distinto, obtenga resultados inesperados y culpe al creador.

Limitada por rango de parámetros. El comprador puede ajustar los parámetros de la estrategia, pero solo dentro de los rangos que permite el vendedor. Una estrategia con un parámetro de ventana de lookback podría permitir valores entre 10 y 50 barras, pero no por debajo de 10 (donde el creador sabe que se sobreajustaba mucho) ni por encima de 50 (donde pierde sentido). El vendedor publica los rangos; el runtime los hace cumplir.

Revocable. El servidor de licencias puede responder con un 403 en la siguiente comprobación periódica de la licencia, y a partir de ese momento el binario deja de ejecutarse. Si se descubre que un comprador incumple las condiciones (comparte el binario o lo ejecuta en hardware no autorizado), el creador puede revocar la licencia sin emitir un reembolso ni pasar por un proceso legal. La revocación es la opción nuclear; los vendedores solo deberían usarla ante incumplimientos claros.

Lo que no hacemos, a propósito

Nada de teatro de ofuscación tipo DRM. El .so es un binario compilado de verdad. Con tiempo suficiente y las herramientas adecuadas, un ingeniero hábil puede hacer ingeniería inversa de su lógica. No decimos lo contrario. La licencia es el contrato, no el formato del binario. La protección viene de las condiciones que aceptó el comprador y de la aplicación de la licencia en el runtime, no de que sea imposible desensamblarlo. Fingir que el binario es irrompible sería deshonesto.

Nada de llamar a casa en cada backtest. La comprobación de la licencia es periódica, no por llamada. El runtime guarda en caché local una licencia válida y consulta el servidor de licencias según una planificación (configurable por licencia; por defecto, diaria). Los backtests funcionan sin conexión mientras la licencia está vigente. No llamamos a casa en cada cálculo de barra. Eso haría que los backtests dependieran de la disponibilidad de la red y añadiría latencia sin ningún beneficio real de seguridad: un atacante que puede interceptar una comprobación de licencia puede interceptar cien.

Nada de repartos de ingresos sorpresa. La comisión del marketplace es un porcentaje fijo que se publica antes del lanzamiento. Los vendedores que se apuntan a la lista de espera conocen las condiciones antes de publicar. Hemos visto marketplaces que revelan su estructura de comisiones solo cuando el producto ya está publicado; nos parece mala fe y no lo haremos.

Preguntas abiertas en las que seguimos trabajando

Clave de licencia comprometida. Si la máquina de un comprador queda comprometida y alguien extrae su clave de licencia, ¿qué ocurre? Las opciones son: (a) revocar y volver a emitir la licencia al comprador legítimo, con la consiguiente interrupción; (b) mantener un esquema de rotación de claves por comprador en el que cada instancia de máquina tenga una clave derivada distinta, de modo que comprometer una máquina no comprometa a todos los compradores. Nos inclinamos por (b), pero la implementación exige una gestión de claves nada trivial.

Valores por defecto definidos por el vendedor junto a los rangos. La dimensión de rango de parámetros permite a los vendedores publicar los límites de cada parámetro. ¿Deberían poder publicar también valores por defecto, es decir, el valor inicial que ve el comprador cuando configura la estrategia por primera vez? Probablemente sí: un vendedor que sabe que su estrategia funciona mejor con un lookback de 20 barras no debería obligar a los compradores a descubrirlo a base de prueba y error. Los valores por defecto serían orientativos, no obligatorios.

Informes de «backtest de demostración» publicados por el vendedor. Antes de comprar, los compradores deberían poder ver pruebas de que la estrategia funciona, no solo las afirmaciones del vendedor. Nuestro plan actual es permitir que los vendedores publiquen un informe de backtest con el formato de la galería (el mismo esquema que la galería en /gallery) usando sus propios datos y su propia ventana de OHLCV. Se verificaría que el informe lo produjo el motor de PineForge con los parámetros de entrada declarados. Los compradores ven listas de operaciones reales, ratios de Sharpe reales y sparklines reales, no una captura de marketing. Es la versión honesta de «míralo antes de comprarlo».

La alineación open-core

Una preocupación con los marketplaces de binarios compilados es que la seguridad del dinero del comprador depende por completo del ejecutor del binario, que en la mayoría de las implementaciones es una caja negra propietaria. Si ejecutas un archivo .ex5 en MetaTrader, confías en el runtime de MetaQuotes y en su garantía de que no ejecutará comportamientos no declarados.

El motor de PineForge tiene licencia Apache-2.0 y es público (pineforge-engine; la imagen Docker, que incluye el motor junto con el transpilador, es ghcr.io/pineforge-4pass/pineforge-release). El transpilador (la parte que compila Pine a C++) es gratuito para trading personal; el uso comercial requiere una licencia. El ejecutor, el código que realmente ejecuta el binario compilado con tu OHLCV y produce las listas de operaciones, es de código abierto.

Esto significa que un comprador preocupado por la seguridad puede auditar el ejecutor antes de confiarle sus backtests. No puede auditar el código fuente de la estrategia (de eso se trata), pero sí el código que la ejecuta. La división es deliberada: mantener abierta la parte que ejecuta la estrategia y licenciar el transpilador para uso comercial.

Estado del marketplace

No hay fecha. El motor y el transpilador existen hoy; el servidor de licencias, el panel del vendedor y el flujo de compra para compradores, no.

El plan es empezar con una beta con incorporación manual de vendedores: un grupo reducido de creadores verificados, publicaciones revisadas por el equipo y un catálogo limitado para detectar problemas de integración antes de escalar. Después vendría un marketplace de autoservicio, en el que los vendedores publicarían por su cuenta, fijarían sus propias dimensiones de licencia, publicarían informes de backtest de demostración y gestionarían su catálogo sin intervención del equipo.

Por dónde seguir

• Únete a la lista de espera de vendedores: si estás creando estrategias que querrías publicar, apúntate a la lista de espera y te escribiremos cuando se abra la incorporación a la beta.
• Prueba el runtime hoy: backtest_pine en los servidores MCP ejecuta el mismo motor sobre el que se ejecutarían las estrategias del marketplace.
• Cómo medimos la paridad: los resultados actuales del motor frente a TradingView.