Respuesta integral a las violaciones de AGPLv3 por parte de Bambu

 (sfconservancy.org)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Bambu Studio es una versión modificada de PrusaSlicer basada en AGPLv3, pero no proporcionó todo el código fuente ni la información de instalación de su biblioteca de red propietaria
  • El Corresponding Source de AGPLv3 incluye el código estrechamente acoplado y el código fuente de bibliotecas enlazadas dinámicamente necesarios para generar, instalar, ejecutar y modificar el programa
  • Bambu exigió que Paweł Jarczak eliminara un fork modificado para conectar Orca Slicer con componentes del servidor de Bambu, lo que entra en conflicto con la cláusula que prohíbe restricciones adicionales
  • SFC impulsa el proyecto baltobu para hacer ingeniería inversa de la biblioteca de red, mantener Orca Slicer for Bambu y desarrollar viscose como fork alternativo de Bambu Studio
  • SFC inició una recaudación de US$250,007 durante dos meses para actividades del derecho a reparar el software de impresoras 3D y planea revelar en junio de 2026 los detalles de un comité permanente

Violaciones confirmadas de AGPLv3

  • Falta del código fuente de libbambu_networking

    • Una investigación de cumplimiento de AGPLv3 sobre el software y firmware de las impresoras 3D de Bambu Lab confirmó dos violaciones
    • Bambu Studio es un slicer que divide modelos de diseño digital como STL en capas 2D horizontales para que la impresora pueda imprimirlas
    • Durante 4 años, Bambu ha informado que Bambu Studio es una versión modificada de PrusaSlicer, un slicer de la competencia licenciado bajo AGPLv3
    • PrusaSlicer es, a su vez, una versión modificada de Slic3r, creado originalmente por Alessandro Ranellucci
    • Parte del código fuente de Bambu Studio está en la cuenta organizacional de GitHub de Bambu, pero Bambu ha indicado que distribuye Bambu Studio a los usuarios combinado con bibliotecas propietarias mediante indicaciones interactivas en la UI
    • AGPLv3 establece que, al distribuir una obra cubierta en forma de código objeto, también debe entregarse el Corresponding Source legible por máquina bajo las mismas condiciones de licencia
    • El Corresponding Source incluye el código fuente y los scripts necesarios para generar, instalar, ejecutar y modificar el código objeto
    • También forma parte del Corresponding Source el código fuente de bibliotecas compartidas y subprogramas enlazados dinámicamente diseñados para que la obra los requiera mediante comunicación de datos o flujo de control estrechamente acoplados
    • Se considera una violación grave y continua de AGPLv3 que Bambu no proporcione el Corresponding Source Code completo ni la Installation Information de libbambu_networking.so, bambu_networking.dll y libbambu_networking.dylib

  • Exigencia de eliminación del fork de Paweł Jarczak

    • Además de mantener la biblioteca de red como propietaria, también se presenta como violación de AGPLv3 la acción de Bambu contra el desarrollador y usuario de Bambu Lab Paweł Jarczak
    • Paweł Jarczak publicó una forma distinta de integrarse con los componentes del lado servidor de Bambu Studio sin reemplazar ni modificar las bibliotecas enlazadas dinámicamente
    • Tras revisar el código fuente incompleto de Bambu Studio, modificó otro slicer bajo AGPLv3, Orca Slicer
    • El Orca Slicer modificado permitía a los usuarios reemplazar Bambu Studio mientras seguía acoplándose, mediante una comunicación de datos estrecha, con partes que se ejecutan en los servidores de Bambu Lab pero cuyo código fuente actualmente no se publica
    • Bambu exigió a Paweł que eliminara de GitHub su fork de OrcaSlicer que incluía esos cambios
    • Bambu afirmó que sus términos de servicio prevalecen sobre AGPLv3, pero AGPLv3§10¶3 especifica que no pueden imponerse restricciones adicionales al ejercicio de los derechos otorgados o confirmados por la licencia
    • Paweł eliminó su fork de Orca Slicer como forma de protesta

Plan de respuesta de SFC

  • Proyecto baltobu

    • SFC lanzó el proyecto baltobu y opera varios repositorios para responder a las violaciones de AGPLv3 relacionadas con Bambu y mejorar el derecho a reparar el software de las impresoras 3D
    • A partir de la acción de Bambu contra Paweł Jarczak, comenzó un trabajo multifacético para ayudar a consumidores y usuarios en el corto plazo y mejorar a largo plazo el derecho a reparar el software de quienes compran impresoras 3D
    • Como Bambu ya era conocida desde hace tiempo como una fuerte infractora de AGPLv3, se decidió empezar por la ingeniería inversa, que puede dar resultados más rápidos que una acción legal

  • reverse-networking

  • orca-slicer-for-bambu

  • viscose

    • El repositorio viscose de baltobu es un proyecto para mantener un fork activo del propio Bambu Studio
    • Con base en los hallazgos de los dos trabajos anteriores, avanzará hacia la creación de un reemplazo de Bambu Studio que funcione mejor para propietarios de impresoras 3D de Bambu

  • Monitoreo de violaciones adicionales

    • SFC seguirá vigilando posibles violaciones adicionales por parte de Bambu Lab
    • En general no busca activamente infracciones, pero en este caso observará de cerca a Bambu Lab e investigará con regularidad posibles violaciones de licencias copyleft

  • Comité permanente de la comunidad de impresoras 3D

    • SFC planea iniciar un comité permanente para debatir la libertad y los derechos del software en la comunidad de impresoras 3D
    • Los detalles del comité se darán a conocer en junio de 2026
    • El comité está planeado como una estructura de reuniones mensuales con fabricantes de impresoras 3D, usuarios, consumidores, expertos en licencias copyleft y activistas por la libertad del software
    • Su objetivo es compartir problemas e inquietudes sobre el derecho a reparar el software de impresoras 3D y software relacionado, y crear planes de acción para resolverlos

