From what i’ve seen of others posting the message it states there was an issue uploading the file, this thread offers some troubleshooting options incase you’ve not already tried them https://www.reddit.com/r/BambuLabA1/comments/1hxvm5i/comment/m6cl2vy/
Given that you say creating a new project works, what exactly is the name of the file you’re trying to send and does renaming it to something simple like test.3mf change the error at all?
Anyone who does not understand that Bambu absolutely does advertise open source, see here: Software Studio - Bambu Lab
Bambu Studio
Bambu Studio is an open-source, cutting-edge, feature-rich slicing software. It contains project-based workflows, systematically optimized slicing algorithms, and an easy-to-use graphical interface, bringing users an incredibly smooth printing experience.
This is a lie, it has been a lie before this. But it is also a lie to claim Bambu Lab is not advertising open source. Anything that follows downstream from Bambu Studio being open source, such as compatibility with third-party slicers, is also something that Bambu Lab is currently advertising. I am fed up with the gaslighting.
The lie goes as far as this: BambuStudio/LICENSE at master · bambulab/BambuStudio · GitHub
For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
Maybe Prusa will take legal action at some point. This also affects the Orca Slicer network plugin integration.
I’m no fan of Bambu Lab’s tactics and gaslighting, but I want to clarify and balance this post.
By the letter of the GNU license, Bambu is fulfilling the open-source requirements for its derivatives from PrusaSlicer, SuperSlicer, and Slic3r.
Where are they failing to follow the spirit of open source? BambuSource.dll. They will not publish the source code for that. The sad truth is, nothing in the FSF licensing library requires them to publish the source code for BambuSource.dll. Why? Because BambuSource.dll isn’t derivative; it’s an original work not derived from open source. Its function is to act as a network library enabling software to interface with their printer. This is how they sidestep the spirit of open source.
Fat chance legal action will happen. FSF has limited financial resources for litigation and primarily relies on cooperation, public pressure, and voluntary compliance. That said, it has successfully pursued legal action when necessary. One notable case was the 2008 lawsuit against Cisco over GPL violations in various Linksys products, including the WRT54GL Wi-Fi router. Cisco settled in 2009, agreeing to improve compliance and contribute to the FSF. But I don’t think Bambu has yet reached the levels of Linksys sales whereby the FSF would take notice and of course there is that loophole I mentioned above.
I really don’t think this is true.
Well, they are sidestepping the spirit of open source, while squarely violating the letter of the free software license.
The work here is “BambuSlicer with the network plugin”, which is derivative from PrusaSlicer. You can tell because in advertising they say: “BambuStudio is […] bringing users an incredibly smooth printing experience.”
What you are saying here is that walking to your printer with the SD card and having the camera feed not work is an “incredibly smooth printing experience”. Why are people complaining then?
Of course Bambu Lab has some excuse for why they think they are allowed to do this, it’s just a lie. The AGPL is specifically designed to rule out this sort of behavior, both in spirit and in letter.
As long as Orca Slicer is allowed to use all the functionalities that Bambu Studio has access to, it is a bit closer to the grey zone and maybe an incompetent judge can be fooled by Bambu lawyers, but once they make that impossible, they have zero legs to stand on.
I had edited the post in the meantime to reflect my new understanding that PrusaSlicer is (C) Prusa Research. So it would be up to Prusa to enforce the license. And also, if what you claim is true, why does FSF encourage people to assign copyright to them so they can take care of enforcement?
Also note that none of this changes the simple fact that it is a lie still being actively peddled by Bambu that Bambu Studio is open source and provides an incredibly smooth printing experience.
You’ve made a couple of statements but haven’t provided any sources to support them. Here’s one example:
I emphasize details because the web is already filled with conjecture, hyperbole, and opinions. If we want to make a strong case against Bambu, we need facts and citations—not just opinions or gut feelings.
As I stated in my post, I am not on Bambu’s side, but misinformation doesn’t help anyone. Repeating factually incorrect claims weakens the argument rather than strengthening it.
Here’s another example—can you provide a source? Do you have concrete evidence that the Bambu Network plugin (BambuSource.dll) is a derivative work based on PrusaSlicer?
Even with access to the source code, proving this claim would be difficult. The network plugin primarily communicates with the firmware, and while Bambu’s closed-source firmware is one of the community’s grievances, it is not covered under the GNU licenses unless it can be proven to be derivative. I’d like to see something more than just an opinion—facts matter.
I want to support your argument and help build a solid case, but that requires meeting me halfway. If you can back up these claims with specific evidence, it strengthens the discussion for everyone. 
I think I have given everything that is needed to make the case. What else do you need? Clearly the claim of “incredibly smooth printing experience” is a smoking gun here.
How is that a smoking gun? It’s a sentence out of a marketing blurb, nothing more. How does that constitute a linkage between function, algorithm or source code that can be proven to be directly derived from prior art? It takes a lot more than that to win the argument that Bambu’s institution of a concept constitutes work derived from someone’s else’s code. For the same reason, one can’t copyright the spreadsheet concept but can copyright the underlying algorithm and code.
Even if all the code in the network plugin was written by Bambu’s engineers, Bambu Studio is derivative work. The AGPL specifically states that code in shared libraries that the software is designed to require (you know, for example, by asking users to agree that the plugin will be downloaded to enable all the functionalities of the software, when you start the software for the first time), needs to be available and licensed as AGPL. This is how copyleft works. If you extend the software, your new code must be licensed the same way.
I’m afraid that’s not how intellectual property works. This concept was long ago challenged and defeated in court in the 1980’s when the IBM PC BIOS was reverse engineered using a Chinese Wall approach. This was later followed up with SONY filing similar suits and even though these companies initially won, the cases were overturned and overall the case law that stands has been in place allowing such reverse engineering.
This is simply not relevant. No reverse engineering has taken place. And anyway, the copyright of the network plugin is Bambu’s, but they are violating Prusa’s license by not making it available to others under the same license.
No matter how many times you may restate your previous position, repeating baseless claims won’t make them true. Produce evidence or admit you have none.
Again, what else are you looking for?
An article from a journalistic source, a specification, a GitHub page, Wikipedia or even an editorial opinion from a respected tech journal will help. Not something from Reddit, Twitter, or Facebook, please.
Is Google’s AGPL policy helpful? AGPL Policy | Google Open Source
No, that isn’t the kind of supporting evidence that will help us win this argument. It references derivative work and contribution requirements for Google Projects, which have nothing to do with Slicer software.
To argue that Bambu has directly violated the Prusa open-source license, one would need to establish a direct link to PrusaSlicer. Since PrusaSlicer itself is derived from SuperSlicer and Slic3r, it would be necessary to trace a specific feature from one of these earlier iterations directly to a function in BambuSource.dll. Smarter people have already attempted this and failed. That’s because, as I mentioned earlier, the network interface is a standalone work with no ties to prior art and does not fall under the Slicer.
Now, if it could be shown that the work inside the printer relies on other open firmware—such as Klipper, Marlin, or RepRap—then one could argue a GPL violation based on those projects, but not on the Slicer GPL. However, proving this would require demonstrating that the same code is running inside the printer’s firmware. Again, the Chinese Wall I cited earlier allows a company to have one team (possibly external) analyze a piece of code and send specifications to developers who never see the original source. This legal precedent protects against claims of direct copying.
Even if Bambu had implemented a Chinese Wall, its innovations have far surpassed what open-source firmware offers, using unique approaches not found in those projects. Proving they “copied” code would be extremely difficult if not impossible. If there were something to uncover, motivated competitors would have done so by now. The fact that they haven’t suggests there’s nothing there to prove a GPL violation.
So your point is that it cannot be established that Bambu Studio is a fork of another AGPL’d slicer?
You keep conflating two separate and distinct issues, which is why you’ll lose the argument that Bambu is violating the GPL. Let’s break it down into bullet points for clarity.
Bambu Studio (slicer) is derived from PrusaSlicer, which itself is derived from SuperSlicer and Slic3r.
BambuSource.DLL, the connection library that interfaces the host computer with the target printer, is closed-source.
It is important to distinguish between Bambu Studio, Bambu Firmware, and the connectivity libraries. Under copyright law, it is valid to have separate licenses for each component, as they are fully encapsulated functional modules.
For example, as you know, one can send a G-code file to an SD card without ever going over a network. The user simply transports the card, inserts it into the printer, and runs the file from the printer’s control panel. In fact, this can be done without even using a slicer—if a third party emails a G-code file, it can be copied to an SD card and used directly. This reinforces the argument that these are separate, independent functions.
I understand all of these distinctions (and I had actually linked to the Bambu Studio github earlier when I quoted from the license), but I just think Bambu Lab would be hard-pressed to argue that the core purpose of Bambu Studio is not tight integration with Bambu Lab printers. It has gotten a lot harder now when the plugin does not even work anymore with other slicers. This is the opposite of a fully encapsulated functional module.
I.e., the argument hinges on whether “Bambu Studio” means “Bambu Studio (including the network plugin)”. Clearly when Bambu Lab advertises Bambu Studio as “providing an incredibly smooth printing experience”, they implicitly include the network plugin in it. (So saying “open source” there is at the very least false advertising.)
I am not claiming the network plugin by itself as a standalone thing is derivative from some GPL’d software, I am saying that Bambu Studio with the network plugin as the core part of it is derivative from an AGPL’d slicer.
Of course, in the end some court will have to agree with this opinion, but there is precedent for enforcing copyleft across dynamic linking boundaries (even when the sets of authors of the two components do not overlap). I think whether the proprietary code is in the dynamic library or the other way around does not really matter, what matters is whether the court considers the combination to be part of a covered work. Bambu Lab certainly seem to think this is the case, otherwise they would have mentioned the network plugin separately.
Of course, if they start requiring Bambu Connect they may become compliant (at the cost of the user experience), but only if forks of Bambu Studio can use it in exactly the same way that Bambu Studio does.
(I need to go to bed now, it is 5am here.)
BambuSource.dll (libBambuSource.so for 
) is necessary for using the camera feed (and other network-related features) in Bambu Studio, yes? That’d make it a dependency for the software’s full functionality, which I think is close to what tg0 is saying. Without the closed source bits the software is only partially functional.
The “Corresponding Source” for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code [it’s needed to run all functionality] and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries [it’s not part of the OS], or general-purpose tools [it’s not general purpose] or generally available free programs which are used unmodified in performing those activities but which are not part of the work [seems like it’s “part of the work” to make the application function to me].
The fact that you can use an SD card instead is N/A, because AGPL doesn’t give an exception for “if the user is able to use a non software workaround, just forget all of this”. (Also, we can’t use the SD card trick to view a live stream cam.)
AGPL definition of “Corresponding Source” later includes an example:
“…the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require…”
Since BambuSource.dll is necessary for Bambu Studio to operate as intended, it falls under this definition. Then it should be considered a derivative work under AGPL and source should be provided.
The fact that it’s original code and not derived from AGPL code is irrelevant, because it’s already in violation due to the functionality dependency.
I’m starting to think they might actually be in violation…
Reverse eng is how Compaq was developed, yep.
