Bambu Lab, OrcaSlicer e open source: il vero nodo è il controllo dell’ecosistema
La disputa tra Bambu Lab e una parte della community open source non riguarda solo un software, un fork o una funzione rimossa. È il segnale di una trasformazione più ampia nel mercato delle stampanti 3D desktop: da strumenti nati per utenti tecnici, maker e sviluppatori, a prodotti sempre più integrati, automatizzati e pensati per un pubblico più vasto.
Al centro del caso ci sono Bambu Studio, OrcaSlicer, Bambu Connect, il cloud di Bambu Lab e una questione delicata: dove finisce il diritto di modificare un software open source e dove inizia il diritto di un’azienda di controllare l’accesso alla propria infrastruttura online?
La risposta non è semplice, perché le due parti stanno parlando di aspetti diversi dello stesso sistema. Da un lato c’è il codice, distribuito con licenza open source. Dall’altro c’è il cloud, che Bambu Lab considera un servizio privato e sottoposto a regole proprie.
Il punto di partenza: Bambu Studio nasce su basi open source
Per capire la vicenda bisogna partire dalla genealogia dei software di slicing. Bambu Studio, il programma ufficiale usato per preparare e inviare le stampe alle macchine Bambu Lab, è pubblicato con licenza GNU Affero General Public License v3.0, cioè AGPL-3.0. Nel repository ufficiale, Bambu Lab dichiara che Bambu Studio è basato su PrusaSlicer, sviluppato da Prusa Research, a sua volta derivato da Slic3r, progetto creato da Alessandro Ranellucci con il contributo della community RepRap.
Questo significa che il cuore del software appartiene a una lunga tradizione di sviluppo collaborativo. La licenza AGPL consente di usare, modificare e ridistribuire il codice, ma impone che anche le opere derivate restino disponibili con la stessa licenza quando includono parti del software originario. Bambu Lab riconosce questo punto: nella propria dichiarazione pubblica afferma che Bambu Studio è un progetto open source sotto AGPL-3.0 e che chiunque può prendere il codice, modificarlo e distribuirlo.
Da Bambu Studio nasce poi OrcaSlicer, uno slicer open source molto usato dalla community. Nel repository di OrcaSlicer viene spiegato che il progetto deriva da Bambu Studio, PrusaSlicer e SuperSlicer, e che mantiene anch’esso la licenza AGPL-3.0. OrcaSlicer è apprezzato perché integra strumenti avanzati di calibrazione, controllo delle pareti, gestione delle cuciture, supporti, profili per molte stampanti e funzioni spesso richieste dagli utenti più esperti.
Il problema non è il fork in sé
Bambu Lab non contesta l’esistenza di OrcaSlicer come fork. L’azienda dice in modo esplicito che non si tratta di proibire OrcaSlicer o altri fork legittimi, né di chiudere il codice. Secondo Bambu Lab, il problema nasce quando un software modificato cerca di accedere direttamente al cloud aziendale presentandosi come se fosse il client ufficiale Bambu Studio.
Qui entra in scena il fork OrcaSlicer-BambuLab, associato allo sviluppatore indipendente Paweł Jarczak. Il progetto mirava a ripristinare la connettività diretta via cloud tra OrcaSlicer e le stampanti Bambu Lab, funzione che molti utenti avevano usato in passato e che era stata limitata con l’introduzione di un sistema di autorizzazione e con l’uso di Bambu Connect come intermediario.
Bambu Lab ha sostenuto che quella modifica inseriva metadati di identità falsificati nella comunicazione di rete, facendo apparire il software come il client ufficiale Bambu Studio. L’azienda ha descritto questo comportamento come impersonificazione del client ufficiale e come rischio per stabilità e sicurezza dei propri server.
Dal punto di vista della community, però, la questione è meno lineare. Jarczak ha sostenuto che il suo lavoro utilizzava codice pubblico AGPL e che non redistribuiva componenti proprietari. Nella sua analisi, il nodo non è l’accesso obbligatorio al cloud di Bambu Lab da parte di qualunque fork, ma la conformità della distribuzione di Bambu Studio alla licenza AGPL quando viene usato insieme al componente chiuso bambu_networking.
Bambu Connect: sicurezza per l’azienda, passaggio in più per gli utenti
Nel 2025 Bambu Lab ha introdotto un nuovo sistema di autorizzazione per alcune operazioni delle stampanti. L’azienda ha presentato Bambu Connect come strumento per mantenere l’integrazione con software di terze parti, tra cui OrcaSlicer, senza consentire a ogni applicazione di accedere direttamente al cloud e alle funzioni critiche della macchina. Nei comunicati dell’epoca, Bambu Lab ha sostenuto che l’obiettivo non era limitare il software di terze parti, ma aumentare la sicurezza del sistema.
Per molti utenti, però, la differenza pratica è evidente: prima OrcaSlicer poteva dialogare in modo più diretto con le stampanti Bambu Lab; con il nuovo modello, il flusso passa attraverso strumenti controllati dall’azienda, oppure richiede modalità alternative come LAN Mode e Developer Mode. Bambu Lab ricorda che queste opzioni restano disponibili per gli utenti avanzati che non vogliono usare il cloud, ma la comodità dell’esperienza “un clic e stampa” resta legata all’ecosistema ufficiale.
Questo è il cuore della tensione: Bambu Lab vuole proteggere un’infrastruttura cloud che consente monitoraggio remoto, stampa da MakerWorld, invio dei lavori e gestione semplificata; gli utenti più tecnici chiedono invece di mantenere pieno controllo su macchine acquistate e software derivato da codice open source.
La posizione di Bambu Lab: il codice è aperto, il cloud no
Bambu Lab distingue due piani. Il primo è il codice di Bambu Studio, che può essere modificato e distribuito secondo la licenza AGPL. Il secondo è il cloud aziendale, che l’azienda considera un servizio privato. Nella sua dichiarazione del 7 maggio 2026, Bambu Lab scrive che “una licenza per il codice non è un lasciapassare per la nostra infrastruttura cloud” e afferma che l’accesso al cloud è regolato da un accordo d’uso, non dalla licenza AGPL.
È una distinzione importante. Una licenza open source concede diritti sul codice, ma non garantisce automaticamente il diritto di usare server, API private, account, servizi cloud e risorse aziendali. Da questo punto di vista, Bambu Lab difende una posizione comune nel mondo dei dispositivi connessi: il software può essere aperto, ma l’infrastruttura remota resta sotto il controllo del gestore.
Il problema nasce perché, nel caso di una stampante 3D moderna, software, cloud e hardware non sono percepiti dagli utenti come tre mondi separati. Chi compra una macchina Bambu Lab compra anche una promessa di semplicità: invio dei file, monitoraggio, profili, fotocamera, gestione da app, integrazione con MakerWorld. Se queste funzioni passano attraverso componenti chiusi, l’utente tecnico può sentirsi escluso da una parte essenziale del prodotto.
La posizione della community: se usi l’open source, devi rispettarne lo spirito
Dall’altra parte c’è una critica di principio. Bambu Lab ha costruito il proprio slicer partendo da software open source sviluppato da altri. Per una parte della community, questo comporta non solo obblighi legali, ma anche un patto culturale: se un’azienda beneficia del lavoro aperto di PrusaSlicer, Slic3r, SuperSlicer e degli sviluppatori indipendenti, non dovrebbe chiudere le funzioni più importanti dietro componenti non verificabili o strumenti proprietari.
La questione del componente bambu_networking è centrale. Nel repository ufficiale di Bambu Studio, Bambu Lab indica che il plugin di rete è basato su librerie non libere, è opzionale e fornisce funzionalità di rete estese agli utenti. Senza quel plugin, secondo la documentazione del repository, si può comunque stampare tramite SD card dopo lo slicing.
Per i critici, però, definirlo opzionale non basta. Se una parte significativa dell’esperienza Bambu Lab dipende da quel componente, e se Bambu Studio lo carica e lo usa per login, monitoraggio, cloud, LAN, fotocamera, messaggistica, preset e telemetria, allora il plugin non sarebbe solo un accessorio separato. Jarczak sostiene che il componente è profondamente integrato nel programma e che quindi dovrebbe essere valutato come parte del “Corresponding Source” richiesto dalla AGPL.
Anche Josef Prusa, fondatore di Prusa Research, è intervenuto sul tema sostenendo che Bambu Studio violerebbe la licenza AGPL di PrusaSlicer a causa del plugin di rete chiuso. Secondo Prusa, il problema non è che Bambu Lab abbia creato un fork, ma che una parte rilevante della funzionalità resti in un “black box” non auditabile.
Il caso diventa simbolico: Rossmann, Gamers Nexus, Snapmaker e il diritto alla riparazione
La controversia non è rimasta confinata agli sviluppatori. Louis Rossmann, volto noto del movimento Right to Repair, ha ospitato una copia del codice tramite la sua FULU Foundation e ha offerto supporto economico legale allo sviluppatore. Anche Gamers Nexus ha dato sostegno pubblico alla vicenda. Snapmaker ha donato a Jarczak una macchina Snapmaker U1 basata su Klipper, presentando il gesto come supporto a sviluppatori e maker impegnati in progetti open source.
Questo allargamento del caso è significativo. La discussione non riguarda più solo Bambu Lab e OrcaSlicer. Tocca temi più ampi: diritto di modificare i prodotti acquistati, dipendenza dal cloud, software non verificabile, compatibilità con accessori di terze parti, durata del supporto e possibilità per una community di mantenere funzioni che un produttore decide di cambiare.
Il mercato delle stampanti 3D desktop si sta dividendo
Il caso Bambu Lab mette in evidenza una frattura che nel settore era già presente. Da una parte ci sono utenti che vogliono macchine semplici, veloci, automatizzate, con profili pronti, cloud, app mobile e pochi interventi manuali. Dall’altra ci sono utenti che vogliono accesso completo, firmware aperti, protocolli documentati, integrazione libera con software esterni, riparabilità e indipendenza dai server del produttore.
Bambu Lab ha costruito gran parte del proprio successo sulla prima direzione. Le sue macchine hanno reso più accessibile la stampa 3D FDM a persone che non vogliono passare ore tra calibrazione, slicer, firmware e modifiche hardware. Questa scelta ha allargato il pubblico. Ma lo stesso modello può risultare meno attraente per chi proviene dalla cultura RepRap, Voron, Klipper, Prusa, Marlin e dagli ecosistemi dove modificare la macchina è parte integrante dell’esperienza.
Il rischio è la nascita di due mercati paralleli. Uno più consumer, integrato e controllato, dove l’utente accetta limiti in cambio di semplicità. L’altro più tecnico, aperto e modificabile, dove l’utente accetta maggiore complessità in cambio di controllo.
Perché la vicenda riguarda anche chi non usa OrcaSlicer
Chi usa solo Bambu Studio potrebbe pensare che la disputa non lo riguardi. La stampante funziona, l’app funziona, MakerWorld funziona, il cloud funziona. Ma la questione è più ampia: cosa succede quando una funzione disponibile al momento dell’acquisto viene modificata o subordinata a un nuovo componente? Quali garanzie ha l’utente se il produttore cambia politica? Un prodotto connesso resta davvero sotto il controllo dell’acquirente o dipende dalle scelte del fornitore?
La stampa 3D desktop ha una storia diversa dalle stampanti 2D tradizionali. È cresciuta grazie a progetti aperti, firmware condivisi, hardware documentato, profili creati dagli utenti e miglioramenti sviluppati fuori dalle aziende. Se il settore si avvicina al modello delle stampanti 2D, con ecosistemi chiusi, servizi cloud e accessori controllati, una parte della cultura originaria della stampa 3D rischia di restare ai margini.
Questo non significa che ogni scelta di Bambu Lab sia sbagliata. La sicurezza dei dispositivi connessi è un problema reale. Una stampante 3D controllabile da remoto muove assi, scalda ugelli e piatti, usa motori, ventole e componenti elettrici. Un’infrastruttura cloud vulnerabile o sovraccaricata può creare disservizi e rischi. Bambu Lab sostiene di aver documentato interruzioni causate da picchi di traffico non autorizzato e di dover proteggere i propri server per garantire stabilità a tutti gli utenti.
Ma la sicurezza non cancella il tema della fiducia. Se un’azienda usa software open source come base per il proprio ecosistema, la community si aspetta trasparenza, dialogo e rispetto dello spirito collaborativo. Se invece la risposta percepita è una minaccia legale contro uno sviluppatore indipendente, la reazione negativa diventa quasi inevitabile.
Il nodo giuridico resta aperto
Al momento non c’è una decisione giudiziaria che stabilisca in modo definitivo chi abbia ragione. Bambu Lab sostiene che il fork contestato non fosse un normale esercizio dei diritti open source, ma un accesso non autorizzato alla sua infrastruttura. Jarczak sostiene che il suo lavoro si basava su codice pubblico e che la questione più importante riguarda la possibile non conformità AGPL del componente di rete chiuso.
La distinzione è fondamentale. Una cosa è dire: “un fork AGPL può modificare e distribuire codice”. Un’altra è dire: “quel fork ha diritto ad accedere al cloud privato di un’azienda”. Sono due domande diverse. La prima riguarda la licenza del software. La seconda riguarda accesso ai servizi, termini d’uso, sicurezza e infrastruttura.
Il problema è che nella pratica gli utenti vivono tutto come un unico prodotto: stampante, slicer, cloud, app, profili e community. Quando una parte si chiude, l’intero ecosistema sembra meno aperto.
Una lezione per tutto il settore
La vicenda Bambu Lab-OrcaSlicer è un campanello per tutti i produttori di stampanti 3D. Più le macchine diventano semplici, automatizzate e connesse, più il controllo passa dal laboratorio dell’utente ai server dell’azienda. Questo può portare vantaggi reali: onboarding più facile, meno errori, aggiornamenti coordinati, sicurezza più gestibile, supporto più uniforme. Ma comporta anche un costo: minore indipendenza, maggiore dipendenza dal produttore e meno spazio per modifiche non approvate.
Per aziende come Bambu Lab, il dilemma è trovare un equilibrio tra crescita consumer e fiducia degli utenti tecnici. Per aziende come Prusa Research, il tema è difendere un modello open source in un mercato dove la concorrenza usa basi aperte ma integra componenti proprietari. Per progetti come OrcaSlicer, la sfida è restare strumenti indipendenti senza trasformarsi in bersagli legali quando toccano funzioni sensibili dell’ecosistema.
La stampa 3D desktop non è più il territorio semiartigianale di dieci o quindici anni fa. Le macchine sono più veloci, più automatizzate e più vicine al pubblico generalista. Il caso Bambu Lab mostra che questa maturazione porta con sé una domanda scomoda: la semplicità deve per forza passare da ecosistemi più chiusi?
La risposta determinerà una parte importante del futuro del settore. Da una parte ci saranno prodotti pensati per chi vuole stampare senza sapere cosa accade sotto il cofano. Dall’altra continueranno a esistere macchine, firmware e software per chi vuole capire, modificare, riparare e controllare ogni passaggio. Il punto non è stabilire quale modello vincerà per tutti, ma evitare che l’uno cancelli l’altro.