Participación y apoyo

  • Participación voluntaria

    • SFC solicita voluntarios para sumarse de inmediato a este trabajo
    • Paweł Jarczak se unió como primer voluntario, y su trabajo desempeñó un papel importante en la investigación de varias violaciones de AGPLv3 por parte de Bambu
    • Si quieres ayudar con el trabajo técnico del proyecto baltobu, puedes revisar cómo solicitar una cuenta en la instancia de Forgejo de SFC
    • Si te interesan otras iniciativas, puedes escribir a 3dprint@sfconservancy.org

  • Recaudación para actividades de derecho a reparar

    • SFC realiza una recaudación de US$250,007 durante dos meses
    • Las nuevas contribuciones Sustainer y las donaciones generales a SFC se asignarán a actividades de derecho a reparar el software
    • Si se alcanza la meta, comenzará de inmediato la contratación de personal adicional para liderar el trabajo a largo plazo
    • Ese personal se encargará de coordinar a los voluntarios, planificar estrategias para mejorar el derecho a reparar el software de impresoras 3D y preparar los siguientes pasos necesarios si no se logra que Bambu Lab cumpla con AGPLv3
    • Si no se llega a la meta, lo recaudado se usará para el tiempo que el personal actual dedique a este proyecto y a actividades relacionadas de derecho a reparar el software

Personas que ya han contribuido

  • Paweł Jarczak hizo que SFC tomara conocimiento de las continuas violaciones de AGPLv3 de Bambu Lab y modificó el código fuente para avanzar en el trabajo de una manera permitida por AGPLv3
  • b3nsn0w investigó más a fondo la situación de Bambu Lab y ha defendido AGPLv3 durante más de un año en relación con la violación de las bibliotecas enlazadas dinámicamente
  • FULU ayudó a llamar la atención sobre este problema y publicó una postura en contra de Bambu Labs

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Lobste.rs
  • Aprecio el esfuerzo en sí. Soy usuario de open source desde hace mucho tiempo y contribuidor ocasional, y también uso una impresora Bambu, pero no he logrado hacer funcionar bien Bambu Studio ni OrcaSlicer compilado desde el código fuente en una máquina Debian medio enredada
    También he seguido las licencias FLOSS durante años, y aunque entiendo la motivación de la AGPLv3, siempre me ha resultado un poco incómoda. Tampoco me gusta cómo Bambu está manejando esto y, aunque quizá no llegue a lo legal, creo que al menos sí viola claramente el espíritu del open source
    Lo que me hace ruido es si lo que se está diciendo aquí es que el software bajo AGPLv3 no puede llamar con dlopen() a binarios no libres, o si distribuir un archivo .so que solo comparte algunas firmas de punteros a función con software bajo AGPLv3 ya constituye una violación de licencia. En este caso entiendo el rechazo porque la misma entidad está publicando a la vez software modificado bajo AGPLv3 y binarios no libres, pero al generalizarlo ya no me termina de cuadrar
    Llevado al extremo, hasta podría parecer que significa que el software bajo AGPLv3 que puede cargar plugins en un formato estandarizado es incompatible con su propia licencia. Por ejemplo, en el caso de software de audio bajo AGPLv3 que puede cargar VST(https://en.wikipedia.org/wiki/Virtual_Studio_Technology), las implicaciones de licencia parecen bastante complejas de entender correctamente
    • Según este hilo, parece que Bambu hace pasar intencionalmente todo el networking por esta biblioteca cerrada. Sin ella, el software queda prácticamente inútil, y hasta parece tener funciones de antidepuración que lo hacen colapsar si intentas inspeccionar su comportamiento
    • La interpretación de “¿significa que el software bajo AGPLv3 no puede llamar con dlopen() a binarios no libres?” no es la postura de la FSF. En la entrada de FAQ sobre plugins, la FSF explica que si se trata de un solo programa combinado depende de cómo el programa principal llame al plugin
      Si solo lo ejecuta con fork y exec y no hay comunicación estrecha, puede tratarse de programas separados; pero si hay enlace dinámico y comparten llamadas de función y estructuras de datos, su postura es que debe considerarse un solo programa combinado. También consideran que intercambiar estructuras de datos complejas por memoria compartida es casi lo mismo que el enlace dinámico
      Tengo entendido que esto aplica en términos generales a todas las versiones de GPL. En resumen, el criterio es si ese plugin ya podía usarse en otro software antes de haber sido escrito para el programa GPL. Si solo es útil con ese programa GPL, entonces en la práctica se considera más cercano a ser parte de ese programa
    • La SFC citó las partes relevantes del texto de la licencia. Corresponding Source incluye el código fuente de bibliotecas compartidas y subprogramas enlazados dinámicamente que el trabajo esté diseñado específicamente para requerir
      Así que el soporte para plugins en sí está bien. El problema aparece cuando una aplicación en la práctica requiere cierto plugin para su funcionalidad normal. El .so mencionado en el texto de la SFC parece estar relacionado con networking, y también suena plausible que sin acceso a red sea difícil usar cómodamente la impresora
      En un contexto más amplio, para una obra en forma de código objeto, “Corresponding Source” significa todo el código fuente y scripts necesarios para generar, instalar, ejecutar y modificar el código objeto, pero excluye bibliotecas del sistema o herramientas de propósito general y programas libres normalmente disponibles que se usen sin modificación
      En particular, es posible desarrollar software bajo AGPL para OSX apoyándose en el SDK propietario que Apple proporciona en todas las máquinas OSX. Lo mismo aplica cuando una aplicación de Windows depende de componentes propios de Windows