AGPL y forks: el caso BambuStudio

El caso de BambuStudio y PrusaSlicer no es solo una pelea entre proyectos de impresión 3D. También es una buena excusa para aterrizar algo que muchas empresas aún tratan como detalle menor: la AGPL no es una licencia decorativa. Si tomas código bajo AGPL, lo modificas, lo redistribuyes o lo pones a disposición de usuarios en red, tienes obligaciones concretas.

Y si no las cumples, el problema no se queda en lo legal. También te pega en la reputación, en la confianza de la comunidad y, a veces, en el producto mismo. En este artículo vamos a usar ese caso para explicar qué exige la AGPL, qué pasa cuando haces un fork y dónde suelen equivocarse equipos que trabajan con software libre.

Qué pasó entre PrusaSlicer y BambuStudio

La discusión pública arrancó a partir de una publicación de Josef Prusa, donde señaló que BambuStudio habría estado violando la licencia AGPL de PrusaSlicer desde que hizo su fork. La acusación, en esencia, apunta a que el código derivado no habría respetado todas las obligaciones de distribución y atribución que exige esa licencia. La fuente original del reclamo fue un hilo en X publicado por Prusa, y el tema se propagó rápido porque toca una fibra sensible en el ecosistema open source: el respeto a las licencias no es opcional.

No hace falta tomar partido para entender por qué el caso llamó tanto la atención. BambuStudio es un proyecto muy visible dentro del mundo de la impresión 3D, y PrusaSlicer es una base técnica conocida y usada por miles de personas. Cuando un fork nace sobre una base AGPL, cualquier duda sobre cumplimiento deja de ser un asunto interno y se vuelve un caso público. Ahí ya no solo importa si el código funciona, sino si la empresa puede demostrar que está cumpliendo con lo que tomó.

Por qué este caso importa más allá de la impresión 3D

Si trabajas en software, este tipo de conflicto te debería sonar familiar. Pasa con apps, plataformas SaaS, herramientas de infraestructura y productos embebidos. El patrón casi siempre es el mismo: una empresa toma una base open source, acelera desarrollo, lanza producto y después subestima las condiciones de la licencia. Cuando la comunidad detecta inconsistencias, el debate deja de ser técnico y pasa a ser legal y reputacional.

Además, el caso sirve para desmontar un mito común: “si el código es abierto, no hay problema”. No. Código abierto no significa sin reglas. Significa que puedes usarlo bajo ciertas condiciones. En AGPL, esas condiciones son más exigentes que en otras licencias porque buscan evitar que un servicio en red se beneficie del trabajo ajeno sin devolver nada a la comunidad.

Qué exige realmente la AGPL

La AGPL, o GNU Affero General Public License, es una licencia copyleft diseñada para software que se usa también como servicio. Su diferencia clave frente a la GPL clásica es la cláusula de red: si modificas el programa y lo usas para ofrecer funcionalidades a usuarios a través de una red, debes ofrecer el código fuente correspondiente a esos usuarios. La lógica es simple: no basta con publicar el código si nunca lo distribuyes como archivo; también cuenta el uso remoto.

La documentación oficial de la Free Software Foundation lo explica de forma bastante clara en su texto de licencia y en su FAQ sobre AGPL. Puedes revisarlo aquí: GNU AGPL v3 y GNU AGPL FAQ. Esa es la base para entender por qué un fork de un proyecto AGPL no puede tratarse como si fuera software propietario con una pizca de open source al final.

La cláusula de red, en palabras simples

Supón que tomas un proyecto AGPL, le haces cambios y lo integras en un servicio que tus usuarios usan vía web o mediante una aplicación conectada a un backend. Aunque no entregues el binario como tal, la licencia te puede exigir ofrecer el código fuente de la versión modificada a quienes interactúan con el software por red. Ese detalle cambia bastante el juego para empresas que construyen productos sobre una base AGPL.

