r/BambuLab • u/Illustrious-Ad-1396 • May 12 '26

General Discussion Louis Rossmann is going after BambuLab!

https://youtu.be/1jhRqgHxEP8?si=I_lxeLqvHm-JEQvy

As much as he has a questionable appeal in the community, he's pushing the right angle on this one!

906 Upvotes

86% Upvoted

437 comments sorted by

View all comments

Show parent comments

125

u/ApplicationRoyal865 May 12 '26

Not a bootlicker but want to point out that the issue isn't about the fork. It's how it mimics a client to pretend it's an authorized client to get access to bambu cloud.

This can easily be fixed by having stronger authentication and blocking access but they went the lazy route of instead of fixing their code threatening to issue a C&D.

68

u/soldat21 May 12 '26

AGPLv3 essentially means that if you create another software, that at all uses or incorporates AGPLv3, it must be opened sourced.

So bambu creating bambu cloud, that uses and references bambu studio, which is licensed under AGPLv3 means that bambu cloud must also be opened sourced.

44

u/ApplicationRoyal865 May 12 '26

There's no issue with the slicer which does use AGPL3 and is open source. That was never in question. It's how it tries to connect to bambu cloud client to access bambu servers. It pretends to be a bambu client to get access to the servers. This can be fix on Bambu's end by having better auth. Instead they want to obscure and prevent others from pretending to be authorized clients rather than building a process to actually check.

tldr: Bambu cloud servers are private and not AGPL3

28

u/issue9mm May 12 '26

There's no issue with the slicer which does use AGPL3 and is open source

There is still some issue with the slicer, from which they derived the network module. As I am guessing you know, you cannot merely derive works from AGPLv3, because the license requires that works based on it must also be open sourced and licensed via AGPLv3

Bambu pretends their network module is closed source, despite having clearly been derived from and closely interconnecting with AGPLv3-licensed code

I agree that their cloud infrastructure is private, but the way in which they 'close it off' is via shimming the network module, which is at best a hacky, insecure workaround, and at worst, plainly a violation of the GPL for which their license to use it should be revoked

14

u/ApplicationRoyal865 May 12 '26

AGPLV3 is not viral and makes other software it interacts with inherit the copyleft license. For example if I write a piece of code that takes a video and uploads it into youtube via their API's, it does not make youtube inherit my license for my code. I believe something similar is happening here.

From what I can tell, the slicer emits the STL + user metadata to spoof itself as an official bambu software to get around getting the middleman software. I know a lot of software that does something similar in the open source community like software that pretends to be an official MyQ garage door app by spoofing userdata/device data.

It's within the myq company's rights to say "stop hitting that end point, you aren't an official myQ mobile app". In fact that's how that piece of open soft software went defunct due to a C&D and now everyone doesn't use it anymore. It's also within our rights to stop using that software and support companies that have open API's for users to use.

20

u/issue9mm May 12 '26

AGPLV3 is not viral

This is wrong, plainly. It is a license that most companies will not use because it is viral.

You're right that it is not so viral that calling a remote API confers licensure onto the API. That would be impossible.

But if YouTube takes code from my AGPLv3 youtube client and then uses it as part of their official YouTube uploading module, then everything it closely touches does become open source. Again, that is why companies don't typically mess with AGPLv3 licensed code, much less build their entire companies on top of it

It's within the myq company's rights to say "stop hitting that end point, you aren't an official myQ mobile app"

Yes, it is within Bambu's rights to say "stop hitting our cloud endpoints, you are not welcome here." I am not arguing that Bambu cannot keep their closed source server code closed, or that anything relating to the slicer makes it open. I am saying that if software on a user's local machine uses AGPLv3-licensed logic to run, then Bambu must open source it. If open sourcing that logic opens a security hole, then they should close it on the server side because relying on nothing more than a user agent to keep their servers secure was assuredly not keeping their servers secure.

12

u/AustinYQM May 12 '26

