Bambu Lab threatened legal action against an OrcaSlicer fork developer for using Bambu’s own AGPL-licensed code to bypass cloud routing.
Key Takeaways
OrcaSlicer-bambulabs used verbatim AGPLv3 code from Bambu Studio; Bambu publicly accused the developer of impersonation and infrastructure risk.
Bambu’s core complaint: the fork spoofed the official client user agent string to hit their servers without cloud mediation.
The slicer chain is slic3r -> PrusaSlicer -> Bambu Studio -> OrcaSlicer, all AGPLv3; Bambu cannot credibly call upstream code use unauthorized.
Bambu’s own 2022 firmware fork caused user telemetry to hit Prusa’s servers; Prusa did not send a C&D.
The author’s mitigation stack: OPNsense firewall block, frozen firmware, Developer mode, OrcaSlicer instead of Bambu Studio.
Hacker News Comment Review
Commenters noted Bambu’s security argument collapses on itself: user agent strings are not authentication, and AGPL grants explicit license to use the code, making “unauthorized access” legally incoherent.
Bambu citing infrastructure outages caused by unofficial clients while admitting user-agent is the only distinguishing signal was widely mocked as an infra scaling failure, not a security issue.
A minority pushed back that most buyers want appliance-like behavior and do not care about openness; the thread split between hobbyist power users and casual print-and-forget owners.
Notable Comments
@danielrmay: “That’s not impersonation. That’s Bambu discovering that user agents are not authentication.”
@syntaxing: LAN mode only exists because of prior community outrage; sustained pressure has moved Bambu before.
@uberduper: OrcaSlicer prompts users to install a closed-source network connector blob that runs locally on the host PC.
