Bambu Lab desativa fork do OrcaSlicer e acaba ampliando seu público
A relação delicada entre um subgrupo de usuários da Bambu Lab e a própria empresa ganhou destaque neste mês, após a fabricante pressionar um desenvolvedor independente a remover um fork do OrcaSlicer que reconectava o slicer à infraestrutura de nuvem da Bambu Lab.
O desenvolvedor Paweł Jarczak publicou o OrcaSlicer-bambulab em abril, chamando rapidamente a atenção da Bambu Lab, que considerou o slicer um risco inaceitável para sua infraestrutura de nuvem. O fork, derivado do programa de código aberto OrcaSlicer e combinado com o código do Bambu Studio (ambos projetos lançados sob a Affero General Public License: AGPL), restaurou o acesso de impressão em nuvem — um recurso que a Bambu Lab havia removido de softwares de terceiros em alterações feitas no ano passado. Cerca de uma semana após o repositório se tornar público, Jarczak o retirou do ar, deixando uma nota na página alegando uma comunicação da Bambu Lab que ameaçava com uma notificação extrajudicial preparada pelos advogados da empresa, caso ele não o removesse.
Por trás das manchetes, há um desenvolvedor que tem sido um colaborador ativo de código aberto para os mesmos produtos no centro da disputa. Jarczak disse à All3DP que “as discussões públicas podem facilmente fazer com que isso pareça um grande ‘drama hacker’. Não é assim que eu me vejo. Sou apenas um cara normal que gosta de ajudar as pessoas”. Ele explicou que é cliente da Bambu Lab e usuário da versão Linux do Bambu Studio, já tendo contribuído com correções de bugs pelos canais oficiais no passado.
“Ao trabalhar com o Bambu Studio compilado localmente, notei que o caminho de rede funcionava normalmente no Linux. Como o OrcaSlicer também pertence à mesma família de código aberto do PrusaSlicer/Slic3r/Bambu Studio, não vi um motivo óbvio pelo qual o caminho do código público do Bambu Studio não pudesse ser adaptado lá também.” Ele esclarece: “Tudo o que eu trabalhei pessoalmente foi baseado no código-fonte do Bambu Studio disponível publicamente.”
Para contextualizar: em janeiro de 2025, a Bambu Lab removeu o caminho da API que o OrcaSlicer e qualquer outro software de terceiros usavam para comunicação direta em nuvem, substituindo-o pelo Bambu Connect – um middleware proprietário que transmite arquivos para a impressora, mas remove o controle de tempo de execução remoto (remote runtime control). A medida limitou efetivamente os comandos que poderiam ser enviados às impressoras pela nuvem da empresa ao Bambu Studio e a terceiros que integram o Bambu Connect como uma etapa adicional no processo.
Foi uma medida controversa, principalmente devido às alegações inespecíficas de melhorias de segurança que a acompanharam — e porque o novo sistema, descrito como seguro pela Bambu Lab, foi comprometido em menos de 24 horas, quando um pesquisador de segurança extraiu a chave privada usada para assinar operações críticas.
O assunto continua sendo um ponto sensível para alguns usuários das impressoras da empresa que preferem o OrcaSlicer. O projeto OrcaSlicer se recusou a incorporar o novo caminho de controle da Bambu Lab, e as duas partes têm mantido um distanciamento constante desde então.
Para esclarecer, o OrcaSlicer ainda pode ser usado para fatiar e enviar trabalhos para o hardware da Bambu Lab; no entanto, o envio remoto de impressões e o controle das máquinas via nuvem da empresa não são mais possíveis. O uso das impressoras no modo LAN ou de desenvolvedor (“Developer Mode”) — uma concessão àqueles preocupados com a mudança inicial de firmware — continua viável; porém, perde-se o aspecto do ecossistema completo, que é um dos principais motivos pelos quais os usuários optam por uma impressora Bambu Lab. Para alguns, a medida criou uma barreira inaceitável e alterou a natureza das máquinas que haviam adquirido.
O slicer de Jarczak funcionava porque o caminho do Bambu Studio no Linux ainda não havia sido atualizado para refletir as restrições de 2025, afirma ele, alegando não ter feito alterações no código utilizado. O argumento aqui é que a Bambu Lab, de certa forma, negligenciou o fechamento de uma das portas que afirmava não estar mais acessível. Em uma postagem de blog publicada em 7 de maio, a versão da Bambu Lab sobre os eventos traz mais detalhes, afirmando que o fork do slicer funcionava configurando sua string de user agent HTTP para se identificar aos servidores da Bambu como um software oficial do Bambu Studio, em vez de um derivado do OrcaSlicer, contornando, assim, a verificação de identidade do cliente no servidor.
Segundo a nota de Jarczak, a comunicação da Bambu Lab afirmava que uma notificação extrajudicial havia sido preparada e alegava que a “implementação” dele: se passava pelo Bambu Studio; burlava seus controles de autorização; violava seus Termos de Uso; envolvia engenharia reversa; e poderia permitir que forks modificados enviassem comandos arbitrários às impressoras.
Ele não aceitou essas alegações como fatos estabelecidos. Após solicitar à empresa detalhes sobre as supostas violações e permissão para compartilhar a conversa, Jarczak afirma que a Bambu Lab recusou seu pedido para publicar a correspondência. Ele removeu o software do GitHub, mas a essa altura, o fork e a resposta da Bambu Lab já haviam começado a chamar a atenção.
Se a lista de queixas da empresa se sustentaria ou não em um tribunal, é algo aberto a debate. Em 6 de maio, o advogado de propriedade intelectual Leonard “Lawful Masses” French publicou no YouTube uma ampla análise jurídica de 19 minutos sobre a posição de execução da Bambu Lab. Ele postulou, com base na explicação de Jarczak sobre a correspondência, que as acusações da empresa poderiam não resistir caso fossem testadas judicialmente.
Um dia depois, em 7 de maio, a Bambu Lab quebrou o silêncio por meio de uma postagem em seu blog, abordando a situação com a intenção declarada de “esclarecer alguns pontos que foram de certa forma mal interpretados ou que geraram confusão não intencional”.
A publicação começa afirmando o óbvio: qualquer pessoa pode criar um fork do código licenciado sob AGPL do Bambu Studio, modificá-lo e distribuí-lo. Eles observam que cerca de 734 forks já fazem isso. A ameaça de notificação extrajudicial, de acordo com o relato de Jarczak, tratou o próprio ato de criar o fork como problemático, mas a postagem do blog não aborda essa discrepância. Em vez disso, restringe a queixa especificamente ao spoofing do user agent, enquadrado como falsificação de identidade do cliente, que potencialmente ameaçaria a estabilidade da infraestrutura de nuvem da empresa.
A Bambu Lab argumenta que sua atitude visa garantir a integridade de sua plataforma em nuvem, a qual descreve como um serviço privado, contra tráfego descontrolado. O fork de Jarczak “funcionava injetando metadados de identidade falsificados na comunicação de rede”, alega a publicação. A justificativa de 2025 para a alteração original de controle concentrava-se em manter seguros os comandos remotos enviados à impressora, além de gerenciar “30 milhões de solicitações não autorizadas por dia“. A resposta de 2026 enquadra a questão diretamente na integridade do serviço, “sobre a estabilidade de nossa infraestrutura de nuvem”, sem menção ao argumento de segurança das impressoras utilizado em 2025.
Em 10 de maio, o ativista pelo direito ao reparo (right-to-repair), Louis Rossmann, comprometeu-se a ajudar caso Jarczak republicasse o código e a Bambu Lab tentasse processá-lo, afirmando: “Se a Bambu Lab for atrás de você por manter seu código no ar, estou tão confiante no seu caso que pagarei os primeiros US$ 10.000.” Esse sentimento é comum em muitos dos fóruns criados para discutir o fork e a resposta da Bambu Lab. Jarczak declarou à All3DP: “Muitas pessoas continuam me dizendo ‘lute contra eles’, ‘processe-os’ e assim por diante. Mas eu sou um programador. Gosto de construir coisas, resolver problemas e ver que algo funciona para as pessoas. Não gosto de brigas judiciais e não tenho prazer na ideia de processar ninguém.”
Jarczak rejeita a alegação da Bambu Lab de que seu trabalho poderia levar a “padrões de carga semelhantes a DDoS” e facilitar a ação de hackers. “Se a Bambu Lab acredita que há um problema grave de segurança em um caminho que ainda existe em seu próprio software, isso deveria ser corrigido do lado deles. Colocar pressão jurídica sobre um colaborador individual de código aberto não parece a maneira correta de lidar com isso.”
Seja qual for o ponto de vista, este é mais um capítulo no atrito constante entre power users exercendo o direito de usar seu hardware como lhes convém (dentro dos limites do licenciamento e do escopo pertinente) e marcas, especialmente aquelas centradas em ecossistemas fechados, que impõem seus limites conforme desejam. Esses dois objetivos raramente se alinham e, neste caso da Bambu Lab, ameaçar um desenvolvedor independente com histórico de contribuições para esse mesmo ecossistema atraiu muito mais atenção para o assunto do que a empresa provavelmente gostaria.
Quando contatado, um representante da Bambu Lab afirmou que a empresa não faria mais comentários além do que foi publicado no blog. A empresa encerra a postagem fazendo menção ao seu programa de recompensas por vulnerabilidades (bug bounty program), incentivando os usuários a relatarem quaisquer problemas e exploits que encontrarem.
Também de interesse:
Licença: O texto "Bambu Lab desativa fork do OrcaSlicer e acaba ampliando seu público", da All3DP, é licenciado pela licença Creative Commons Atribuição 4.0 Internacional (CC BY 4.0)