Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Writing closed-source Linux kernel modules is legally "difficult". It is generally believed that modules which make use of highly Linux-specific internal infrastructure can be considered derived works of the kernel and thus required to be released under GPL. It's not always perfectly clear what is allowed and what is not and hardware vendors are reluctant to find it out in court. Some kernel APIs are explicitly marked as not callable from proprietary modules and the module loader enforces this. As a famous example, NVIDIA claims that inability to use one of these APIs prevents them from supporting Optimus in their video driver.

Hardware vendors who don't want to open their drivers need to work around these issues. They can either divide the driver into open-source Linux-specific part and closed-source "hardware support library" which avoids calling suspicious kernel APIs, or simply move the whole driver to a userspace shared library and give userspace processes access to the hardware.



So the userspace driver uses the same syscalls or they need to do the work around. I guess I am most interested in the workarounds.


Userspace components are expressly excluded from being considered derived works of the kernel by text at the top of its license. Within the kernel, individual symbols (e.g. function calls) are explicitly tagged with a bit that tells the kernel whether they can be used by non-GPL code, and the kernel checks this at runtime.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: