Resposta abrangente às violações da AGPLv3 pela Bambu

 (sfconservancy.org)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Bambu Studio é uma versão modificada do PrusaSlicer baseada em AGPLv3, mas não forneceu todo o código-fonte nem as informações de instalação da biblioteca de rede proprietária
  • O Corresponding Source da AGPLv3 inclui o código necessário para gerar, instalar, executar e modificar, além do código-fonte de bibliotecas dinamicamente vinculadas que estejam fortemente acopladas
  • A Bambu exigiu que Paweł Jarczak removesse um fork que modificava o Orca Slicer para funcionar com componentes de servidor da Bambu, entrando em conflito com a cláusula que proíbe restrições adicionais
  • A SFC está promovendo o projeto baltobu para fazer engenharia reversa da biblioteca de rede, manter o Orca Slicer para Bambu e desenvolver o viscose como fork substituto do Bambu Studio
  • A SFC iniciou uma arrecadação de US$250.007 por dois meses para atividades de direito ao reparo de software em impressoras 3D e pretende divulgar os detalhes de um comitê permanente em junho de 2026

Violações confirmadas da AGPLv3

  • Código-fonte de libbambu_networking não fornecido

    • Uma investigação de conformidade com a AGPLv3 sobre o software e o firmware das impressoras 3D da Bambu Lab confirmou duas violações
    • O Bambu Studio é um slicer que divide modelos de projeto digital como STL em camadas 2D horizontais que a impressora consegue imprimir
    • Há 4 anos, a Bambu divulga o Bambu Studio como uma versão modificada do PrusaSlicer, um slicer concorrente licenciado sob AGPLv3
    • O PrusaSlicer, por sua vez, é uma versão modificada do Slic3r, criado originalmente por Alessandro Ranellucci
    • Parte do código-fonte do Bambu Studio está na organização da Bambu no GitHub, mas a empresa afirma distribuir o Bambu Studio aos usuários por meio de prompts interativos na UI, combinado com bibliotecas proprietárias
    • A AGPLv3 determina que, ao transmitir uma obra coberta em forma de código-objeto, também deve ser transmitido o Corresponding Source legível por máquina sob os mesmos termos de licença
    • O Corresponding Source inclui o código-fonte e os scripts necessários para gerar, instalar, executar e modificar o código-objeto
    • Também inclui o código-fonte de bibliotecas compartilhadas e subprogramas com link dinâmico projetados para serem exigidos pela obra por meio de comunicação de dados estreita ou fluxo de controle
    • O fato de a Bambu não fornecer o Corresponding Source Code completo nem as Installation Information de libbambu_networking.so, bambu_networking.dll e libbambu_networking.dylib é considerado uma violação grave e contínua da AGPLv3

  • Exigência de remoção do fork de Paweł Jarczak

    • Separadamente da decisão da Bambu de manter a biblioteca de rede como proprietária, as medidas tomadas contra o desenvolvedor e usuário da Bambu Lab Paweł Jarczak também são apresentadas como violação da AGPLv3
    • Paweł Jarczak divulgou outra forma de integração com os componentes do lado do servidor do Bambu Studio sem substituir nem modificar a biblioteca vinculada dinamicamente
    • Após revisar o código-fonte incompleto do Bambu Studio, ele modificou outro slicer sob AGPLv3, o Orca Slicer
    • O Orca Slicer modificado permitia que usuários substituíssem o Bambu Studio enquanto se conectavam, por comunicação de dados estreita, a partes executadas nos servidores da Bambu Lab cujo código-fonte ainda não foi publicado
    • A Bambu exigiu que Paweł removesse do GitHub o fork do OrcaSlicer com essas mudanças
    • A empresa alegou que seus termos de serviço prevalecem sobre a AGPLv3, mas a AGPLv3§10¶3 afirma que não se podem impor restrições adicionais ao exercício dos direitos concedidos ou confirmados pela licença
    • Paweł removeu o fork do Orca Slicer em protesto

