原文链接：On the value of EXPORT_SYMBOL_GPL
当一个可加载模块被插入时，它对内核函数和数据结构的任何引用必须与当前运行的内核链接。然而，模块加载器并不提供对所有内核符号的访问；只有那些被明确被导出的才是可用的。导出这个需求减少了模块可以看到的 API，尽管没有减少那么多：在 2.6.13 内核中有超过 6000 个符号被导出。
导出有两种形式：vanilla（EXPORT_SYMBOL）和 GPL-only（EXPORT_SYMBOL_GPL）。前者可用于任何内核模块，而后者不能被任何没有 GPL 兼容许可证的模块使用。如果模块声明的许可证不合格，模块加载器将通过拒绝访问只适用于 GPL 的符号来执行这一区别。目前，只有不到 10% 的内核符号是 GPL-only 的，但是 GPL-only 符号的数量正在增长。在许多情况下，有一定的压力使新的导出只适用于 GPL。
经常有人争论说，这两种类型的导出没有实际区别。那些认为所有的内核模块都被内核许可证要求为 GPL 许可证的人认为所有的符号在任何情况下都是隐含的 GPL-only。另一个阵营认为模块接口是 GPL 不能跨越的边界，他们不相信只适用于 GPL 的限制可以被坚持。在任何情况下，只适用于 GPL 的符号可以很容易地通过修补内核、虚假声明 GPL 兼容的许可证，或者通过插入一个提供更广泛访问感兴趣的符号的垫片模块而被规避。
然而，Linus 认为，仅允许 GPL 的导出是重要的。
我和一两个律师谈过，这(a)绝对有 巨大 的区别，(b)他们喜欢这样。
事实是，法律并不是一台盲目的、无意识的计算机，不会照字面意思去理解你所说的东西。意图是非常重要的。而用 xxx_GPL() 的版本来表明它是一个内部接口，确实非常有意义。
其中一位律师说，这比试图让许可证解释所有的细节要好得多——将意图编入代码本身不仅更灵活，而且更不容易被误解。
他还指出，规避纯 GPL 的导出需要一个明确的行动，使其明确由此产生的版权侵犯是一个故意的行为。
不管它们是否有任何法律意义，只适用于 GPL 的导出确实成功地传达了内核开发社区中希望限制使用非自由内核模块的大量子集的意愿。彻底禁止这类模块可能不会很快被提上日程，但它们的功能也不可能有太大增长。