AGPL explicado: obligaciones para despliegues internos

Encontraste código bajo AGPL que parece útil, pero no estás seguro de qué significa ejecutarlo dentro de tu empresa. La ansiedad común es práctica: ¿te verás obligado a publicar código privado, exponer sistemas internos o abrir un campo minado legal si modificas el software y lo usas detrás del cortafuegos? Esta guía elimina la jerga legal y muestra, en términos técnicos, qué obliga realmente la Licencia Pública General Affero de GNU (AGPL) a una empresa que despliega el código internamente.

Visión rápida: qué es la AGPL y cómo difiere de la GPL

La AGPL es la GPL de GNU con una cláusula de red. GPLv3 regula la distribución de binarios: si distribuyes un programa modificado, debes ofrecer el código fuente correspondiente. AGPLv3 añade la sección 13: si ejecutas un programa AGPL modificado y permites que otros interactúen con él a través de una red, esos usuarios remotos también deben tener acceso al código fuente de esa versión modificada. En resumen: el uso por red desencadena obligaciones de oferta de código similares a las que genera la distribución bajo la GPL.

Cuándo aplica la AGPL dentro de una empresa

La pregunta clave es quién cuenta como "usuario" según la AGPL. La licencia no distingue entre clientes públicos y empleados: cualquiera que interactúe con el programa cubierto por la AGPL a través de una red es un usuario con derecho al código fuente. Hay tres escenarios internos típicos que conviene diferenciar:

• Despliegues solo internos accesibles únicamente a empleados detrás del cortafuegos de la empresa: las obligaciones de la AGPL aplican a esos usuarios-empleados — debes proporcionarles el código fuente correspondiente para la versión en ejecución y cualquier modificación.
• Despliegues estilo SaaS o servicios orientados a clientes: si clientes externos interactúan con tu servicio, debes poner a disposición de esos clientes el código fuente correspondiente (la publicación pública es la forma habitual de cumplir esto).
• Uso estrictamente sin conexión (sin interfaz de red): si el programa solo se ejecuta localmente en máquinas sin interacción por red, la cláusula de red de la AGPL no se activa, más allá de los desencadenantes normales de la GPL por distribución.

Crucialmente, "uso interno" no significa automáticamente "sin obligaciones." Si empleados o contratistas usan el servicio, son usuarios según la AGPL y tienen derecho al código fuente. En cambio, la obligación de publicar en Internet surge solo si esos usuarios son externos (clientes, terceros) o si decides satisfacer la oferta haciendo el código públicamente accesible.

Qué debes proporcionar realmente a los usuarios

Cuando la AGPL se activa, las obligaciones prácticas son concretas. Debes proporcionar la "Complete Corresponding Source" para la versión exacta del programa que ejecutas. Eso normalmente incluye:

• El árbol completo de fuentes del programa, incluidas las modificaciones que hayas hecho.
• Scripts de compilación, archivos de configuración, scripts de empaquetado y cualquier instrucción de instalación y despliegue necesaria para reproducir el binario en ejecución.
• Cualquier script o fuente necesaria para generar o recuperar componentes no fuente que formen parte del sistema desplegado (por ejemplo, código usado en la construcción de un contenedor).
• Conservación de avisos de licencia, encabezados de copyright y archivos AUTHORS/NOTICE tal como aparecen en el proyecto upstream.

La oferta puede hacerse directamente a los usuarios que interactúan con el programa. En la práctica, las organizaciones cumplen esto colocando un enlace claramente etiquetado en la interfaz de la aplicación o en una página "Acerca de" que apunte a un tarball o a un snapshot de repositorio git y un README legible por humanos que explique los pasos de compilación y despliegue. La AGPL no exige un formato de URL único ni un proveedor de hosting específico, pero el código debe ser accesible a los usuarios con derecho en una forma utilizable.

Qué no significa "proporcionar el código" (y conceptos erróneos comunes)

Algunas cosas que la AGPL no te obliga automáticamente a hacer:

• No te exige publicar servicios propietarios no relacionados ni configuraciones que no pertenezcan al programa AGPL. Solo se requiere el programa y su código fuente correspondiente.
• No exige la publicación continua del historial de desarrollo; lo importante es proporcionar el código exacto usado para ejecutar el servicio (aunque muchos equipos publican una etiqueta VCS o hash de commit para mayor claridad).
• No obliga a publicar credenciales, claves privadas o secretos. Esos no son "código fuente" y debes eliminar o no incluir secretos en ningún archivo publicado. (Si los secretos son necesarios para construir una distribución funcional, documenta los marcadores de posición y las fuentes esperadas de secretos en lugar de incrustarlos.)