Plano de resposta da SFC

  • Projeto baltobu

    • A SFC iniciou o projeto baltobu e está operando vários repositórios para responder às violações da AGPLv3 relacionadas à Bambu e melhorar o direito ao reparo de software em impressoras 3D
    • Motivado pelas medidas da Bambu contra Paweł Jarczak, foi iniciado um trabalho multifacetado para ajudar consumidores e usuários no curto prazo e melhorar, no longo prazo, o direito ao reparo de software para consumidores de impressoras 3D
    • Como a Bambu já era conhecida havia muito tempo como uma forte infratora da AGPLv3, a prioridade foi começar por engenharia reversa, que pode trazer resultados mais rápidos do que medidas judiciais

  • reverse-networking

  • orca-slicer-for-bambu

    • O repositório orca-slicer-for-bambu do baltobu deve se tornar o repositório padrão para manter e aprimorar o fork do Orca Slicer originalmente publicado por Paweł, com base no trabalho dele
    • A SFC está pedindo voluntários para manter um fork do OrcaStudio que funcione com impressoras 3D da Bambu
    • Contribuidores voluntários que atuem em nome da SFC podem receber um certo nível de proteção de responsabilidade pessoal, e a SFC pretende intervir sempre que possível caso a Bambu faça ameaças legais contra esses voluntários

  • viscose

    • O repositório viscose do baltobu é um projeto para manter um fork ativo do próprio Bambu Studio
    • Com base nas descobertas dos dois trabalhos anteriores, a iniciativa caminha para criar um substituto do Bambu Studio que funcione melhor para donos de impressoras 3D da Bambu

  • Monitoramento de violações adicionais

    • A SFC pretende continuar monitorando possíveis violações adicionais da Bambu Lab
    • Em geral, ela não sai ativamente procurando violações, mas neste caso pretende observar a Bambu Lab de perto e investigar regularmente possíveis violações de licenças copyleft

  • Comitê permanente da comunidade de impressoras 3D

    • A SFC pretende iniciar um comitê permanente para discutir liberdade e direitos de software na comunidade de impressoras 3D
    • Os detalhes do comitê serão divulgados em junho de 2026
    • O plano é que o comitê reúna mensalmente fabricantes de impressoras 3D, usuários, consumidores, especialistas em licenças copyleft e ativistas da liberdade de software
    • O objetivo é compartilhar problemas e preocupações sobre o direito ao reparo de software em impressoras 3D e software relacionado, e criar planos de ação para resolvê-los

Participação e apoio

  • Participação voluntária

    • A SFC está pedindo voluntários para participar imediatamente desse trabalho
    • Paweł Jarczak já entrou como primeiro voluntário, e o trabalho dele teve papel importante na investigação de várias violações da AGPLv3 pela Bambu
    • Quem quiser ajudar no trabalho técnico do projeto baltobu pode verificar como solicitar uma conta na instância Forgejo da SFC
    • Quem tiver interesse em outras iniciativas pode enviar e-mail para 3dprint@sfconservancy.org

  • Arrecadação para atividades de direito ao reparo

    • A SFC está realizando uma campanha de arrecadação de US$250.007 por dois meses
    • Novas contribuições como Sustainer e doações gerais à SFC serão destinadas às atividades de direito ao reparo de software
    • Se a meta for alcançada, a organização iniciará imediatamente a contratação de pessoal adicional para liderar o trabalho de longo prazo
    • Esse profissional ficará responsável por coordenar contribuições voluntárias, planejar estratégias para melhorar o direito ao reparo de software em impressoras 3D e definir os próximos passos necessários caso não seja possível levar a Bambu Lab à conformidade com a AGPLv3
    • Se a meta não for atingida, os valores arrecadados serão usados no tempo que a equipe atual dedicar a esse projeto e em atividades relacionadas ao direito ao reparo de software

