> NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".
Going by GNU's description of what does and does not extend the GPL requirement[1] and how Blender plugins works, to me at least it seems they very clearly have to be GPL. Unless someone took the route that is common in closed source Linux drivers of having a small open source module that communicates with a binary blob where the majority of the actual interesting code is, but I have not seen any Blender plugins like that.
The Linux kernel actually provides a specific license exemption[2] for the headers that makes software using syscalls not bound by the GPL.
[1] https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins
[2] https://www.kernel.org/doc/html/v4.18/process/license-rules....
Frankly if you want to be doing any meaningful computation in your addon it probably makes sense to go this route and have the closed source part in C while the addon "bridge" is python.
We should GPL the software that is calling the Api of the GPL software.
>not all software running on Linux using Linux APIs (syscalls) is GPL
This is because linus Torvold(Other contributors) has given the syscall exception along with GPL-2.0. That's why there exists all kind of proprietary software running on top linux os.
Note: I am an open source officer I deal on this topic very often
Well yeah it's a debate - I guess this is their side of the debate. Arguing for something isn't 'pretending'.
