Comprehensive Response to Bambu's AGPLv3 Violations
135 points by susanthenerd
135 points by susanthenerd
I appreciate the effort they're putting into this. Long time (last century) open source user and occasional contributor, Bambu printer owner, have tried unsuccessfully to get the either Bambu Studio or source-compiled OrcaSlicer to work on my potentially borked Debian machine. I've also followed the FLOSS licensing for just as long. AGPLv3 has always been something that has felt... a little uncomfortable for me, although I understand the motivation. I also have no love for how Bambu is handling all of this and I think they're definitely violating at least the spirit of OSS if not the legality of it.
The thing that gives me pause: is the assertion here that AGPLv3 software cannot call dlopen() on a non-free binary? Or that it's violating the AGPLv3 license by releasing a .so file that shares no source other than some function pointer signatures with the AGPLv3 software? In this particular case I understand the aversion to Bambu doing this since they're the same entity releasing both the modified AGPLv3 software and the non-free binary, but in the more general case it's a bit of a struggle to wrap my head around. Taking it to an extreme, it seems like this would mean that AGPLv3 software that can load plugins in a standardized format is... incompatible with its own license? For example, AGPLv3 audio software being able to load VSTs (https://en.wikipedia.org/wiki/Virtual_Studio_Technology)... feels like it could be quite complicated to really grok the licensing implications.
Based on this thread it would appear that Bambu is intentionally routing all networking through this closed-source lib, so that without it the software is essentially useless. They even appear to have anti-debugging features that crashes when you attempt to inspect what it's doing.
From the linked Reddit thread:
Yes and yes. Use OrcaSlicer without logging into your BL account. Set your printers in LAN + dev mode and block their internet access through your router.
OrcaSlicer/Bambu Studio has a ton of functionality that doesn't depend on this network library. You don't need the network library to use your printer. You can run the printer with no network access at all and write the sliced g-code straight to an SD card that the printer will consume. This library provides optional and exceptionally convenient functionality.
is the assertion here that AGPLv3 software cannot call dlopen() on a non-free binary?
That is not the position of the FSF. As they describe in their FAQ entry about plug-ins:
When is a program and its plug-ins considered a single combined program? (#GPLPlugins)
It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in?
Please see this question for determining when plug-ins and a main program are considered a single combined program and when they are considered separate works.
If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way. A main program that is separate from its plug-ins makes no requirements for the plug-ins.
AFAIK, that is true for all GPL versions. My short-hand for this is whether the plug-in is usable by any other software prior to being written for use with the GPL-covered program. If the plug-in is only useful with the GPL-covered program then it is effectively a part of the program.
Right, so I am very curious how that would actually be interpreted in court, especially with Google v. Oracle to consider (where implementing against APIs was found to be Fair Use).
Your short-hand is interesting and that has generally been how I've interpreted things as well... but VSTs are a very interesting exception (https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/API+Documentation/Index.html#creation-and-initialization-from-host-point-of-view). VSTs are used as audio processing plug-ins and definitely meet this criteria:
If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins.
The way you and I have interpreted this conflicts with what the FAQ says. VSTs share complex data structures with the host application and are dynamically linked (via dlopen() et al), but are also developed completely independently of the host application. This seems to imply to me that a GPL host application (e.g Audacity, GPLv2) is problematic if it were ever distributed with any non-GPL VSTs.
The other interesting bit is that GPL is only concerned with distribution, AGPL is too but also considers network access to a service to be "distribution". In the Bambu case here, the AGPL software (Bambu Studio) is not being distributed with the network plugin; the network plugin is a piece of software that is downloaded and installed separately. The argument is going to have to be "the bambu network plugin is not allowed to be distributed without source because it is covered by AGPLv3 virally, because although it isn't distributed with Bambu Studio it ends up being part of the Bambu Studio program in the end"
I'm really curious to see how that ends up panning out if it goes to court. It seems, to me, unlikely to succeed. I appreciate why GNU/FSF see it that way, but I'm not sure the courts will agree.
In Google v. Oracle, the only thing Google copied was the API. They didn't copy the source code to the implementation of the Java library. Their use of this copied API was considered transformative, since they reimplemented the library from scratch in a new context, hence fair use.
If that standard applies to a plugin API for a GPLed program, then I could write a program that implements the API, and distribute it, separate and independent of the GPL'ed program, using the licence of my choice, without being legal liable for a GPL violation, regardless of what the FSF says, because according to this standard, it's fair use, hence the GPL does not apply. Note that I'm not distributing the GPL'ed program itself, just my own code, which conforms to this API. I think this scenario actually occurs with closed source Linux kernel modules.
In the case of Bambu, I think it is unclear that Google v. Oracle applies, since in this case, they are distributing the closed source plugin as an integral part of the otherwise GPL'ed slicer. I think this use case is less "transformative" and more "derivative work".
But I am not a lawyer.
In the case of Bambu, I think it is unclear that Google v. Oracle applies
I agree. I think a lot of the nuance here is going to be interesting from a FOSS perspective if it goes to court and needs to be interpreted, because there are so many slight variations of what’s happened here that would have a reasonable different outcome.
If I put together an API spec and publish it as an open binary spec, implement the host side in an (A)GPL application, and don’t implement the plugin side… I obviously haven’t done anything wrong. The application works fine without any plugins added, they’re not required functionality. If someone else puts together a closed source dynamic library that also implements that spec, without ever having seen my application… they obviously haven’t done anything wrong.
Per the (A)GPL, those probably can’t be distributed as a bundle, even if the bundle has permission from the author of the closed source plugin: the distribution doesn’t include all of the source for the full distributed application and is a GPL violation.
However… Bambu isn’t distributing these together either. Their version of Bambu Studio gives you the option to download and install it, but it’s not required for the software to work. You can import models (or download them from makerworld), slice them, and export the G-Code all without this plugin. You just can’t upload to their cloud service. Is that “required”? Hard to say.
The thing that gives me pause: is the assertion here that AGPLv3 software cannot call dlopen() on a non-free binary? Or that it's violating the AGPLv3 license by releasing a .so file that shares no source other than some function pointer signatures with the AGPLv3 software? [...] Taking it to an extreme, it seems like this would mean that AGPLv3 software that can load plugins in a standardized format is... incompatible with its own license?
The SFC quotes the relevant part of the license text:
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, such as by intimate data communication or control flow between those subprograms and other parts of the work.
So it's okay to implement support for plugins. The problem comes if your application specifically requires a certain plugin for its common functionality. (The .so mentioned in the SFC post seems related to networking, and it's plausible that you cannot conveniently use the printer without network access.)
If you are interested in more context, the full paragraph in which this quote is contained is as follows:
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 and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. 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, such as by intimate data communication or control flow between those subprograms and other parts of the work.
In particular it is possible to develop AGPL software on OSX that depends on proprietary SDKs provided by Apple on all OSX machines (or depending on Windows stuff for a Windows application, etc.).
the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
That is the ambiguity that makes me uncomfortable. If you decide that you don't want your Bambu A1 on the network at all, Bambu Studio sans the network plugin is fully functional. You can download stuff from Maker World, you can import your own STL/3MF files, you can configure your print settings, slice the model, and write it to an SD card that you hook your printer up to.
Doing it networked through Bambu's cloud service is incredibly convenient. I use it all the time. But it is ambiguous as to whether it's "required" or not.
Let's consider a slightly different scenario that is conceptually the same for me although the implementation is mechanically a little bit different. Instead of libbambu_networking.so, let's say that Bambu released a bambuprinterd. It's a standalone closed-source binary that listens on a Unix domain socket and makes HTTPS requests out to Bambu's cloud service. The interface isn't documented. They also release a Fusion 360 plug-in that lets you print direct from CAD. Bambu then makes a fork of OrcaSlicer and adds code to it that knows how to talk to bambuprinterd. That leads to an absurd set of circumstances:
The act of adding source code to an open source project cannot affect the license of an unrelated piece of software (bambuprinterd). If it were the case that adding code that does "intimate data communication" could cause the license of the target code to change, that would mean that an AGPLv3-licensed version of Samba back in the day would mean that Microsoft would've been required to open source their SMB service.
The act of adding source code that knows how to speak a particular network protocol to a project and open sourcing those changes in compliance with the license... so that people who receive the compiled software can use and modify that source code... is that where the license violation actually happens? Source code that knows how to talk to a proprietary undocumented service is disallowed under the AGPLv3?
Source code that knows how to talk to a proprietary undocumented service is disallowed under the AGPLv3?
Basically, yes. You cannot redistribute to someone else a derivative of an AGPL project if you cannot also distribute all the source code. So if you modify a piece of AGPL software to talk to a proprietary service (or proprietary dynamic library, etc.), you can use it yourself but you cannot redistribute it to others. (And if you write the full program yourself, you can distribute it under any terms you want, but if you choose AGPL they cannot redistribute it to others.)
Note that this entire conversation still holds just for GPLv3, without the Affero provisions
the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require
This is the only piece of the AGPLv3 that, to me, makes that implication. The word "require" is doing a lot of heavy lifting here and if this ends up in court, I'm not convinced that the GNU/FSF interpretation is going to stand up. The Bambu network plugin is not "required"; you can run the software without it.
Oracle v. Google established that APIs are essentially fair use. Oracle v. Remini Street so far looks like it's going to establish that interoperability does not make something a derivative work. The notion that the (non)-existence of a GPL library that implements a specific API outside of the GPL application that's being distributed determines whether or not that distribution is violating the terms of the license seems absurd.
There’s one thing in this that bothers me, seeming a fairly egregious error.
As we have previously explained: Object Code combined with AGPLv3'd software must also be licensed under AGPLv3! As such, these Object Code libraries are governed by the AGPLv3. SFC and our volunteers are within our rights to reverse-engineer these libraries for the purpose of creating our own Source Code that can function as a drop-in replacement in Bambu Studio.
The first sentence is true. But the second does not follow from the first. These libraries must be AGPLv3, but that “must” only means “are required to be”—it does not mean that they are. It’s perfectly possible for them to have just, y’know, violated the AGPLv3 in their own stuff. If the license they’ve actually granted denies reverse-engineering, you’re breaking that license by reverse-engineering. If you want to compel release as AGPLv3, the courts are open. You’ll probably have a solid case. And if they want to complain about you breaking their license, they can sue you, and you can try the “it was supposed to be AGPLv3” defence, which may well be compelling. But it’s still a “he hit me first!” sort of a situation to a considerable extent.
GPL licenses are not functionally viral as a physical inevitability, but legally viral, and legal systems move slowly.
This seems like a distinction without difference. It must be under AGPLv3 to be distributable at all. So there's no working action one could use to claim it isn't, not matter what is written anywhere.
Unless a court decides otherwise which would indeed be A Whole Thing.
If the license they’ve actually granted denies reverse-engineering, you’re breaking that license by reverse-engineering.
They aren't in a position to grant a different license to the libraries, unless they want to go with the argument that they never had a license to the Prusa slicer in the first place, or they don't want to have it now. If they accepted the Prusa AGPLv3, then they already accepted that "required" libraries would have to be licensed under AGPLv3. There's no separate decision for them to make, other than the option of rejecting that requirement and thus rejecting the original license. "This License gives no permission to license the work in any other way…"
One could argue about the interpretation of the library provision of the AGPL, but the whole theory behind the GPL has always been that if you distributed the licensed software, you must have implicitly accepted the license, and all that it requires.
(Edited to fix my broken logic)