All of their issues are self-inflicted. What benefit is there to their cloud backend except getting around the home NAT? If you want to build your IoT product privacy-friendly, your cloud offering can be reduced to a STUN/rendezvous server and a proxy server as fallback [1]. Ship your devices with individual tokens to rate limit the proxy, have the STUN/rendezvous/proxy server address configurable and publish their source code for users to not be dependent on your continuous operation.
You can even go so far and have a public sub domain for each devices ( serialnumber.manufacturer.com ) which you only operate as a dumb proxy so that even the TLS certificates are negotiated end-to-end between the IoT device and Let's Encrypt. (The devices connect to your backend via Wireguard and you rate limit with their device individual key, whose public key you read out during the end-of-line production step.)
Hell, with today's browser heavy applications you can even run the whole slicer in the browser. Let the app be distributed via CDN so the code does not need to go through the proxy.
[1] In the case of non-battery operated and always or mostly on devices, like 3d printers at least.
Honestly, a lot of devices that use cloud apps for things could be improved both for the customer and manufacturer by using a "STUN/TURN" style proxy for the cloud service rather than forcing all data to go through a cloud service (to add to the other advantages, you don't need as many developers on the cloud side). But nobody in the engineering departments of these companies seem to be willing to touch WebRTC with a nine-foot pole lol
I dont understand what the issue is. Theres not really any benefit in having cloud enabled if local is working fine. I have my bambu printer set to local only, and dont miss the cloud offer one bit.
I disagree. They’re redistributing software under the AGPL while trying to prevent others from using the same freedoms they’ve been granted by the license.
The fact that Pawel was able to copy their source code and paste it into an Orca fork is direct proof from Pawel himself that they are honoring the AGPL.
The C&D presumably wanted him to remove the ID/version string or at least stop distributing it, i.e., they only want real BambuStudio on their cloud and that was the laziest way to achieve that
If we sign a contract that says you're allowed to park in my driveway in exchange for $10, then I threaten to sue you for parking in my driveway, technically I'm not violating our contract. It's not an issue until I actually sue. But I'm still abusing our contract by threatening you for doing something I explicitly allowed you to do.
Likewise, Bambu was able to benefit by forking and distributing AGPL software in exchange for giving everyone a license to do the same for their fork. Then they turned around and threatened legal action against someone for doing what they previously said was allowed. This may not technically be a violation but it's definitely abuse.
Pawel still has access to the Bambu-modified software, which is what the AGPL covers. There is no violation there.
Bambu's issue is with him taking a fork of Orca and spoofing some data (from THEIR FREELY AVAILABLE SOURCE CODE) to appear as Bambustudio to their servers.
A contract that says you can park in my driveway doesn't give you permission to access my garage and use all my tools.
Absolutely a dick move but not really not abuse of a contract.
The AGPL does not just say he has to have access to the modified software. It also says he has to be granted permission to redistribute it, or derived works, under the same terms.
He redistributed a derived work under the same terms and got hit with the threat of legal action.
I don't know what "access my garage and use all my tools" is supposed to be an analogy for in this situation.
He is free to remove the part where it spoofs itself as BambuStudio and do whatever the hell he wants with it. He can probably distribute it with the spoof and continue without actually getting sued because they are likely fixing this as I type this. If they do sue him it will be for unauthorized use of their cloud services. I do think they'd have to sue individual users.
Accessing my garage and using my tools == using Bambu's cloud infrastructure, which they clearly do not want him (or apparently any non-BambuStudio clients) doing any more.
The "spoof" as you call it is literally just using their unmodified code. You make it sound like he went in and deliberately changed it so that it would connect. He did not. That part of the code was left unchanged from Bambu's own publicly available source code.
I agree that they might possibly have a case to go after individual users. They don't have a case to go after this guy for distributing a fork of their software with their own publicly available user-agent string unmodified. Threatening to do so is very much against the spirit if not the letter of the license that they're using.
Using their cloud infrastructure without authorization is different from distributing a fork of their software. They may have a legitimate gripe with the former, but they threatened legal action against the latter. If they didn't want people distributing a fork that could connect to their cloud infrastructure by just using their code verbatim, maybe they shouldn't have designed it that way.
He copied the code from BambuStudio into an Orca fork to make it connect to Bambu's cloud. That is A) deliberate and B) easily meets the definition of spoofing.
It is embarrassing that copying that one little thing made a third party fork able to connect to their cloud because A) that would be embarrassing for smaller IoT devices and we're talking about thousand-dollar printers and B) it's highly regarded to be saying on the one hand that your cloud needs security while on the other hand a simple copy/paste of a single function bypassed the security of said cloud that needs protecting.
I agree he would win in court. I don't think they ever planned to even file a complaint. I disagree that it is against the spirit of the AGPL. Signal does the same thing (here's our source code but only our official app can officially connect to our servers and we can ban your app at any time) as far as I can tell and no one complains about them and their shit is AGPL 3.0 only.
As I already said, I don't think they would have any beef with him if he removed that single function - the one that enables use of their cloud infrastructure. The exact problem they have with him, is his distribution of that. I agree that he can distribute it, and they would lose any lawsuit about that. I also agree that its on them to fix it. But returning to the original point, by making source code that can be so easily copied available for download, they have not violated the AGPL. They are not saying he can't distribute his own Orca fork or even his own BambuStudio fork. They're saying "Stop making it connect to our servers" which again I agree is actually their problem. The C&D is just a lazy stopgap.
Orca is a fork of Bambu Studio anyway so it's just merging something across forks. It's not like he put it into some unrelated piece of software.
Again, abuse is different from violation. I agree that they're not violating the AGPL merely by threatening legal action. They would be if they actually took legal action. The fact that they're threatening to violate the license in order to get what they want but still take advantage of what the license grants them is IMO abuse of that license.
Proprietary plugins in [A]GPL software are always contentious. It's the old linking argument and it's especially strong here, given how useless Bambu Studio is without the networking plugin.
I imagine some (many?) people just enjoy accessing their printer over the mobile phone without setting up VPN, even if said mobile phone isn't on the home wifi.
There's no reason I couldn't access through the cloud on my phone and from Orca locally without any cloud. The spool management is on the physical printer. I don't need Orca to use their cloud; it just needs to chat to the printer.
They have no rights to prevent people modifying and using AGPL software however they want.
They should have no rights to control how people use hardware they bought. ToS for hardware should simply be unenforceable.
People should have full rights to adversarial interoperability, even if it means modifying proprietary software or hardware.
It always surprises me when people (on this site particularly) are more interested in the law as it stands than how things could or should be.
I wonder whether tech has become so exploitative partly because so many of us have lost track of (or never understood) how important civil disobedience has always been in the process of democracy and securing our rights.
As an individual you really don’t have to follow the terms of service! You certainly don’t have to support the [ab]use of ToS, DRM and related tech to screw you at every opportunity!
> They have no rights to prevent people modifying and using AGPL software however they want.
AGPL software can be used and modified within the limits of what the AGPL permits. People can do that with their Bambu software running on their own hardware.
That does not extend to using their proprietary BambuNetwork cloud service (somebody else's computer). The AGPL specifically mentions this scenario in section 6. There are open source alternatives to that like the third-party Bambu-Farm and bambuddy that people can self host instead.
Interestingly, Bambu's own initial approach to the AGPL was more in line with "modifying and using AGPL software however they want" (and potentially violating their section 6 obligations), until customer backlash forced them to adhere to the terms of the licence.
Id Louis Rossman's YouTube rant is correct, nobody involved here modified the AGPLK software. They just used a version of the AGPL software from before Bambu Labs changed the auth code.
While I agree that the AGPL does not grant users any rights to Bambu's cloud service, sending DCMA nastygrams to people hosting copies on old versions of their software isn't the right (or even legal) way to enforce that. And since Bambu choose to build their products and software stack on pre existing AGPL code, they've backed themselves into a corner a bit with other options. They can add new auth to new versions of the code (which is stringer than just hardcoded useragent-like strings in the code) but they'll then have to release the source code to their new version - exactly like the original authors who chose the AGPL intended.
If I just build the software from their repo without any modifications, getting an identical result to what I can download via their website, would I be allowed to use the service? If not, why not? If yes, what if I made a modification? How much may I change and where was this ever codified? What about using an unmodified, prior version of the source code to build? Why would that not be ok?
Interesting question. In the first case, where you install your own build from unmodified source code, although AGPLv3.0 still allows discontinuing support, I see no explicit carve-out in the licence to restrict network access.
However, the AGPL comes with no right to such network access to begin with. Permission to access the network would usually come separately from the AGPL; I suppose you could potentially bundle it as an additional permission under section 7, but I don't think Bambu is doing that.
To take it a step further, even if you use the latest official software, installed by the vendor (and not by you), they can still refuse you access to their network. That might violate some other agreements or laws (e.g. contract to provide a service), but it does not violate the AGPL itself.
What they cannot do is prevent you from running your modifications on your hardware.
But they had no access control in the first place. If I built their repo without modifications, I automatically have access. I would need to make modifications not to get that access.
> [...] they can still refuse you access to their network.
Sure, they can and yes, AGPL doesn't give users right to just access services, I have said before that they may enforce their EULA upon individual users. They are however not doing that, they are harassing repo owners. Let me put it this way: If the network access were the issue, as you seem to think, why go after the dev hosting your code rather than the individual users that you claim improperly access your services.
> What they cannot do is prevent you from running your modifications on your hardware.
They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
That's why I was asking specifically regarding what level of code modifications is acceptable for them. Because they made this an issue not about using their servers but hosting code, regardless of how it's used.
> They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
I agree. I think the argument they are going for is similar to that from Google against yt-dl, but unlike in that case, Bambu is obligated to allow this codebase.
> many prefer to break their license agreement because They Really Want It
By "many" do you mean Bambu Lab themselves who are violating the AGPL license of Prusa slicer & predecessors with their non-AGPL, proprietary networking plugin?
They're choosing to violate the license because they don't think anyone will actually dare to sue them, and they're probably right. Ascribing some sort of moral righteousness to Bambu's actions and accusing users of breaking their license is hysterical.
That's a highly creative interpretation of events. The software license agreement usually upfront covers what can or cannot not change. It is pretty rare in most countries to see successful legal action for changed features, but best of luck.
They will just fine them into oblivion; they are known to fine companies AUD10M to AUD50M for this sort of thing, and from 1st April this year they can now fine up to AUD100M.
Will this mean that Bambu will withdraw from the Australian market? Possibly maybe probably, but the ACCC takes a very hard stance against bait and switch.
The largest ACCC fine to date for a company undertaking anti consumer practices is $483m against an educational provider for misleading students.
I'd be reasonably happy to lodge a complaint if I could find a version that's reasonably articulated. As a Bambu customer in Australia I switched my printer to local mode and its been great.
It's a whole lot better than the US, but AUD100M isn't enough to scare a lot of companies. A law with real teeth would go after an increasing percentage of their revenue for each offense.
As a percentage of global revenue, sure, it's not much. But as a percentage of what that company is likely to make in the Australian market, it can be significant.
Taking functionality away from a product after you bought it is a scum move. If the law lets them get away with it, the law should be changed.
When I buy a product, I look at reviews and make my purchasing decision on the features and functionality at the time of sale. If a software update later ruins that, I want the option to get my money back.
No, it’s not creative at all, it’s what happened — I have first hand experience to corroborate this.
Regardless, at least in the US, not only are software-based ToS becoming unenforceable, but there’s a large upswing towards “right to repair” legislation, which, I think, is what you’re arguing against here… and I really think you’re going to be on the wrong side of history with your current line of thinking (despite what Bambu Labs does).
No, it is with you -- the legislators are doing "fine" (and, again, are heading in a fine direction wrt RTR and software ToS).
I have no idea why you think copyright violations apply here? You seem to be throwing legal terms around without regard for their actual meaning. It's clear you're here to argue for the sake of argument, but I'd really encourage you to reflect and think about why you're so loyal to a corporate entity instead of your fellow consumers (of which there are many in the parent and sibling comments... hint: you may be on the wrong side).
Just for fun, pretend you bought a propane grill for cooking on Monday. On Tuesday, you cooked some bbq chicken and some corn. Later on Thursday, and without your knowledge or authorization, the grill no longer allowed you to use the propane apparatus for cooking non-meats unless you call a special telephone number and said a magic word whenever the call was answered. As a minimum, I feel, it'd be very confusing because, even though you're doing the exact same thing as Tuesday, the outcome is not the same.
Your freedoms have been restricted by someone else; if you are okay with that, then have fun licking boots. The rest of us will still be here advocating for your freedoms.
The "agreement" is at best coerced, and under blackmail of hardware you bought and paid for.
At worst, its a fraudulent indefinite rental masquerading as a 'sale'.
And lets discuss 'updates that fuck over your hardware'. In dwcent countries, thats hacking, and a serious criminal charge. But lol, companies are somehow exempt.
Maybe legally, but morally “you have permanent physical access to this but don’t ’own’ it” and anti-circumvention are debatable.
There’s a small benefit of anti-circumvention where businesses sell hardware for cheaper with restrictions and a TOS that prevents bypassing them. But even that doesn’t apply here because Bambu changed the software after purchase.
This reminds me of RMS and GPLv3. Now I personally don't use GPLv3, but this here is literally a case-in-point, and it is not even only limited to the "cloud-only". Because this now includes a company threatening to sue a developer. If they sue one developer, they, by proxy, sue all of them in principle. So RMS was kind of right.
> If you want to use Bambu's software against their TOS
How does the TOS get involved here? I don't use their TOS. Why would or should they be able to enforce it? Note that it also depends on the jurisdiction. For instance, Microsoft's EULA never had any legal bearings in the EU.
"Bambu's software" is forked from an AGPL project and is therefore itself AGPL. I have a right to fork, modify, and use it how I wish subject to the terms of the AGPL. Bambu's TOS is irrelevant. Their TOS is superceded by the terms of the AGPL.
> it's their right to enact that restriction on their software
The issue here is less "they put in a restriction" and more "they are trying to bankrupt/imprison consumers for daring to modify the property they purchased."
> Bambu is trying to bankrupt/imprison their customers? Big if true!
I could interpret this three ways:
1. It's a reflexive double-down "nuh uh" denial, with no deeper cause.
2. You jumped in without knowing the risks that people (regular non-rich ones, anyway) face from lawsuits or CFAA charges, and you assumed the OrcaSlicer maintainer abandoned their project just to be polite.
3. You're whining that Bambu lawyers were "forced" to make disproportionate threats with nonsense logic. (Which isn't a huge step up, because it means they're still telling threatening lies for their own benefit.)
Have they threatened financial pressure? The answer to this question is: yes.
Legal representation typically has a cost associated to the individual,
unless you have the state put down a lawyer for you. You could
assume that bankrupting may not be the primary goal by Bambu Lab, but it
most assuredly can be an associated outcome, in particular if your
income is comparatively low. I don't think sarcasm is appropriate
here.
This is only true due to a firmware they pushed last year. It's an artificial limit.
There's no reason at all a local client couldn't just talk to a local printer without any cloud.
Every problem BambuLabs have here is self-inflicted. They could allow simultaneous cloud and local queue management with or without authentication.