I'm developing a driver for my employer and am using some of the functions in linux/drivers/base/class.c to work with sysfs & udev:
class_create(), class_device_create(), etc.
I'm using the Centos 5.2 release with Linux kernel 2.6.24.7-65. I had to change the license to GPL
MODULE_LICENSE("GPL");
to get the driver to compile because of the
EXPORT_SYMBOL_GPL(class_create);
in class.c.

I need to keep the driver proprietary, so how do I work with udev and sysfs without using the functions in class.c? Is there another non-gpl interface to those systems?

It looks like I'm going to run into this same issue with the lower-level functions that class_create() calls, like sysfs_create_file(), kobject_uevent(), etc, so I can't just do an end-run around those functions.

If you really must keep it closed source, then you cannot use the code from class.c, but have to implement the same functionality yourself (to whatever sub-level it takes). The whole point of the GPL is that end-users should not be restricted from viewing/changing source code (the very license that lets you use class.c in the first place).

But I'd encourage your employer to consider the GPL license, especially if you are a hardware manufacturer.

On the plus side, the GPL is there so that those you distribute to (your customers) have reasonable access to the source code. It is only a license (it does not hand over copyright to the customer), and it does not mean that you have to open the source to the whole world, only to those who you distribute to.

On the caveat side, the customer will now have a license to redistribute the source code, and any proprietary secrets in the driver will be easier to access than if the customer had to disassemble the binary.

If there are significant proprietary secrets, you can often move them out of the driver and into the user application, unless the device has a very wide interface (eg a graphics card).

IMO having MODULE_LICENSE was overkill