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.
Yes , Win32 / DirectX in common HAL for games now , just compile your game for windows/steam , you can run everywhere , minimize the headache of doing native game development , like breaking with X11 / wayland kde / wayland gnome / wayland mutter .
For the OSes runtime side you can depend on SteamOS / Apple's Game Porting Toolkit / Crossover / Proton / DWProton / Wine / and Android's Winlator/Gamehub/Gamenative .
For DirectX compatibility you can depends on Apple's D3DMetal , DXMT , VKD3D , DXVK and WineD3D .
I think not only win32 but win32 + directx API, the most used API for gaming industry. Wine , Proton , Crossover, DXVK, VKD3D, D3DMetal , WineD3D, Apple game porting toolkit , SteamOS , Winlator/Gamehub etc android Wine variant , ReactOS , MinGW from that API
avalonia xpf is xplat wpf runtime on top avalonia, paid. avalonia maui is xplat maui runtime on top avalonia, mit for now. avalonia have they own ui called avaloniaUI also xplat, free.
