Recent Features
| |||||||||||||
On DTrace envyOn DTrace envyPosted Aug 8, 2007 13:07 UTC (Wed) by paulj (subscriber, #341)In reply to: On DTrace envy by tfheen Parent article: On DTrace envy
DTrace is licenced under the CDDL, the Linux kernel is licenced under the GPLv2. Those two licences are incompatible, so any wholesale lifting of DTrace into Linux would give you a result which is (legally) undistributable. It's pretty simple. a) Follow AHL's recipe (see his blog, linked to several times in this article) That gets you GPLed reimplementation of certain DTrace bits for the linux kernel (perfectly redistributable) and CDDLed DTrace bits for the linux kernel (which a user is perfectly entitled to download and combine together with the GPLed bits - many Linux users already have long availed of this right to download and install completely proprietary Linux modules from their distributions repositories). For 100%-shiny-white redistribution, you need: b) Linux kernel developers to state they're fine with redistribution of CDDLed Linux kernel modules together with GPLed kernel and/or modules (remember, they're both free software licences). If the bulk of Linux devs of significance do so, then the problem is solved.
(Log in to post comments)
On DTrace envy Posted Aug 8, 2007 13:32 UTC (Wed) by paulj (subscriber, #341) [Link] "If the bulk of Linux devs of significance do so, then the problem is solved."
Hmm, I should re-state that, as in the above form it allows for possibly morally-bankrupt situations (e.g. some developers objecting, but who do not have resources to take action), which wasn't my intention. So:
"If no Linux kernel developers object, then there is no problem".
On DTrace envy Posted Aug 8, 2007 17:12 UTC (Wed) by madscientist (subscriber, #16861) [Link] > That gets you GPLed reimplementation of certain DTrace bits for the linux> kernel (perfectly redistributable)
While it is redistributable, I should point out that as described there's very little chance that those changes will ever be accepted into the mainline kernel. Linus et.al. have a long standing, and firm, position that no code will be accepted (even if it's perfectly legal GPL code) into the mainline kernel if its only purpose is to enable proprietary modules of one sort or another.
Of course, there's no reason why individual distributors like Red Hat, SuSE, Debian, etc. couldn't apply that patch themselves to their kernel packages, but this becomes a pain.
Of course, another option would be for the DTrace port to use existing, generic kernel facilities or, if none such exist, work on getting them added. This would be a lot more work, I expect.
On DTrace envy Posted Aug 8, 2007 17:28 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] In this case, that's not the purpose; DTrace is free software, not proprietary software, even though the license isn't compatible. Furthermore SystemTap could use the same hooks.
On DTrace envy Posted Aug 8, 2007 19:30 UTC (Wed) by ahl (guest, #40497) [Link] That's a very interesting point. I wonder if Linus et al. would object to hooks for an open source component, and, if they did, what the grounds for those objections would be.
On DTrace envy Posted Aug 9, 2007 11:47 UTC (Thu) by paulj (subscriber, #341) [Link] I don't want to sound too humbugish about attribution, but that was my point with "(remember, they're both free software licences)" from my point b) (get linux devs to agree CDDLed Dtrace modules are ok). Any points about potential odd-standards are implied in that (particularly as I had already referred to proprietary modules earlier in my post, highlighted in bold too to make it obvious..). :)
On DTrace envy Posted Aug 9, 2007 19:55 UTC (Thu) by bfields (subscriber, #19510) [Link] I wonder if Linus et al. would object to hooks for an open source component, and, if they did, what the grounds for those objections would be. That sort of thing has always met a lot of resistance. Currently any in-kernel API can be changed as long as you take care to fix up all the in-tree users. Obviously that makes certain kinds of changes much easier. And having in-tree users for API's makes those API's easier to understand and maintain.
On DTrace envy Posted Aug 8, 2007 21:30 UTC (Wed) by madscientist (subscriber, #16861) [Link] You're right, I misspoke. I wonder about ahl's point as well: is the Linux devs' position that they shouldn't create special hooks for code that is not GPL-compatible, and hence stands no chance of ever being integrated with the mainline kernel? Or is it only binary blobs they don't like? They really push hard the goal of getting everything promoted up to the mainline kernel.
Of course if it's the case that the in-kernel hooks can be made generic between SystemTap (et.al.) and DTrace, then it doesn't matter anyway.
On DTrace envy Posted Aug 29, 2007 20:06 UTC (Wed) by renox (subscriber, #23785) [Link] > Follow AHL's recipe (see his blog, linked to several times in this article)
Well AHL's "recipe" is the one followed by FreeBSD I think to use DTrace and they won't integrate DTrace in FreeBSDv7 because some of them have doubts about the legality of linking BSD code with CDDL headers.
The issue would be of course the same for the Linux kernel.
Is the legal issue real or not? Some say yes, some say no, I have really no clue..
Hopefully this legal mess will be cleared at some point, otherwise maybe Sun could relicense just the header under the BSD license to clear this mess once for all?
|
|||||||||||||