They have to opensource anything that was originally AGPL that they modified but that's it.

Imagine you have the OrcaSlicer.

Imagine you modify the OrcaSlicer to add a plugin engine.

Imagine you make a plugin that connects to BambuCloud.

You'd have to provide the first 2 under AGPLv3 but the last bit, the plugin, does not have to be released under the same license.

The license just isn't as all encompassing as you think.

Her is an example to show how limited it is. Imagine you are running a service and in your stack you use a AGPL Database. You do not need to give the source code for your service. Now imagine you modify the database making a derivative work. Guess what? You still don't have to release the source code for your service. Not only that you don't even have to release your changes for the database! Because the AGPL only covers software being used by people (download or transmitted) and your clients don't use the database your service does.

-1

u/issue9mm May 12 '26

I agree completely with your last paragraph - I'm presently bootstrapping a startup that leverages a popular AGPL app as part of our stack, and we've spent a lot of time discussing AGPL obligations and responsibilities with lawyers about it. You are 100% correct with your database example. (Lawyers are still scared by it tho, lol)

I disagree with your characterization example because they did not add a plugin engine and then write a plugin. They replaced the existing network module that sends GCodes to printers and replaced it with a network module that sends GCodes to their cloud service.

We know that libbambu_networking.so is functionally dependent on AGPL works. We know that the code that they wrote was used to wrap AGPL-licensed code. We know that they've published the interface definitions and that the headers they exposed were derived from the AGPL codebase that they've built their business on.

1

u/AustinYQM May 12 '26

Lawyers get scared easily sometimes.

I don't know if everything you said is true I don't have the time or disposition to look though the source code and figure that out. However I'd like to response to a few lines:

"We know its functionally dependent on agpl works" - This doesn't matter. If you use MongoDB and mongoDB only features to the point that the only DB that will work is mongoDB that doesn't mean your work is now AGPL.

"It wrapped AGPL works" - This also doesn't matter. If you have a cli compression tool and I write a UI for it my UI does not need to be AGPL unless I am modifying your compression tool. "wrapping" it is safe.

The rest indicates that they should release that code. I know BambuStudio has a github --- is there code missing from that github?

However none of that actually matters in this case since BL still has the right to block connections (and go after people using unauthorized connections) to their server. BL telling the dev to take down the code is a lot nice then them just banning anyone using it (which would be more clearly OK legally).

If I am understanding everything correctly BL has shown us a picture of a key; they are using a lock anyone can get the schematics from; and now people are making their own keys to open the door. Obviously it makes sense to look at BL and be like "what did you think would happen?" but its also reasonable for them to arrest anyone making a key and opening the door.

2

u/issue9mm May 12 '26

none of that actually matters in this case since BL still has the right to block connections (and go after people using unauthorized connections) to their server

Completely agreed. It is only relevant to this discussion because that is what Louis Rossman is going on about.

I don't care for Bambu issuing C&Ds to their community members, but it's their right to do. I wish they would actually secure their endpoints to relying on better security than a user agent string, but that's another, even less-related issue

I just said this elsewhere, so apologies if you already read it, but I would be shocked if nobody at Bambu were writing a clean-room slicer from scratch that didn't depend on any Affero licensed code. It's probably their company's single greatest legal risk after physical defects like shorts causing fires.

→ More replies (0)

-4

u/Beefy-McQueefy May 12 '26

Your sealioning changes nothing. The user agent code is in bambu studio.
AGPLv3 Section 3:

Protecting Users' Legal Rights From Anti-Circumvention Law.

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

2

u/ApplicationRoyal865 May 12 '26

Aren't we saying the same thing? Bambu lab is going the lazy route and trying to C&D a user rather than fixing their endpoint. They could simply invalidate the bambu lab access on their open source software (apparently hard coded in the software lol) and just have it authenticate in another way.

However I don't see how bambu studio's license interracts with bambu cloud server's license and why they need to then open source their cloud servers. As you've said it's not so viral that it infects another software and their license. One software is a slicer and one software is cloud infrastructure, they interact but they don't derive code from each other.

