If Bambu Lab responds to this criticism with lawyers instead of clear technical answers, it will only make the forced cloud requirement look more suspicious.
To me, this is an obvious security risk. These printers are often used in labs, startups, engineering teams, and potentially even government environments. If print data, models, logs, or usage patterns are routed through a company controlled infrastructure, that creates a real opportunity for corporate espionage or data harvesting.
I would not be surprised if Bambu Lab eventually faces the same level of scrutiny that Huawei network devices did.
This looks to be a clone of the prior state of the repository that caused all the Bambu drama earlier this week.
I did a ton of research because I didn't understand what people wanted here, and this is what's going on:
Right now, Bambu have adjusted their system into two modalities:
* "default" or "Cloud" mode, where you get an app, remote monitoring, but you have to use Bambu Studio or Bambu Connect to send prints. They implemented this by adding cloud auth to their "internal API;" the client application has to get a token from Bambu's servers, even if the request it eventually makes is a "local" one.
* LAN / Developer mode, where the device displays a token and you put it into your app. This disables all of the remote monitoring but in exchange, clients can send prints locally.
What users want is to "have their cake and eat it too;" they want the local token authentication _and_ the cloud authentication enabled at the same time. This isn't actually possible, so this plugin approximates it by emulating the interface to the cloud authentication to make the "Bambu Network" cloud RPC calls from a local slicer (one of these calls is a local_print call, so ostensibly this allows you to send prints without running them through the cloud, although with all of the online functionality still enabled and required, this seems like a pretty brave thing to trust).
Personally, I find the Bambu reaction distasteful, and there's an argument that the offline mode only exists due to similar outrage, but I don't see the current system as particularly bad and find the appetite to restore "untrustworthy" cloud functionality a bit amusing.
There are two reasons to be mad here and you only covered one. The first is that Bambu is trying to remove (for the 2nd time) features from existing printers.
The 2nd thing, and the reason the linked repo is now hosted by Louis Rossman (YouTuber / Consumer Rights guy) is that Bambu are abusing the AGPL license of the original slicer code. TL;DR is that Bambu Slicer is a fork of an AGPL lineage of similar tools. The gatekeeper of the cloud features hosted by Bambu was a user agent string embedded in the AGPL code. The original dev of the linked repo just copied and pasted AGPL code, and Bambu sent a cease and Desist. At least Louis Rossman believes that violates the AGPL terms against additional restrictions which is why he is hosting the repo, because the original dev was chilled from wanting to deal with the legal threats.
I have an Ender3 that I use plugging in a microsd card to do prints with. What am I missing here? Seems like you can do the same with these printers. People want to use the cloud?
A lot of the distrust toward Bambu is because they originally announced cloud auth would be required even for printing locally in LAN mode, and only backpedalled on that when they saw the backlash.
Critical Operations That Require Authorization
The following printer operations will require authorization controls:
Binding and unbinding the printer.
Initiating remote video access.
Performing firmware upgrades.
Initiating a print job (via LAN or cloud mode).
Controlling motion system, temperature, fans, AMS settings, calibrations, etc.
It was a mistake by BambuLab to piss off and alienate the community. They poked the bear; stung the bee; squashed the frog. This is literally the Barbara Streisand effect in the modern era. Now people are watching. Reputation went out the window already: "If they can sue one of us, they can sue all of us". (Well, threaten to sue at the least, aka applying financial pressure on that developer.)
Just make sure never, ever to buy from them again.
It's the same story as Synology with their forced reliance on specific hard drives.
As long as there are still other providers out there...
Reminder about the way Ubiquiti does this, as a vendor who wanted to provide users remote access to their own devices behind NAT: Unifi Cloud handles the auth and connection brokerage through a public portal, but you’re then connected straight to your own gear using your web browser (or one of the apps, if you choose). I can even turn all this off if I want to handle the remote access side of it myself.
Ubiquiti really should be the model for every company selling hardware today.
Their business model is a straightforward "sell a good product at a reasonable price" approach, and they seem to be quite successful at it without needing to resort to gimmickry, subscription fees, or other even less savory ways of monetizing other people's activities.
I considered buying bambu lab A1, bout watching this and previous dramas I rather go with different vendor. Are there any good alternatives for newcomers? I like hacker nature and openness of Prusa, but I’m worried if it is good printer as a first one…
It's maddening that quite a few people are jumping to defend Bambu here.
Principally if you sell a device with a certain functionality and you later modify that device later to remove that functionality that is called theft. It does not matter the slightest bit whether you break into someone's house to physically alter the device or whether you remotely install a malicious software update to do that.
But what's even more insane here is that some people are claiming that BambooLabs would somehow have the right to do this, because while BambooLab might not have the right to limit the hardware they already sold (which they did and these people just pretend did not happen) they have the right to limit their printer client software under the license conditions they impose on it from the beginning, when their printer client is literally a modification of AGPL licensed software. The entire point of the GPL is to prevent people like BambooLabs from doing exactly this. The AGPL is literally the single license with the most restrictions on BambooLabs to ensure that the users of the software — the customers — do not have any restrictions in what they can do with it.
Some people are seeing this situation and just decide to side with the company against their customers on imposing restrictions on an already sold product after the sale and they are literally making shit up to justify it.
Edit: For people who do not know what this is about: Someone modified AGPL software to reenable features of these 3D printers that BambooLabs stole after the sale and BambooLabs sent a legal threat to them to stop distributing the software.
> if you sell a device with a certain functionality and you later modify that device later to remove that functionality that is called theft.
It could be argued that it is not theft by various devious uses of legalise¹.
Personally I'd go with calling it, at best, deceptive sales practices (on the assumption that they knew they'd be moving this way long before they did), or possibly outright fraud if I'm in a less generous mood.
[FYI: Bambu A1 user for nearly two years, also have a Snapmaker U1, if I buy anything else it won't be Bambu unless their attitudes change. The A1/A1mini are still two of the best budget beginner printers IMO, though some clones come close, and I do recommend them if asked but with caveats around potential lock-in later and not believing promises due to a history of changed online posts, deliberately excluded from the WayBackMachine, and what to my understanding is an AGPL breach]
--------
[1] “There is a way to use the feature, so it isn't an attempt to permanently deprive”, or “you agreed to the possibility of such changes in the EULA”, and so on.
There's a class of person who's so fundamentally incapable of ignoring authority figures that they'll defend even the most pathetic positions possible.
So the C&D was stupid, and so is how their network works apparently.
Fundamentally, what Bambu are saying is that they have a right to restrict what software accesses their network. The C&D was allegedly sent to stop distribution of software that was written to access their network in an unauthorized fashion (Allegedly according to their ToS).
AGPL covers source code. It does not cover who can access what network with AGPL'ed software.
Thus Bambu - like it or not - have a right to limit what software accesses their cloud. You are still free to do whatever you want with Bambu's AGPL'ed software. But they don't have to let you on their network if they don't want to.
With that out of the way, sending a C&D is a pretty regarded way to accomplish this. The correct way would be to sniff out which clients are using 'real' Bambu Studio and which aren't. However according to Bambu, Pawel specifically modified BambuStudio (ya know, because they haven't violated the AGPL, because he is free to do that) to make it look like Studio.
I can only assume that actually locking down their network for real would require every Bambu printer to have a firmware update that would add some sort of signed encryption to access the cloud features. The C&D appears to be a shitty action prior to a huge undertaking.
I do wonder exactly how secure their super spendy "Enterprise" X1E printer could possibly be given how easily Pawel was able to make a fork work on their cloud.
As to your second paragraph about functionality and theft, 1) I can still print from Bambu's cloud with my Bambu printer so I don't think they've changed any functionality, and I can still use Orca in LAN mode. and 2) designed obsolescence exists.
I disagree with your assertion that because forks were able to access cloud functionality previously, that Bambu must maintain that functionality ad infinitum. My opinion would change if anyone showed me where previously they were promoting how any third party apps could access their cloud.
> It's maddening that quite a few people are jumping to defend Bambu here.
I haven’t read each of the hundreds of comments, but I haven’t seen anyone defending Bambu really.
What I have seen is a lot of comments trying to correct all of the bad information, which might look like defending Bambu labs to those who came into this thread not understanding what the problem was. Many of the angry comments think that this is a fork to enable LAN mode or remove a cloud requirement, but this is actually the opposite. It’s code to splice the Bambu cloud code from official Linux slicer into OrcaSlicer, which is a fork of the Bambu slicer.
This is allowed and should be defended. Bambu was wrong to try to threaten it because, as I understand it, this was a matter of merging some of their AGPL code into a fork of their AGPL code. Fair game.
I do think the angry mob of people who don’t own Bambu printers who have jumped on this issue is starting to become their own worst enemy, though. There are a lot of confused Bambu printer owners in this thread trying to understand what’s going on and getting the wrong explanations delivered by people who I would guess have no understanding of the situation other than being brought here by some YouTube videos that didn’t really explain the matter well either. There’s also apparent a foundation getting involved which has a vibecode AI slop website that doesn’t explain anything but it getting shared as an explanation, and this GitHub repo was also uploaded by someone who doesn’t understand git or GitHub because they uploaded a copy of the forked code as a single commit instead of keeping git history or introducing it as a real fork.
I suggest that this repo not be used by anyone because it’s not good practice to run a fork without verifying the provenance and checking the changes, which cannot be done when the repo is nothing more than an upload of a copy of some source with no link to the base repo and no history of changes. There are several other actual copies of the fork on GitHub and linked throughout this thread that would be better sources.
> Principally if you sell a device with a certain functionality and you later modify that device later to remove that functionality that is called theft.
Factually, it is not. Maybe you think it should be prohibited -- as I also do.
But the proper legalese here is likely a consumer protection regulation.
I run Bamboo Printer on it's own wifi VLAN in developer mode / LAN only mode, and been developing my own Flutter App to monitor video and MQTT status in this state. I am also progressing towards filament management and uploading / printing from SD Card.
Just sharing to let other know how they can cope running in LAN / Dev mode.
Genuine question here, is the Chinese government telling Bambu Lab what to do? The longer Bambu keep shooting themselves in the foot, and then doubling down on their mistakes, it really makes me start to wonder if the whole thing isn't being controlled by the party in service of the PRC.
I can't think of a scenario in which they aren't going to subject themselves to more Streisand effect visibility every time they file an obviously bogus AGPL claim, so why do it??
How much of this action by Bambu is driven by the fact that they're being threatened from Washington DC that they will have to be able to prevent people from printing "illegal" items, like gun parts, in the future?
38 comments
[ 2.9 ms ] story [ 58.6 ms ] threadhttps://www.youtube.com/watch?v=1jhRqgHxEP8
To me, this is an obvious security risk. These printers are often used in labs, startups, engineering teams, and potentially even government environments. If print data, models, logs, or usage patterns are routed through a company controlled infrastructure, that creates a real opportunity for corporate espionage or data harvesting.
I would not be surprised if Bambu Lab eventually faces the same level of scrutiny that Huawei network devices did.
I thought that was the point, that people didn't want to be tethered to their servers?
I did a ton of research because I didn't understand what people wanted here, and this is what's going on:
Right now, Bambu have adjusted their system into two modalities:
* "default" or "Cloud" mode, where you get an app, remote monitoring, but you have to use Bambu Studio or Bambu Connect to send prints. They implemented this by adding cloud auth to their "internal API;" the client application has to get a token from Bambu's servers, even if the request it eventually makes is a "local" one.
* LAN / Developer mode, where the device displays a token and you put it into your app. This disables all of the remote monitoring but in exchange, clients can send prints locally.
What users want is to "have their cake and eat it too;" they want the local token authentication _and_ the cloud authentication enabled at the same time. This isn't actually possible, so this plugin approximates it by emulating the interface to the cloud authentication to make the "Bambu Network" cloud RPC calls from a local slicer (one of these calls is a local_print call, so ostensibly this allows you to send prints without running them through the cloud, although with all of the online functionality still enabled and required, this seems like a pretty brave thing to trust).
Personally, I find the Bambu reaction distasteful, and there's an argument that the offline mode only exists due to similar outrage, but I don't see the current system as particularly bad and find the appetite to restore "untrustworthy" cloud functionality a bit amusing.
The 2nd thing, and the reason the linked repo is now hosted by Louis Rossman (YouTuber / Consumer Rights guy) is that Bambu are abusing the AGPL license of the original slicer code. TL;DR is that Bambu Slicer is a fork of an AGPL lineage of similar tools. The gatekeeper of the cloud features hosted by Bambu was a user agent string embedded in the AGPL code. The original dev of the linked repo just copied and pasted AGPL code, and Bambu sent a cease and Desist. At least Louis Rossman believes that violates the AGPL terms against additional restrictions which is why he is hosting the repo, because the original dev was chilled from wanting to deal with the legal threats.
I'm not sure why their entire domain has been excluded from archive.org but you can still see the original post for now: https://blog.bambulab.com/firmware-update-introducing-new-au...
--
Critical Operations That Require Authorization The following printer operations will require authorization controls:
Binding and unbinding the printer. Initiating remote video access. Performing firmware upgrades. Initiating a print job (via LAN or cloud mode). Controlling motion system, temperature, fans, AMS settings, calibrations, etc.
Other vendors take note !
Their business model is a straightforward "sell a good product at a reasonable price" approach, and they seem to be quite successful at it without needing to resort to gimmickry, subscription fees, or other even less savory ways of monetizing other people's activities.
Wonder how Bambu can prevent this kind of forks, where no code - just instructions to AI on how to build a network plugin from scratch.
Principally if you sell a device with a certain functionality and you later modify that device later to remove that functionality that is called theft. It does not matter the slightest bit whether you break into someone's house to physically alter the device or whether you remotely install a malicious software update to do that.
But what's even more insane here is that some people are claiming that BambooLabs would somehow have the right to do this, because while BambooLab might not have the right to limit the hardware they already sold (which they did and these people just pretend did not happen) they have the right to limit their printer client software under the license conditions they impose on it from the beginning, when their printer client is literally a modification of AGPL licensed software. The entire point of the GPL is to prevent people like BambooLabs from doing exactly this. The AGPL is literally the single license with the most restrictions on BambooLabs to ensure that the users of the software — the customers — do not have any restrictions in what they can do with it.
Some people are seeing this situation and just decide to side with the company against their customers on imposing restrictions on an already sold product after the sale and they are literally making shit up to justify it.
Edit: For people who do not know what this is about: Someone modified AGPL software to reenable features of these 3D printers that BambooLabs stole after the sale and BambooLabs sent a legal threat to them to stop distributing the software.
It could be argued that it is not theft by various devious uses of legalise¹.
Personally I'd go with calling it, at best, deceptive sales practices (on the assumption that they knew they'd be moving this way long before they did), or possibly outright fraud if I'm in a less generous mood.
[FYI: Bambu A1 user for nearly two years, also have a Snapmaker U1, if I buy anything else it won't be Bambu unless their attitudes change. The A1/A1mini are still two of the best budget beginner printers IMO, though some clones come close, and I do recommend them if asked but with caveats around potential lock-in later and not believing promises due to a history of changed online posts, deliberately excluded from the WayBackMachine, and what to my understanding is an AGPL breach]
--------
[1] “There is a way to use the feature, so it isn't an attempt to permanently deprive”, or “you agreed to the possibility of such changes in the EULA”, and so on.
Fundamentally, what Bambu are saying is that they have a right to restrict what software accesses their network. The C&D was allegedly sent to stop distribution of software that was written to access their network in an unauthorized fashion (Allegedly according to their ToS).
AGPL covers source code. It does not cover who can access what network with AGPL'ed software.
Thus Bambu - like it or not - have a right to limit what software accesses their cloud. You are still free to do whatever you want with Bambu's AGPL'ed software. But they don't have to let you on their network if they don't want to.
With that out of the way, sending a C&D is a pretty regarded way to accomplish this. The correct way would be to sniff out which clients are using 'real' Bambu Studio and which aren't. However according to Bambu, Pawel specifically modified BambuStudio (ya know, because they haven't violated the AGPL, because he is free to do that) to make it look like Studio.
I can only assume that actually locking down their network for real would require every Bambu printer to have a firmware update that would add some sort of signed encryption to access the cloud features. The C&D appears to be a shitty action prior to a huge undertaking.
I do wonder exactly how secure their super spendy "Enterprise" X1E printer could possibly be given how easily Pawel was able to make a fork work on their cloud.
As to your second paragraph about functionality and theft, 1) I can still print from Bambu's cloud with my Bambu printer so I don't think they've changed any functionality, and I can still use Orca in LAN mode. and 2) designed obsolescence exists.
I disagree with your assertion that because forks were able to access cloud functionality previously, that Bambu must maintain that functionality ad infinitum. My opinion would change if anyone showed me where previously they were promoting how any third party apps could access their cloud.
From Louis Rossmann himself.
I haven’t read each of the hundreds of comments, but I haven’t seen anyone defending Bambu really.
What I have seen is a lot of comments trying to correct all of the bad information, which might look like defending Bambu labs to those who came into this thread not understanding what the problem was. Many of the angry comments think that this is a fork to enable LAN mode or remove a cloud requirement, but this is actually the opposite. It’s code to splice the Bambu cloud code from official Linux slicer into OrcaSlicer, which is a fork of the Bambu slicer.
This is allowed and should be defended. Bambu was wrong to try to threaten it because, as I understand it, this was a matter of merging some of their AGPL code into a fork of their AGPL code. Fair game.
I do think the angry mob of people who don’t own Bambu printers who have jumped on this issue is starting to become their own worst enemy, though. There are a lot of confused Bambu printer owners in this thread trying to understand what’s going on and getting the wrong explanations delivered by people who I would guess have no understanding of the situation other than being brought here by some YouTube videos that didn’t really explain the matter well either. There’s also apparent a foundation getting involved which has a vibecode AI slop website that doesn’t explain anything but it getting shared as an explanation, and this GitHub repo was also uploaded by someone who doesn’t understand git or GitHub because they uploaded a copy of the forked code as a single commit instead of keeping git history or introducing it as a real fork.
I suggest that this repo not be used by anyone because it’s not good practice to run a fork without verifying the provenance and checking the changes, which cannot be done when the repo is nothing more than an upload of a copy of some source with no link to the base repo and no history of changes. There are several other actual copies of the fork on GitHub and linked throughout this thread that would be better sources.
Factually, it is not. Maybe you think it should be prohibited -- as I also do.
But the proper legalese here is likely a consumer protection regulation.
Just sharing to let other know how they can cope running in LAN / Dev mode.
https://github.com/richyo-codes/boom-print
I can't think of a scenario in which they aren't going to subject themselves to more Streisand effect visibility every time they file an obviously bogus AGPL claim, so why do it??