> -----Original Message----- > From: Bernd Petrovitsch [mailto:[email protected]] > 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 _______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