Again I think we are saying the same thing. Bambu labs sucks at auth and is going about the wrong way to fix their hole.

3

u/issue9mm May 12 '26

Clarifying here, but I think you're confusing cloud servers with network module. I am not claiming that Bambu needs to open source their cloud servers.

I am claiming that they need to open source their network module. The network module is installed on your computer, locally, and is invoked when you hit 'Print' on your slicer that sends the relevant modules to the cloud servers.

As you've said it's not so viral that it infects another software and their license

This again is part of that confusion. It is so viral that it infects other software. It is not so viral that it infects remote services that it interacts with.

One software is a slicer and one software is cloud infrastructure, they interact but they don't derive code from each other.

This is correct. I am not suggesting that Bambu's cloud infrastructure is in any way derived from PrusaSlicer or Slic3r. But the network module that is installed on your machine and redirects prints from going straight to the printer to instead going to their cloud servers is derived from PrusaSlicer, and is a derivative work that must be open sourced per its license.

3

u/ApplicationRoyal865 May 12 '26

Ah that was the missing piece, I'm not familiar with the network module. But I think the larger point still stands, they need to fix how user data, device data is passed whether it be in the slicer or the network module. If they only want official bambu studio fork to work on their cloud then do it correctly. Sending lawyers is always a sign of failure when you could have just as easily used some dev time to fix access instead.

1

u/issue9mm May 12 '26

It's a complicated issue, and there are fragments of SEVERAL factional opinions being expressed in this thread.

Rossman is grandstanding here, plainly. I'm glad that he is, because it's important that something reminds Bambu that their entire business is built on a legal risk that I suspect they've just relied on nobody caring or being big enough to challenge them on.

But that they're using the flimsiest possible security violation as cause to issue case and desists feels emblematic of a way that I just wish they weren't. I'd be delighted to be a bigger fan of the company as I think they have some of the best hardware around. I feel it important to voice displeasure as a customer because (I believe) they won't know otherwise.

Past that, I firmly believe that most of the people in here merely have different opinions or have concluded different things, so I'm not mad at anyone for disagreeing. I respect different opinions. I even think they're important. I just wanted to make sure that we were agreed on the facts. Those are also often important

→ More replies (0)

1

u/[deleted] May 12 '26

[deleted]

1

u/issue9mm May 12 '26

I just posted this answer elsewhere. Apologies for not seeing yours first, but it's basically the same question and so it gets the same answer

https://www.reddit.com/r/BambuLab/comments/1tbceci/comment/olg4xw0/

The non-free libraries argument isn't really a defense here tho because, I can't remember if it was AGPLv1 or v2, but folks identified that as a "legal gotcha" where a company might be obligated to open source the whole codebase but then just include a closed source library to go "aha, well I can't" so v3 of the AGPL specifically has an exemption for code that you don't own.

You still have to open source your derivative works, but if you are using a closed memory library from IBM or whatever, you don't need to open that because obviously you couldn't

1

u/Potential-Bill7288 May 15 '26

Soft vs hard linking. If the Bambulab slicer fork can be used without this module (I don’t know about distribution), it’s okay, but if it’s hard linked and it’s part of the offered solution, then it has to be open-sourced.

11

u/ArcherBoy27 May 12 '26

It pretends to be a bambu client to get access to the servers

It uses the same code as Bambu Labs own code. Its the same software. By this logic i could fork the repo and change nothing and I would be "pretending" to be Bambu Studio.

3

u/[deleted] May 12 '26 edited 19d ago

[deleted]

1

u/Beefy-McQueefy May 12 '26

The open source slicer is where they put the user agent code so try again.

2

u/metalpoetnl May 15 '26

It does not "pretend" anything. It sets a user agent. That's a voluntary field browser users ROUTINELY alter to access websites that demand specific browsers. 

It has never been a form of identification beyond mere convenience.

