| |||||||||||||
Oracle offering DTrace for LinuxOracle offering DTrace for LinuxPosted Feb 23, 2012 17:32 UTC (Thu) by khim (subscriber, #9252)In reply to: Oracle offering DTrace for Linux by lambda Parent article: Oracle offering DTrace for Linux
However, as an exception, kernel developers have granted the ability for non-GPLed kernel modules to link against the kernel, as long as they only use certain symbols that are exported via EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL. Citation needed™. And it's needed really badly because historicaly Linux developers had the opposite POV. It's hard to interpret the infamous Linus's If an author claims your work is derivative, you should step very very lightly. except as "if you lawyer believes your work is not derivative and if you are ready defend this POV in court, then maybe, just maybe your work is indeed not a derivative and thus can be non-GPL licensed". However, someone else cannot come along, and grant themselves additional freedoms. Yes, they can. This is just a marker. But yes, what Oracle did is a clarion call: they took symbol which was marked with "no way in hell can you use it without creating derived work" symbol and removed this mark. Their lawyers should be prepared to defend removal of said mark quite seriously. And I can imagine that some kernel developers might wind up being fairly unhappy about that. Not necessarily. If it can be shown that DTrace indeed uses this hook in way which does not imply intimate knowledge of kernel internals then this will be strong signal that this symbol was marked as EXPORT_SYMBOL_GPL by mistake.
(Log in to post comments)
Oracle offering DTrace for Linux Posted Feb 23, 2012 19:28 UTC (Thu) by lambda (subscriber, #40735) [Link] Sorry, you are right. I got the sense backwards in terms of which one is more explicit. EXPORT_SYMBOL is not explicit about what it is declaring; using it, you may or may not be creating a derived work. EXPORT_SYMBOL_GPL is a way of documenting "if you use this interface, you are clearly mucking about in the internals of the kernel and thus are clearly creating a derived work." The only explicit disclaimer is that any interface exported to user space is disclaimed from creating a derived work for purposes of the GPL. That doesn't really change my point about the intent of changing an interface from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL; that change says "I know that the kernel developers have said that what I'm doing will create a derived work, but I am going to do that anyhow, and I am not releasing my module under the GPL." That does not automatically mean that what they are doing is a copyright violation; but it shows that they are aware that there are kernel developers who believe that use of that interface constitutes creating a derived work, and they are proceeding anyhow.
Oracle offering DTrace for Linux Posted Feb 24, 2012 0:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
If you look at this[1] comment, it isn't a proper diff. The kernel that DTrace is based on didn't export print_context_stack at all and their patches exported it as non-GPL, whereas more recently, kernel developers exported it as GPL. A grep through the 2.6.32.57 tarball doesn't show print_context_stack being exported at all, so this seems, to me, to be taken out of context.
Oracle offering DTrace for Linux Posted Feb 24, 2012 13:49 UTC (Fri) by vonbrand (subscriber, #4458) [Link] AFAIU, there are three cases here:
Oracle offering DTrace for Linux Posted Feb 24, 2012 21:14 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
I would imagine if it still weren't exported today, there would be discussion of making it non-GPL enforcing export for merging. I imagine other symbols gained an EXPORT_SYMBOL after being unexported for a time. In any case, it seems a moot point since (apparently) the 0.2 version obeys the EXPORT_SYMBOL_GPL.
|
|||||||||||||