Submitted by DTrace has been ported to QNX. “The initial port to Neutrino that Colin and I have done is slightly different from the other OS ports. Since Neutrino is a micro-kernel, we wanted to see how far we could go keeping the dtrace module out of the kernel… And if possible even outside of the process manager. The current implementation has all of the dtrace system code, normally found in the kernel or a kernel module, encapsulated in a resource manager, io-dtrace, and the utility is a straight port of the Solaris utility.”
thats really cool actualy. nice work guys
that’s great news! i would love dtrace or something like it for netbsd and linux.
There was an error in the article: dtrace doesn’t work in NetBSD, but it’s in FreeBSD that someone worked on this.
Unfortunately licensing concern prevented him to merge his work on FreeBSD.
So do not believe Sun when they say that they want to see DTrace widely accepted: their license prevents both FreeBSD and Linux developers to include their work.
To be clear: Sun has every right to license their work however they want, but it’s quite hypocrital of them to say ‘we hope that everybody will use our work’ then release it with a license which doesn’t allow it.
I guess that DTrace license will be changed when Linux will be on the verge to have a truly competing project which does the same (like Java).
The prevailing wisdom is that Linux can find a way to do this if they want to, and that their worries about derived works are not technically sound. This has been discussed on osnews before:
http://osnews.com/comment.php?news_id=18428
http://osnews.com/comment.php?news_id=18388
Especially after Adam posted this:
http://blogs.sun.com/ahl/entry/what_if_machine_dtrace_port
I work with the DTrace engineers at Sun, and we certainly do want to see DTrace widely accepted. It’s irritating and offensive when people claim to know otherwise, as it’s both completely wrong and is accusing us of lying about the matter. How do they know otherwise, pray tell? They certainly didn’t ask us.
It’s also suspicious that these people talk big, but don’t use their real name.
So you guys chew out John Birrell whom is doing the dtrace port?
http://dtrace.what-creek.com/2007/10/interacting-with-sun-microsyst…
“who”, not “whom”.
I’m sure it will be shocking to hear that there’s another side to this.
My understanding is that a DTrace port to Linux would involve clean-room reimplementation of a reasonably small core kernel component under the GPL and porting a bunch of kernel modules under the CDDL.
Assuming the first part was done, then the modules could potentially be maintained out-of-tree and distributed separately from the kernel, like the NVIDIA module. But this effort would neither be managed as part of the Linux kernel project nor hosted on kernel.org.
Adam’s post identifies these sticking points and suggests that Google might want to become the steward of DTrace for Linux. But let me ask one question: Why not Sun? Why won’t Sun maintain and distribute DTrace kernel modules for Linux? Doesn’t Sun do a lot of Linux business? Doesn’t Sun have an interest in DTrace for Linux, not to mention the expertise?
The GPL-incompatible license means that Sun can’t expect the Linux community to take DTrace under its wings. But Linux is open-source, and nothing is preventing Sun from separately delivering CDDL kernel modules for Linux. What’s the problem?
Why should Sun spend the time and money on GNU/Linux when their primary focus is Solaris?
It doesn’t make good business sense to them or to their shareholders to canabalize their own platform.
I just love the double-standard most people seem to have about open-source; a community spends millions of dollars on something, makes it available under fairly liberal licensing terms and then all people do is criticise them for not “doing enough.” Well, bah to that.
While what you are saying is quite true. I would question your assumption that their primary focus is solaris. From what I am seeing, Sun doesn’t really care what platform/OS combo, as long as you buy it from Sun.
Didn’t sun recently make a deal to install windows on Sun hardware?
Yes, ultimately, if they can’t get you to run Solaris, they’ll take you as a GNU/Linux or Windows customers.
However, they obviously want you as a Solaris customer since they get the support contract money for that.
But they obviously want somebody else to cannibalize Solaris for them. They appear to have no strategic intention of preserving DTrace as a Solaris-only feature. Their rhetoric implies that they want to see DTrace on any *nix system, so it must make good business sense to Sun.
I’m not criticizing Sun, I’m just suggesting that if they want this to happen, they might have to do it themselves. I can’t see what business interest Google has in distributing DTrace. Red Hat and IBM are investing heavily in SystemTap, and Novell will follow along. The ball is in Sun’s court on this one. DTrace for Linux under the CDDL isn’t going to happen without their sustained leadership.
I have nothing against the CDDL/MPL. IMHO it’s the best developer-oriented FOSS license, whereas the GPL is the best user-oriented license. But the fact of the matter is that they’re mutually incompatible. Sun is the sole copyright owner, so once again the ball is in their court. If they want the Linux community to pick up the ball and bring DTrace to Linux, then Sun has to distribute it under the GPL.
Whether they choose one of these two paths or not depends on their priorities. How important is it to Sun to have DTrace on Linux? How important is it that DTrace remain exclusively under the CDDL? If they’re not willing to put in the effort, and if they’re not willing to distribute it under a compatible license, then they might as well stop spouting the empty rhetoric, because they’re obviously not interested in bilateral cooperation.
There’s too many horror stories out there about developers who just wanted to port Sun technology to other platforms, only to get verbally assaulted by Sun employees. I have great respect for Sun as a leader in *nix platform technology, but they clearly seem like the kind of vendor where you need to get explicit assurances of cooperation in writing before you waste any time and energy on their code. For the Linux community, that assurance is the GPL.
Your continued implications that what they say is “rhetoric” is tantamount to calling them liars. That doesn’t really help your argument.
No, actually, they don’t. Just as there are many kernel modules, etc. available for Linux that aren’t GPL, so could DTrace be made available if people really wanted it. Sun would like to see other platforms adopt DTrace, and has gone out of their way to *assist* folks who have taken on that role. However, it is unreasonable to expect them to start or do all of the work.
At last check, cooperation was a two-way street. Sun doing all the work doesn’t sound like cooperation to me.
Unsubstantiated, vague horror stories are little more than just that: not worth the paper they’re written on. So far, I’ve only heard of one such thing and that person wasn’t specific enough to substantiate their claims.
Which isn’t very assuring to some vendors, etc. I think OpenSolaris is going to provide the alternative that many are looking for. A platform with great technology that doesn’t force you to give away your technology for free.
No, I use the term “rhetoric” to indicate language that’s intended to persuade without explanation. Sun says they want DTrace on Linux, but they don’t explain how this will occur or what they’re doing to help make it happen. They’re not lying. I really do believe they want to see DTrace on Linux. But it doesn’t seem like they have any plans to these ends.
And all of them, to my knowledge, are developed by commercial and/or proprietary vendors to support their products on what most of them see as an alternative platform. Just like Sun would do to support their tracing technology on Linux.
They don’t have to if they distribute DTrace under the GPL.
Yes. Sun distributes DTrace under the GPL, and the Linux community develops/maintains the port. If Sun wants the Linux community to do all the work, then they’ll have to cooperate on the license. Either Sun or the Linux community is going to wind up doing all the work, so it’s in Sun’s interests to solve the licensing problem so that the Linux community can shoulder the burden.
True. But it’s the only form of reassurance that holds any water in the Linux kernel community, and in terms of getting DTrace for Linux, that’s all that matters. Besides, dual-licensing under CDDL/GPL doesn’t jeopardize anyone’s ability to add arbitrarily licensed source files to DTrace under the CDDL. And it can only strengthen the guarantee of reciprocity to Sun.
Who is harmed by Sun adding the option of receiving DTrace under the GPL?
Nonetheless you are implying negative things about them that aren’t true.
No, not just like Sun would do. Not all of those kernel modules out there are developed by the original manufacturer, and there is on reason why Sun has to do this work.
]q]
They don’t have to if they distribute DTrace under the GPL. [/q]
But Sun has no reason to have to it license it under the GPL. If folks want DTrace now they can do it, GPL or not. Therefore Sun has already made sufficient steps. Sun’s current license has already allowed several operating systems to adopt it that could not otherwise. It seems to me that Linux is the only one losing out.
Sun has already done the majority of the work (in terms of millions of dollars and man hours) in developing DTrace. I would call that most of the work. In addition, they have also provided advise as to how it could be ported despite the licensing concerns of some. As such, the only thing stopping DTrace from being available is the lack of someone to step forward and do that.
Encouraging people to use a tool and bending over backwards for them are two different things.
We’re just going to have to agree to disagree to the degree Sun has to do things to accomplish this.
The OpenSolaris community. Dual-licensing as seen by recent disagreements between the OpenBSD project and Linux kernel project causes a host of problems. You have to rely on the honesty of both parties involved to contribute code back under the original license.
If dual-licensed projects could depend upon people to contribute all changes back under both license; then it would be fair. But they won’t; as such the chain of “quid pro quo” is broken in my view and it is harmful to the community.
You and I both know that if Sun dual-licensed it; many changes would be made under GPL terms only thus preventing them the OpenSolaris community and anyone else that adopts DTrace (such as QNX, etc.) from benefiting from those changes.
That is the harm in dual-licensing. It creates a divergent community.
I work with the DTrace engineers at Sun, and we certainly do want to see DTrace widely accepted. It’s irritating and offensive when people claim to know otherwise, as it’s both completely wrong and is accusing us of lying about the matter. How do they know otherwise, pray tell? They certainly didn’t ask us.
It’s easy to see Sun’s intentions by the license they use for Dtrace and ZFS. If they really wanted it widely accepted they would use a more free license like BSD or GPL. In fact they could dual or tri-license if they wanted to. It’s not like they didn’t forsee licensing issues with kernels like FreeBSD and Linux. It reminds me of the Java issues that we had for years. If they wanted Java everywhere they could have just changed the license. It took years before they finally gave in and we’re still waiting for a fully functional free Java. In the meantime we’ve had gcj and classpath. Even now it is RedHat who has given us IcedTea. I give SUN some credit for freeing up most of Java, but the real credit should go to the OSS community who has attempted to create a free Java, put pressure on Sun to free Java, and ultimately is filling in the pieces that Sun has not released under a free license. I really don’t think Sun would have any freely licensed software today if it wasn’t for the OSS community.
if they made it gpl then bsd would still not be able to use it – you can’t please everybody. Dual licensing just a bad idea, and it was from the beginning.
if they made it gpl then bsd would still not be able to use it – you can’t please everybody. Dual licensing just a bad idea, and it was from the beginning.
If it’s so bad then why is the tri-licensed Firefox so popular? People don’t seem to have a problem with that. In fact gecko has been incorporated into more than a few browsers.
the popularity of firefox is anything but related to its license.
the popularity of firefox is anything but related to its license.
I didn’t say it was. What I said is that it doesn’t seem to be hurting it. You haven’t given a reason why dual or tri-licensing is so bad. Just declaring it doesn’t make it so.
Oh, then while we’re at it, let’s call Apache evil too for using that “GPL-incompatible” license for so many years. The Apache foundation stood by their license, and the FSF is the one that ended up changing theirs to be compatible (GPLv3).
What’s funny is the Linux world is the only one that can’t jump on the train. FreeBSD, Mac OS X, QNX, Solaris, all have DTrace now. Makes you wonder who really has the best license…
Oh, then while we’re at it, let’s call Apache evil too for using that “GPL-incompatible” license for so many years. The Apache foundation stood by their license, and the FSF is the one that ended up changing theirs to be compatible (GPLv3).
That makes absolutely no sense at all. Apache doesn’t need to be GPL to be widely available and usable. Non GPL applications can be run on a GPL operating system. That has never been an issue. Kernel level stuff is entirely different and I’m pretty sure that SUN isn’t so dense that they don’t know that GPL incompatible licensed code cannot be including in the kernel. They also knew it would prevent inclusion in FreeBSD. Pretending they want their code widely available by using a license that is incompatible with two of the most popular and widely used UNIX-like systems out there is either dense or spinning the truth.
What’s funny is the Linux world is the only one that can’t jump on the train. FreeBSD, Mac OS X, QNX, Solaris, all have DTrace now. Makes you wonder who really has the best license…
FreeBSD doesn’t include DTrace, not even the latest version and probably won’t ever because of licensing issues. QNX and MacOSX are both proprietary and can include whatever they want as long as it is licensed. They don’t care about having encumbered code as long as it is aqcuired legitimately.
Incorrect. According to legal counsel, there is nothing preventing inclusion in FreeBSD except for the objections of individuals that are not qualified to legally evaluate the situation.
Only one of those systems has that incompatibility and it isn’t any of the *BSDs.
FreeBSD doesn’t include DTrace because of the unqualified legal evaluations of individuals that wrongly believe that it would affect the kernel’s licensing; it would not.
Qualified legal counsel has repeatedly provided advice to the contrary.
Encumbered? Wrong. DTrace is licensed under an OSI-approved open source license. A license that even the FSF denotes as free and open source and as a “copyleft” license.
A BSD license is not practical for a few reasons:
1) It doesn’t deal with patent rights
2) It’s a 30-year old research license that is out of touch with today’s legal environment (see recent comments by Alan Cox of Linux fame)
Edited 2007-11-11 05:18
Incorrect. According to legal counsel, there is nothing preventing inclusion in FreeBSD except for the objections of individuals that are not qualified to legally evaluate the situation
There is a very real backlash by some in the FreeBSD community about releasing an official version with encumbered code. The code definitely has the ability to cause some real problems in the future.
Only one of those systems has that incompatibility and it isn’t any of the *BSDs.
The developer of the DTrace port to FreeBSD thinks otherwise along with a host of other people.
FreeBSD doesn’t include DTrace because of the unqualified legal evaluations of individuals that wrongly believe that it would affect the kernel’s licensing; it would not.
Are you a lawyer? Are you making “qualified legal evaluations”? If there is any question to the legality it is always better to err on the safe side, especially when you are NOT a lawyer. Winging it with software licenses is a potential minefield of lawsuits.
Qualified legal counsel has repeatedly provided advice to the contrary.
Who’s legal counsel? SUN’s? I’m pretty sure they have a vested interest in luring FreeBSD to trap their code in the CDDL.
Encumbered? Wrong. DTrace is licensed under an OSI-approved open source license. A license that even the FSF denotes as free and open source and as a “copyleft” license.
It’s encumbered if you use either of the two most popular OSI approved licenses. I would say the vast majority of open source operating system installations are either Linux or FreeBSD. That’s a pretty big chunk of users who do not have DTrace available. It’s pretty ingenious to say that they want it everywhere but encumber it enough to be incompatible with the two most popular free operating system kernels.
Backlash from a small number of individuals who are not legally qualified to evaluate the situation.
The developer has made vague comments that do not sufficiently substantiate his claims.
No, I am not However, Sun’s legal counsel has provided advice to the DTrace team that says differently.In addition, obviously QNX and OS X legal counsel has provided the same counsel as well; otherwise the same “tainting” that would apply to FreeBSD would apply to them.
Yes, Sun’s. Though Apple and QNX’s has proved the same. Your conspiracy theories are also unqualified since you are not a lawyer. I prefer to take adoption by legally responsible companies as evidence that you are wrong.
Using the word encumbered is tantamount to FUD in this case. Even the FSF recgosnises it [the CDDL] as a free software license. It is not incompatible with the BSD license. Only a lawyer can say that and you aren’t one.
edit: wrong thread.
Edited 2007-11-11 16:13
Yes, Sun’s. Though Apple and QNX’s has proved the same. Your conspiracy theories are also unqualified since you are not a lawyer. I prefer to take adoption by legally responsible companies as evidence that you are wrong.
Like I said before Apple and QNX are proprietary. It’s a different ball game with them. As for SUN, they have a vested interest in claiming it is ok to use. Your interpretation of the law is no more or less qualified than mine.
Using the word encumbered is tantamount to FUD in this case. Even the FSF recgosnises it [the CDDL] as a free software license. It is not incompatible with the BSD license. Only a lawyer can say that and you aren’t one.
Maybe you should look up the work encumbered.
2. To hinder or impede the action or performance of
3. To burden with legal or financial obligations
They’re not fully proprietary though. A lot of the code to OS X’s foundation is released under Apple’s open source license (which is now certified as a free software license by the FSF).
Using that as the definition, then even BSD code is encumbered since it has legal obligations. In fact, every single software license in existence qualifies.
Even the GPL is “encumbered” by that definition.
So perhaps you may want to reconsider how you are using that word.
Arguably, every software license also impedes the action or performance of certain actions; it all depends on the license and what you are trying to use it for.
So, as I said before, using encumbered in the context you have specified is “FUDly.”
They’re not fully proprietary though. A lot of the code to OS X’s foundation is released under Apple’s open source license (which is now certified as a free software license by the FSF).
I think you’re missing the point as to why this is bad for FreeBSD but can be good for a company like Apple. The CDDL creates additional restrictions that make hacking on the FreeBSD kernel more cumbersome. It can indeed wreak havoc on development when what you can and cannot do with the code is different depending on the source file. It does indeed create an encumberence for FreeBSD. The very nature of open source development is incompatible with this kind of piecemeal licensed software. It becomes incredibley hard to hack on without stepping all over a license. These are the licensing issues that the FreeBSD hackers are talking about more than the ability to release a license compliant version of FreeBSD with DTrace. It’s possible, but it isn’t likely to stay out of legal trouble for very long. Look at the driver license disputes just between OBSD hackers and Linux hackers. Think about what something as intrusive as CDDL could cause. It’s definitely a legal problem for FreeBSD.
Using that as the definition, then even BSD code is encumbered since it has legal obligations. In fact, every single software license in existence qualifies.
The word used in the definition is “burden” not “affect in any way” as you seem to imply. It isn’t a burden for proprietary operating systems because they don’t participate in decentralized development and rapid release cycles.
So, as I said before, using encumbered in the context you have specified is “FUDly.”
I just think you are missing the point entirely.
Except it isn’t my interpretation. I’m merely repeating what *qualified* legal counsel has provided to Sun. So what I say is actually more qualified than what you say, because I’m repeating what a lawyer said
Besides, you are also aware that Solaris contains BSD licensed code that links against the CDDL code? Right?
Plus many other licenses.
DISCLAIMER: All legal counsel likes to note that legal counsel is only valid for the part which has a contract with them
Edited 2007-11-11 16:34
Except it isn’t my interpretation. I’m merely repeating what *qualified* legal counsel has provided to Sun. So what I say is actually more qualified than what you say, because I’m repeating what a lawyer said
Taking SUN’s word for it isn’t exactly a good idea for any open source project.
Besides, you are also aware that Solaris contains BSD licensed code that links against the CDDL code? Right?
BSD is a more permissive license which allows it to be used almost anywhere with minimal impact on licensing issues. It’s almost public domain. It’s a little different when you are talking about using the CDDL in a BSD licensing kernel.
Well.. how would you explain the inclusion of ZFS in freebsd then, if what you claim about the rationale for licensing is true?
Edited 2007-11-10 07:55
The CDDL is not incompatible with the BSD licence. The reason that dtrace can not be integrated with FreeBSD at the moment is that the default kernel shipped in the release must be entirely BSD licenced as per the project policy. ZFS is not affected by this policy since its implemented entirely as a module.
It could be made an optional compile option now but it would mean that dtrace may not be available if you happen to be running a release kernel so the person porting it is looking for a better solution.
*retracted* Missed “in-” part of compatible.
Edited 2007-11-10 19:49
>>The CDDL is not incompatible with the BSD licence.
>Wrong. The CDDL is quite compatible with the BSD license according to *expert advice* from legal counsel.
We said the same thing.
The one thing that is wrong is that some of the BSD folks incorrectly believe that including DTrace headers will make the kernel non-BSD. That belief is not substantiated by legal counsel so far.
That is at the heart of the disagreement.
I tend to agree with Sun, since obviously, Apple’s lawyers don’t believe that it makes their kernel CDDL somehow either.
that’s great news! i would love something like dtrace for netbsd and linux. the existing methods are not as elegent, specific, generic nor performance and safe. (strace, truss, system tap, etc)
Here we go again, GPL is the panacea and CDDL is not. Load of crap. As said before in this discussion, the non-inclusion reason is due to some rules the kernel developers set up. Not due to license.
As far as acceptance? I suppose that’s only the case if it’s in Linux, huh? Let’s not regard that there’s dtrace in Solaris, MacOSX, QNX, NetBSD and as in this article in FreeBSD (if you’re willing to jump some hoops). That’s five operating systems!
Edited 2007-11-10 19:03
LoseThos stores addresses of functions with their names when it loads code in. This was to allow symbolic disassembly. When it crashes, I do a stack dump with symbolic output. I wrote a routine which goes up the stack by assumeing procedures start and end with
…..push rbp
…..move rbp,rsp
…..
…..pop rbp
…..ret
LoseThos calls a plug-in for the wallpaper and the default wall-paper reports on tasks. It fetches the rpb of all tasks and uses it to give a stack report. I never heard of DTRACE, but I have something which reports the 4 levels of calls on my wallpaper. See the “new wallpaper” demo on my website.
http://www.losethos.com/newwall.html
That’s funny — I’m ahead 😉
If you do not follow the push rbp rule, it will not work, but my compiler does and if you mess-it-up, tough luck.
I made the wall paper look like a blue screen of death as a joke. LoseThos is for programmers and most programmers like BSOD’s because they’rre interesting. When I see one, I’m like, “Cool, what does it say?”
Are you guys lawyers or techies? You’ve been wasting an incredible amount of energy splitting hairs on the legal merits/problems of a dtrace port, when what you SHOULD have been doing is getting wild about what an incredibly cool and elegant piece of technology it is!
Bryan, Adam and Mike have given a huge gift to you all, and very few seem to be in the slightest bit grateful.
Who cares about whether it’s GPL or not – just take a look at it in detail (Bryan’s talk at Google is a good start) and enjoy it for what it is!
Edited 2007-11-11 15:43
BROUGHTEST OBEDIENTLY TEMPESTUOUSLY PUFFED EXULT TEMPLE
SATISFACTION DERIDING COLLECTIVELY OSTIA COMPARISON CONFUSED
UNGOVERNED UNMARRIED ATTENTIVE
Mac OSX recently got DTrace too. Also they build a lot of stuff on it in the form of a QA testing suite called XRay. I presume its a FreeBSD port of DTrace and the interface is build with Cocoa framework. Point being: a lot of good things are coming from work on DTrace, are these things related; and will other OS have nice interfaces to DTrace like XRay where D-Programming is not needed?
Cheers, Brian Ray http://kazavoo.com
I am in the process of revising my original FreeBSD/DTrace work to partition the CDDL code from the BSD GENERIC kernel code.
A requirement of the FreeBSD project is that the GENERIC (base or default) kernel is that it is purely BSD licensed.
We have no problem making CDDL or GPL kernel modules available for people to use. That’s why ZFS is available.
DTrace is a bit more complicated than ZFS because it has to have hooks into the bowels of the kernel, like trap handling.
My understanding is that Sun wants both DTrace and ZFS to be universally available. Sun just wants to reserve it’s rights.
In the FreeBSD project we have to tread carefully. NetApp is based on FreeBSD and NetApp is the largest single donor to the FreeBSD project so far this year. When I log into FreeBSD developer systems, my user directory is hosted on a filer donated by NetApp.
We appreciate the fact that there are companies out there which are prepared to base their products on FreeBSD. We aim to keep the GENERIC FreeBSD kernel purely BSD licensed so that FreeBSD remains a viable option for companies looking for a truly free operating system.
Let’s not argue about the CDDL vs BSD license any more. Please. It isn’t a job-stopper — it just requires jumping through a few hoops.
I am not a Linux developer, however from what I know about DTrace, it is possible to port DTrace to Linux and retain the GPL2 status of the kernel as well as the CDDL status of DTrace. If you have enough money to pay me, I’ll do it! Seriously.
Edited 2007-11-17 00:57