Hacker News Reader

Comment by liamgm | Hacker News Reader

it is okay for agpl3 app to consume propietary library , not the opposite that derived code must be same viral license

If you want to distribute binaries or code based on the (A)GPLv3, or use them to serve content over the wire, you have to distribute the source code of the entire software project under the (A)GPLv3. If part of that software is proprietary and licensed in such a way that you can't or won't distribute its code under the (A)GPLv3 or a compatible license, then you can't use any of the (A)GPLv3 code at all.

Now, there is some unclear legality around the distribution of plug-ins to a standalone software package. Are you allowed to distribute a GPLv3 plug-in to a proprietary program, like a GPLv3 plugin for Visual Studio? Maybe. Are you allowed to sell a proprietary plug-in for a GPLv3 software, like a paid plug-in to Emacs? Again, maybe.

However, the chances for both go down significantly if the "plug-in" is distributed by the same company as the software itself, and if the plugin is critical to major functionality of that software.

From i read that not "plugin"/module problem but library problem , difference is a lot. It's okay to depend on propietary library but not ok for propietary "plugin"/module.

Apple also doing this for their fork of CrossOver's Wine GPL called Game Porting Toolkit, composed by Wine + propietary D3DMetal DirectX library

are you referring to the exception for proprietary libraries that are part of the operating system? an exception that is needed because otherwise it would be impossible to build GPL software for non-free operating systems.

wine is under the LGPL which allows linking to any non-free libraries as long as those libraries are available in a form that allows relinking to a changed version of the application.

This sounds like pro-Bambu wishful thinking rather than an informed opinion. On what basis do you believe proprietary plugins or libraries are allowed under any conditions by the AGPLv3? And if you want to counter that you didn't say "under any conditions", I agree, but that means we need to discuss the particulars of this case to decide whether it's allowed or not.

Bambu took existing open-source, AGPL slicer software for free from the rest of the community and then has continually snubbed that open community by not giving back, or only giving back when they can maintain ultimate control to later decide to be less friendly to their users.

Sorry, no, they can build their own slicer from scratch (hah, good luck) or play by the license. Their networking plugin is tightly integrated with the AGPLv3 Bambu Studio. GNU's stance on plugins is fairly straightforward, and this is not at all a borderline case where the plugin interface is limited: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins

Nah you cannot force proprietary library that consumed by fork of viral licenced app to changed it license.

For example of this case is Apple Game Porting Toolkit which is fork of Crossover version of Wine GPL , Apple modified the code add dependency to their own implementation of DirectX's D3DMetal which is proprietary licensed library. So GPTK is composed with mixed GPL Wine app + propietary D3DMetal.

This can apply as long as the library has no references or dependencies on the application.

The illegality of Bambu Labs' actions results from the dependencies of the binary module on the AGPL app, not the other way around.

Reply on news.ycombinator.com