En la práctica, la cláusula de red busca cerrar una puerta que la GPL dejaba más abierta. Con GPL, una empresa podía modificar el código y correrlo internamente sin distribuirlo. Con AGPL, si el software presta servicio a terceros, la obligación de compartir el código modificado aparece igual. Por eso muchas compañías revisan con lupa si una dependencia es GPL o AGPL antes de meterla en producción.

Qué suele pedir la AGPL cuando redistribuyes

La obligación exacta depende del caso, pero normalmente incluye varios puntos concretos:

1. Mantener avisos de copyright y licencia.
2. Entregar o poner a disposición el código fuente correspondiente.
3. Identificar cambios relevantes sobre la versión original.
4. Conservar la misma licencia para obras derivadas, si aplica.
5. No imponer restricciones adicionales que contradigan la licencia.

Si una empresa omite uno o más de estos pasos, no necesariamente “pierde todo” de inmediato, pero sí se expone a una reclamación formal. Y cuando el proyecto es visible, la corrección suele requerir más que una disculpa: toca ordenar repositorios, empaquetados, avisos legales y procesos internos.

Dónde suelen fallar las empresas cuando hacen forks

El error más común no es técnico, sino operativo. Muchas veces el equipo de ingeniería sí sabe que trabaja sobre código abierto, pero no hay un proceso claro de compliance. Entonces el repo se bifurca, se renombra, se ajusta la UI, se agregan funciones y nadie revisa qué archivos de licencia deben mantenerse, qué créditos deben aparecer o cómo se publica el source correspondiente.

También pasa algo más incómodo: algunas empresas creen que pueden “limpiar” el origen del fork para evitar obligaciones. Eso rara vez funciona. Si el código sigue siendo derivado, la licencia sigue corriendo. Cambiar nombres, borrar historiales o empaquetar el proyecto como si fuera propio no borra la trazabilidad jurídica.

Errores frecuentes que sí generan riesgo

Aquí tienes una lista de fallos que aparecen una y otra vez en productos basados en AGPL:

• Quitar o esconder el archivo LICENSE original.
• No publicar el código fuente exacto de la versión distribuida.
• Mezclar código derivado con módulos propietarios sin separar bien las partes.
• Omitir avisos de atribución en binarios, instaladores o documentación.
• Usar un fork en un servicio en red sin ofrecer el source a los usuarios afectados.
• No documentar qué cambios se hicieron respecto del upstream.

No todos los errores terminan en demanda, pero sí aumentan la probabilidad de una reclamación, un takedown o un conflicto público. Y en productos de hardware o software de consumo, el costo reputacional puede ser más alto que el costo legal directo.

Riesgos legales y reputacionales para una empresa

Cuando una empresa usa código AGPL sin cumplir, el primer riesgo es obvio: el titular de los derechos puede reclamar cumplimiento, exigir la corrección del incumplimiento o incluso iniciar acciones legales si la situación no se resuelve. En open source, el enforcement no siempre llega a juicio, pero el solo hecho de tener una disputa pública ya complica ventas, alianzas y confianza de la comunidad.

El segundo riesgo es comercial. Si tu producto depende de una comunidad técnica activa, una acusación de incumplimiento puede afectar tu capacidad de contratar talento, cerrar partnerships o mantener una base de usuarios fiel. La gente que contribuye a proyectos libres suele tener buena memoria y poca tolerancia a los atajos con licencias.

El costo reputacional en números prácticos

No siempre vas a ver una multa publicada o un cálculo exacto del daño. Pero sí puedes medir impactos indirectos:

En empresas pequeñas, ese costo puede ser todavía más duro porque no hay un departamento legal grande que absorba el golpe. Una corrección tardía puede retrasar lanzamientos, obligar a rehacer documentación y abrir una conversación incómoda con la comunidad.

Cómo se aplica la AGPL en un fork de software libre