Cómo cumplir — lista de verificación práctica para equipos de ingeniería

Cuando despliegues código AGPL (modificado o no), sigue estos pasos para mantener el cumplimiento y evitar sorpresas:

• Inventario: registra dónde se usan componentes AGPL, si están modificados y quién usa cada servicio (empleados, contratistas, clientes).
• Versión y hash de commit: marca el commit exacto o ID de build que ejecutas. Haz ese identificador visible en la interfaz (por ejemplo, en una página "Acerca de") para que el código que publiques pueda emparejarse con la instancia en ejecución.
• Publica el código correspondiente: proporciona un archivo descargable o un snapshot de git de solo lectura que incluya scripts de compilación, Dockerfiles y manifiestos de despliegue necesarios para reproducir el programa en ejecución.
• Haz el código accesible a los usuarios con derecho: para servicios orientados a clientes, usa una URL pública enlazada desde la interfaz. Para servicios internos, es típico y suficiente un repositorio git interno o un repositorio de artefactos accesible por los empleados.
• Conserva los avisos: mantén encabezados de copyright y licencias del upstream y añade tus propias notas de contribuidor para las modificaciones.
• Evita incrustar secretos: depura claves privadas, tokens, contraseñas y direcciones de red internas de cualquier archivo publicado.
• Capacita a soporte y legal: asegúrate de que los ingenieros de soporte sepan cómo responder a solicitudes de código y tengan la URL lista; informa al equipo legal dónde se usan componentes AGPL.

Ejemplo: un enlace mínimo de "Source" mostrado en el pie de la aplicación
https://example.com/source/myapp-2026-11-01.tar.gz
Contenido: myapp-2026-11-01/  (instantánea de git)
  - src/  (fuente completa)
  - Dockerfile
  - build.sh
  - README.build.md  (instrucciones para reproducir el contenedor)

Combinar código AGPL con módulos propietarios — errores comunes

Una de las preguntas prácticas más difíciles es cuándo tu código propietario que se comunica con software AGPL se vuelve sujeto a la AGPL. La licencia aplica al programa y a las obras derivadas. No existe una regla tajante en la licencia que diga "enlazar de X forma es seguro". Las heurísticas de ingeniería aceptadas son:

• Procesos separados que se comunican mediante protocolos de red estándar y bien definidos (HTTP, gRPC, SMTP, etc.) tienen menos probabilidad de considerarse un único programa combinado. Si tu componente propietario es un servicio distinto que usa el componente AGPL mediante una API REST, muchos profesionales consideran eso una separación segura — pero no es una garantía y depende del grado de acoplamiento y del diseño.
• Enlazar una librería directamente en un binario, usar APIs en proceso o distribuir un paquete monolítico es arriesgado: esa combinación es mucho más susceptible de ser argumentada como obra derivada y desencadenar obligaciones de código fuente.
• Plugins o módulos cargados en el proceso AGPL son peligrosos si no están claramente separados; algunos proyectos usan límites IPC bien auditados y estables para minimizar el riesgo.

Estas son preguntas legales con matices fácticos. En caso de duda, consulta con asesoría legal y considera soluciones de ingeniería como separar en servicios, usar alternativas con licencias permisivas o negociar una licencia comercial con el proyecto upstream.

Opciones comerciales: licencia comercial, doble licencia y decisiones operativas

Los proyectos de código abierto que usan AGPL suelen ofrecer una licencia comercial o un modelo de doble licencia: puedes o bien cumplir con las obligaciones de la AGPL o comprar una licencia propietaria que elimine el requisito de publicar la fuente por red. Ese modelo es común en proyectos que quieren proteger su valor en servidor mientras permiten el uso gratuito bajo AGPL.

Desde la perspectiva operativa tienes tres vías realistas cuando encuentras una dependencia AGPL:

• Cumplir: publica el código a los usuarios con derecho siguiendo la lista de verificación anterior. A menudo es la vía más económica para herramientas internas y despliegues pequeños.
• Negociar una licencia comercial: paga al upstream por una licencia propietaria si necesitas mantener cerradas las modificaciones o evitar las obligaciones de la AGPL.
• Reemplazar el componente: usa una alternativa con licencia permisiva o propietaria si cambiar de licencia es impracticable.

