Native is fast , no extra layer , the problem is maintaining on every native platform your app available. And AI tooling can handle that efficiently today , not way back then.
The problem with xplat is they add extra layer on top of platform native.
- React native and similar, add extra js runtime engine.
- Flutter and Kotlin MP add extra skia graphics engine.
this is when still using FreeBSD/NextBSD kernel, that DE using ObjC and basic framebuffer no x11 / wayland. The current one using Darwin kernel but still CLI only and no graphics subsystem supported yet.
"NAPI allows native Node dependencies to target Node without actually depending on a specific version of Node or V8. NAPI abstracted the V8 JS engine away, by providing JS-like APIs for: creating an object, declaring a property, etc.
NAPI is the contract that all modern native Node modules use to interact with Javascript." [1]
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.
reply