Does the GPL protect your GPU kernels? Host-kernel languages such as OpenCL, CUDA, DirectCompute and RenderScript don’t really link a kernel. Instead, they load and launch it. That makes me worry that the GPL might not be ready for GPU kernels.
Disclaimer: I am not a lawyer. Below is my humble opinion only. This post is meant for insight, not as legal advice.
The GPL has always protected you against someone running away with your code and making money with it. At the very least, it forces people to give their improvements back to the community. Unprepared companies got quite stressed when the GPL forced them to give their software away. Does that protection also hold for GPU kernels under the GPL?
The GPL is already quite complicated when you mix it with commercial code. GPU kernels add a new grey area. New to kernels? Read how to learn OpenCL and CUDA first.
If your GPL kernels are dual-licensed, a commercial user could pick the GPL option instead of buying a license. Read below why that might work for them.
What the GPL FAQ says about plug-ins
Some people claim that a kernel is an independent piece of software that gets loaded, not linked. If so, the GPL does not protect the code of GPU kernels. The GPL FAQ says this about GPL plug-ins for non-free software:
If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in’s license, giving permission to link it with the non-free main program.
From the first paragraph, we can conclude the following. Suppose you generalise a kernel into a standard plug-in (for instance, every kernel has kernel void performFilter() ) and ship it with the GPL license. Then non-free software may load those GPU kernels, even under the GPL. And yes, “exec” describes launching a kernel better than “linking” does.
The second paragraph describes what happens if loading and launching a kernel counts as linking. I can only think of a few such cases, and you can avoid them.
It gets more difficult because a lot of existing software already has complete functionality. There, the GPGPU code is truly a plug-in that replaces existing functionality with faster code. The software doesn’t depend on it.
How to protect your GPU kernels under the GPL
Always be explicit. If you really want to be sure, extend the GPL with a statement that loading the kernel file counts as dynamic linking, so the GPL applies. Ask your lawyer how exactly to do this.
For commercial kernels, I recommend checking the licenses that come with Java code. Anyone can decompile jar files, so those licenses face the same problem.
Which license do you use?
I hope we can discuss this in the comments and get to the bottom of it. Do you release your own kernels under the GPL, or under another license?