Setting the Record Straight on Cloud Access and Community

You don’t have a point or an explanation that backs it up and refused to answer my questions. Only vague “we should settle” or “I think it’s not appropriate” (WHY?) messages that waste everyone’s time and run in circles.

Istg this discussion is full of LLMs that chain together some plausible words but once you look at the whole comment it’s half hallucinated and without contextual awareness or reasoning or aware what it or someone else said 5 minutes ago. That’s not a personal attack, it’s becoming a suspicious common pattern here even for other accounts whose messages match my opinion.

You know discourse is falling apart when someone relies on accusing others of being/using AI. Which is this case is not justified because there are no signs of LLM use.

You need to get through your head that you are arguing two different things. And instead of trying to twist what they are saying to fit the argument that you are trying to make, engage with what they are saying instead. The conversation only runs in circles because you are not building off of eachother.

Think of this in an ethical way, and maybe the conversation will go somewhere. :grin:

That has been my point. The issue is not whether this can be done, but whether it is appropriate. I do not think it is.

As I said last week, I agree, it is not appropriate, but neither is it the security circumvention measure Bambu claims. The fact Bambu relies upon the user agent is their own fault for bad system design. The first thing anyone building a network connected system learns is sanitize your inputs. You should not assume a client app will do the right thing, even innocently.

There may be good reasons Bambu chose to design their system this way. But regardless, they are being badly disingenuous about it. I cannot approve of that.

I am not sure why whether or not the useragent identity string is “appropriate” is germane to the conversation, other than as evidence of bad faith or of ignorance by Bambu (either is possible) in their public statements.

The “why” is simple: I do not think a fork should keep acting like the official app when it connects to Bambu’s services after Bambu says no.

You see that as normal. I see it as using the official app’s name to connect in a way Bambu does not want.

You do not have to agree with that.

Bambu still claims to be in the right, though admits and acknowledges handling badly Pawel’s development.

And yet, reading between the lines of the article and Bambu’s statement, despite what it claims, it kinda transpires the fact that Bambu ain’t actually that confident and reassured on its AGPLv3 compliance, and it’s heavily pushing towards, and relying on its cloud security defence, and pushing further the “impersonation “ claim of an original Bambu software (wondering what’s really “original” in it, given that it was - still is- open source software), and all the other unfounded claims brought against Pawel’s fork. What a bunch of…..lollipops (to be polite, given that there are quite a few minors among the users)…

Looking forward to seeing what comes out of the SFCs endeavor.

Getting closer to breaking out of the circle…

  1. Bambu objects to behavior
  2. Therefore behavior is inappropriate
  3. Therefore it is wrong to do it
  4. Because Bambu objects to it

That still depends on “acting like the official app” meaning what exactly. If it just means using the same public protocol behavior and client format, then that’s compatibility, not impersonation or misuse of a name.

The argument only really holds if there’s a concrete, enforceable rule that this kind of third-party compatible client is not allowed. The “security” framing that’s been used by Bambu for that is pretty weak in practice here, because nothing about a matching client implementation inherently creates a security boundary failure. It reads more like a policy choice about controlling access to their cloud ecosystem than a technical necessity.

I’m not trying to agree/disagree with your opinion but just want them to give a direct answer that doesn’t already assume the key disputed point, or saying one thing in announcements but then doing the opposite behind closed curtains.

  1. what’s supposed to be wrong about compatibility?
  2. Is blocking compatible clients purely done for technical reasons or for controlling the ecosystem?

I think that your question is a rhetorical question, as it also contains the the answer you seek (see highlighted), given Bambu’s continuous behavior and actions since January 16th last year.

After the LLM comment and “getting closer to breaking out of the circle,” this does not read like someone looking for a direct answer.

I have already said the part I disagree with.

Been spending a lot of time this evening wondering if I’m real, or just a LLM. I feel like I have memories, but maybe each memory is just a Reddit story regurgitated against the flavor of the prompt that is me. I’m just a string of meaningless words wrapped in the delusion of coherence. :robot:

(For anyone wondering, I drank all the chocolate milk.)