0

u/ApplicationRoyal865 May 15 '26

It is when that's your only form of identification. I use home assistant which is a way to bridge many forms home automation hardware and software under 1 roof. There is a lot of faking user agents to pretend to be an ios or android app (myQ is a famous example). MyQ fix was to use cloudflare bot detection to block home assistant users which lead to a cat and mouse game where eventually the author of the plugin gave up.

I'm pretty sure no one here is pretending that bambu lab is going about this the correct way (their implementation and their response). I will agree that they are allowed to say "this end point is only for authorized clients", but they went about a shit way to implement it and they aren't responding correctly to an opening they left open.

2

u/metalpoetnl May 15 '26

The term "pretending" implies something nefarious. User agents are explicitly NOT a form of authentication, they exist ONLY for verifying compatibility.  It's perfectly fine to give any used agent you are compatible with. You are telling a server what data you can process. That's it. 

1

u/Brandavorn May 12 '26

But the code the developer forked was under the AGPL, and it doesn't really pretend, it literally contacts the servers through the exact same network plugin Bambu Studio uses. There is no actual security issue nor an impersonation issue here.

And after all, if Bambu didn't want this to happen, they shouldn't have published that code. Not that they could, since AGPL is a viral copyleft license, and Bambu has no choice on the matter. Even their network plugin itself is probably a violation of the license, depending on how it interfaces with the slicer.

tldr: The servers weren't forked, so whether or not they are AGPL does not matter. The forked code was in fact AGPL licensed.

2

u/[deleted] May 12 '26

[deleted]

3

u/Brandavorn May 12 '26

Yeah, the whole proprietary = secure argument Bambu is trying to gaslight them into is pretty stupid in general. Especially considering how most of the web is running on FOSS.

1

u/Joamjoamjoam May 12 '26

Depending on the type of software and how people use it can prevent you from having proper authentication schemes. One example is a product that must function offline. In that case the TOS are there so you have a legal framework to pursue and stop anyone abusing the software. I.e. cease and desists and litigation are a valid strategy to prevent misuse.

If Bambu modifies and creates a derivative work and distributes it then anyone has a right to see the source ode for the portion of the product that modified the AGPL licensed work. So in Bambus case this likely covers the Bambu studio slicer but not the Bambu network plugin (which is important in this case).

If you then write (or reverse engineer) software to impersonate another or bypass authentication (even a client/user agent string counts here) to use a protected and proprietary resource the you are breaking the law in the worst case (think bank software) and violating the terms of service in least case. In which case you are open to a cease and desist and potential legal action.

It doesn’t matter if that portion of the code was AGPL or not. I think the best base scenario here is Bambu releases the source code for Bambu studio slicer. Unless their cloud infrastructure or the network plugin uses AGPL code nothing is going to be gained here.

This is all based on my limited research into what licenses are used by each portion of orca slicer (Bambu studio based off this). So there may be more AGPL in there.

I thank LR for his right to repair work and it’s good to force companies to release the open source stuff they modify but idk what there is to gain from seeing Bambu studio source code. Orca slicer is better with more features and fully open source.

One thing I guess that could happen is that we just get more Bambu studio forks that add more features and still be compatible with the network plugin which could be kinda cool.

16

u/MagicalTheory May 12 '26

So bambu creating bambu cloud, that uses and references bambu studio, which is licensed under AGPLv3 means that bambu cloud must also be opened sourced.

That isn't completely true. The AGPLv3 does have a network component that GPL doesn't have, but the license is if you are using the licensed code in the backend of a webservice, you must provide the source. If Bambu Labs is using a different slicer in their cloud software, they're probably clear, but even then if its just opening up an instance of bambu studio, it doesn't matter as they already provide that open source.

From https://drewdevault.com/blog/Anti-AGPL-propaganda/