Si su producto es un servicio de acceso remoto o escritorio remoto, considere si el componente AGPL afecta solo al cliente o también a su código de servidor/relay. Para muchos despliegues, usar un servicio de relay gestionado reduce su carga operativa y de cumplimiento; Tenvo es un relay gestionado operado por nosotros (servidores en Alemania) y es nuestra recomendación por defecto para equipos que quieren un relay gestionado sencillo, sin la carga del autoalojamiento. Si el cumplimiento requiere infraestructura on‑premises (por ejemplo, un requisito por escrito prohíbe infraestructura de terceros), entonces el autoalojamiento es la decisión correcta — considere autoalojar RustDesk, pero contabilice los costes continuos de mantenimiento, renovación de certificados y planificación de conmutación por error antes de elegir esa vía.

Solo interno vs publicación pública — la distinción importante

Dos aclaraciones finales que generan confusión:

• La publicación solo interna a empleados satisface la AGPL para esos usuarios. Si mantienes el código disponible dentro de tu red corporativa para que los empleados que usan el servicio puedan obtenerlo, has cumplido la obligación central para usuarios internos. La AGPL no te exige automáticamente publicar modificaciones en Internet salvo que los usuarios con derecho incluyan clientes externos y decidas satisfacer sus solicitudes mediante publicación pública.
• Hacer el código público suele ser la vía de cumplimiento más sencilla para servicios orientados a clientes porque evita trabajo de distribución por cliente y muestra buena fe. También se alinea con las expectativas de muchos proyectos upstream, pero implica que tus modificaciones son visibles para competidores.

Cuando se requiere autoalojamiento u otros arreglos especiales

El autoalojamiento es apropiado cuando un requisito escrito prohíbe depender de infraestructura de terceros (normas regulatorias de residencia de datos, redes clasificadas o obligaciones contractuales). De lo contrario, la opción de relay gestionado / infraestructura gestionada suele costar menos en términos reales una vez que sumas carga on-call, parcheo, custodia de certificados y conmutación por error. Discutimos estos trade-offs en más detalle en Self hosting hidden costs y en nuestro artículo más amplio sobre Open source business model: why AGPL works for SaaS.

Ejemplos prácticos y una breve FAQ

• P: Si modifico código AGPL y solo mi equipo de operaciones lo usa, ¿tengo que publicar? R: Sí — tu equipo de operaciones son usuarios. Pon el código a disposición internamente.
• P: Si proveo un servicio respaldado por AGPL a clientes, ¿debo publicar públicamente? R: Debes proporcionar el código correspondiente a esos clientes. Publicarlo públicamente es el método estándar para cumplir ese requisito.
• P: ¿Puedo mantener la configuración y los secretos cerrados? R: Los secretos no son "código fuente" según la licencia. Elimina secretos de los archivos publicados y documenta las entradas de secretos esperadas en su lugar.
• P: ¿Es suficiente apuntar al upstream si hice modificaciones locales? R: No. Debes proporcionar el código de la versión específica que ejecutas, incluidas tus modificaciones.

Si quieres un ejemplo práctico de autoalojar una pila de escritorio remoto de código abierto y los pasos exactos de compilación para mantener el cumplimiento, consulta nuestra guía de Self-hosted remote desktop y el tutorial Docker de RustDesk en RustDesk self-hosted setup para mecánicas que puedes reutilizar.

El cumplimiento con la AGPL es mecánico: identifica a los usuarios, fija la revisión en ejecución, reúne la Complete Corresponding Source y las instrucciones de compilación, y hazlo accesible a esos usuarios. Las partes difíciles son la gobernanza y la arquitectura: decidir si separar componentes, negociar licencias o aceptar la visibilidad pública de las modificaciones.

Si estás desplegando infraestructura de acceso remoto y quieres evitar ejecutar y publicar un relay propio, el relay gestionado de Tenvo es la opción pragmática por defecto: clientes nativos para Windows, macOS y Linux, un cliente de navegador en beta pública, un relay gestionado con servidores en Alemania y planes desde Free $0 hasta Lite $2.99/mes y Pro $7.99/mes. El autoalojamiento debe usarse solo cuando un requisito escrito lo exige; de lo contrario, la opción gestionada suele costar menos cuando consideras on-call, parcheo, custodia de claves y requisitos de failover.

Las preguntas que requieren certeza legal — límite de obras derivadas, interpretación de una arquitectura de plugins concreta o negociación contractual — son cuestiones legales. Este artículo busca aclarar el panorama técnico para que puedas tomar una decisión informada y tener una conversación sensata con el asesor legal.

Cuando estés listo para probar un relay gestionado y mantener baja tu sobrecarga operativa, descarga Tenvo y familiarízate con el modelo de despliegue y la interfaz: Descargar Tenvo.