OSNews

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?

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.

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.