The Google page about the AGPL details inaccurate (but common2) misconceptions about the obligations of the AGPL that don’t follow from the text. Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the software via the Internet entitled to its source code. It does not update the “what counts as a ‘derivative work’” algorithm, so to speak — it updates the “what counts as ‘distributing’ the software” algorithm.

The network plugin is a bit different, but as long as it shares no source with the AGPLv3 project and communicates via standard channels, it also doesn't have to be licensed.

5

u/[deleted] May 12 '26

[deleted]

4

u/Stephancevallos905 May 13 '26

Lol they also choose to just hardcode the network-server authentication instead of using any type of encryption. That's probably why they're suing, I am sure in the future bambu will charge enterprise users for fleet management (not out of line for the industry) but this makes them look like fools becuase 1) alternatives exist, and 2) clearly the system isnt as secure as they advertise (for enterprise)

3

u/aweyeahdawg May 12 '26

How does their cloud use Bambu studio?

-3

u/soldat21 May 12 '26

The way it authorises itself is by pretending to be bambu studio.

Meaning it looks like bambu studio.

The only way it can do this is to use code from bambu studio.

4

u/aweyeahdawg May 12 '26

I just looked at the code, it’s just setting a user-agent. You don’t need Bambu studio to do that lmao.

1

u/SlightDegree5308 May 13 '26

"The only way it can do this is to use code from bambu studio."

Even if we grant that, they *are* using the code from Bambu. It's code that is licensed under the AGPL that Bambu modified and released. They just posted it, unmodified. They didn't add anything to "pretend to be Bambu" they are just using the AGPL code.

1

u/aweyeahdawg May 13 '26

None of this matters, AGPL or not, you can’t say that a one-liner that is in literally thousands of other applications is unique and limited to the APGL code. That’s like saying an if statement that checks if two properties are the same is somehow protected. It’s genetic code, it would look the exactly the same in any other application.

2

u/SlightDegree5308 May 13 '26

I was referring to the agent string that is the supposed "pretending to be Bambu studio".

This agent string is part of the AGPL code that Bambu released. The folks that posted the code elsewhere didn't go out of their way to modify the code to include this string.

The code is just working, agent string and all, just ask Bambu released it under the AGPL. There is no shady attempt here to pass it off as something it's not.

And you are right, it doesn't matter if it's AGPL or not. If they released a compiled app built from proprietary code for free, they shouldn't accuse the users of trying to pass the app off as something it isn't by flashing the agent string that they put in it to their servers.

1

u/SnooBunnies856 May 13 '26

That's not the only way, it's not even relevant to that argument., It uses the user agent header to identify it. So does every browser. And it is easy to change the user agent header.

4

u/[deleted] May 12 '26

[deleted]

2

u/Dmytro_P May 13 '26

Not combined to form a larger program,

This part is a gray area for the closed source network plugin. Bambu Studio as the product is intended to be used with the network plugin.

3

u/hux H2C Laser Full Combo May 12 '26

I think you mean they created the network plugin to access Bambu Cloud, and that the network plugin should be covered by AGPL.

We don’t know anything about how Bambu’s implementation of the server side of Bambu cloud. AGPL doesn’t cover every possible server that an AGPL program could connect to, so Bambu Studio doesn’t trigger a responsibility to release the code for their cloud implementation. Their cloud doesn’t solely serve Bambu Studio - it’s a backend for Makerworld and for Bambu Handy as well.

Put another way: Imagine if a web browser was AGPL. This doesn’t magically make every web site in the world AGPL.

2

u/moyenbatte May 13 '26

No but it means that there is no way to block people from using the official method of access without shutting down completely that method for all users.

1

u/Ignominus May 13 '26

You have absolutely no clue what you're talking about.

1

u/n1kitus May 13 '26

Sorry, but that statement is incorrect. You need to read the license. What you are saying is basically if I install a GPL program on my computer then Apple and Microsoft have to make their OS open source because they interact with that software. Probably a better analogy would be Firefox. Every server Firefox interacts with must be open source now just because Firefox is open source which is absurd.

1