Pessoas que já contribuíram

  • Paweł Jarczak fez a SFC tomar conhecimento das contínuas violações da AGPLv3 pela Bambu Lab e modificou o código-fonte de formas permitidas pela AGPLv3 para avançar o trabalho relacionado
  • b3nsn0w investigou mais a fundo a situação da Bambu Lab e vem defendendo a AGPLv3 há mais de um ano em relação à violação envolvendo bibliotecas com link dinâmico
  • A FULU ajudou a chamar atenção para esse problema e publicou uma posição contra a Bambu Labs

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Lobste.rs
  • Agradeço o esforço em si. Sou usuário de código aberto há muito tempo e contribuo de vez em quando, além de usar uma impressora da Bambu, mas não consegui fazer o Bambu Studio nem o OrcaSlicer compilado do código-fonte rodarem direito numa máquina Debian meio bagunçada
    Também acompanho licenças FLOSS há bastante tempo e, embora eu entenda a motivação da AGPLv3, ela sempre me pareceu um pouco desconfortável. Também não gosto da forma como a Bambu está lidando com isso e, mesmo que eu não saiba dizer se chega ao nível jurídico, pelo menos certamente viola o espírito do open source
    O ponto que me pega é: o que está sendo dito aqui é que software sob AGPLv3 não pode chamar dlopen() em binários não livres, ou que distribuir um arquivo .so que só compartilha algumas assinaturas de ponteiros de função com um software AGPLv3 já é violação de licença? Neste caso específico, dá para entender a rejeição, já que a mesma entidade está distribuindo junta uma versão modificada de software AGPLv3 e binários não livres, mas generalizando isso a ideia não entra muito bem na minha cabeça
    Levando ao extremo, isso poderia parecer significar que software AGPLv3 capaz de carregar plugins em um formato padronizado seria incompatível com a própria licença. Por exemplo, no caso de um software de áudio AGPLv3 que consegue carregar VST(https://en.wikipedia.org/wiki/Virtual_Studio_Technology), parece bem complicado entender corretamente as implicações de licença
    • Pelo que aparece neste tópico, a Bambu aparentemente faz com que todo o tráfego de rede passe intencionalmente por essa biblioteca proprietária. Sem ela, o software praticamente perde a utilidade e, ao que tudo indica, há até funcionalidade de anti-debugging para derrubar o programa se alguém tentar inspecionar o comportamento
    • A interpretação de “isso quer dizer que software AGPLv3 não pode chamar dlopen() em binários não livres?” não é a posição da FSF. A FSF explica, no item do FAQ sobre plugins, que a definição de se é um único programa combinado depende de como o programa principal chama o plugin
      Se ele apenas o executa com fork e exec e não há comunicação estreita, pode ser um programa separado; mas, se há linkagem dinâmica e compartilhamento de chamadas de função e estruturas de dados, a posição deles é que isso deve ser visto como um único programa combinado. Eles também consideram que trocar estruturas de dados complexas por memória compartilhada é quase o mesmo que linkagem dinâmica
      Pelo que sei, isso se aplica de forma geral a todas as versões da GPL. Em resumo, o critério é se aquele plugin já poderia ser usado em outro software antes de ser escrito para o programa GPL. Se ele só tem utilidade naquele programa GPL, então na prática é mais próximo de uma parte daquele programa
    • A SFC citou os trechos relevantes do texto da licença. Corresponding Source inclui o código-fonte de bibliotecas compartilhadas e subprogramas vinculados dinamicamente que a obra foi projetada especificamente para exigir
      Portanto, o mero suporte a plugins em si é aceitável. O problema surge quando um plugin específico se torna, na prática, necessário para a funcionalidade normal da aplicação. O .so mencionado no texto da SFC parece estar relacionado à rede, e também parece plausível que seja difícil usar a impressora com conforto sem acesso à rede
      Em um contexto mais amplo, “Corresponding Source” para uma obra em forma de código objeto significa todo o código-fonte e scripts necessários para gerar, instalar, executar e modificar o código objeto, mas exclui bibliotecas de sistema e ferramentas de uso geral ou programas livres geralmente disponíveis que sejam usados sem modificação
      Em particular, é possível desenvolver software AGPL no OSX dependendo de um SDK proprietário fornecido pela Apple em todas as máquinas OSX. O mesmo vale para aplicativos Windows que dependem de componentes do lado do Windows