It's likely the case that the author doesn't understand that they can't encumber their users under the terms of the license granted to them.
> Sharing or selling Blender add-ons (Python scripts)
> Blender’s Python API is an integral part of the software, used to define the user interface or develop tools for example. The GNU GPL license therefore requires that such scripts (if published) are being shared under a GPL compatible license. You are free to sell such scripts, but the sales then is restricted to the download service itself. Your customers will receive the script under the same license (GPL), with the same free conditions as everyone has for Blender.
Merely using an API doesn't infect GPL software (for example, syscalls on an OS). The actual legal argument from the FSF on this point is more convoluted, and hinges on the plug-in being a derivative work in the legal sense. Whether this is true or not isn't settled.
It seems to me that the legal community leans in the direction that using an API doesn't make a work derivative in and of itself, and that transforming the actual work and redistributing the transformation (or the work itself) is required. It is however clearly a gray area.
Yes, I agree. However using an API that may-or-may-not be bound by the GPL is different (de facto) from using an API that the licensor claims is covered by the GPL. It's quite a bit more risky IMO.
> using an API doesn't make a work derivative in and of itself
Note that while it might be a gray area, there is some (recent) precedent [1]. Although a SCOTUS ruling isn't quite as binding as it used to be... :(
IIRC that case isn't that the using an API makes it a derivative work, but that the API itself is copyrighted and that making an implementation of that API is a copyright violation (except for fair use, etc...).
EDIT: gpm is correct, they didn't arrive to such a conclusion.
They didn't decide either way on that question. To quote wikipedia "This conclusion rendered the need to evaluate the copyright of the API unnecessary".
Yeah...if that is the case, wouldn't nvidia graphic driver's kernel-shim-to-closed-source-binary not be legit, since the shim defines an API in the kernel and then the closed source blob uses that GPL'd API?
Nvidia are already moving to a world where the Linux kernel driver is GPLed and in Linux mainline and only the firmware and userspace parts would be proprietary. So that potential GPL violation is in the process of being resolved. Eventually the signed proprietary firmware and the upstream Linux kernel driver would be shared between the proprietary nvidia driver and the open source nouveau driver. Of course they shoved parts of the Linux kernel driver into the proprietary firmware as part of the process, so....
The bulk of a modern video driver on linux (and most operating systems) is not in the kernel. The kernel module just facilitates communication between the user space drivers in mesa and the hardware.
Precisely. Though perhaps NVidia would argue they're giving themselves a license exemption?
If you understand drivers as plugins (which makes sense, really, drivers are kernel plugins), and if you understand plugins as derivative, it would be even worse. It would mean every driver on Windows's copyright is Microsoft's by default. And that the original NVidia closed source is already GPL.
Not just NVIDIA, ZFS too. From the GPL perspective, any non GPL compatible license is considered the same way.
That said, that part of the GPL on library linking was never attempted to be enforced in court.
For additional entertainment: redistributing a linked GPL program to a non-GPL compatible non-OS bundled (those have an exception) library is supposed to be forbidden too, but is very often done. For example, for the Visual C++ runtimes.
It’s supposed to not be okay according to the FSF, which does quite some overreach in their FAQs. A reminder that the FAQs themselves are _not_ part of the license.
There is a way that Oracle could solve the ZFS situation; release a CDDLv2 that is compatible with the GPL, then the CDDLv1 auto-upgrade clause would mean that all CDDLv1 software that hasn't opted out of the upgrade clause would now be GPL compatible. Some parts of OpenZFS would need to be relicensed or reimplemented, but that job would be much smaller than reimplementing ZFS for GPL compatibility. More discussion here:
Drivers aren't plugins. They link to and incorporate GPL code. You can't grant special terms in that scenario. The best they can do is dual license their headers. The hazy area is where no linking happens and it's just a pure API without code sharing.
Do DKMS drivers have to include headers as redistributed? I was under the impression they didn't have to, but I have very little expertise with DKMS and could definitely be wrong.
> Sharing or selling Blender add-ons (Python scripts)
> Blender’s Python API is an integral part of the software, used to define the user interface or develop tools for example. The GNU GPL license therefore requires that such scripts (if published) are being shared under a GPL compatible license. You are free to sell such scripts, but the sales then is restricted to the download service itself. Your customers will receive the script under the same license (GPL), with the same free conditions as everyone has for Blender.