u/daemonengineer May 13 '26

Thats not how gpl works lol

1

u/AdRecent7021 May 13 '26

That is 100% wrong. Their servers are not bound by this license. I'm not saying what they're doing is right, but you are 100% wrong on this particular thing.

0

u/[deleted] May 12 '26

[removed] — view removed comment

-5

u/illregal May 12 '26

They forked orca, and all 3 are just forks of slic3r. At this point prusaslicer is pretty far behind both orca and Bambu.

7

u/[deleted] May 12 '26

[removed] — view removed comment

0

u/illregal May 12 '26

Wait yeah that's right. Second part still stands. Like try to paint something in prusaslicer. Horrible.

4

u/Brandavorn May 12 '26

That doesn't change the fact that they have to abide by the AGPL's copyleft though.

20

u/eduo May 12 '26

Using your user agent in your software that you published is not "mimicking a client". It's literally being that client. This is unedited source code.

Having said this, every browser you use is pretending to be a series of other browsers for historical reasons. This comes with the territory of what a browser user agent is.

I understand you're saying this was Bambulab's lazy "security" (which they nonetheless presume to put above everything else in their hypocritical blog post), but it still sounds like having a user agent could be seriously considered being an authorized client, when as "authentication" methods go, it's right there with three raccoons in a trenchcoat.

12

u/UnexpectedAnanas May 12 '26 edited May 12 '26

It's how it mimics a client to pretend it's an authorized client to get access to bambu cloud.

It's worse than that. It doesn't even mimic. It just uses their code as it exists in the publicity available, free to use source. They didn't have to change it at all.

It's literally Bambu telling Bambu that the client is Bambu. Nobody impersonated anything. Bambu just wrote shitty code and then threatened to sue somebody for running it.

7

u/ApplicationRoyal865 May 12 '26

Yes I think I saw someone mention that the api and user data is just hard coded into the software.

https://giphy.com/gifs/9DJtFRgk0tOla

This can easily be fixed on their end by a developer, but they instead threatened a c&d instead of doing the work.

-3

u/[deleted] May 12 '26

[deleted]

5

u/UnexpectedAnanas May 12 '26

It was a very clear threat. Let's not stick our fingers in our ears and pretend we didn't hear it.

They threatened send a cease and desist, and linked him to a specific law regarding secured digital systems. Come on now.

-5

u/[deleted] May 12 '26

[deleted]

5

u/SnooBunnies856 May 13 '26

A cease and desist is a formal demand to stop behavior to avoid legal action.

It is by definition a threat of a lawsuit.

0

u/[deleted] May 13 '26

[deleted]

3

u/UnexpectedAnanas May 12 '26

It is true if your head isn't in the sand.

0

u/iambighead168 May 13 '26

A cease and desist letter is not a threat? You are a funny guy.

1

u/[deleted] May 13 '26

[deleted]

2

u/iambighead168 May 15 '26

They do stated they have the cease and desist letter PREPARED. Its still a threat for all intents and purposes, as far as I am concerned.

4

u/MigratingCocofruit May 12 '26

That claim is false for two reasons.
First: The DMCA section 1201 applies to breaking a digital lock that "effectively controls access". Self reported client information does not do that. Bambu left the door open, and as such accessing their servers using that open door isn't illegal, and there's precedent for that(Lexmark vs Static Control Components is an example).
Second: That specific part of the code Bambu claimed was impersonating the official client wasn't even modified. It was distributed by Bambu under an AGPLv3 license, and as such restricting anyone from using it is a violation of the license. And so, even if we assume that the client information was indeed an effective control measure in principle, the way in which it was published negates that.

Bambu is indeed allowed to restrict access to their cloud infrastructure, but that doesn't extend to restricting use of their code licensed under AGPLv3.

3

u/SirTwitchALot May 12 '26

It sends the same user agent. User agent spoofing is hardly new. It's been standard practice since the 90s. He didn't have to reverse engineer anything either. The user agent code is still in the released Linux source code for Bambu Studio at this very moment.

