Skip to content
Tenvo AI · EN VIVO · v0.16.16 · TLS · Certificados por dispositivo · AGPL-3.0 · PLAN GRATUITO · 30 DISPOSITIVOS · INFRA AUTOHOSPEDABLE · BYO API KEY · MCP PARA CLAUDE & CURSOR
Volver al blogOpinion

modelo de negocio open source: por qué AGPL funciona para SaaS

Tenvo Editorial Team8 min de lectura
modelo de negocio open source: por qué AGPL funciona para SaaS

Mantienes un proyecto open source de acceso remoto y temes que proveedores en la nube lo copien, lo ofrezcan como servicio hospedado y no contribuyan de vuelta. Ese escenario —la llamada laguna de SaaS— es la razón por la que algunos equipos eligen AGPL.

Mantienes un proyecto open source útil de acceso remoto y te preocupa que proveedores en la nube lo copien, lo ofrezcan como servicio hospedado y no contribuyan de vuelta. Ese escenario —la llamada laguna de SaaS— es la razón por la que algunos equipos eligen AGPL. Este artículo explica qué hace realmente la AGPL para un operador SaaS, cómo condiciona las opciones de monetización y los compromisos operativos reales, incluyendo el hospedaje de relays y despliegues gestionados vs autoalojados.

Qué cambia la AGPL (Affero GPL v3), en términos sencillos

AGPLv3 es GPLv3 más una cláusula de uso en red (a menudo llamada Sección 13) que te obliga a ofrecer el código fuente a cualquiera que interactúe con el programa a través de una red. En la práctica eso significa: si ejecutas el lado servidor de una app AGPL y los usuarios interactúan con ella vía web o API, debes poner tus cambios a disposición de esos usuarios. Cierra la clásica 'laguna de SaaS' de GPL donde una compañía modifica código, lo ejecuta como servicio hospedado y nunca publica los cambios.

Ese efecto legal es estrecho y concreto. No impide mágicamente que la gente hospede tu software, pero crea una obligación legal de compartir cambios y da a los licenciantes palanca cuando un tercero reempaqueta tu código como un producto hospedado propietario.

Cómo la AGPL respalda modelos de negocio SaaS

Hay tres patrones prácticos de negocio donde AGPL tiene sentido para un producto respaldado por SaaS:

  • Licencia dual: Ofrecer el código bajo AGPL para la comunidad y vender licencias comerciales (propietarias) a clientes que necesiten integrar o extender el código sin las obligaciones de la AGPL. Este es el modelo clásico de negocio open source para proveedores de bases de datos y middleware.
  • Complementos hospedados e infraestructura gestionada: Mantener el protocolo/código central abierto bajo AGPL y vender servicios hospedados que son operativamente difíciles de replicar barato — relays multirregión, analítica, backups u orquestación. Los clientes pagan por la conveniencia, los SLA y la reducción de carga operativa.
  • Soporte, SLA y características empresariales: El código AGPL permanece abierto, pero monetizas mediante soporte pago, capacitación, integraciones a medida o plugins empresariales propietarios servidos desde un límite de servicio separado.

Para software de escritorio remoto específicamente, el relay hospedado es un producto natural: los relays manejan ancho de banda y requieren presencia global para baja latencia. Vender un relay gestionado tiene sentido comercial mientras el cliente y el código del servidor permanezcan AGPL.

Licencia dual: mecánica y realidades

La licencia dual es sencilla en concepto: publicas el proyecto bajo AGPL y además ofreces una licencia comercial a clientes que no quieran las obligaciones de la AGPL. Los dos puntos clave de implementación son el control de contribuciones y la claridad legal.

Control de contribuciones: para vender licencias comerciales necesitas una cesión limpia o un Contributor License Agreement (CLA) que te permita relicenciar código de contribuyentes. Sin eso, no puedes legalmente vender una licencia propietaria que incluya contribuciones de terceros.

Precios comerciales: espera que las primeras licencias comerciales se negocien más que listarse. Muchos proyectos comienzan con un producto hospedado modesto (por ejemplo, un servicio de relay) con precios transparentes — la oferta de relay gestionado de Tenvo es un ejemplo de empaquetar la pieza operativa manteniendo el código de protocolo abierto — y reservan precios negociados para integraciones profundas o instalaciones on‑prem.

