This is a follow up of my existing question Does GPL apply to proprietary software that is linked in through a compatibility layer, but has a new major focus (i.e. the shadow Linux).

Suppose a Linux-like kernel (i.e. "shadow Linux") is developed from scratch, which use a very similar kernel data structure and intra-kernel APIs as Linux kernel. But this new kernel is released under permissive open source licenses.

Then driver (or kernel modules) developed for shadow Linux don't need to release their sources. But considering the similarity of the kernel of Linux and shadow Linux, it is very straightforward to develop a compatibility layer in the Linux kernel that can let Linux to use proprietary driver binaries for shadow Linux directly.

Now if you want to develop a driver for Linux without releasing your code, you just need to develop a driver for the shadow Linux.

Is this possible (not considering the difficulties of the development of the shadow Linux)?


(1) The shadow Linux can't replace Linux which take too much effort to develop. To simplify the development of the shadow Linux, it doesn't include anything that is not needed to develop a kernel module/driver, and it contains a lot of bugs and performance issues and is not a production level kernel.

(2) To prevent any copyright issues about Linux, althought the shadow Linux kernel's data and API structure is very similar to Linux, they are not the same, e.g. not the same name and even structurally redesigned but still allow a compatibility layer to be developed with ease.

  • 3
    “it is very straightforward” – no, it is very difficult to show that such a close emulation of the kernel's internals wouldn't be a derivate work, and thus bound by the kernel's license. In any case, the module would have to declare a MODULE_LICENSE of “GPL” in order for the Linux kernel loader to give the module access to many APIs.
    – amon
    Jan 19, 2021 at 10:19
  • @amon (1) " it is very difficult to show that such a close emulation of the kernel's internals wouldn't be a derivate work" Is it about showing it is not a derivate work or to show it to be a derivate work to be forced to open the source? (2) OP said to get rid of copy right issues, the API of the new kernel can be redesigned, but. (3) Can't "MODULE_LICENSE" be dealed with the compatibility layer? It won't be shown in the binary.
    – jw_
    Jan 21, 2021 at 1:02
  • @amon BTW why is this question downvoted? Hope it not just because it talk about how to not release your source.
    – jw_
    Jan 21, 2021 at 1:04

1 Answer 1


As I interpret the question your plan is that you have your own API and ABI ("shadow linux") with a permissive license. The ABI is then implemented in linux which may be used to insmod kernel modules compiled for "shadow linux". Right?

You are right with that, at least in theory. There are no actual violations of the terms, because no GPL code is used in the module.

There are examples of this being done already, like NDISWrapper. It implements a compatibility layer for proprietary windows drivers in linux. Totally legal.

You could also implement a virtual machine and run proprietary byte code in kernel space.

BUT: Why even bother? It is already common practice to write proprietary kernel modules. It is illegal, yes. There are efforts to prevent this, like this. But that doesn't seem to stop companies from using binary blobs.

Finding holes in licenses is not that hard. There will always be possibilities to exploit copylefted code, but that doesn't mean you should do it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.