Dear Mr Moglen, I am developing proprietary software which will eventually become an "appliance" of sorts, and will need a kernel to run on. However, this software will also require proprietary NIC drivers, extensions to the kernel's TCP/IP stack, and overall, will add many functions which need to run in kernel-space and be accessible by user-space programs. The Linux kernel's somewhat recent move toward "GPL-only symbols" presents a problem for people like myself, who are suddenly no longer sure Linux is an appropriate kernel that can serve their needs in the future. It also muddies the waters such that a company can no longer be ensured that code which can load as a module is free from becoming encumbered by the GPL. I may be required to choose a different kernel than Linux for my "appliance" because of this uncertainty. I will certainly need to plan for supporting more than one underlying kernel, for example, the ability to run atop (and load into) both Linux and FreeBSD. Can one expect their product to be labeled a "derived work" if it functions entirely as a loadable module and does not make use of GPL-only symbols? The answer from some in the Linux community is still yes. Does this change if the work is also compatible with a different kernel, and thus is a marketable product offering the user a choice of kernels, or perhaps, simply defending the business from becoming "locked in" to a kernel with a foggy future for proprietary software? Should all makers of "appliances" who need loadable modules to interface with proprietary hardware now see the Linux kernel as a dead-end platform? We may find ourselves having to contribute code to FreeBSD to bring some of its VM capabilities up-to-speed with Linux, which would benefit the free software community. However, we are not sure we can open-source and GPL-license the in-kernel code we need to make our proprietary hardware and "appliance" work -- it's part of the secret sauce. This is why Linux is an uncertain option.