Advertisement
Interested in hardware, diags, validation, Linux, C, ARM, Microcode and low level programming and blazing networks?
| |||||||||||||
|
| |||||||||||||
Binary modules and derived worksBinary modules and derived worksPosted Dec 11, 2003 15:15 UTC (Thu) by zone (guest, #3633)Parent article: Binary modules and derived works Restricting the symbols that are available to binary modules would effect modules such as NVidia's that are distributed as binary modules meant to be used with standard distributor kernels. However, for Linux-based appliances, which symbols are available in the mainline kernel might be a non-issue. An appliance manufacturer could just apply EXPORT_SYMBOL() to every symbol in the kernel that they needed, release their changes under the GPL, and then create a binary module that uses their newly created interface. Some kernel developers might cry foul, but the GPL protects the right of the appliance manufacturer to create a derived work, and deciding which symbols to export to binary modules could definitely be seen as a valid technical change.
(Log in to post comments)
Binary modules and derived works Posted Dec 11, 2003 18:30 UTC (Thu) by maolson (subscriber, #4077) [Link] The problem with your example, as I see it, is that having enough exposure to the kernel source to create the exports strongly suggests that the binary module would be a derived work. To understand which new exports would be needed, the person creating them would need to be intimately familiar with GPL'd code and would be working from that knowledge when creating the hypothetical binary module.
|
|
||||||||||||