Por qué un relay gestionado suele ser la recomendación por defecto

La complejidad operativa es el costo silencioso del autoalojamiento. Un clúster de relays necesita gestión de certificados TLS, monitorización, protección DDoS, conmutación por error multirregión, facturación de egress y ingenieros on‑call. Para la mayoría de clientes comerciales, comprar un relay gestionado reduce tiempo al valor y da costos predecibles.

El relay gestionado de Tenvo se ofrece multirregión por defecto y está incluido en nuestros planes comerciales: Free $0, Lite $2.99/mo y Pro $7.99/mo. Para equipos que buscan simplicidad y SLA, un relay gestionado suele costar menos que contratar a una persona de operaciones completa si se consideran parches, respuesta a incidentes y ciclo de vida de certificados.

Autoalojamiento: cuándo es la opción adecuada

El autoalojamiento es absolutamente la elección correcta cuando un requisito escrito lo obliga: regulaciones que prohiben infraestructura de terceros, una red aislada sin salida a internet, o restricciones estrictas de residencia de datos que tu relay gestionado no pueda cumplir. En esos casos la AGPL sigue funcionando —y puede incluso ser preferible— pero debes aceptar los costos operativos: aprovisionamiento, alta disponibilidad, respuesta a incidentes, custodia de claves y renovación de certificados TLS.

Si estás sopesando el autoalojamiento, lee los compromisos prácticos en nuestra Guía honesta 2026 sobre escritorio remoto autoalojado — recorre DNS, automatización de certificados y la monitorización básica que no puedes omitir.

Seguridad y cifrado: lo que la licencia no cambia

La licencia no cambia la seguridad del transporte. A nivel arquitectónico, una conexión peer‑to‑peer directa es end‑to‑end entre los dos dispositivos. Si una sesión cae a un relay, TLS debe terminar en ese relay, por lo que el operador del relay está en posición de observar el tráfico de la sesión. Eso es un hecho operativo que debes considerar al vender infraestructura hospedada o cuando los clientes preguntan sobre exposición de datos.

Sé explícito sobre esto en la documentación de producto: describe cuándo son posibles las conexiones directas, qué implica la caída a relay y qué puede y no puede acceder el operador del relay. Para un tratamiento más profundo de amenazas en escritorios remotos, consulta Seguridad de escritorio remoto: lo que necesita saber.

Arquitectura práctica: mantener las partes monetizables separadas

Cuando eliges AGPL, estructura el proyecto para separar los componentes que pretendes monetizar del núcleo licenciado bajo AGPL. Patrones típicos de separación:

  • Core abierto: Cliente y protocolo centrales bajo AGPL; componentes opcionales de servidor propietarios (por ejemplo, una API de orquestación avanzada) entregados bajo licencia comercial o SaaS.
  • Límite de servicio: Coloca el relay hospedado y los servicios operativos en un servicio separado que interactúe con el core abierto mediante APIs documentadas. El relay puede ser propietario o cobrarse como servicio mientras el core permanece AGPL.
  • Plugins vs núcleo: Mantén el runtime, el protocolo y el transporte de bajo nivel en AGPL; expón puntos de extensión donde plugins empresariales (licenciados comercialmente) puedan ejecutarse en un entorno controlado.

La separación arquitectónica reduce la ambigüedad legal y facilita explicar a los clientes qué partes son abiertas y cuáles son servicios comerciales.

Compensaciones para desarrolladores y la comunidad

AGPL atrae a contribuyentes que quieren copyleft fuerte y mejoras comunitarias, pero puede disuadir a corporaciones que rechazan obligaciones de uso en red. Espera menos pull requests entrantes desde empresas que construyen SaaS propietarios —pero las contribuciones comunitarias de desarrolladores individuales e instituciones a menudo son mayores porque ven que el código permanecerá abierto.

Para mantener las contribuciones saludables, ten documentación clara de contribución, un CLA si planeas licenciar dualmente y gobernanza transparente. Muchos proyectos adoptan una política de Gobernanza transparente, cadencia de lanzamientos regular (p. ej., estable mensual + versiones nocturnas) y procesos claros de divulgación de seguridad para reducir fricción a usuarios empresariales.

Aplicación y reputación — la palanca blanda