Un fork no es automáticamente un problema. De hecho, es una práctica normal en software libre. El punto es que un fork no te libera de la licencia original. Si tomas el código y lo sigues desarrollando, heredas sus condiciones. Y si el proyecto original usa AGPL, tu fork también debe respetar ese marco para el código derivado.

La clave está en distinguir entre “puedo hacerlo” y “puedo hacerlo sin obligaciones”. La respuesta a la primera suele ser sí. La respuesta a la segunda casi nunca es sí. Si redistribuyes, debes mantener avisos, atribución y acceso al código fuente cuando corresponde. Si además ofreces el software como servicio, la cláusula de red entra en juego.

Flujo básico de cumplimiento que deberías seguir

Si tu equipo trabaja sobre un fork AGPL, este flujo mínimo te ayuda a no improvisar:

1. Identifica la licencia exacta de cada componente.
2. Separa el código derivado del código propio.
3. Conserva avisos de copyright y archivos de licencia.
4. Documenta cambios relevantes en un changelog o en el repo.
5. Publica el código fuente correspondiente al release distribuido.
6. Si el software se ofrece por red, revisa la obligación de acceso al source para usuarios.
7. Haz una revisión legal antes de cada release grande.

No es un proceso glamoroso, pero sí evita sustos. Y si trabajas con hardware conectado, apps de escritorio con telemetría o servicios híbridos, conviene tenerlo automatizado desde el inicio. Un checklist manual al final del sprint suele llegar tarde.

Qué debería mirar tu equipo legal y técnico

El equipo técnico suele fijarse en dependencias, build y empaquetado. Legal mira compatibilidad de licencias, atribución y distribución. En un fork AGPL, ambos lados tienen que hablar el mismo idioma. Si no, puedes terminar con un producto que compila perfecto pero incumple la licencia en el primer release público.

Una buena práctica es mantener un inventario de licencias por componente y una política interna para forks. No hace falta montar una burocracia enorme. Sí hace falta saber, con precisión, qué parte del código es tuya, cuál viene del upstream y qué obligaciones acarrea cada una.

Qué lecciones deja el caso para empresas en LatAm

En Latinoamérica hay muchas startups y pymes que usan open source para salir rápido al mercado. Eso tiene sentido. El problema aparece cuando el crecimiento llega antes que el orden interno. Ahí es fácil asumir que la licencia es un trámite secundario y que se arregla después. Con AGPL, ese “después” puede salir caro.

Si operas desde Ecuador, México, Colombia, Argentina o cualquier otro mercado de la región, probablemente no tengas un equipo legal especializado en licencias de software. Aun así, no estás exento. La buena noticia es que el cumplimiento básico no requiere una estructura gigantesca. Requiere disciplina, documentación y revisar el texto de la licencia antes de lanzar.

Checklist práctico para no tropezar

Antes de publicar un fork o una versión derivada, revisa esto:

• ¿Sabes exactamente de qué repo y commit partiste?
• ¿Conservaste el archivo de licencia original?
• ¿Tu build publica el source correspondiente al binario o servicio?
• ¿Tu documentación explica qué cambió respecto del upstream?
• ¿Tu equipo legal revisó si la cláusula de red aplica?
• ¿Tu repositorio público refleja la versión que realmente distribuyes?

Si respondes “no” a dos o más de estas preguntas, tienes una deuda de compliance. No significa que el proyecto esté condenado, pero sí que conviene frenar antes de escalar el problema.

Tabla resumen

El caso BambuStudio deja una lección bastante clara: usar open source no te da inmunidad, te da responsabilidades. Y en AGPL esas responsabilidades están redactadas para que no puedas beneficiarte del trabajo ajeno sin devolver las mejoras cuando corresponde.

Si estás construyendo sobre un fork, no lo trates como un detalle administrativo. Trátalo como parte del producto. Porque cuando una licencia está mal resuelta, el problema no se queda en el repo: llega a soporte, a ventas, a la comunidad y, a veces, al área legal.