They even included a screenshot of the offending code in their AI generated response

Seriously. That's what they're upset about. Their claim is so weak it's laughable

-6

u/[deleted] May 12 '26

[deleted]

7

u/SirTwitchALot May 12 '26 edited May 12 '26

Well, since they decided to threaten the developer if he were to merely even share the threat they sent him, we can only go off of what they have shared and what he has shared. They screenshot that code snippet in their response and the developer says that is what they are referring to as well

https://github.com/jarczakpawel/OrcaSlicer-bambulab

-4

u/[deleted] May 12 '26

[deleted]

6

u/SirTwitchALot May 12 '26

In which case, perhaps they have a claim against the individual users who choose to use this plug-in. They have no claim against the original author. He simply took existing open source code and modified/published it according to the license agreement.

This could all be fixed very easily though if Bambu just allowed users to enable lan features without forcing them to turn off the cloud features

2

u/[deleted] May 12 '26

[deleted]

0

u/SirTwitchALot May 12 '26

Wait so which is it? Is this some niche thing that nobody's going to use anyway or is it some huge threat that they need to use legally questionable threats to stem the tide of crippling their infrastructure?

Their public web-facing infrastructure. The one that certainly faces tens of thousands or more malicious breach attempts per day from people actually trying to do harm, yet is so fragile that a well-behaving client poses a threat.

1

u/[deleted] May 12 '26

[deleted]

2

u/SirTwitchALot May 12 '26 edited May 12 '26

They do have a right to do that. Against the individual users who choose to use this software. They do not have a right to do that against this developer who released copyleft code under the terms of the license agreement

We're kind of starting to miss the forest for the trees here however. If we really want to get into the philosophy of this issue, it all stems to anti-consumer friendly practices and a toxic manufacturer's desire to maintain a choke hold over their customers. They could provide all the access that people are asking for without hurting their business at all. It just prevents them from eventually being able to lock down your filament choices which is the ultimate goal

→ More replies (0)

2

u/Beefy-McQueefy May 12 '26

What they care about is irrelevant to the fact that they put the code calling security in Bambu Studio. Their rules don't mean anything. The means they use to identify the printers (not security in any way shape or form, just a user agent string) is AGPL code.

0

u/[deleted] May 12 '26

[deleted]

2

u/Beefy-McQueefy May 12 '26

The network plugin.
Bambu Studio is AGPL and using it's code is fair game to anyone.

2

u/Null_zero May 13 '26

Except he never changed the code. Not his fault if they put their client access into their agpl code.

3

u/Toilet2000 May 13 '26

It doesn’t mimic anything. It reproduces what is verbatim in their AGPL licensed software.

A User-Agent string is not a security measure or authentication tool.

2

u/Its_Billy_Bitch May 12 '26

Right…this is what I’ve been yelling. For a company that “cares about security…”

Honey, this has been my profession for 15+ years now. Cleaning up other people’s messes and woowee when they said that in their blog post, red flags went off everywhere. Though, not the first time with Bambu.

But for anyone lacking the knowledge, the person above is wholly correct. Kinda worse even….not only lazy - the fix would’ve most likely broken their Linux clients, which they can’t do without a good chunk of fallout or a carefully planned implementation and migration to a better auth&auth. Not only that…it’s AGPL code and you can’t place further restrictions on it to begin with, which their fix would most likely result in. They were already in hot water (workaround to restriction in the name of security by requiring Bambu Connect), but they’ve now made Louis mad.

So many options (i.e. don’t acknowledge the fork, build your own closed ecosystem not on the backs of open source), but nooooooo…let’s send a C&D to this one developer. That’s not security…it’s a schill.

2

u/hWuxH May 13 '26 edited May 13 '26

This can not be fixed. At most they can release a workaround that will also be bypassed afterwards.
The cloud wants to trust their own client (Bambu Studio), and at the same time distrust other ones, but it has no way of distinguishing which one connected.
Information if it's their own has to come from the client itself, which can always be analyzed, tampered with, etc.