Las licencias solo son útiles en la medida en que puedas aplicarlas. La aplicación puede ser legal, pero a menudo es reputacional: llamados públicos, acercamientos educados y presión de la comunidad importan. Cambios de alto perfil en el ecosistema open source (por ejemplo, proveedores de bases de datos que migraron a SSPL o a licencias source‑available) muestran que las elecciones de licencia condicionan el comportamiento —pero la aplicación requiere recursos y disposición a litigar o a acciones adyacentes al litigio.

Si la aplicación es central para tu modelo, prepárate: conserva historiales de contribuciones, rastrea desplegadores (en la medida legalmente posible) y presupuestá soporte legal. Para muchos proyectos, el valor práctico de AGPL es la disuasión y una vía clara para la negociación más que peleas judiciales frecuentes.

Precio y ejemplos de costo: contabilidad realista

Los números reales varían, pero considera estos ejemplos orientativos al elegir entre modelos de relay gestionado y autoalojado:

  • Equipo pequeño usando una sola región de relay con poco ancho de banda: un relay gestionado a <$100/month suele ser más barato que contratar tiempo de ops para ejecutarlo y asegurararlo.
  • Servicio en producción que requiere HA multirregión y on‑call 24/7: replicación, protección DDoS y egress pueden empujar los costos de autoalojamiento a cientos o a bajas miles de dólares al mes. Un relay gestionado con SLA puede ser más rentable cuando incluyes personal.

Estos son rangos aproximados — capacidad, volúmenes de egress y requisitos de cumplimiento cambian la ecuación rápidamente — pero el punto es que el costo operativo de un relay global fiable no es trivial, por eso empaquetarlo como servicio de pago es racional económicamente.

Lista de verificación: lanzar un SaaS basado en AGPL responsablemente

  • Elige la versión de licencia explícitamente (AGPLv3 recomendado para la mayoría de equipos) y documenta qué cubre.
  • Usa un CLA o cesión de contribuciones si planeas vender licencias comerciales.
  • Separa la infraestructura monetizable (relays, orquestación, analítica) detrás de un límite de servicio claro.
  • Documenta cuándo las sesiones pasan por relays y las implicaciones de seguridad (terminación TLS en el relay).
  • Publica documentación clara de actualización, instalación y hardening para bajar la fricción de los autoalojadores.
  • Decide la postura de aplicación y presupuestá recursos legales o una política de mediación.
  • Precio de los servicios hospedados con niveles transparentes; el modelo Free $0 / Lite $2.99/mo / Pro $7.99/mo de Tenvo es un ejemplo de un embudo de entrada simple que escala hacia planes empresariales con SLA.

Cuándo elegir otra cosa

AGPL no es la elección adecuada si tu objetivo es máxima adopción por parte de proveedores SaaS de terceros o si quieres reuso permisivo en sistemas cerrados sin negociación. Para librerías que se van a incrustar en productos propietarios, las licencias permisivas (MIT/BSD/Apache 2.0) suelen ser mejores.

También considera enfoques híbridos: una librería cliente permisiva con un servidor AGPL, o un core permisivo con un servidor de referencia AGPL. Cada elección envía una señal clara sobre los tipos de reutilización que quieres incentivar o prevenir.

Lecturas y comparaciones adicionales

Si quieres comparar los compromisos específicamente para proyectos de escritorio remoto, nuestra comparación fork‑and‑host es una lectura útil: RustDesk vs Tenvo: comparación de forks para autoalojadores. Y si estás decidiendo el coste/beneficio del autoalojamiento, revisa los pasos operativos en Guía honesta 2026 sobre escritorio remoto autoalojado.

La licencia es una palanca entre muchas. Elige AGPL cuando necesites la seguridad legal de que los usuarios en red puedan acceder al código y cuando planees monetizar servicios operativos, pero sé explícito con los clientes sobre lo que AGPL sí y no resuelve: aborda contribuciones de código y divulgación, no la seguridad del transporte ni errores de configuración.

¿Listo para probar una pila de acceso remoto con respaldo AGPL y opción de relay gestionado? Descarga el cliente y experimenta, o consulta detalles de precios y planes gestionados en nuestra página de precios. Cuando quieras poner manos a la obra, descargar y prueba una configuración con relay en minutos.

Obtén Tenvo

¿Listo para probarlo?

Gratis para 30 dispositivos, sin tarjeta de crédito. En funcionamiento y conectado en dos minutos.