On the value of EXPORT_SYMBOL

On the value of EXPORT_SYMBOL_GPL

Posted Oct 6, 2005 15:02 UTC (Thu) by sepreece (subscriber, #19270)
In reply to: On the value of EXPORT_SYMBOL_GPL by mingo
Parent article: On the value of EXPORT_SYMBOL_GPL

The core advice here is completely solid - if you're distributing a non-GPL kernel module you should definitely consult a lawyer. IANAL.

I'd like to bring in a couple of additional considerations.

It's important to remember that copyright covers only expression, not function. I would tend to think [IANAL!] that any exported interface would inherently be a functional aspect, not an expressive aspect, and hence not covered by copyright, no matter what restrictions you claimed for it. The abstraction-filtration-comparison method is supposed to make sure that simple functional equivalences can't be claimed.

HOWEVER, the important thing about the GPL is that it's what allows you to distribute all the rest of the kernel. So, if you don't play by the rules, which in a future version could conceivably include abiding by the EXPORT_SYMBOL_GPL rule, you could still lose the ability to distribute the kernel, whether or not your work was legally derivative. I think, though, that that would only be the case if the license explicitly stated that rule. Since the rules in the license today are based on whether your work is derivative, I think it would be hard to win a legal case, under the current license, based on that distinction.

In particular, I would think that the "shim" or "adaptation" approach mentioned in the article would be a reasonable defence under the current license language. Assuming the shim module connects to Linux-exposed interfaces on one side and provides non-Linux interfaces that a binary module needs on the other side, I think you would have a hard time claiming the binary module was a derived work of the kernel, even if the shim module itself was, especially if the [non-Linux] interfaces exposed by the shim to the binary module were preexisting interfaces from another operating system or environment.

Again, IANAL. I've read a lot about copyright law, but don't claim to be an expert. I also believe that it's good practice and good ethics to respect the intentions of the license, not just the language. However, that said, the function of an operating system is to provide an execution environment for stuff that is explicitly not part of the operating system, potentially including both user-space and kernel-space non-parts.

I would prefer to see the license drawn and interpreted so that it kept that distinction. I would prefer to see the license distinguish between changes to the kernel functionality (the code that provides the operating environment) and changes to things that run in the operating environment, The former changes being derivative works, the latter being simply uses of the system.

(Log in to post comments)