Oracle offering DTrace for Linux

Posted Feb 23, 2012 13:18 UTC (Thu) by nevets (subscriber, #11875)
In reply to: Oracle offering DTrace for Linux by rich0
Parent article: Oracle offering DTrace for Linux

-EXPORT_SYMBOL_GPL(print_context_stack);
+EXPORT_SYMBOL(print_context_stack);

Is a clear attempt to circumvent the GPL. I don't know the CDDL license but just posting their modified source is not enough to satisfy the GPL license. You must also allow those that you distribute the code to, the same rights that you have with the code. Free to modify themselves, and they too must follow the rules as well.

Needing the print_context_stack makes their module a derived work. Not something that was ported straight from Sun OS.

Oracle offering DTrace for Linux

Posted Feb 23, 2012 17:17 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (1 responses)

Needing print_context_stack is an indication that the kernel developers feel it's likely to be a derived work. Oracle's legal department may have disagreed.

Oracle offering DTrace for Linux

Posted Feb 23, 2012 17:38 UTC (Thu) by nevets (subscriber, #11875) [Link]

As the author of print_ftrace_graph_addr() I would want them to remove that from their version. There's no need for a module to use it unless it was a derived work. I'll let others talk about the rest. It looks like the rest of the function originated from Arjan.

Oracle offering DTrace for Linux

Posted Feb 23, 2012 17:52 UTC (Thu) by kvh (guest, #83085) [Link] (4 responses)

I am not sure what you diff'd the source code against, but the 0.1 beta release of the DTrace code for Linux was against 2.6.32, and print_context_stack was not an exported symbol in that release. We needed to be able to override the default walk stack functionality (which in turn calls print_context_stack) and therefore I added an export for print_context_stack, and made it match the export for dump_trace (which is not GPL-only) since it is part of the same code. The ability to specify a walk stack function was added as well.

As soon as we realized that in later kernels print_context_stack was exported as GPL-only rather than the non-GPL-only we had chosen, we changed our code to match that, and we moved the part of the DTrace code that uses it GPL as well. This is evidenced in the source code drop for 0.2 that will be placed on oss.oracle.com very soon.

Oracle offering DTrace for Linux

Posted Feb 24, 2012 2:47 UTC (Fri) by clump (subscriber, #27801) [Link] (2 responses)

Given that DTrace's copyright owner now distributes DTrace for Linux, should there be any reason not to simply dual-license DTrace as GPL? I'm assuming inclusion/harmony with kernel.org is a goal, in which case the GPL seems rather obvious.

Oracle offering DTrace for Linux

Posted Feb 24, 2012 3:29 UTC (Fri) by nevets (subscriber, #11875) [Link] (1 responses)

Well if they would like any changes into the kernel their module would have to be shipped GPL (dual license or not), otherwise you can expect big NAKs to any changes that help them out.

Oracle offering DTrace for Linux

Posted Feb 24, 2012 19:56 UTC (Fri) by clump (subscriber, #27801) [Link]

Precisely. Working around deliberately incompatible licenses might be necessary if Oracle didn't own the copyrights to DTrace. I hope the goal isn't to make DTrace harder to use on other versions of Linux.

Oracle offering DTrace for Linux

Posted Feb 24, 2012 7:03 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

Thanks for the reply.

Sorry for not using the version that will be released "very soon" :) Thanks for the oss.oracle.com pointer though; I've been comparing the SRPMs. Seems like I did compare 2.6.32-201.0.1.el5uek to Red Hat's 2.6.32, where they seem to have backported the print_context_stack() independently. Certainly my fault, let me apologize.

Having recompared against 2.6.32-200.19.1.el6uek, on top of which was it based according to the change log, the following seems to have been exported:

+EXPORT_SYMBOL(syscall_nr_to_meta);

Now -- I don't get this; using symbols that are GPL-only from a non-GPL module is wrong, while using ones that have not been exported at all is fine?