In this case, what you think does not matter. This whole thing has nothing to do with someone’s opinions on something. If code is forked under the AGPL and no changes are made, it is still required to work like it did in the repo it was forked from. That is how the license is written, and what Bambu Lab agreed to when they first used the license. If there was a different license involved, then they would be bound by the agreement to that license. AGPL has been tested in court multiple times, and violations of it have been considered copyright infringement. This isn’t some hypothetical. You are free to search and find the specific cases in question. They are available.

That must be a lot of milk… my condolences

dw ur chocolate milk drinking videos are more than convincing

How is this relevant ? is something supposed to be wrong ?

not my words. that’s what I’ve been trying to figure out the whole time:

I have read back quite a ways and cant find where anyone said something is supposed to be wrong with compatability.

We all know they would’ve said the user agent doesn’t count for the bug bounty if someone had reported this earlier…until they changed their minds and said so.

It’s funny how now Bambu PR is trying the”Damage limitation” tectics to silence the community. Too late. Cat is out of the bag.

How many people at Bambu going to loose their jobs over this?

I’m predicting none…

IMO a very low percentage of people who own 3d printers care about this. Most are happy with the machine just doing the prints and, when needed, they will buy the next new Bambu printer…

Bambuzled

Bambu Lab’s Bind: Company Stands By Its Position in Open-Source License Fight

Bambu Lab’s critics continue to line up to take shots at the company. Following the company’s pressure to take an OrcaSlicer fork that restores the connection to its cloud service offline, attention has sharpened onto an alleged AGPL license violation that may have lived within Bambu Studio since its launch in 2022. Bambu Lab contests this.

When Bambu Lab published its “Setting the record straight” post on May 7, it addressed its dispute with developer Paweł Jarczak as one of cloud access. The company claimed Jarczak’s OrcaSlicer-bambulab was impersonating an official client, effectively gaining unauthorized access to the company’s cloud service. Cloud platforms are private infrastructure governed by terms of use, not open source license obligations, the post says.

To recap quickly, Jarczak discovered a difference in the Linux version of Bambu Studio that, combined with OrcaSlicer – itself based on Bambu Studio – restored cloud access controls: the ability to send and control the printer while logged in and using Bambu Lab’s cloud. Bambu Lab changed how third-party slicers could do this, introducing a middleware app called Bambu Connect in 2025, which the OrcaSlicer team decided not to implement. Jarczak’s slicer, working only with the available code as released by Bambu Lab, effectively rolled the clock back and restored this access.

Bambu Lab disagreed, and Jarczak – rather than facing a firm legal action – took the fork down. After talking about the interaction on social media, Jarczak’s story quickly sparked a firestorm of attention from an intersection of 3D printing, right-to-repair, and open source communities. The criticism against Bambu Lab has coalesced around a long-disputed claim of Bambu Studio breaching the open source license it is available under.

What follows has split into two parallel disputes that are legally distinct but have become politically inseparable. The first is Bambu Lab’s: that Jarczak’s fork impersonated an official client to gain unauthorized access to private cloud infrastructure, that its cloud is governed by terms of service rather than open source obligations, and that those terms extend to prohibit reverse engineering its systems – Jarczak removed his project at Bambu Lab’s request, but the Software Freedom Conservancy (SFC) has recreated it, and is now deliberately reverse engineering the networking plugin as part of its Baltobu project.

The second is the community’s: that Bambu Lab has been in breach of the AGPLv3 license governing Bambu Studio since its original 2022 fork of PrusaSlicer, specifically by treating its networking plugin as exempt when the license requires its source be made available, and also now by imposing restrictions on use of the open code (pressuring Jarczak to take his slicer down).

Bambu Lab’s intention to protect its cloud service remains a core of the company’s communication about the incident. It’s a defensible component of the dispute, but one that sidesteps what has become a larger argument against the company: accusations of breaching the Affero General Public License (AGPL) that governs its software. This has become the sticking point and lightning rod for a collection of campaigns challenging Bambu Lab’s willingness to test its legal interpretation of things, as well as now a coordinated campaign to “jailbreak” the company’s closed source networking plug-in – the component at the heart of critics’ complaints.

