Orcas Slicer is a fork of Bambu Studio, which is a fork of PrusaSlicer, itself a descendant of Slic3r.

Orca Slicer was forked to improve usability and features, not to get around any cloud printing requirements, Bamboo added those later and removed the ability to print locally.

It has to impersonate to transfer a gcode file locally, which is another open standard.

Bamboo restricted LAN printing, that is the issue.

> OrcaSlicer-bambulab: if the goal of this fork-of-a-fork is to bypass Bambu's cloud servers, why would it still need to "impersonate" the UA and communicate with Bambu's servers (as Bambu claimed)? Wouldn't the whole point be to avoid doing that in the first place?

I finally got to the bottom of this; there is a cloud-based RPC method called `bambu_network_start_local_print` where Bambu's Cloud would authorize a print using (ostensibly) only locally transferred data. The goal of this project was basically to pretend to be the Bambu plugin in order to authorize this method, which is otherwise locked behind Bambu's auth system.

The alternative is to run the printer in LAN mode (which OrcaSlicer has always supported) where the client connects natively over MQTT, but after Bambu added their cloud authentication, this requires putting the printer in Developer mode and severing the Cloud features.

Bambu has the slicer (orca, bambu) download a plugin (owned and written by bambu, closed source.) which is what the controversy is about.

Orcaslicer is a perfectly legal fork, and in the past downloaded the official (closed source) binary blob to talk to the servers.

Bambu doesn’t want to serve people who reverse engineer the new (again, closed source) binary blob.

All of this being about the AGPL is just disingenuous ragebaiting.