[vfvthunter]

So the C&D was stupid, and so is how their network works apparently.

Fundamentally, what Bambu are saying is that they have a right to restrict what software accesses their network. The C&D was allegedly sent to stop distribution of software that was written to access their network in an unauthorized fashion (Allegedly according to their ToS).

AGPL covers source code. It does not cover who can access what network with AGPL'ed software.

Thus Bambu - like it or not - have a right to limit what software accesses their cloud. You are still free to do whatever you want with Bambu's AGPL'ed software. But they don't have to let you on their network if they don't want to.

With that out of the way, sending a C&D is a pretty regarded way to accomplish this. The correct way would be to sniff out which clients are using 'real' Bambu Studio and which aren't. However according to Bambu, Pawel specifically modified BambuStudio (ya know, because they haven't violated the AGPL, because he is free to do that) to make it look like Studio.

I can only assume that actually locking down their network for real would require every Bambu printer to have a firmware update that would add some sort of signed encryption to access the cloud features. The C&D appears to be a shitty action prior to a huge undertaking.

I do wonder exactly how secure their super spendy "Enterprise" X1E printer could possibly be given how easily Pawel was able to make a fork work on their cloud.

As to your second paragraph about functionality and theft, 1) I can still print from Bambu's cloud with my Bambu printer so I don't think they've changed any functionality, and I can still use Orca in LAN mode. and 2) designed obsolescence exists.

I disagree with your assertion that because forks were able to access cloud functionality previously, that Bambu must maintain that functionality ad infinitum. My opinion would change if anyone showed me where previously they were promoting how any third party apps could access their cloud.

[wpm]

I think the really important part of this is that Pawel modified OrcaSlicer to look like BambuStudio by looking at the AGPL licensed source code of BambuStudio and copying it over.

And the function he copied over just set the UserAgent string to some hard coded values also available in the AGPL source code of BambuStudio. He didn't reverse engineer anything. Just went and looked at public code that's free to use for any purpose.

BambuLabs is probably just big mad that their "security" argument for their walled garden, weak as it was, just got publicly pantsed. I've never heard of a fucking dumber way of "securing" a service than a plaintext client-side assertion "I'm allowed to send you print jobs uwu :3"

The entire debacle is incredibly embarrassing for Bambu.

[tootie]

Yeah they're argument is based on saying that sniffing a user agent string is illegal reverse engineering. If they get the right 100 year old judge they might even succeed but it feels like a thoroughly lame argument to me.

[observationist]

Not even sniffing - no special action need be taken, simply looking at the code which they are legally obligated to provide is sufficient.

It's like putting up a sign that says "No trespassing, unless you know the secret code word, which is 'Stegosaurus'".

[ixwt]

According to the video about this by Louis Rossman, there wasn't even string sniffing. No changes were made in the code, the client ID was hard coded in, and was untouched by the author.

[SV_BubbleTime]

> never heard of a fucking dumber way of "securing" a service than a plaintext client-side assertion "I'm allowed to send you print jobs uwu :3"

Love it; but just wait, I bet Claude surprises you this year.

[basilikum]

I mean, client side secrets and user agent white listings aren't exactly uncommon.

[emilecantin]

> However according to Bambu, Pawel specifically modified Orca to make it look like BambuStudio

"Specifically modifying" as in "not even touching that part of the code in the fork"...

[basilikum]

> Thus Bambu - like it or not - have a right to limit what software accesses their cloud. You are still free to do whatever you want with Bambu's AGPL'ed software. But they don't have to let you on their network if they don't want to.

Even if we take this at face value, it is irrelevant to their legal threat. They demanded the author to stop distributing software. So no they do not respect your right to be "free to do whatever you want with Bambu's AGPL'ed software.

[vfvthunter]

I didn't say they respected anyone's rights.

They sent a C&D asking him to take the code down. He was and still is free to ignore that C&D. It's simply the easiest, laziest move on their part to get non-BambuStudio software off their cloud. I am sure they are working on software updates right now; their shitty, dickish C&D was simply the most expedient way to stop it.

I seriously doubt they would've taken him to court over it, and also doubt they'll sue this clout- and click-chasing Rossmann idiot either. But a C&D requires almost no effort.

Sending that lazy childish C&D still in no way violates the AGPL.

[therealpygon]

A lot of the things you are perpetuating are outright lies. Just FYI.

Figure I should explain:

Lie #1: “Access their network in an unauthorized fashion.”

The perfectly legal use of public AGPL code does not constitute “unauthorized access”. If they allow their AGPL product to connect, and publish that method of connection, they are not permitted to add additional restrictions on the use of said code. They are permitted to require additive code to be make itself appear unique — but that must follow the license and be part of the license as an addendum, not a retroactive afterthought.

Lie #2: Pawel “specifically modified” BambuStudio [sic.] to look like Studio.

A patently false and outright lie. Pawel used AGPL licensed code. End of story.

Assertion: “Bambu has the right to limit the software that connects to their network.”

Yes! They do! They don’t, however, get to publish the code to do so under AGPL and then claim no one else can use it. Copying and executing that code is an explicit right in AGPL. Bambu is not required to continue operating their cloud or allowing those connection. They absolutely have that right to refuse all connections and correct their mistake.

Bambu also absolutely had the right to keep their cloud access private and to provide a system library to handle the connection to their cloud without it being AGPL. That is literally the specific purpose of AGPL.

“A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.”

Bambu chose to open up access to their cloud when they published the connection method under AGPL code. They can shut down that service, issue a new firmware, and release their revised non-AGPL system library for Bambu Studio to use their cloud at any time.

What they don’t get to do, and why everyone is giving them the finger, is retroactively decide “whoopsie, I didn’t intend that” and then abuse laws to violate the license they agreed to.

Listen, you can believe what you like, but there is a reason Louis Rossman had no hesitation to host this code. That’s because anyone less afraid and with at least a little technical and legal knowledge probably would have just as high degree of certainty that Bambu will be paying their legal fees. (Louis has the added benefit of living in an Anti-SLAPP state…intentionally.)

[Onavo]

This is essentially the same as Signal. Signal foundation, despite their non-profit status, behaves like for profit entities and refuses to allow 3rd party forks of signal. If you fork and build the signal app, you better host the servers yourselves too.

[subscribed]

And yet, I'm using Molly, an independent Android fork of Signal.

Signal itself is released on AGPL-3.0: https://github.com/signalapp/Signal-Android so this is probably why Molly forked.

So not sure what are you talking about.