Jarczak, who removed his fork voluntarily after Bambu’s private C&D warning, has since published a 616-line technical document contending that Bambu Studio has an AGPL compliance problem that lives entirely within Bambu’s own software distribution, upstream of any cloud term-of-service question.

Since Bambu Studio is licensed under AGPLv3, the license it inherited when it was forked from Prusa Research’s PrusaSlicer, there’s a scope for the release of “Corresponding Source” – meaning all the code needed to reproduce the compiled software – including dynamically linked components a program is “specifically designed to require” through “intimate data communication or control flow.”

In response to questions from All3DP, Bambu Lab says it does not agree that the plugin constitutes “Corresponding Source” under AGPLv3, maintaining that it is “a separately delivered, optional networking component that provides additional functionality.” The company’s reading of Section 1 of the license holds that the covered work is not “specifically designed to require” the plugin – a distinction it says its lawyers and external experts examined when the question was first raised in 2022, and a position it reaffirms today.

In 2022, independent researcher Roy Sigurd Karlsbakk shared a post on his personal blog highlighting what he saw as an AGPL breach concerning Bambu Studio’s networking plugin. Bambu Lab saw fit to directly address Karlsbakk to assert its confidence, backed by “considerable time consulting with our lawyers” and experts, that it is not in breach. The company stands by this today.

On May 13, 2026, Josef Průša – who has never been shy about lobbing grenades in Bambu Lab’s direction – posted a thread to X restating his view that Bambu Studio has violated the PrusaSlicer AGPL since its original 2022 release – a position he says he flagged publicly in March 2023.

Prusa Research maintains the immediately upstream codebase from Bambu Studio, meaning it would hold copyright on any code that remains in the latter today, if there is any, giving it a potential compliance claim distinct from Jarczak or any end user.

Jarczak’s document, asserted by the SFC and its read on the situation, argues that Bambu Studio downloads, installs, versions, and directly pulls the bambu_networking into memory at runtime – not as distinctly separate or optional as Bambu Lab suggests. Bradley M Kühn at the SFC, who co-drafted the Affero clause that’s relevant to this situation, says it “provably” is, writing further in the announcement for its campaign against Bambu Lab on May 18 that “Bambu falsely claims that their terms of service override the AGPLv3 (along with other specious claims). Bambu’s scare tactics against Paweł constitute a violation of AGPLv3 §10¶3 – which states the matter quite simply: ‘You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.'”

Following Jarczak’s overview of what he views as Bambu Lab’s AGPL violation the Software Freedom Conservancy, in consultation with Jarczak, has publicly moved to address Bambu Lab head-on with what it calls the “Bringing Affero Licensed Things (On)to Bambu Users” (Baltobu) project, a pressure campaign of multiple components that the organization says intends to achieve short and long term change.

In a blog post on the SFC website, Kühn writes: “Bambu has behaved badly for years and made multiple, provably false public statements regarding the AGPLv3 and its requirements. The recent aggressive behavior toward Paweł Jarczak was a last straw for us.”

Talking to All3DP, Kühn elaborates, saying that he finds it “very likely there are more AGPLv3 violations ‘under the hood’. For example, We know that the Bambu Studio software connects to a network service.” Parts §1 and §13 of the AGPLv3 license interact in this situation. “If it turns out – arguendo — that Bambu has moved some of their ‘subprograms’ that interact via ‘intimate data or control flow’ with the slicer on the customer’s computer, then §13 requires Bambu to provide the Corresponding Source and Installation Information for those network services to the consumer.

I simply don’t know at this moment if that type of AGPLv3 violation is present” he admits. “Our investigation is only beginning. But, SFC plans to investigate this fully and come to a conclusion about these and other issues in the coming months.”

He continues: “SFC uses litigation as an absolute last resort. While we’ve accelerated our response with Bambu from our usual copyleft enforcement practices, our goal now is to get some useful material created that will help the consumers who have been wronged by Bambu’s AGPLv3 violations as quickly as we can. Once we do that, which will surely take at least a few months, we at SFC will reassess the situation and figure out what to do next.”

