choosing whether to allow dtrace integration with gnu/linux
Posted Jul 9, 2008 20:09 UTC (Wed) by mjw
In reply to: More DTrace envy
Parent article: More DTrace envy
we would welcome DTrace in Linux
You seem to flipflop a bit on the that point :) Certainly you don't have any obligation to make it possible by removing the legal uncertainty around the current dtrace CDDL license and how it interacts with the GPL. But as you can see from the discussions whenever you claim that dtrace would be better than sliced bread for integration into GNU/Linux systems (or at least so much better than what is currently only half-integrated, like Systemtap and friends), this legal uncertainty is the only real reason dtrace isn't even a choice in providing something better.
You keep claiming that there is no way to resolve the legal ambiguity without harming the OpenSolaris community. If true, then indeed dtrace will never be a choice for GNU/Linux as a whole. I am not convinced that is really impossible though. Pure GPL or LGPL is too copyleft for your taste. That can be rectified by adding an explicit exception for your use cases. This is what Sun did for OpenJDK which had the same constraints, there still was proprietary code that needed to be linked to. The other way is of course dual-licensing. Which you say you don't want because of the fear of forks. Which of course is true and could happen in theory. But Sun also did this for projects like Glassfish and NetBeans which were originally CDDL only, but are now dual licensed CDDL/GPL. So it seems at least Sun legal thinks this is an appropriate way to both protect a code base and make it more compatible with other communities. The suggestion from others to only do this if you can get some prominent figures in the community to say that they support the dual licensing and condemn single-license forks is a good suggestion. Richard Stallman did that explicitly when Mozilla dual licensed their code (see the legal FAQ Q/A 11 till 13).
Now I am not claiming that systemtap, lttng, tracepoints, markers, kprobes, utrace, uprobes, ftrace, etc. did everything so much better than dtrace. In fact you could see all the trouble they needed to go through to make their implementations as generic as possible before being (partially) accepted and integrated into mainline as an indication of the hard work that still is still ahead for dtrace to get integrated and accepted even if the legalities were cleared up. But they did make it so that eventually their code could be integrated legally into the mainline kernel and intermingled with each other to ultimately provide better, safe and powerful frameworks for observability under GNU/Linux.
It will be interesting to see how these projects morph GNU/Linux into a fully observable system such as solaris has through dtrace. It would be even more interesting if you could lift the legal uncertainties around dtrace and make it a true contender in this coopetive race towards full observability. It is your choice to make though.
to post comments)