Bambu Lab Took From Open Source, Then Locked the Door Behind Them

What happened

Jeff Geerling — open source advocate, Ansible author, and one of the most-watched voices in the 3D printing community — published a detailed teardown of Bambu Lab's relationship with open source software. The core accusation: Bambu Lab built its rapid ascent in the consumer 3D printer market on the backs of GPL-licensed projects, then systematically closed the door behind them.

The projects in question are foundational to modern 3D printing. Klipper (GPLv3), the high-performance printer firmware by Kevin O'Connor. Marlin (GPLv3), the most widely deployed open source printer firmware in existence. PrusaSlicer, itself a fork of Slic3r (AGPLv3), the slicer that turns 3D models into printer instructions. Bambu Lab's own Bambu Studio is a direct fork of PrusaSlicer, and they do release its source code under AGPL — technically satisfying the license.

But technical license compliance and honoring the open source social contract are two very different things. Bambu Lab used these projects to shortcut years of R&D, shipped hardware that quickly became the price-performance leader in consumer 3D printing, and then introduced firmware lockdowns, cloud authentication requirements for LAN-mode printing, and restrictions on third-party modifications that effectively make their ecosystem proprietary.

Why it matters

This isn't just a 3D printing story. It's a template that keeps repeating across hardware and infrastructure.

The pattern is straightforward: a well-funded company forks open source software, ships a polished product that undercuts incumbents on price, builds market share, and then progressively locks down the stack once customers are invested in the ecosystem. The open source community provides the R&D subsidy; the company captures the value; and the original maintainers get nothing but a competitor who used their own code to do it.

Bambu Lab's specific moves follow a textbook escalation. First, firmware updates that removed features users relied on. Then, mandatory cloud account authentication — even for printing over your local network, on hardware you own, in your own home. Then restrictions on third-party firmware modifications. Each step individually seems minor. In aggregate, they transform an open-source-derived product into a locked-down appliance.

The community reaction, reflected in a Hacker News thread that hit 477 points, breaks along predictable lines. One camp argues this is the market working as designed: Bambu Lab complied with the license text, users voted with their wallets, and if people care about openness they should buy from Prusa or build a Voron. The other camp — and this is where Geerling lands — argues that license compliance is necessary but not sufficient. The social contract of open source includes an expectation of reciprocity: if you build on community infrastructure, you contribute back, or at minimum you don't weaponize that infrastructure against the community that created it.

Josef Prusa and the team behind PrusaSlicer have been vocal about this dynamic for years. They watch a competitor fork their slicer, use it to sell hardware that undercuts Prusa's printers on price, and then layer proprietary restrictions on top. Prusa invests in open source because they believe in the ecosystem. Bambu Lab invests in open source because the license required it.

The license gap

Here's the uncomfortable technical reality: the GPL family of licenses was designed for a world where software was the product. GPLv3 requires you to share source code for derivative works. AGPLv3 extends that to network services. But neither was designed for a world where the real value capture happens in proprietary firmware running on locked-down hardware that users can't modify.

Bambu Lab releases Bambu Studio source code. That's the slicer — the desktop app. The firmware running on the printer itself, the cloud authentication layer, the increasingly restrictive update pipeline — none of that is covered by the slicer's AGPL license. The GPL's copyleft provisions stop at the binary boundary, and hardware companies have learned to draw that boundary very carefully.

This is the same structural gap that allowed TiVo to ship GPL-licensed Linux on hardware with locked bootloaders — the original "Tivoization" that prompted GPLv3's anti-lockdown provisions. But GPLv3's installation information requirements are narrowly drafted and have never been seriously tested in court against a hardware vendor with competent lawyers.

Some commenters in the HN discussion pointed to the Server Side Public License (SSPL) and Business Source License (BSL) as examples of the open source world trying to close these gaps. But those licenses solve a different problem (cloud service providers reselling open source as-a-service) and come with their own controversial trade-offs. There's no widely-adopted license that specifically addresses the hardware-firmware lockdown pattern.

What this means for your stack

If you maintain an open source project that hardware vendors depend on, this story is a direct warning. The GPL gives you less protection than you think. Your options are: accept that commercial adoption means some companies will extract value without reciprocating, add license terms that restrict commercial use (and lose your "open source" designation per OSI), or build community norms and public pressure as your enforcement mechanism.

Geerling is effectively choosing the third option — using his substantial platform to make Bambu Lab's behavior visible and costly in reputation terms. Whether that works depends on whether enough buyers care about open source principles to change purchasing decisions. The 3D printing market suggests they don't, at least not yet: Bambu Lab's sales have continued to grow despite repeated controversies.

For developers building on open source dependencies more broadly, the lesson is about evaluating ecosystem risk. When you adopt a tool maintained by a single commercial entity, you're betting on that entity's continued goodwill. That bet has a specific failure mode: the entity captures enough market share to change the terms. This isn't hypothetical — it's the Redis story, the Elasticsearch story, the HashiCorp story, and now the Bambu Lab story, each playing out at a different layer of the stack.

If you're building hardware products on open source firmware, consider this the canonical example of how not to manage community relationships. The short-term savings from forking GPL code are real. The long-term cost of a reputation as an open source bad actor is harder to measure but compounds over time, especially as your engineering hiring pipeline increasingly consists of developers who care about these things.

Looking ahead

The Bambu Lab saga isn't going to resolve cleanly. The company is too successful and the license enforcement tools are too weak for this to end in a dramatic courtroom reversal. What it will do is accelerate two trends: more open source maintainers exploring non-traditional licenses (CockroachDB-style BSL, Elastic-style dual licensing), and more hardware communities investing in fully open alternatives like Voron and RatRig that can't be captured by a single vendor. The social contract Geerling describes is real, but it runs on trust — and once a company demonstrates it will exploit that trust for competitive advantage, the only durable fix is architecture that removes the need for trust entirely.