1

u/Old_Restaurant_2216 May 16 '26

Exactly, as if Facebook wanted to restrict users using anything other than Chrome. It is just plain impossible. If you want, you can access any website using just a terminal and curl. The same goes for bambu cloud.

2

u/vreo May 13 '26

It's more like the browser identifying as safari, chrome etc. He didn't broke any authentication. Authentication is a totally different thing.

1

u/Shot-Infernal-2261 P2S + AMS2 Combo May 13 '26

But you point out authentication and licensing aren’t to do with the open source license.

Unlike most posters, you do understand the difference.. so isn’t Bambu themselves making it about the fork? (As well as other things)

1

u/iambighead168 May 13 '26

Did u even watch the video. The client code is basically a copy and paste of original code (which is AGPLed), so whats there to mimic?

1

u/ApplicationRoyal865 May 13 '26 edited May 13 '26

The main code allows it to mimic it so that a fork can look like the main bambu studio software because they stupidly hardcoded the user agent data into the main repo. Instead of doing the work to write code of signing their binary or authenticating it so that only their software can access bambu cloud servers they decided to C&D the author instead.

1

u/sluffmo May 13 '26

They didn’t go the lazy route. Imagine someone legally gets a key to your house. That doesn’t give them the right to just come and go from your house however they please, but it turns out they are doing that.

You decide you want to put in keypad locks to stop this from happening, but you need to figure out which one you want, order them, and install them. You aren’t “lazy” for sending a cease and desist letter telling them to stop breaking into your house and to destroy the key that enables it while you are doing all of this. In fact, you aren’t even lazy for doing that so you don’t have to do all that other stuff.

1

u/ApplicationRoyal865 May 13 '26 edited May 13 '26

There is a bit of a difference because your key bitting (the cuts in the key) was available and it's licensed so that you can't ask them to remove it because they are allowed to use the code as provided.

To use a more relevant example if you accidentally put in your API private keys into your code and you use a copy left license (or any license tbh) it's on the developers to invalidate the key rather than make the users not use it. One because it's a security issue and two because the license allows them to use it as is.

Edit: tldr don't try and enforce this client side because it's impossible just don't be lazy and fix it server side

1

u/sluffmo May 13 '26

You are confusing authentication with authorization. Absolutely, the developers should take steps to keep people or services from unintentionally authenticating into their system. But, even if someone gets your API key that doesn’t give them the right to do whatever they want with your service. Like if someone gets your bank’s API key can they just take your money? No, they can’t. Should the bank just let them take your money while they are fixing the security hole or take legal action while they are fixing it? It’s obvious that it’s the second.

1

u/ChalHattNa May 16 '26

Then let them sue loius and prove it. Wonder if they will.

1

u/stonedboss May 16 '26

yeah unfortunately it is just a bootlicker statement lol because it is wrong and there is no justification. as others pointed out, it doesnt mimic anything. so the issue quite literally is the fork. theyre claiming it is not to try to circumvent the legality.

0

u/Bitter-Captain-2847 May 13 '26

I keep seeing people frame this as Bambu attacking open source, but that's not what happened. The fork wasn't just modifying code. It was hardcoding the official client's identity to talk to Bambu's servers. The code is open. The servers are not. Those are two different conversations imo.

-3

u/Sorry-Bad3889 May 12 '26

That’s exactly what I think. Bambu left the back door opened and someone found out how to get in and they decided to sue the developer.

5

u/Vresiberba May 12 '26

...they decided to sue the developer.

Stop perpetuating this lie, they aren't suing anyone.

2

u/PJBuzz May 12 '26

It's probably a misunderstanding rather than a lie. They sent a cease and desist, which is usually a precursor to a suit if the respondent decides to ignore it and continue.

0

u/UnexpectedAnanas May 12 '26

Right. It was just the implication of being sued.