Prusa, the original author of PrusaSlicer, argues Bambu has been out of compliance since the fork began. He cites a documented pattern: BambuStudio releases lagging the public repo, missing build instructions, third-party modifications shipped in binaries without source, and UI/engine changes appearing in installers before (or never) hitting GitHub.
By submitting Prusa's thread under the framing 'BambuStudio has been violating PrusaSlicer AGPL license since their fork,' the submitter endorses the position that this is a clear and ongoing license violation rather than an open question. The 250-point score reflects HN community resonance with that framing.
The editorial emphasizes that AGPL-3.0 is 'not the MIT license with extra steps' and requires that every recipient of a modified binary receive the complete corresponding source, including build scripts and installation information. 'We'll push to GitHub when we get around to it' is explicitly called out as failing the license's actual requirements.
On May 22, Josef Prusa — founder of Prusa Research and the original author of PrusaSlicer — went public on X/Twitter with a pointed accusation: Bambu Lab's BambuStudio, the slicer that ships with every Bambu printer, is a fork of the AGPL-3.0-licensed PrusaSlicer, and Bambu has been out of compliance with that license since the fork began. The thread, mirrored on xcancel and surfaced on Hacker News with 250 points, lays out a pattern Prusa says his team has documented internally for years: BambuStudio releases that lag the public source repo, missing build instructions, third-party modifications shipped in binaries without the corresponding source, and — crucially — UI and engine changes that appear in the installer before they appear (if at all) on GitHub.
The relationship between the two codebases is not in dispute. BambuStudio's own README acknowledges it is derived from PrusaSlicer, which is itself derived from Slic3r. What Prusa is alleging is not that Bambu forked the code — that's explicitly allowed — but that they've been distributing modified binaries to hundreds of thousands of customers without honoring the AGPL's source-release obligations on the timeline and in the form the license actually requires.
Bambu has not, as of this writing, issued a substantive public response. Their GitHub repo for BambuStudio is active, but Prusa's claim is specifically that what's *in* the repo doesn't match what's *in* the shipped installer — a gap that, if accurate, is the textbook failure mode for GPL-family compliance.
The AGPL-3.0 is not the MIT license with extra steps. It requires that anyone who distributes — or, for network use, runs — a modified version make the Complete Corresponding Source available to every recipient, including build scripts, installation information, and any modifications to libraries the program depends on. "We'll push to GitHub when we get around to it" does not satisfy this. Neither does shipping a binary today and a tarball six months later with the build system stripped out. The FSF has been explicit on this for two decades: the source you publish must be sufficient to rebuild the binary you shipped, at the time you shipped it.
The hardware angle matters here. Bambu makes consumer 3D printers and ships closed-source firmware on the printer itself — that part is theirs to do as they like. But BambuStudio runs on the user's PC and is the daily interface for slicing models, and that's the artifact derived from Prusa's AGPL code. The pattern Prusa describes — taking an open-source project, building a proprietary product experience around it, and treating the upstream license as a suggestion — is one the hardware industry has gotten away with for a long time, partly because the original authors rarely have the appetite or budget to litigate. Prusa Research does. That asymmetry is what makes this thread worth watching.
Community reaction on Hacker News split predictably. One camp pointed out that PrusaSlicer itself is a Slic3r fork and that Prusa's own historical compliance was imperfect in the early days — a fair point, but not a defense. Another camp noted that Bambu's commercial success (the X1 Carbon is, by most estimates, the best-selling consumer 3D printer of the last two years) was built substantially on the back of a slicer they didn't write and don't appear to be reciprocating to. The AGPL exists precisely to prevent the "open-source as free R&D for a proprietary product" pattern, and if Prusa's allegations hold, BambuStudio is a near-perfect case study of what the license was designed to stop.
There's also a precedent issue. AGPL enforcement is rare in consumer hardware — most high-profile GPL cases (BusyBox, VMware/Linux, Vizio) have been GPLv2, and they've been slow. An AGPL action against a well-funded hardware vendor with a global customer base would be one of the more visible tests of the license to date. Even without litigation, a credible compliance demand from the upstream author, made publicly, is the kind of reputational pressure that usually moves legal departments faster than lawsuits do.
If you're a developer shipping anything built on AGPL code, this thread is a useful forcing function to audit your own posture. Three concrete things to check this week:
One: Does your build pipeline produce a Complete Corresponding Source artifact alongside every release binary? Not "the repo at HEAD" — the exact source, build scripts, and patches that produced *this* binary. If you can't reproduce the shipped artifact from what you publish, you're in the same posture Prusa is describing.
Two: If you depend on a vendor fork of an AGPL project — and there are more of these than people realize, especially in the ML tooling space where AGPL'd libraries get quietly forked into proprietary products — your compliance story is downstream of theirs. A vendor who is sloppy with AGPL upstream obligations is a vendor whose code you should not be embedding in your own AGPL-touching distribution chain.
Three: If you're the *author* of an AGPL project and a well-funded company forks you, the Prusa playbook is worth studying. Document the gaps privately first. Try direct contact. Then go public with specifics — not vibes — and let the community pressure compound. It's not a lawsuit, but it costs the other side something real in developer trust, which for a hardware company selling to makers is not a small currency.
The most likely near-term outcome is the boring one: Bambu publishes a more complete source drop, updates their build instructions, and the thread fades. The more interesting outcome is whether this becomes the moment AGPL grew teeth in the consumer-hardware world, the way GPLv2 eventually did for embedded Linux a decade ago. Either way, the lesson for anyone shipping software built on copyleft foundations is the same one it's always been: the license is the contract, the contract is enforceable, and "nobody's going to check" stops being true the moment your fork outsells the original.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.