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.
I've always been told it's called business. But I fully agree with you. Just wanted to note that this is the current business model both with hardware and software
Without the ability to run your own code, this will be everywhere and everything.
Without some counter force of open source pushing back and offering alternatives, we'll be putting tokens in a machine to check your email. Reading email will cost 4 tokens and you'll only be able to buy them in groups of 7.
The "business" ended when the sale transaction concluded. The fact that you were the seller in that past transaction doesn't entitle you to vandalize goods that now belong to someone else.
This is just crime trying to disguise itself as legitimate business, as scams often do.
Actually not, though not in a way that makes the rest of your post incorrect.
Various laws and regulations state that the seller has responsibilities to the buyer after the initial transaction has completed, one of which Bambu might¹ be transgressing by removing features that people we lead to believe were part of the product, and could reasonably expect to remain part of the product, at the time of the sale.
--------
[1] This has not been tested in court, and I'm no lawyer, take my idea of what is the case with a requisite serving of condiment.
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.
And the function he copied over just set the UserAgent string to some hard coded values also available in the AGPL source code of BambuStudio. He didn't reverse engineer anything. Just went and looked at public code that's free to use for any purpose.
BambuLabs is probably just big mad that their "security" argument for their walled garden, weak as it was, just got publicly pantsed. I've never heard of a fucking dumber way of "securing" a service than a plaintext client-side assertion "I'm allowed to send you print jobs uwu :3"
The entire debacle is incredibly embarrassing for Bambu.
Love it; but just wait, I bet Claude surprises you this year.
"Specifically modifying" as in "not even touching that part of the code in the fork"...
Even if we take this at face value, it is irrelevant to their legal threat. They demanded the author to stop distributing software. So no they do not respect your right to be "free to do whatever you want with Bambu's AGPL'ed software.
They sent a C&D asking him to take the code down. He was and still is free to ignore that C&D. It's simply the easiest, laziest move on their part to get non-BambuStudio software off their cloud. I am sure they are working on software updates right now; their shitty, dickish C&D was simply the most expedient way to stop it.
I seriously doubt they would've taken him to court over it, and also doubt they'll sue this clout- and click-chasing Rossmann idiot either. But a C&D requires almost no effort.
Sending that lazy childish C&D still in no way violates the AGPL.
Figure I should explain:
Lie #1: “Access their network in an unauthorized fashion.”
The perfectly legal use of public AGPL code does not constitute “unauthorized access”. If they allow their AGPL product to connect, and publish that method of connection, they are not permitted to add additional restrictions on the use of said code. They are permitted to require additive code to be make itself appear unique — but that must follow the license and be part of the license as an addendum, not a retroactive afterthought.
Lie #2: Pawel “specifically modified” BambuStudio [sic.] to look like Studio.
A patently false and outright lie. Pawel used AGPL licensed code. End of story.
Assertion: “Bambu has the right to limit the software that connects to their network.”
Yes! They do! They don’t, however, get to publish the code to do so under AGPL and then claim no one else can use it. Copying and executing that code is an explicit right in AGPL. Bambu is not required to continue operating their cloud or allowing those connection. They absolutely have that right to refuse all connections and correct their mistake.
Bambu also absolutely had the right to keep their cloud access private and to provide a system library to handle the connection to their cloud without it being AGPL. That is literally the specific purpose of AGPL.
“A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.”
Bambu chose to open up access to their cloud when they published the connection method under AGPL code. They can shut down that service, issue a new firmware, and release their revised non-AGPL system library for Bambu Studio to use their cloud at any time.
What they don’t get to do, and why everyone is giving them the finger, is retroactively decide “whoopsie, I didn’t intend that” and then abuse laws to violate the license they agreed to.
Listen, you can believe what you like, but there is a reason Louis Rossman had no hesitation to host this code. That’s because anyone less afraid and with at least a little technical and legal knowledge probably would have just as high degree of certainty that Bambu will be paying their legal fees. (Louis has the added benefit of living in an Anti-SLAPP state…intentionally.)
Signal itself is released on AGPL-3.0: https://github.com/signalapp/Signal-Android so this is probably why Molly forked.
So not sure what are you talking about.
Never buying a cartridge based inkjet printer again.
https://www.techradar.com/pro/did-your-3d-printer-start-prin...
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.
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.
And many of these same people probably (and rightfully) laughed at music and movie people casting piracy as “theft”.
It is irrelevant whether the thing or feature you took away is implemented in hardware or software. Notably it is often hardware functionality but the thief uses software to restrict it.
You could perhaps argue that another property crime might better describe it such as criminal mischief or in some cases fraud. But in any case it is a crime against someone else's property.
From Louis Rossmann himself.
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.
This sounds really unpleasant to use. Maybe users just want a better UX for the local mode?
Using an AGPL violating mystery meat binary plugin that you run on your host, which potentially compromises any airgap you put around your printer (it attempts to connect to bambu servers, or did last time I checked it) and potentially your entire host.
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.
Because they have a track record of altering their website, gaslighting the community, and then getting caught through archive.org so they simply blocked it, not realizing that other archives exist and then getting caught again.
They tried to alter their warranty terms and got caught. They altered their ToS which would allow them to block prints until the printer firmware was updated. When the community got upset, they not only backpedaled but altered the associated blog post and accused everyone of spreading baseless misinformation because "it's clearly explained in this [edited, backdated] article".
That's precisely the article you linked to. See the original version:
http://archive.today/2025.01.16-173123/https://blog.bambulab...
Think about why they'd make such a request to archive.org.
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.
There’s basically no information there. Is this just a copy of the other GitHub repo that was removed and someone is trying to rebrand it as their own? Or did they do some different work?
the explanation for that is here https://youtu.be/II2QF9JwtLc
basically louis found that not using AI to design his website drastically reduced the hits he would get from google.
https://arstechnica.com/gadgets/2025/10/synology-caves-walks...
This is admittedly a bit tinfoil hat, but they wouldn't be the first company to attempt to legislate away the competition.
When it's companies based in the U.S. or EU, like Chamberlain / LiftMaster garage door openers, it's pretty obvious they plan to monetize some cloud services subscription for upgraded features beyond the free basic tier as well as probably selling consumer data.
However, the China-based companies like Bambu Lab (and many others) are more puzzling because meaningful ongoing subscription revenue seems unlikely. Especially in the case of lower-end consumer tech peripherals where the companies usually invest as little as possible in their websites, ongoing feature updates or direct end-user support. Which makes no sense if they really aspire to build long-term subscription revenue. Here's my theory: the Chinese government is quietly compelling them to require cloud connections to China-based data centers as a long-term strategy.
I'm not even saying the companies are some direct arm of the Chinese government or planting nefarious firmware. I think that's too likely to be caught if done at mass scale and it's not even necessary. As long as the cloud servers are in Chinese data centers, the Chinese government can get consumer IP addresses and usage data just from passive packet sniffing and if things turn icy with some foreign countries, they can cause a lot of turmoil simply by selectively blocking packets at the firewall to brick millions of consumer devices.
I know it maybe sounds paranoid and, to be clear, I'm not claiming Bambu Labs specifically is doing this. I actually came up with this theory before I ever heard of Bambu Labs because I have a lot of inexpensive Chinese home automation devices and was surprised by their bizarre insistence on forcing cloud connectivity despite there being no apparent business model incentive and these smaller-scale Shenzen hardware companies showing zero enthusiasm for making a real business out of cloud services. Their cloud implementations are almost invariably the bare minimum possible and seem woefully underfunded. After all, for a low-margin hardware peripheral, every dollar spent running a no-revenue cloud after the sale is pure overhead in a business that live or dies by pennies. It's almost like requiring a cloud connection is an export tax the company is paying just to be left alone to sell their hardware overseas.
For home automation gear, cloud-connectivity is a non-starter in my book. In some cases, it's literally built into our walls, so I only buy devices which will work on a local-only subnet or on which I can install open source firmware like Tasmota or ESPHome.
Some of the proposed 3d printer laws will require printers being sold to be capable of evaluating what you are using them for and blocking “bad” usages. I’m not aware of any such legislation around firearms.
So to say you spend significantly less money for a product that will be changed whenever bambu sees fit to whatever extend they see fit.
I regret my bambu purchase a lot. I have to keep up with all the ways bambu wants to lock in my hardware and take it basically away from me.
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.
I thought that was the point, that people didn't want to be tethered to their servers?
There are many reasons one might prefer OrcaSlicer over Bambu Studio. One might be perfectly fine using Bambu's cloud services while preferring OrcaSlicer for different reasons; this is for those people.
Others might not want to use Bambu's cloud services at all; OrcaSlicer as it currently exists is fine for them.
i bought the dang thing, let me decide how I use it.
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??
Just sharing to let other know how they can cope running in LAN / Dev mode.
the real goal here as Louis stated himself is this https://consumerrights.wiki/w/DMCA_Section_1201
I don’t mind the sd card thing, also happy with my bottom of the barrel ender 3.
I get it. The convenience of networking - when it works FOR the customer - is great.
But networking controlled by corporations is a path to enshittification.
Bambu is not (never has been?) targeting 3D printing hobbyist but everyday people; and for them cost/reliability is more important than running your custom slicer. Until there is a serious competitor that has a polished and cheap printer, Bambu can alienate all of the open source community and still be fine.
Bambu is following Synology's footsteps here. And just like Synology, they will wake up to press at some point and common wisdom "don't buy Synology, the elite moved off when Green came out and now the rest are leaving too".
I own the most expensive Bambu (The H2C) - and even I am willing to admit that the snap maker is a great printer, and a better technical path in someways then the H2C vortek system for anyone who doesn't care about engineering filament
Most commenters here will value the openness of Prusa, but most lambda users will have limited budgets that Prusa does not cover. The U1 is a great attempt at taking on BambuLab head front, with interesting features at a reasonable price point.
In the end, a lot of people (including here) are using an iPhone even though it's locked down to a higher degree. Some people like a walled garden, some don't care.
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.
Like Adobe's 'creative' software and Onshape, they are working as hard as possible to make YOU pay more to have less.
But when it was online, I never checked the app for failed prints. If the print has failed, I'll find out when I'm near enough to it to do something about it.
When offline, it amused me when there was a "hairball" and the printer detected it advising "AI Detecting Print Error".
At what level does an image analysis algorithm become "AI"?
Prusa.
It’s like saying a bicycle is a serious contender to a train, they both have kind of similar things going on but you’d have to be insane to suggest that they do as good of a job as one another at the things people actually want to achieve.
i'm mostly printing small mechanical parts and i can't say i have any complaints, i assume a modern prusa would be much better, surely there are other FDM printers that are good?