In addition to hosting the slicer that started this whole saga, Baltobu has repositories for deliberately reverse engineering the networking plugin, as well as a project it calls Viscose, a mirror of sorts to Bambu Studio that will “work toward a replacement for Bambu Studio that works better for consumers who own Bambu 3D printers” Kühn writes. The group is actively raising funds through donations to pay for a full-time maintainer to work on 3D printing campaigns including, but not limited to, Baltobu. The organization hopes to raise the target amount of ~$250,000 by July 17 – an amount that’s “less than the average cost of 300 3D printers!” Kühn says. “That amount will allow us to continue address any copyleft violations in the 3D printing industry for at least two years to come.”

Asked about the new projects designed to force its closed source code into the open, Bambu Lab told All3DP “The AGPL, the DMCA, and Bambu Lab’s terms do not permit reverse engineering that violates applicable protocols, rules, or circumvents technical protection measures protecting our cloud services… . We are aware that some people are hosting relevant codes.

From the beginning, our preference has been dialogue, not confrontation. At this stage, rather than escalating conflict, we are focusing on strengthening our own infrastructure and protection measures moving forward. Interim measures have already been implemented. Security will continue to be strengthened in future releases, and we recommend that users update to the latest version in a timely manner.”

Bambu Lab has signalled it views the reverse engineering effort as legally distinct from the open source debate. The company cites DMCA Section 1201 and WIPO Copyright Treaty Article 11 – which obliges signatory nations to provide legal remedies against circumvention of technical protection measures. “This is not a uniquely American legal concern,” the company says, “it reflects a broad international consensus on protecting secure systems.”

What changes in all this? Nothing much for now. Bambu Lab’s stance that it has handled its code appropriately remains unchanged, and it continues to view efforts to crack it as a breach of its copyright and the contract of its terms of service, while third parties are certain the company is already in breach of licensing terms and now actively works to scrutinize it closer and unpick the code.

In the statement shown to All3DP, Bambu Lab concedes its approach with Jarczak was misjudged. The company states, “we nonetheless regret that our reference to Terms of Service, legal context and a potential C&D understandably came across as a legal threat. That was not the outcome we wanted.” Jarczak says he has had no contact with the company since the initial exchange.

see original here: An unbiased view from All3dp

Just to put a wrinkle in things, Bambu Studio uses components from from 39 different open-source license owners and is itself licensed under the AGPL.

The back story of Bambu is the founders came from DJI and were looking for a product that they could apply their collective talents to. Having been disappointed with the quality of consumer 3D printers at the time, they decided that they could make a better printer, which they have done spectacularly. They had considered creating a universal AMS system but quickly discovered that other printers lacked the technological sophistication to accommodate an AMS system.

Those who say that Bambu took from the 3D printer community and gave nothing in return, do not make 3D printers. Bambu has shown the once stagnant industry the way forward, featuring multi-color printing with consumer level ease of use. Anycubic quickly saw the writing on the wall and developed a line of FDM printers and an ecosystem that can be seen as Bambu light, with Creality following not far behind as Bambu extra light. Even Elegoo and Flashforge have Bambu-like offerings, while Prusa struggles to stay relevant.

Orca is essentially Bambu Studio with a few extra settings to set. Without Bambu, there would be no Orca Slicer. Those who use Orca and claim Bambu never gave the open-source community anything come off sounding unknowledgeable as well as being rather ungrateful.

Seems to me that Bambu purposely used open-source components with the idea that Bambu would be part of the industry, not outside of it. Why reinvent the wheel. Open-source works best when it allows different companies to create compatible products. Seems to me that the free software crowd loses sight of that. Last year, while the free software crowd was crying about Bambu turning into a closed system, Bambu was adding Fiberon and SUNLU filament profiles to Bambu Studio.

Close to three years on and five printers later and still, printing is the easiest part of the process. Whatever I design, the printers print. Failures are rare. Other than periodically greasing up the leadscrews and occasionally fishing out a piece of broken filament, there has been no need for maintenance.

Seems to me, those who seek to tear Bambu down, don’t have a leg to stand on.