Weekly Edition
Return to the Front page
| |||||||||||||
More DTrace envyNearly a year ago, we looked at the status of SystemTap in the context of Sun's much-hyped DTrace tool. Since that time there has been progress, but the basic problem still remains: Linux does not have a good, ready-to-run answer to those wanting the equivalent functionality of DTrace. Due to an apparent disconnect between the developers of SystemTap and the kernel hackers, tracing for the Linux kernel—never mind user space programs—is not up to the competition. Both SystemTap and DTrace are tools meant to help administrators track down performance and other problems on production systems by instrumenting the kernel. Because SystemTap has not matured to the point of easy usability, DTrace is often seen as a prime differentiator between Linux and Solaris. In a posting to the ksummit-2008-discuss mailing list—where Kernel Summit topics are considered—Matthew Wilcox brought up the subject based on his experience at a recent PostgreSQL conference:
There was a lot of
buzz around DTrace. Sun and a couple of other companies have put DTrace
hooks into postgres, so they now have some really useful canned queries.
If you're running Solaris or MacOS, of course.
So there was a lot of talk about switching away from Linux. This can't possibly be a good thing for us. I don't personally know what the state of our competing projects are, but clearly they haven't got their hooks into postgres ... at least not upstream. Typically Linux has been in the forefront of interesting new technologies for free operating systems. When Sun opened up Solaris, though, a few features jumped ahead of their Linux counterparts, in particular the ZFS filesystem and DTrace. SystemTap is supposed to provide the tracing functionality while Btrfs is the leading candidate for a "next generation" filesystem. But, so far, SystemTap has not lived up to its potential. There are a few reasons for disappointment with SystemTap, some of which were pointed out by James Bottomley:
When I go around end users, I find people in two camps: The ones who've
drunk the sun coolaid and won't take anything on linux that isn't a
fully replicated dtrace (sort of like windows people who demand the
availability of outlook on linux) and people who are migrating to Linux
and trying to use systemtap for tracing. These latter seem to have a
number of genuine concerns including latency, the time it takes to
actually go from command executing to functional trace, the inability to
trace user programs (dtrace can) and concerns about the amount of
perturbation the probes actually place inside the kernel.
Those are all valid concerns, but the biggest problem for users is that, unless they are knowledgeable about kernel internals, it is difficult to know how to use SystemTap. A more simplified interface, one that is less reliant on kernel internals, needs to be created; the way to do that is through the placement of static trace points in the kernel and the creation of "tapsets" to make them easily usable. The SystemTap developers think the kernel hackers are in the best position to do that work. Ted Ts'o agrees but sees some barriers:
The big thing that are missing are the tapsets
— the macro libraries that allow a system administrator to use it to
find and solve performance problems without being a kernel developer,
and more importantly, the documentation for said macro libraries so a
system administrator can actually use it.
[ ... ] the real problem isn't as much kernel developers, it's that (a) it's too hard for many kernel developers to use (and so many kernel developers are [not] using it), and (b) there aren't enough tapsets. The latter is something that kernel developers can help solve, but unfortunately I'm not sure discussing it at the Kernel Summit will necessarily lead to making forward progress. If the kernel developers have trouble using SystemTap, they are unlikely to add the tapsets that would make it more usable for system administrators and others who have some general kernel knowledge but not enough to sensibly instrument it. For people using distribution kernels—at least for the enterprise distributions and Fedora—it is only somewhat painful to get SystemTap up and running. But kernel hackers tend to run their own kernels, often many different versions in a short period of time, so they need to be able to be easily build one that works with SystemTap and includes all of the debugging information that it requires. SystemTap developer Frank Ch. Eigler has a long reply to many of the complaints in the thread. It seems clear that the SystemTap folks and the kernel hackers have not been communicating—there are solutions to many of the problems that were cited. They are in various states of readiness, but are mostly working. So SystemTap is most of the way there for kernel tracing as long as you are well-versed in kernel internals, but that has been true for some time. In order to get SystemTap to where it needs to be, the kernel hackers need to be involved. Building the infrastructure and waiting for tapsets to magically appear is not a recipe for success. The SystemTap hackers need to be engaging the kernel community, as well as distributions, to make the tool into something that gets used. SystemTap can use static probe points, kernel markers—merged into 2.6.24—but it is notable that no one has, as yet, made use of them. A concerted effort needs to be made to make the tool more usable for the kernel developers who can, in turn, help make it more usable for others. There is a clear problem when folks like Ts'o regularly try, but find it too difficult to be useful:
But maybe as more people try using it, they'll discover some of these
rough edges, and will start trying to fix it. Every couple of months,
I've tried using it, and because it [h]as so many rough edges, I've
normally found it less work to debug the kernel using manual methods
rather trying to make Systemtap work on my system and with my kernel
development workflow.
It is a commonly heard complaint that while SystemTap is difficult to use, DTrace "just works" for Solaris; Eigler responds:
Yeah, so I hear, but think about how different their target
environment is. Their kernel hardly changes (several fixed APIs,
ABIs): this has huge implications. Their kernel was willing to
insert probes (~ markers), a bunch of build system changes (debug
info subset transcribing). Here in linux land, we suffer
multifaceted tensions and it is hard to go toward a goal without
obstructions (well-meaning as they may be).
A bunch of third-party scripts are often conflated with "dtrace", which is just a matter of growing the user community enough, and giving them a good tool to build on top of. A growing set of runnable end-user scripts is already packaged with systemtap, intended for use by nonexperts, more help (e.g. concise problem statements about what you'd like to measure/see) would be welcome. Many administrators and other users of tracing facilities are not necessarily interested in kernel-level tracing, but would really like to be able to use the instrumented versions of things like PostgreSQL. That is in the plan according to Eigler: "We aim to piggyback on these efforts by reusing the dtrace instrumentation calls embedded into postgres etc., if at all possible." Until the rough edges can be smoothed on the kernel side, Bottomley wonders if it even makes sense to start considering user space:
Although there are
differing opinions about what systemtap could and should do, it's clear
that it's not working incredibly well for its design space: the kernel,
so talking about extending it to userspace is a premature.
DTrace sounds like a nice working solution that has many uses and many happy users. If one can ignore the self-congratulatory postings from its lead developer, it might be worth having in Linux, but that simply is not going to happen. Paul Fox is working on a port of DTrace to Linux, but that ignores the licensing realities that would never allow it to become part of Linux. It also ignores the difficult path a DTrace port would face getting merged into the mainline. (We hope to have an article from Mr. Fox on his DTrace porting work soon, stay tuned). For all of the talk out of Sun about how they would love to make DTrace a part of Linux, they clearly made a choice to ensure that could not happen. Even if any technical barriers were lifted, the CDDL is not compatible with the GPL. It is perfectly fine as a free software license, but if you wish to get things into Linux, they must be licensed in a GPL-compatible way. This was well understood at the time Sun freed Solaris, so this must have been a conscious decision. Given how much their marketing organization likes to tout DTrace, it would seem to be a choice that Sun is quite happy with. Linux will eventually get the tracing support it needs, in a way that is easily accessible to users, but it may take some time. Conversations like the recent one on ksummit-2008-discuss are an important part of getting there. It would appear that better support for the use cases of kernel developers will be forthcoming. It is mostly a matter of documentation along with simplifying some of the building and installation issues. Once the kernel hackers actually start using it, progress is likely to be fairly swift. This is the way free software development works; it generally does not track a straight path to a solution, but often wanders about in the solution space for a while. It is highly unlikely that a development like DTrace could have come about in the way that it did in a true community-developed operating system. For that you need everyone pulling in the same exact direction, which may be why Sun is reluctant to turn over much of the governance of Solaris to the community. That may help them develop things more quickly, because there will be fewer barriers, but it won't help them to foster the kind of development community that characterizes Linux. (Log in to post comments)
More DTrace envy Posted Jul 2, 2008 18:26 UTC (Wed) by martinfick (subscriber, #4455) [Link] For that you need everyone pulling in the same exact direction, which may be why Sun is reluctant to turn over much of the governance of Solaris to the community. That may help them develop things more quickly, because there will be fewer barriers, but it won't help them to foster the kind of development community that characterizes Linux. Perhaps this should have had the word "some" interjected in it? That may help them develop some things more quickly,I think that most people would agree that overall linux is developing at a much quicker pace than Solaris. These 2 high profile areas dtrace and ZFS are constantly mentioned as areas where Solaris is ahead of Linux (and I am not disagreeing,) but let's put things in perspective, there are many areas where linux beats the pants off of Solaris, so many that there just doesn't happen to be (only) 2 highly touted ones. :)
More DTrace envy Posted Jul 2, 2008 23:53 UTC (Wed) by mjg59 (subscriber, #23239) [Link] To an extent, it's unfair comparing Solaris with desktop Linux distributions. If you compare Solaris to RHEL or SLES, it doesn't fare as badly. For instance, desktop Linux distributions have power management functionality that's still nowhere near present in any shipping versions of Solaris. Enterprise Linux distributions aren't likely to ship that functionality until next year, and they're the market that Solaris is competing with. (Though, really, I expect we'll still be ahead on power management for a long time. Solaris isn't anywhere near supporting a tickless kernel and that's one of the major factors in the idle power consumption on modern hardware)
More DTrace envy Posted Jul 3, 2008 3:40 UTC (Thu) by flewellyn (subscriber, #5047) [Link] It's frustrating that Bryan Cantrell apparently reacts to all mentions of license issues as "I want to talk about technology, not law, legal issues are unimportant". Well, no, they're not. If they were, that'd be great, but as it happens, we have to care about under what terms we use the code that we use, and if the licenses aren't compatible, we can't use it. He goes on and on about how foolish the SystemTap people are for trying to reimplement DTrace when DTrace already exists, while refusing to even discuss the SOLE reason why they saw the need to bother!
More DTrace envy Posted Jul 3, 2008 5:54 UTC (Thu) by bcantrill (guest, #31087) [Link] I didn't say that the issues are unimportant, I said that I didn't want to discuss them in the comments section of my blog (which I don't). I also happen to think that (1) the licensing issues are largely a smokescreen for good 'ole NIH in the Linux community and (2) the law (that is, the case law) in the domain of software licensing is so ill-defined that one can often conclude what one wishes to conclude. Take these two together, and you have a plague of amateur legal opinions, contorted to justify rampant, metastasized NIH -- and I personally want no part of it.
More DTrace envy Posted Jul 3, 2008 7:48 UTC (Thu) by k8to (subscriber, #15413) [Link] A Sun developer accusing the Linux community of NIH. Great.
More DTrace envy Posted Jul 3, 2008 8:05 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Eben Moglen is not an amateur. And he vets the FSF's legal opinions on license compatibility, so...if they say it's not compatible, it probably isn't. As for NIH, well, no, Linux has often adopted ideas from other systems.
More DTrace envy Posted Jul 3, 2008 8:51 UTC (Thu) by paulj (subscriber, #341) [Link] Licences being incompatible is a moot, philosophical matter (least until the *AA succeed in making copyright infringment a criminal matter) if no one thinks the infringment matters. Who exactly is going to sue if someone distributes a DTrace modified kernel? Sun would have no standing, as the CDDL seems to allow combining with GPL works. So it'd have to be a Linux kernel contributor, sueing someone for distributing free software derived from free software.
More DTrace envy Posted Jul 3, 2008 9:28 UTC (Thu) by mjw (subscriber, #16740) [Link] But it isn't a "moot, philosophical matter". As one of the people who worked for Sun on the CDDL said the license was explicitly designed to be GPL incompatible on request of the engineers: http://en.wikipedia.org/wiki/CDDL#cite_note-5 It is simple to make this matter really moot if Sun would want to. All they have to do is change the CDDL so that there is an explicit permission to distribute a larger combined work under terms compatible with the GPL. Since there are records of the incompatibility being deliberate it isn't even just a legal matter. It would actually be rude and impolite to go against the wishes of the copyright holder at this time. You do have to respect their wishes even if you could find some legal loophole to go against it. But if they really change their minds and put that in writing by updating the CDDL that would be wonderful of course. Lets hope they mean it and indeed make this a legally mood matter for real. And then we can all happily work together without having to have any doubts about it.
More DTrace envy Posted Jul 3, 2008 12:10 UTC (Thu) by paulj (subscriber, #341) [Link] Look, the CDDL appears to be absolutely fine with copyright holders of GPL works incorporating CDDL software and distributing it. All the GPL copyright holders have to do is promise not to sue themselves or others for it. Pretty simple. (Consult your own counsel, of course!). Essentially, you're complaining that Sun released free-software under a licence not quite to your liking. Further, given that Sun legal had some involvement in the GPLv3 process, it's possible that even if Sun had chosen the GPL, Sun'd have chosen v3 (course, v3 took another few years to be finalised..), and people would still be complaining. Further, in good humour, you're speculating yourself toward conspiracy-theory kook land. Read what Danese said, she said "partially because". It's therefore entirely reasonable to think there were other factors involved. E.g. one of the major differences between the CDDL and the GPLv2 concerns patent rights and Sun is subject to patent infringment suits on a not-infrequent basis. It seems reasonable to put and two and two together and speculate that Suns' lawyers really wanted a licence with some kind of patent cross-licensing language. I.e. it's possible GPL-licensing simply would not have been acceptable, regardless of what you take from Danese's comment. NB: I work for Sun, but I was no more privy to the "which licence for opensolaris?" discussions than you were (indeed, they would have predated my employment largely ;) ).
More DTrace envy Posted Jul 3, 2008 12:45 UTC (Thu) by mjw (subscriber, #16740) [Link] No, I am not complaining about which free software licenses Sun choose. I am happy they release software under a free license. And I hope they will do more of it. However pretending that legal uncertainty and explicitly distributing source code under GPL-incompatible terms aren't a (the) major issue, while claiming to want wider adoption of that code base under GNU/Linux and suggesting it isn't adopted because of NIH is just silly. I have worked on several occasions with Sun, and I have spoken on several occasions to Danese and other people at Sun about free software, CDDL, GPL, communities and legal issues to know they really understand that the legal uncertainty around the CDDL is the only issue preventing adoption of the technology on a wider scale in GNU/Linux. As GNU Classpath maintainer I have been more than impressed with how Sun handled Java the last couple of years. The GNU and Sun java communities happily work together now (after 15 years of separation) exactly because Sun made sure to do the right thing legally to ensure the widest possible adoption and cooperation with the existing libre-java communities. I have only praise for how that was handled. And that is really the reason I am so disappointed about the mess they made with dtrace/cddl preventing cooperation and adoption on a wider scale, while claiming to want cooperation that is impossible to achieve because of these messy legal issues.
More DTrace envy Posted Jul 3, 2008 14:13 UTC (Thu) by paulj (subscriber, #341) [Link] Well, Danese left Sun quite a few years ago. Also, be sure to read Simon Phipps response (linked from the Wiki article you linked to). I accept there are differences and difficulties. However, it is Suns' prerogative to define how the software it created is to be derived from. Again though, Suns' licence does *not* (AIUI+IANAL) prevent other OSes from re-using that code - not even Linux (even if it does require collective action from Linux copyright holders). Reading the tea-leaves to find evidence of Suns' "evil" intentions is however not at all productive, no matter whose side you're on. Then projecting a moral duty of having to respect these *divined intentions* is, again with all due respect, not very sensible. If there are problems on some side, then the only way understanding can increase and so solutions (if any) are ever be found is through dialogue.
More DTrace envy Posted Jul 3, 2008 14:29 UTC (Thu) by drag (subscriber, #31333) [Link] You have it backwards. It's not that the GPL is incompatible with the CDDL... The CDDL was designed, specifically, to be incompatible with the GPL. Even if all the Linux kernel developers decided that CDDL was acceptable, then it still wouldn't matter. Sun _doesn't_want_it's_code_in_the_linux_kernel_. That's it. They don't want Dtrace to be in Linux. They don't want ZFS in Linux. Get it? They did it on purpose. So all the philosophical or political are the arguments that are MOOT. Sun made sure of that. Sun says their code isn't going into Linux, then their code isn't going in. There is absolutely no question about this. Your the only one mentioning 'evil' here or anything like that. You can see their intentions very clearly written in between the lines in the CDDL license even if you don't believe Danese. All the legal ramifications have already been worked out years in advanced for Mozilla-like licenses and Sun could of easily made it compatible with Linux, but they chose not to do that. EASILY. No question about that at all. Most everybody, unless they are loonies, is happy that Sun has their code under a open license, even if it's intentionally incompatible with the (pre-existing and very well established) GPL license. They may change their mind in the future and make the license compatible, but until then it's not going in. You see, that's how you know Sun wouldn't mind having it's code in Linux. If they made the license compatible then you'd know it was ok. Everything else is handwaving.
More DTrace envy Posted Jul 3, 2008 14:55 UTC (Thu) by paulj (subscriber, #341) [Link] Even if all the Linux kernel developers decided that CDDL was acceptable, then it still wouldn't matter. Sun _doesn't_want_it's_code_in_the_linux_kernel_. Sun has published its code under the CDDL. It's a free software licence that's quite permissive. At least one other OS (if not two) has incorporated code (the crown jewels no less) from Solaris, by way of the CDDL licence. Take that + whatever statements you want from its officers that seem interpretive or estopping and ask your lawyer for an opinion. What you feel Sun wants, or what you think the CDDL was designed specifically for, is amazingly speculative at best and largely irrelevant to anyone considering porting CDDL code.
More DTrace envy Posted Jul 3, 2008 19:21 UTC (Thu) by bronson (subscriber, #4806) [Link] > what you think the CDDL was designed specifically for, is ... largely irrelevant to anyone considering porting CDDL code. Do you seriously believe this? Do you agree that the CDDL is incompatible with the GPLv2? If so, then don't you think that someone considering porting CDDL code to a GPL project had better consider whether his actions are even legal? That hardly sounds irrelevant! If there's estoppel that would allow the CDDL to be used with the GPL, do you suppose you share a link? Every communication from Sun that I've seen has very specifically avoided this. If Sun actually does want its CDDL code to be incorporated into GPLv2 projects, it would take only tiny changes. Since the GPL is older and more popular (http://freshmeat.net/stats/), one would expect that Sun carefully considered researched GPL compatibility. Even if the incompatibility is an honest mistake, then why doesn't Sun make the tiny changes required now to rectify the situation?
More DTrace envy Posted Jul 5, 2008 19:13 UTC (Sat) by drag (subscriber, #31333) [Link] > Sun has published its code under the CDDL. It's a free software licence that's quite permissive. At least one other OS (if not two) has incorporated code (the crown jewels no less) from Solaris, by way of the CDDL licence. Take that + whatever statements you want from its officers that seem interpretive or estopping and ask your lawyer for an opinion. They don't care if FreeBSD or OS X adopts ZFS or Dtrace because those operating systems are irrelevant and are not competitive. Sun doesn't care if OS X adopts ZFS because they won't do anything interesting with it. At most it will make OS X users feel better because they can finally have a file system that doesn't suck worse then Vfat. If Sun has it's software adopted by the Linux folks then they lose control over it. They will improve it and incorporate it into Linux and it will be yet another reason why nobody has a reason to choose Solaris over Linux. Linux is now the dominate Unix system out there. Sun wants to maintain control over their 'ip'. They've done that with most everything they've released. They are learning to let go, but it's slow coming. Then explain to me why the hell Sun has not extended it's patent protections (use our IP and we won't sue you) only to the users of CDDL-licensed code and not open source programmers and users in general? Other people have done this (Redhat, Novell (not talking about the MS-Novell agreement, but previous things they've done), it's certainly possible. > What you feel Sun wants, or what you think the CDDL was designed specifically for, is amazingly speculative at best and largely irrelevant to anyone considering porting CDDL code. _read_the_license_. The license expresses intent. That's the point of it. 70%-90% of open source software used in a commercial environment is going to be licensed GPL. Your telling me that Sun made CDDL problematic to be used in the majority of popular open source software by ACCIDENT? All they had to do was make a exception. They can still do it now. Mozilla did it. They took and copied a license that everybody, including the original authors (Mozilla), realizes is problematic when combined with other open source software and Sun didn't realize it?
More DTrace envy Posted Jul 6, 2008 11:10 UTC (Sun) by paulj (subscriber, #341) [Link] You're the second person to have misread my (I thought fairly clear) comment, so I guess I need to reply and clarift: I specifically said that *your* opinion of Suns' motivations in choosing the CDDL was largely irrelevant (not least because motivations, even when generally acknowledged, aren't that relevant). Next (sorry to restate, but its important to the coherence of this post) you have been given several reasonable, practical and good reasons why the GPLv2 would not have been acceptable to Sun, regardless of Suns' motivations towards Linux, namely: - Sun did not want to dictate to ISVs that they must GPL their code. (This one you have heard directly from Bryan) - Sun does not want licence-forking (to cover any rebuttal to the previous point of "so use LGPL", as the LGPL can be converted to GPL, and ignoring the fact that the LGPL is far from pretty) - The GPLv2 is out of date with regard to patents. That Sun added patent cross-licensing+MAD terms to CDDL suggests this may have been a factor. (Why it applies only to CDDL? I've no idea.. I suspect there may be legal, technical difficulties in drafting the language to have many other licences - particularly with regard to the 'MAD' aspect of the CDDL patent language. Can you provide a pointer to the grants you refer to? Be interesting to read). Next, ignoring the above and if we accept your argument: Exactly how did you develop this massive sense of entitlement that you think it is your automatic right to Suns' code on licensing terms favourable to your chosen OS? I'm a Free Software Foundation supporter and I always understood that the ethical reasoning for companies to choose the free software was out of respect for their *users*... Finally, can you tell me with a straight face that had Sun chosen the GPL but it had chosen the GPLv3 (imagining the GPLv3 had existed), that you'd then not be complaining here today about Suns' choice of licence? Even though it too is incompatible with Linux to the *same extent* as the CDDL is (namely: it'd require linux copyright holders to agree to update the Linux not-quite-GPLv2 licence)?
More DTrace envy Posted Jul 7, 2008 2:39 UTC (Mon) by clump (subscriber, #27801) [Link] Forgive me, but the argument appears to be about whether CDDL-licensed can be used in Linux, or specifically GPL-licensed works. You started by saying:Licences being incompatible is a moot, philosophical matter...and: Look, the CDDL appears to be absolutely fine with copyright holders of GPL works incorporating CDDL software and distributing it.However this next quote is curious given your views: Exactly how did you develop this massive sense of entitlement that you think it is your automatic right to Suns' code on licensing terms favourable to your chosen OS?With the last quote, it looks like you agree that the CDDL and GPL aren't compatible. You object to people arguing *why* Sun chose the license. Fine. But you very much appear to give legitimacy to those not wishing to mix the licenses together.
More DTrace envy Posted Jul 7, 2008 9:48 UTC (Mon) by paulj (subscriber, #341) [Link] You have deliberately omitted the statements immediately following the ones you've quoted which qualify those quotes. The first quote is particularly out of context, as the qualifying statement is in the same sentence: "... if no one thinks the infringment matters.". That's quite trollsome behaviour, something I would not have expected from an LWN subscriber.
More DTrace envy Posted Jul 7, 2008 17:22 UTC (Mon) by clump (subscriber, #27801) [Link] Ignoring your attacks, myself and some others here obviously think infringement matters. That's kind of the point... It's also ironic that you've gone out of your way to condemn others for thinking they know why Sun chooses the licenses it does, yet you consider it a deliberate attempt to troll when someone points out what appears to be inconsistency in your logic. By all means, disagree with my point if I am wrong but don't pretend you're taking the high road.
More DTrace envy Posted Jul 3, 2008 15:41 UTC (Thu) by zooko (subscriber, #2589) [Link] Be careful using the notion of "Sun" as a person which can have intentions and plans and so forth. Even though the people who chose CDDL did so deliberately in order to avoid their technologies being added into Linux (according to Danese Cooper's public comments and other private communications that I've had with other Sun employees), that doesn't mean that Bryan Cantrill so chose, or even that he is aware of or believes that it was so chosen. Anyway, Bryan Cantrill's knowledge, opinions, and intentions are necessarily different than those of other Sun employees, and neither is he wholly responsible for what the company does nor is the company wholly responsible for what he does. There is a sense in which companies cannot actually have intentions. Fortunately, in our society we allow them to enter into binding agreements, such as by publishing their software under an open source licence, so that we no longer have to form a mental model of the company's intention in order to know what we can do with their source code. P.S. I'm glad that free and open Solaris exists, as well as other free and open operating systems such as the BSD's and apparently eventually Symbian. If every computer in the world ran Linux, we would all be poorer for it -- monoculture leads to stagnation and fragility. Diversity and competition is the fount of creativity and excellence.
More DTrace envy Posted Jul 3, 2008 14:33 UTC (Thu) by bcantrill (guest, #31087) [Link] However pretending that legal uncertainty and explicitly distributing source code under GPL-incompatible terms aren't a (the) major issue, while claiming to want wider adoption of that code base under GNU/Linux and suggesting it isn't adopted because of NIH is just silly.And now we have arrived at the central disconnect between us and the Linux community: we did not open source Solaris to get "wider adoption of that code base under GNU/Linux"; we open sourced Solaris because of our own business objectives, some of which I have previously described. Contrary to the beliefs of some in the GNU/Linux community, GNU/Linux and GPL are not the beginning and end of open source, and as we have explained, GPLv2 was not acceptable to us because we could not dictate licensing terms to in-kernel software writers, many of whom are 3rd parties who either will not or cannot relicense. Having an open source license that allowed for different license terms (including proprietary ones) was and is a constraint; allowing our technology to be ported to other operating systems was of secondary concern. So there you have it: while we would welcome DTrace in Linux (and we will help and are helping those that would port it), it's not something we covet. If you want it, take it. If you don't, fine -- but know that many of your users would like to see you embrace the technology, and happen to care much more about solving their business problems than about legal arguments about why it's "impossible"...
More DTrace envy Posted Jul 3, 2008 16:32 UTC (Thu) by willy (subscriber, #9762) [Link] Brian, if you want DTrace to be part of Linux, just dual-license it. You can release your code under "CDDL or GPL" and then it can happily become part of Linux. I, for one, would welcome that.
More DTrace envy Posted Jul 3, 2008 17:30 UTC (Thu) by bcantrill (guest, #31087) [Link] Brian, if you want DTrace to be part of Linux, just dual-license it. You can release your code under "CDDL or GPL" and then it can happily become part of Linux. I, for one, would welcome that.Dual licensing is something that the OpenSolaris community is very strongly against -- in part because dual licensing creates the possibility of a license-based fork. (Which given the enmity towards both Sun and the CDDL among many in the Linux camp, seems to be a very real possibility.) And again: we don't "want" DTrace to be a part of Linux -- it's up to the Linux community to want that, just as it was up to the FreeBSD, MacOS X and QNX developer communities to want it...
More DTrace envy Posted Jul 3, 2008 19:33 UTC (Thu) by bronson (subscriber, #4806) [Link] FreeBSD, MacOS X, QNX... So all we have to do is relicense the Linux kernel under BSD? Well, why didn't you say so! That sounds so easy! Perhaps you're interpreting a specific licensing incompatibility as a lack of desire from the Linux community? I can assure you, the community as a whole really does want to integrate DTrace. A lot! TONS. It would happen in a matter of weeks if only the licenses allowed it to be possible.
More DTrace envy Posted Jul 3, 2008 20:00 UTC (Thu) by bcantrill (guest, #31087) [Link] Now there's some big talk! Do you have any idea of the technical details involved in this, or are you one of the ESR groupies who believes that given "enough eyeballs" pixies and fairies magically solve all problems? I can assure you from working with Paul that the Linux idiosyncrasies are making the DTrace port rougher going than most -- and porting DTrace is a deeply technical endeavor on the best of days. So it would not show up in a "matter of weeks", even if it were GPLv2 and Torvalds himself were doing the port. (Sacrilege, I know.)
More DTrace envy Posted Jul 3, 2008 21:16 UTC (Thu) by bronson (subscriber, #4806) [Link] I was careless and I'm sure you're right. What I *should* have said is, "lots of Linux devs would spend a lot of their time incorporating DTrace, if only the licenses allowed it." But my point remains: you seem to be interpreting license problems as a lack of desire. The desire is there, no question! If the licensing problems could just be fixed somehow, I'm confident the Linux camp would devote amazing hours to DTrace. As it is, they have to devote amazing hours to replicating DTrace. :(
More DTrace envy Posted Jul 3, 2008 19:42 UTC (Thu) by k8to (subscriber, #15413) [Link] Wow, more disingenouousness. I'm impressed.
More DTrace envy Posted Jul 4, 2008 9:33 UTC (Fri) by dark (subscriber, #8483) [Link] Dual licensing is something that the OpenSolaris community is very strongly against -- in part because dual licensing creates the possibility of a license-based fork. No, it doesn't. Even if there were a GPL-only fork, SUN could simply use the GPL code in its CDDL products, under the "legal arguments don't matter" approach that you advocate. After all, they are both free software licenses. Or does the shoe pinch on the other foot?
More DTrace envy Posted Jul 6, 2008 2:13 UTC (Sun) by dirtyepic (subscriber, #30178) [Link] Dual licensing is something that the OpenSolaris community is very strongly against -- in part because dual licensing creates the possibility of a license-based fork. How can you fear a licensed-based fork when incompatible licenses are a "moot, philosophical matter"?
fork fears could be worked out Posted Jul 7, 2008 18:09 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] The issue of a fork could be worked out. Sun count agree to dual-license DTrace, and Linus and the other kernel developers could agree to dual-license all improvements to that code that are accepted into the internal tree. This would neutralize any legitimate fears on the part of OpenSolaris developers that the Linux side would take and not give. It might require some re-architecting to separate out common code, from code that is Solaris-specific or Linux-specific. But Sun would gain a larger developer community to help improve the code.
More DTrace envy Posted Jul 3, 2008 16:43 UTC (Thu) by nhippi (subscriber, #34640) [Link] > know that many of your users would like to see you embrace the technology, and happen to care much more about solving their business problems than about legal arguments about why it's "impossible" It works the other way around too. Many people would like to use solaris but can't since the drivers are missing and care more about solving their business problems than legal arguments why it's "impossible" to solaris to copy those drivers from Linux to solaris. And to remind you, this problem was not created by Linux community or GPLv2, but by SUN. The more paranoid side of community believes the problem was created on purpose. In a hindsight it might seem it's not a problem to sun's customers, since Sun is surely capable of rewriting (who was it again calling NiH?) all drivers needed to run the Sun servers being sold, even if there already is a working GPLv2 driver. However, even Sun systems have these USB/PCI-express expansion slots, where many people would like to attach interesting hardware...
More DTrace envy Posted Jul 7, 2008 10:26 UTC (Mon) by arafel (subscriber, #18557) [Link] >but know that many of your users would like to see you embrace the >technology, and happen to care much more about solving their business >problems than about legal arguments about why it's "impossible"... I'm sure it wasn't what you intended, but the tone of that comment makes it appear (at least to me) like you're suggesting legal restrictions don't matter. Could you clarify that slightly...? To be honest, I'm having some difficulty with your post altogether. The suggestion that the Linux developers are being deliberately obtuse in not integrating software which legally they cannot integrate is, um, curious. Or do Sun not bother with such restrictions? ;-) (Joking, I'm joking...)
choosing whether to allow dtrace integration with gnu/linux Posted Jul 9, 2008 20:09 UTC (Wed) by mjw (subscriber, #16740) [Link] we would welcome DTrace in LinuxYou 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.
More DTrace envy Posted Jul 3, 2008 9:34 UTC (Thu) by mjg59 (subscriber, #23239) [Link] Pedantically, it's a Linux kernel copyright holder rather than a Linux kernel contributor. Some portions of code have been lifted from other projects, and some portions of code have been signed away to other organisations. But to the extent that I think it's unlikely that anyone would sue, I agree. "Unlikely" probably isn't good enough for the large companies that could be potential targets, though, and as a result it's a practical matter as well as a philosophical one.
More DTrace envy Posted Jul 3, 2008 12:26 UTC (Thu) by paulj (subscriber, #341) [Link] "Unlikely" probably isn't good enough for the large companies that could be potential targets, though, and as a result it's a practical matter as well as a philosophical one. You're talking about legal risk, and you can't eliminate it. All companies must live with it, companies shipping software particularly so. Your legal department should be well-versed in considering legal risks and you really should talk to them about it. I didn't realise there'd be such a big risk of Linux kernel contributors and/or copyright holders suing *each other*. Sounds like a fun community..
More DTrace envy Posted Jul 3, 2008 12:41 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
As an example, SCO own copyright to various pieces of Linux. Microsoft could buy one of the
small companies that owns various files. Stepping into obvious legal uncertainty like this
would allow for the generation of huge quantities of FUD ("Linux violates its own copyright
license. Do you really trust that it doesn't violate others?"), DMCA takedowns and lawsuits.
Paranoid? Yes. But no major Linux vendor is going to leave themselves open to that for the
sake of a single feature, no matter how attractive it is.
More DTrace envy Posted Jul 3, 2008 13:44 UTC (Thu) by tzafrir (subscriber, #11501) [Link] Even worse: Apple might buy all the copyrights from Linus tommorow to all of his works and relicense them as proprietary (let's make it even worse: CDDL ;-) ). The sky will fall, right? Not quite. http://www.fsf.org/licensing/licenses/gpl-faq.html#CanDev... Any other legal uncertainty?
More DTrace envy Posted Jul 3, 2008 14:57 UTC (Thu) by mjg59 (subscriber, #23239) [Link] You've missed the point. If Microsoft (say) end up holding the copyright on part of the kernel, they get to enforce that copyright. If they interpret the GPL as preventing the incorporation of the CDDLed dtrace then they get to sue everyone distributing the Linux/dtrace combination. With that as a possibility, I just don't see any major Linux vendor taking the risk.
More DTrace envy Posted Jul 3, 2008 15:29 UTC (Thu) by tzafrir (subscriber, #11501) [Link] If it was already published as GPL, then they cannot change that. (Otherwise they would have done so already). That's the nice thing about free software. BTW: look at the Tentacles of Evil test in http://en.wikipedia.org/wiki/Debian_Free_Software_Guideli... . We try to assume the worst. We try to assume that the copyright owners will suddenly become a second Caldera/SCO. The software must remain usage, distributable, modifiable etc. even in that case. If a software fails that test it won't make it into Debian. In fact, there are those who claim that the CDDL does not qualify because it fails exactly that test (due to the choice of venue clause).
More DTrace envy Posted Jul 3, 2008 15:48 UTC (Thu) by mjg59 (subscriber, #23239) [Link] No, you're still missing the point. For the sake of argument, we'll assume that using the CDDLed dtrace code in Linux is a violation of the GPL[1]. Let's also assume that none of the Linux copyright holders are going to sue anyone who distributes this infringing combined work. Now let's imagine that Microsoft buy a small Linux contracting company that holds the copyright for part of the Linux kernel. Microsoft now get to enforce the GPL against anyone shipping Linux in a way that violates it, and so file takedown notices against Red Hat and Novell. The only defence these companies would have is "It's not a derivative work of the kernel", which runs counter to arguments that they've made in the past. Do you really think anyone wants to be open to that situation? [1] As Bryan points out, this is a grey area. But I don't see any of the major Linux vendors being keen on being the first to have that tested in court.
More DTrace envy Posted Jul 3, 2008 16:04 UTC (Thu) by paulj (subscriber, #341) [Link] You have completely ignored the "if the Linux copyright holders agree" condition repeated several times across, at least, my comments. It is entirely within the power of the copyright holders to define the licence used, including adding their exceptions to the GPL, such as "incorporating CDDL code is ok". My understanding is that the Linux licence has even been modified in the past, and unilaterally at that! We could imagine otherwise, sure. We could also imagine Jonathan Schwartz as He-Man battling it out with Linus as Skeletor over who is master of Greyskull*... (feel free to mentally reverse the roles according to preference). * NB: humour..
More DTrace envy Posted Jul 3, 2008 16:13 UTC (Thu) by mjg59 (subscriber, #23239) [Link] Some of the Linux copyright holders are dead. Some have merely vanished. One of them's a company that tried to kill Linux a few years ago. In some cases we probably don't even have a solid idea who the copyright holder is. Changing the license isn't a real possibility. (The last time the license changed was in 1992, when it probably was possible to identify everyone who'd contributed any code to Linux using a single person's fingers. Since then Linus has clarified what his interpretation of the license is at various points, but these clarifications aren't binding)
More DTrace envy Posted Jul 3, 2008 18:02 UTC (Thu) by paulj (subscriber, #341) [Link] ISTR some kind of brouha, discussed on LWN I think, not so long ago about Linus changing the Linux copyright to exclude the possibility of upgrading its GPLv2 to GPLv3 (it was claimed he hadn't actually changed the licence, but that wasn't accepted all? I dont quite remember).
More DTrace envy Posted Jul 3, 2008 18:11 UTC (Thu) by paulj (subscriber, #341) [Link] Huh, nm. You covered the GPLv2 clarification. My bad for not reading.
More DTrace envy Posted Jul 3, 2008 18:04 UTC (Thu) by paulj (subscriber, #341) [Link] Oh.. dead copyright holders either have successors in interest, or else they don't matter, is what I suspect a lawyer would tell me.
More DTrace envy Posted Jul 3, 2008 18:31 UTC (Thu) by mjg59 (subscriber, #23239) [Link] Indeed, my understanding is that the copyright will generally end up with whoever holds the estate. That doesn't make it easy to track them down.
More DTrace envy Posted Jul 3, 2008 19:18 UTC (Thu) by paulj (subscriber, #341) [Link] I bet there are ways to solve this problem, such as publicising a proposed change and asking for objections. Perhaps the law has already dealt with cases where some minority of copyright holders in a collective work can't be found and/or don't take an interest... It's not Suns' problem though..
More DTrace envy Posted Jul 3, 2008 19:33 UTC (Thu) by mjg59 (subscriber, #23239) [Link] I agree - it's unfortunate for Linux that Sun chose a license that the GPL is incompatible with, but they were entirely within their rights to do so. My only objection is to the repeatedly raised "Linux people hate dtrace for irrational reasons" type claims. Linux vendors feel they can't ship dtrace for justifiable legal reasons, which means that there's little incentive to work on the technical details. Whatever NIH tendencies the Linux community may have, they're not the reason for ignoring dtrace.
More DTrace envy Posted Jul 3, 2008 21:32 UTC (Thu) by bronson (subscriber, #4806) [Link] No, it's not Sun's problem. Unfortunately, it's not Linux's problem either -- the GPLv2 was written 15 years before the CDDL. It's a mutual problem. The Linux team is unable to modify the Linux Kernel's license, and the DTrace team sounds quite unwilling to amend/modify/dual license DTrace, so I guess we're at an impasse. Can anything be done?
More DTrace envy Posted Jul 3, 2008 21:51 UTC (Thu) by paulj (subscriber, #341) [Link] I'm sure we could find licences which predate the GPL which also would *not* have served OpenSolaris. E.g. Solaris engineering has a fairly strong BSD background and you can bet that licence was at least mentioned.. So, sorry, that's just a daft argument.
More DTrace envy Posted Jul 3, 2008 22:55 UTC (Thu) by bronson (subscriber, #4806) [Link] Hm, I don't understand. What is a daft argument? That it's a mutual problem? That combining CDDL and GPL code appears to be at an impasse?
More DTrace envy Posted Jul 3, 2008 18:35 UTC (Thu) by smoogen (subscriber, #97) [Link] There are probably over 1000 Linux copyright holders. Getting 100% agreement out of 1000 people is rare if not impossible. One of the bonuses Sun can say as a business argument is that OpenSolaris is 100% theirs and they can do whatever they want when they want without having to get such agreement.
More DTrace envy Posted Jul 3, 2008 19:06 UTC (Thu) by paulj (subscriber, #341) [Link] Getting 100% agreement out of 1000 people is rare if not impossible. Asked a lawyer whether 100% of 1000+ is required? It's very tempting for programmers to try interpret law almost programmatically, yet incorrectly. There surely must be case law from the music industry.. This still isn't Suns' problem though. It's not reasonable to expect Sun to open-source Solaris under any licence but one that suits the needs of Solaris users and Suns' business (see Bryan's post, and ealier post of mine).
More DTrace envy Posted Jul 3, 2008 17:50 UTC (Thu) by bcantrill (guest, #31087) [Link] Now we've drifted into the absurd. What are the supposed damages in this hypothetical case? In the historical conflict between open and closed source, the case for damages is clear: if Hacker's GPL code is swiped by Meglocorp and ships as a (closed-source) component in a Meglocorp product, the revenues from that product are (arguably) damaging Hacker. But when all of the components are open source, I don't really see the case for damages -- how could a Linux copyright holder possibly be harmed by the presence of another open source component in the same address space? This is not a theoretical point, by the way: if there are no damages, there is no tort.
License incompatibility Posted Jul 3, 2008 18:42 UTC (Thu) by corbet (editor, #1) [Link] So you're saying that free software license incompatibility does not exist, at least as far as the US legal system goes?
License incompatibility Posted Jul 3, 2008 20:23 UTC (Thu) by bcantrill (guest, #31087) [Link] In terms of the law, I think that the GPL is in a dimly lit area to begin with -- and the issue of free software license incompatibility extinguishes whatever light remains. So strictly in terms of case law, no, it doesn't exist. Not that this is desirable, of course; I think software desperately needs legal precedent on the linking issue in particular. If (as I personally believe) dynamic linking does not create a derived work, there is no real "incompatibility" issue to speak of, and we can stop wasting our collective time huffing and puffing about it. Unfortunately, it is in nearly everyone's best interests (FSF, companies, lawyers) for this issue to stay murky -- and I expect it to remain so for the foreseeable future...
More DTrace envy Posted Jul 3, 2008 18:42 UTC (Thu) by mjg59 (subscriber, #23239) [Link] The DMCA allows for damages to be set at the profit realised as a result of the infringement (504(b)). An injunction against Red Hat or Novell would almost certainly be rather more crippling for them than the actual monetary damages.
More DTrace envy Posted Jul 3, 2008 20:27 UTC (Thu) by bronson (subscriber, #4806) [Link] > if there are no damages, there is no tort. Erm, it's fairly easy to get injunctive relief and attorney's fees even without damages. On top of this, there are plenty of reasons to sue other than tort. Unfair competition, deceptive business practices, breach of contract, etc. Any of these might apply. More generally, while article 3 of the constitution leaves this open for interpretation, a few of the recent Supreme Court decisions have allowed large suits with some awfully vague damages (Mass v. EPA). And many states have their own laws, like CA's recent prop 64, that essentially do allow tort without damages in certain circumstances. So, depending the state where the lawsuit is brought and the current makeup of the Supreme Court, your statement ranges from somewhat incorrect to completely false. So, just because two entites are making no profits, that doesn't mean they can wantonly violate their mutual licenses and contracts. Now *that* would be absurd!
More DTrace envy Posted Jul 3, 2008 20:45 UTC (Thu) by paulj (subscriber, #341) [Link] So who is going to sue whom on what grounds? Say Novell ships a Linux-DTrace and SCO file for injunction relief based on their copyright interest in Linux (see mjg's comments). What are the grounds exactly? If you really want to find reasons why you can't port DTrace, knock yourself out. Seems a productive use of energy..
More DTrace envy Posted Jul 3, 2008 20:55 UTC (Thu) by mjg59 (subscriber, #23239) [Link] The argument would be that any Linux implementation of dtrace is going to end up being a derived work of the Linux kernel, and therefore would have to be available under the terms of the GPL. The CDDL includes restrictions not present in the GPL, making it impossible to satisfy both licenses simultaneously. Shipping the combined work would therefore be a violation of the GPL. In the absence of the GPL there's no further permission to distribute the Linux (and Linux derived) code, and therefore doing so constitutes a copyright infringement. Various people have various opinions on the validity of that argument. I'm aware of various legal opinions that have been professionally offered. To the best of my knowledge, though, there's no especially useful case law and so it's difficult to know which way the courts would go. People tend to err on the side of caution when the potential cost (injunctions against distributing their primary product) outweigh the potential benefit (a single, even if useful, feature).
More DTrace envy Posted Jul 4, 2008 0:52 UTC (Fri) by giraffedata (subscriber, #1954) [Link] You missed his point. He's saying even stipulating that a Linux copyright holder would have a legal right to stop someone from distributing a Dtrace-enhanced Linux kernel, why would he do it?The answer lies in the basis of the free software movement: Any free software activist who happens to be a copyright holder and able to stop Red Hat from distributing a Dtrace-enhanced Linux kernel would want to do so. The movement is about encouraging the proliferation of free software by restricting the proliferation of less free software, using copyright. So yes, he would deprive the world of Linux Dtrace so that 1) he wouldn't be personally contributing to the expansion of less free software, and 2) to put pressure on Red Hat to create some GPL alternative. It's the same reason Linux people have sued router manufacturers for distributing enhanced Linux kernels that contain code for which you can't get the source.
More DTrace envy Posted Jul 4, 2008 12:14 UTC (Fri) by mjg59 (subscriber, #23239) [Link] You missed his pointNo, I didn't.
More DTrace envy Posted Aug 31, 2008 20:10 UTC (Sun) by rlhamil (guest, #6472) [Link]
> The movement is about encouraging the proliferation of free software by restricting the
> proliferation of less free software, using copyright.
_That's_ what makes me crazy about the GPL: to advance the Cause and preserve one's
I never saw how some could argue that BSD is _less_ free than GPL, especially the GPL
GPL strikes me as equivalent to the mandatory volunteerism one sees in high schools today
Nevertheless, I don't deny it serves a purpose, just that its purpose is not and should not
Sure would be nice if someone worked out a way to dual-license that required that
IMO, the _real_ problem isn't license incompatibility so much as it is what causes a lot of
There may not be any good answers given a range of perfectly legitimate if widely varying
More DTrace envy Posted Jul 3, 2008 22:46 UTC (Thu) by bronson (subscriber, #4806) [Link] > So who is going to sue whom Doesn't matter. > on what grounds? From my previous post: unfair competition, deceptive business practices, breach of contract, etc. Depends on the circumstances and parties. > If you really want to find reasons why you can't port DTrace, knock yourself out. Nobody's trying to create reasons not to port DTrace if that's what you're implying. But here's the thing: if it isn't clearly legal and moral to snake someone else's code, then it's only considerate and safe to assume that you can't! I've been searching for reasons to believe that they're compatible but I haven't found any clear legal statement from Sun or anyone else, nor even any tiny nugget of estoppel. Did Sun ever produce the Devleoper's Bill of Rights? http://www.cbronline.com/article_news.asp?guid=3B8EDD57-1...
More DTrace envy Posted Jul 3, 2008 22:10 UTC (Thu) by bronson (subscriber, #4806) [Link] I showed my engineer-attemptls-law post to a friend and she said: > Sometimes when you sue for breach of contract, you can be awarded restitutionary damages which means that even if you can't prove that you have been damaged, you can be awarded money equivalent to the other party's "ill gotten gain". So if the other party unfairly got some advantage that was, for lack of a better term "unfair", you could recover their gain just because it is unfair for them to keep it. > That's one reason why it is dangerous for profitable companies to use open source code. You use code in a way that breaks your contract with the programmer ... that programmer could recover your "ill gotten gain". Wow. Now I'm curious if this has been used in any of the GPL violation cases. I'll have to watch them a little closer!
More DTrace envy Posted Jul 3, 2008 22:47 UTC (Thu) by bcantrill (guest, #31087) [Link] You (or rather your friend) is making my point: the restitutionary damages that she mentions are the case of Meglocorp shipping GPL'd goober in proprietary product, and Hacker suing for damages. That's not the case that was being floated; the assertion was that Meglocorp would become a Linux copyright holder and then could sue when CDDL'd source was distributed with the(ir) GPL'd source. I don't see what the damages are in this case -- compensatory or restitutionary. I think if it's flipped around -- Meglocorp ships GPL'd+CDDL'd goober, Hacker sues because GPL has been violated -- one at least has a case, but I happen to think it's an extraordinarily weak case: it relies on both an expansive definition of a derived work, and a creative approach to damages.
More DTrace envy Posted Jul 3, 2008 22:58 UTC (Thu) by mjg59 (subscriber, #23239) [Link] Nobody knows how far the derived work clause of the GPL would actually reach. Staking your future business to a legal gamble isn't a move many people are willing to make without a large resulting benefit, and dtrace simply isn't perceived as a sufficiently large benefit. It's perfectly rational reasoning.
More DTrace envy Posted Jul 4, 2008 0:03 UTC (Fri) by bronson (subscriber, #4806) [Link] > Meglocorp ships GPL'd+CDDL'd goober, Hacker sues because GPL has been violated Agreed. This is the only one that seems plausible. But proving damages seems to be rather easy nowadays. And just about anybody involved with Meglocorp could sue; it doesn't have to be a Linux kernel hacker. Here's the big-picture problem as I see it: after the SCO disaster, the Linux kernel devs will not incorporate any code of questionable license status into the kernel. They want to keep the entire tree completely unencumbered by legal issues. It was a good lesson at a good time. So, until it can be demonstrated that CDDL and GPL code absolutely can be mixed, they won't accept CDDL-licensed code into the kernel. it's just too risky. As far as derived work, while I agree that those parts of the GPL are horribly murky and untested, I don't think it's very relevant here... Even if someone *could* claim that DTrace is a derived work (a stretch!), as long as the CDDL+GPL combination is "licensed as a whole at no charge to all third parties under the terms of [the GPL]" everything is good. If the CDDL and the GPL are compatible, the terms of the GPL are met, and the whole derived work issue is moot. (Right?) To make CDDL+GPL compatible, IIUC the patent issues just need to be resolved the way Mozilla did with the MPL. Everything else in the CDDL and the GPL is compatible today. (I'm no expert though so I'd sure value someone else's opinion. That almost sounds too easy!) It would be nice to see someone reject license prejudices and try to maintain an out-of-tree DTrace-Linux but... can you imagine? The git-rebases would make the even the heartiest programmer cower in fear!
Contracts Posted Jul 3, 2008 23:13 UTC (Thu) by corbet (editor, #1) [Link] This scenario, of course, depends on the idea that the GPL is a contract; the people who wrote the GPL did not intend that, however; they wrote a license. Assuming that legal reasoning holds, there's no contract to be sued for breaching. And no, I do not believe any GPL-violation case has been a breach-of-contract case; they are copyright infringement cases.
Contracts Posted Jul 3, 2008 23:17 UTC (Thu) by bcantrill (guest, #31087) [Link] Yes, the authors did intend it to be a license -- but the attorneys that I have spoken with on this issue believe that the expansive views of the GPL require it to be interpreted as a contract. Again, some case law here would be quite helpful...
Contracts Posted Jul 4, 2008 0:22 UTC (Fri) by bronson (subscriber, #4806) [Link] http://lwn.net/Articles/61292/ That's a relief, although it does diminish the chances of me finding my code in the Google Toolbar and making a quick hundred million. :)
More DTrace envy Posted Jul 3, 2008 16:30 UTC (Thu) by smoogen (subscriber, #97) [Link] Various parts of Sun went at each other with iron tongs when SunView was looked at being opensourced back in the early 1990's. It is just harder to sue each other inside of a corporation. [I think parts of IBM tried that in the 1960's.]
More DTrace envy Posted Jul 5, 2008 17:55 UTC (Sat) by brouhaha (subscriber, #1698) [Link] (least until the *AA succeed in making copyright infringment a criminal matter)Huh? They succeeded at that 16 years ago! Felony copyright infringement was introduced with the Copyright Felony Act of 1992, and extended by the No Electronic Theft Act of 1997.
More DTrace envy Posted Jul 3, 2008 8:37 UTC (Thu) by nhippi (subscriber, #34640) [Link] NIH: Exactly what technology from Linux kernel has Solaris adopted instead of re-implementing it yourself? License: If the licensing is so unclear, how come there is no GPL code mixed into Solaris? I'm fairly certain it's not a smokescreen or amateur opinion, but something professional Sun lawyers said would be best... Don't get me wrong, I'm happy for all the things sun has contributed, but the amount of licensing misery caused by inventing (NiH!) yet another license, CDDL, is very real.
More DTrace envy Posted Jul 7, 2008 2:59 UTC (Mon) by clump (subscriber, #27801) [Link] License: If the licensing is so unclear, how come there is no GPL code mixed into Solaris?You have a valid point. I'm curious what the Sun employees who are commenting here have to say about this.
More DTrace envy Posted Jul 9, 2008 22:43 UTC (Wed) by Tet (subscriber, #5433) [Link] good 'ole NIH in the Linux communityYou could try to be less inflamatory. DTrace was hardly an original idea at Sun, either. You claim SystemTap is a "Linux-born DTrace-knockoff". By that logic, I could claim that DTrace is a Sun-born knockoff of the tracing work IBM did years ago. Sure, Sun have made some big improvements to the art of tracing, such as the D language, and a massive improvement it was too. As are some of the other innovations that have come from DTrace. But that's how the progress is made in this industry -- by building on work done by others. DTrace is not the be all and end all of tracing, and claiming that NIH is the reason behind SystemTap doesn't really help anything at the end of the day. Both DTrace and SystemTap are useful products and have their place in the world. DTrace is good enough to stand on its own technological merits, without the needless put downs aimed at SystemTap (which pretty much everyone agrees is currently lagging DTrace by some margin). You're rightfully proud of the work you've done on DTrace, but perhaps a little less hostility to the competition might be appropriate...
More DTrace envy Posted Jul 9, 2008 22:58 UTC (Wed) by bcantrill (guest, #31087) [Link] By that logic, I could claim that DTrace is a Sun-born knockoff of the tracing work IBM did years ago.I'll call that bluff. What technology are you referring to, exactly? Or more concisely, in our 2004 USENIX paper, what piece of related work did we neglect? I'm eager to see what technology you're going to parade out as an example of dynamic instrumentation done "years ago" at IBM -- at least we'll be talking about concrete technology and not licensing!
More DTrace envy Posted Jul 3, 2008 13:16 UTC (Thu) by SEJeff (subscriber, #51588) [Link] @Jake, the article writer: How can you mention SystemTap's lack of userspace tracing support when it does support this feature? Roland McGrath of redhat is working on a new ptrace() named utrace[1]. Using utrace, someone created a project named uprobes [2]. Using uprobes, tapsets including userspace tracing were written at [3]. Roland made grumbles of submitting utrace for mainline again not so long ago. Once utrace is in mainline we will soon see full userspace + kernelspace tracing support in SystemTap. The systemtap + utrace userspace tracing support was put into RHEL5.2 beta [4]. So please get the facts straight. While it would be *REALLY NICE* if sun were to allow DTrace in Linux by relicensing it gplv2, that doesn't look like it will happen. So eventually... Linux's answer to DTrace = SystemTap + uprobes Linux's answer to ZFS = btrfs As fast as things are developing we aren't a long way off. This isn't fud, only facts people. [1] http://people.redhat.com/roland/utrace/2.6-current/ [2] http://ols.108.redhat.com/2007/Reprints/keniston-Reprint.pdf [3] http://lwn.net/Articles/255429/ [4] http://www.redhat.com/archives/rhelv5-announce/2008-March... CTRL F SystemTap
User-space probes Posted Jul 3, 2008 13:55 UTC (Thu) by corbet (editor, #1) [Link] Perhaps Jake was watching the discussion, where the systemtap developers talked about their work toward having user-space probes in the future? If I wanted to run systemtap with any sort of user-space probing now - especially if I wanted to take advantage of all those nice probe points already put into applications like postgresql - I'd be pretty much out of luck. I think Jake has his facts straight enough.
More DTrace envy Posted Jul 3, 2008 20:30 UTC (Thu) by oak (guest, #2786) [Link] > As fast as things are developing we aren't a long way off. This isn't fud, only facts people. I don't want to be pessimistic, but Utrace seems still work in progress, only the very first patchset from it has gotten to upstream, it supports well only x86 & powerPC and rest of it's still being designed. See the latest status report: http://www.redhat.com/archives/utrace-devel/2008-July/mht... I think it's at least a year until it's fully (API stabilized etc) in upstream kernel with Systemtap supporting it well, a good set of tapsets, useful scripts, documentation and some GUIs (Mortadelo and Stapgui lack a lot of things). This is what Apple is already doing with DTrace: http://developer.apple.com/documentation/developertools/C... And before that their developers already had Shark (which AFAIK doesn't use DTrace): http://developer.apple.com/tools/performance/optimizingwi... Btw. the Tracing Summit in Canada earlier this year produced fairly good overview of the state of tracing tools currently (also elsewhere than on x86): https://ltt.polymtl.ca/tracingwiki/index.php/TracingBook
More DTrace envy Posted Jul 10, 2008 5:23 UTC (Thu) by renox (subscriber, #23785) [Link] Probably because the author know the state of the user tracing where DTrace support has been/is being incorporated in many tools: Ruby, etc which simplify a lot the tracing by the end-user.. Whereas currently SystemTap doesn't have this 'support' of all the enduser tools. >we aren't a long way off. Depends of your measurements! If you look at Ted Tso complaints, support of SystemTap by endusers tools, the schedule, SystemTap appears to be very, very late compared to DTrace..
More DTrace envy Posted Jul 3, 2008 17:28 UTC (Thu) by karim (subscriber, #114) [Link] Personally, the DTrace thing looks like a clear case where the Linux development model fell flat on its face. I first released the Linux Trace Toolkit back in July '99 -- close to 10 years ago now. From very early on I met a tremendous amount of resistance to it, despite having made clear that this was made for users (not kernel developers) to understand how their system behaves. Maybe I didn't do a good job of communicating that view, and, hey, maybe even the implementation wasn't the best out there (though the record would show that implementation quality was hardly a reason for refusing to merge the code), but it remains that interest in kernel tracing for *users* only came to the forefront and remains on the forefront for one simple reason: the existence of DTrace. And that, it seems to me, is the wrong reason for things to happen. If Linux (kernel and system) is to lead the pack in what it delivers to its users, it must be able to give functionality to users that other OSes can't. But as the recent "Ubuntu girlfriend experiment" has shown, we're still trailing other OSes (DTrace is but a symptom) and that needs to change.
LTT was: More DTrace envy Posted Jul 5, 2008 17:38 UTC (Sat) by linuxbox (subscriber, #6928) [Link] Thanks, seems like LTTng is more than worth a look.
More DTrace envy Posted Jul 12, 2008 14:56 UTC (Sat) by foxcrisp (guest, #52781) [Link] I find most of the comments to this article 'interesting' in that they debate the licensing issues and who owns what. Nearly everyone is missing the point. Whilst you all debate the merits of a license, nothing much happens. Dtrace is needed by real people in real production environments. Environments designed for dtrace - production critical, and by people who dont know the kernel. There are lots of issues with dtrace - which relate to competence of a user in a scenario where they need or could use dtrace. Does dtrace have to be in the kernel? Absolutely not. I dont know why people are hung up on that issue. We dont put mplayer or firefox in the kernel, and dtrace doesnt need to be either. By *not putting this in the kernel simply increases the work for the dtrace maintainer (presently, me)* to handle the Linux development model. When I buy an off the shelf product - I expect it to work, irrespective of my platform or version of OS. Dtrace should be like that. That is the issue - can it be platform independent to an end user. (The code may end up with horrid #ifdefs but the end user wont/shouldnt care). The more i get into dtrace the more I am convinced of the above. I have not had to modify a Linux kernel to make it work and have no intention in the future - the difficult bit (proving it can be done) is over. The next phase is looking at the end-user experience and looking for compatibility and least-surprise. paul fox
|
|||||||||||||