-----Original Message----- From: Bernd Petrovitsch [mailto:bernd@petrovitsch.priv.at] Sent: Wednesday, November 23, 2011 2:51 AM To: Sengottuvelan S Cc: Graeme Russ; Greg KH; Kernel Newbies; Jeff Haran Subject: RE: GPL-only symbol Error
On Die, 2011-11-22 at 17:21 -0800, Jeff Haran wrote: [....]
Perhaps, but that's not what I asked about. It seems to me the essence of GPL is that it grants people the right to modify GPL sources like the Linux kernel in any way they want so long as they make those changes available to whoever uses the code in the future. I don't see
You forgot that you also have the hand out the same rights you have to other people with the (changed) source. You forgot that all of that also holds for all of your changes, removal and additions to that code (and lawyers don't care if the changes good, bad or ugly).
Which is what I suggested in the hypothetical scenario I described. The change to the kernel source to change an EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL() would be published.
anything in it that prohibits specific changes. So if I take a symbol that in the sources from kernel.org is declared with EXPORT_SYMBOL_GPL(), make a 1 line change that declares it EXPORT_SYMBOL() and put that on a publically available web site, how have I violated GPL?
IANAL (and there are pretty much no non-lurking lawyers on LKML), but you probably didn't violate the GPL as such on the kernel you downloaded with such a change. But that hasn't anything to do with the legal side - ask a lawyer if can change the legal "status" with such a change.
Just to be clear, I haven't done any of this. This thread originated with somebody else asking why he was getting this build error when he attempted to build his non-GPL module that referenced EXPORT_SYMBOL_GPL() exported symbols. I was attempting to explain to that original poster why he was getting the error.
Let's say I then ship a product that uses that custom kernel and a non-GPL kernel module of my own writing that only works with the custom kernel, how is that prohibited in the GPL license?
That's the actual bug: You assume that you can legally make a proprietary Linux kernel module by simply declaring to do so (and going deeper is not quite possible as we do not know the module ....).
I can clearly legally write a user space program that results in calls to kernel symbols without publishing it. To do that I load parameters into registers and onto the stack and issue a trap to generate a system call. A kernel module does almost the same thing, except instead of generating a trap, it makes a more traditional function call. The difference is technical and I don't see anything in the COPYING file that makes any reference to this difference. If I have missed that verbiage in the license, please point it out to me.
Than you stumbled on a warning to help you to realize that (and not hitting such warnings or plain simply removing them doesn't change anything on the legal side IMHNLO). And you think you can "fix" the warning by simply removing it (ignoring the underlying issue).
Again, it I didn't stumble on this warning. The original poster did. All I did was respond to a post on a public email list.
But your kernel module is very probably a derived work of the Linux kernel anyway and thus automatically and implicitly GPL (even if your whole company may want it, has been told or think otherwise).
"very probably a derived work". That is a big assumption. What in the license defines all code that makes calls into kernel symbols via the dynamic module loader mechanism different than code that calls into that code via a trap?
Not that I am planning on doing this and I've never done it in the past, but technically it seems that there would be no violation here.
Technically, your module is a derived work of the Linux kernel unless proven otherwise.
Again, not my module, not my company's module. I was simply answering a post to this email list and asking questions around a hypothetical scenario. Jeff Haran