Geerling documents that Bambu Lab's printers run firmware derived from Marlin, a GPL v3 project, which requires releasing modified source code. Despite years of community pressure, Bambu Lab has never complied. He frames this as not a technicality but a fundamental violation of the license that made their products possible.
Geerling argues the GPL non-compliance isn't isolated — it sits alongside mandatory cloud authentication for LAN printing, encrypted firmware that prevents inspection, and a walled-garden slicer ecosystem. The pattern shows a company systematically removing user autonomy over hardware they purchased.
Geerling emphasizes the hypocrisy: Bambu Lab's own slicer was forked from PrusaSlicer, and OrcaSlicer was forked from Bambu's slicer — yet the company steers users away from open alternatives. Marlin represents over a decade of contributions from hundreds of developers whose work Bambu Lab commercialized without giving back.
Submitted the story with strong community endorsement (1247 points), signaling broad agreement that Bambu Lab is taking from the open source commons without contributing back — a violation of the social contract that underpins collaborative hardware development.
Jeff Geerling — hardware tinkerer, Ansible maintainer, and one of the most-watched voices in open source hardware — published a detailed breakdown of how Bambu Lab has systematically violated the open source social contract that made its products possible.
Bambu Lab's printers run firmware derived from Marlin, a GPL v3-licensed open source project that powers the majority of consumer 3D printers. The GPL v3 is explicit: if you distribute modified versions of GPL code in a product, you must make your modified source available to recipients under the same license. Bambu Lab has not done this. Despite repeated community requests and years of pressure, the company has failed to release the source code for its firmware modifications.
This isn't a technicality dispute. Marlin is one of the most important open source projects in desktop manufacturing. Hundreds of contributors have spent over a decade building a firmware stack that handles motion planning, thermal management, and hardware abstraction for 3D printers. Bambu Lab took that work, built a premium product line around it, and locked the door behind them.
The GPL non-compliance doesn't exist in isolation. It's part of a broader pattern that Geerling and others have documented over the past two years.
Bambu Lab has progressively restricted what owners can do with printers they've purchased. The company introduced mandatory cloud authentication for LAN printing, meaning your printer phones home to Bambu's servers even when it's sitting on your desk three feet away. They moved to encrypted firmware updates that prevent users from inspecting or modifying the code running on hardware they own. And they've built a walled-garden slicer ecosystem that steers users away from open alternatives like PrusaSlicer and OrcaSlicer — despite the fact that OrcaSlicer itself was originally forked from Bambu's own slicer, which was forked from PrusaSlicer, which was forked from the open source Slic3r project.
The irony is structural: Bambu Lab's entire software stack exists because of open source, yet the company treats openness as a vulnerability to be patched rather than a principle to uphold.
The community response has been fierce. On Hacker News, the post generated over 1,200 points — a signal that this isn't niche 3D printing drama but a story that resonates with developers across domains. The frustration isn't just about firmware source code. It's about a company that used open source as a springboard, captured market share with genuinely good hardware, and is now pulling up the ladder.
Every few years, the developer community re-learns the same lesson: the GPL's copyleft provisions exist precisely for this scenario. Companies that consume permissively-licensed or copyleft code without reciprocating aren't just being ungrateful — in the case of GPL, they're breaking the law.
The GPL is not a gentleman's agreement. It's a copyright license with teeth, and it's been enforced successfully in court multiple times. The Software Freedom Conservancy and the Free Software Foundation have both pursued GPL enforcement actions against hardware companies, and they've won. The question isn't whether Bambu Lab is violating the GPL — the community consensus on that is clear — but whether anyone with standing will pursue enforcement.
Geerling's post frames this as a "social contract" issue, and that framing matters. The social contract in open source is simple: you can use the code, but you play by the rules. When a company worth hundreds of millions of dollars decides the rules don't apply to them, it poisons the well for every other hardware startup that wants to build on open source foundations. Contributors start asking why they should volunteer their time if the primary beneficiary is a company that won't even release its modifications.
This dynamic has played out before. It's why the Linux kernel's GPL enforcement has been so important to the embedded industry. It's why Elastic, MongoDB, and HashiCorp moved away from permissive licenses — they watched cloud providers consume their work without contributing back and decided the social contract had failed. The difference is that the GPL was specifically designed to prevent this outcome. Bambu Lab isn't exploiting a loophole; they're ignoring the license entirely.
If you ship products that incorporate GPL-licensed code, Bambu Lab is a cautionary tale in two directions.
First, the compliance side: GPL compliance isn't optional, and "nobody has sued us yet" is not a legal strategy. The bar is straightforward — make your modified source available, include the license text, and don't add restrictions that prevent recipients from exercising their GPL rights. If you're building on Marlin, Linux, GCC, or any other GPL project, your legal team should be auditing compliance quarterly, not annually.
Second, the community side: even if you're using permissively-licensed code (MIT, Apache, BSD) where there's no legal obligation to contribute back, the Bambu Lab situation shows how fast community goodwill can evaporate. Developers have long memories. The companies that thrive in open source ecosystems are the ones that contribute upstream, not the ones that extract value and build moats. Bambu Lab makes excellent hardware — by most accounts, the X1C is the best consumer 3D printer on the market — but their brand is now synonymous with open source exploitation in the developer community. That's a reputation that's expensive to repair.
For developers who own Bambu printers, the practical implications are real. The lock-down trajectory suggests that future firmware updates may further restrict third-party software, LAN-only operation, and user modification. If you depend on open slicer workflows or local-only printing for security reasons, it may be time to evaluate alternatives from Prusa, Creality, or the growing ecosystem of fully open designs like the Voron project.
The elephant in the room is enforcement. The GPL is only as strong as the willingness of copyright holders to enforce it. Marlin is a community project with hundreds of contributors, and coordinating a legal action requires someone with both standing (copyright ownership of contributed code) and resources (legal fees) to pursue it.
The Software Freedom Conservancy has signaled interest in 3D printer GPL compliance before. If Geerling's post generates enough momentum — and a 1,200-point Hacker News discussion suggests it might — formal enforcement proceedings are plausible. Bambu Lab's response, or lack thereof, in the coming weeks will be telling.
Bambu Lab has a choice: comply with the GPL, release their firmware source, and rebuild community trust — or continue down the lock-down path and face both legal risk and a community that's actively building around them. The 3D printing ecosystem is too vibrant and too rooted in open source culture for a single company to wall-garden its way to dominance indefinitely. The open source social contract is enforced not just by lawyers, but by the collective decision of thousands of developers to contribute — or to stop contributing — to the ecosystem a company depends on. Bambu Lab's hardware is excellent. Their relationship with the community that made it possible is not.
This sentence in Bambu Lab's blog post is wild:> We have documented incidents of service outages caused precisely by spikes in unauthorized traffic - overwhelming the servers, causing service disruptions affecting everyone. The cost was instability felt by all users.So it's a problem th
Funny how fast people forget. LAN mode was NOT part of their original plan until outrage like this happened last time. They shifted their course and changed their blog post after. Putting pressure as a customer is how you steer company’s direction.
"It pretended to be the official client" is not a security argument if the mechanism was client-supplied metadata.That’s not impersonation. That’s Bambu discovering that user agents are not authentication.
I am an outsider on the details of the Bambu software requiring users to go through their servers in China and the closing of their software.Still I suspect it is about spying in wartime, Bambu printers are at the core of the Ukrainian war effort, the main reason even Ukraine is winning since januar
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Full disclosure: I've never owned a Bambu because I've never loved the idea of a "closed" ecosystem 3D printer, however I have used them, and am very familiar with the 3d printing space beyond Bambu.For anyone considering alternatives: You should know that almost all other 3D pri