dtrace on Linux
dtrace on Linux
Posted Sep 19, 2008 1:48 UTC (Fri) by njs (subscriber, #40338)In reply to: dtrace on Linux by zooko
Parent article: KS2008: Tracing
And no major distro's legal department is going to let them blatantly violate the copyrights of everyone on lkml and open themselves up to legal action. (But at least SCO would finally have a valid case against Novell!)
So don't let me stop your fun, but you're kind of tilting at windmills, to prove some sort of point that I don't quite see...
Posted Sep 19, 2008 12:22 UTC (Fri)
by zooko (guest, #2589)
[Link] (13 responses)
For example:
http://fedoraproject.org/wiki/ForbiddenItems#MP3_Support
https://help.ubuntu.com/community/RestrictedFormats
In both cases, there is some source code which is legal for end-users to use, but (perhaps?) not legal for Linux distributions to distribute.
If I'm right that this is the same legal situation, then this implies that it is legally possible for dtrace-on-linux to be as widely used as MP3-on-linux is. :-)
Regards,
Don Quizooko
P.S. I love tilting at windmills. Every now and then you get a solid hit on those titanic monsters.
Posted Sep 20, 2008 1:37 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (12 responses)
Posted Sep 20, 2008 14:43 UTC (Sat)
by zooko (guest, #2589)
[Link] (11 responses)
How's that for a comparison? The legal constraint on using dtrace or ZFS on Linux is exactly the same as the legal constraint on using a proprietary hardware driver on Linux.
Posted Sep 21, 2008 4:43 UTC (Sun)
by njs (subscriber, #40338)
[Link] (2 responses)
I note that proprietary hardware drivers *suck* in many, many ways. They make your system impossible to provide support for, which is kind of a problem for a product whose core market is high-end enterprise production servers. They break things horribly and regularly -- and dtrace is obviously *much* more intrusive than your average driver. They're a huge pain to use and maintain -- is there any reason to think that the guy porting dtrace will be more successful at tracking linux mainline than RH's engineers are with systemtap? And will it even be possible to load as a module, or will you have to patch your core kernel/rebuild/reboot?
And, perhaps worst, they create all kinds of obnoxious arguments that divide the community -- look at any discussion of nvidia drivers, or the dtrace discussions here. Part of the magic of FOSS is that normally the enthusiasts, the law-skirters, the enterprise distros, the big-iron vendors, the small consultants, etc. etc. can all work towards common goals, and all provide necessary value at different parts of a system's lifecycle. When people spend their time yelling at each other over whether nVidia's drivers are legal or whether systemtap/btrfs/whatever is worth the effort, we all lose.
Which maybe shouldn't be surprising, since all the evidence suggests that one of Sun's strategic goals in choosing to license dtrace and ZFS in a Linux-incompatible way was to create exactly this sort of division within the FOSS community, and thus give Solaris a competitive chance. What I'm still not clear on is which of these titanic monsters you're going after, exactly...
Posted Sep 21, 2008 12:39 UTC (Sun)
by zooko (guest, #2589)
[Link] (1 responses)
But this original argument is not true. At least, it is true only inasmuch as it is also true that the licensing issues of nvidia drivers make them undistributable by anyone, so therefore not not of any practical interest.
Now you're making two other arguments. If I understand correctly, Argument 2: If people do use kernel modules or patches with this kind of legal restriction, it is hard to support and tends to break. and Argument 3: It distracts the community with inflammatory bickering about legal issues.
I don't necessarily disagree with either of those. I personally have gone to great effort to get Free Software drivers for my graphics cards. On the other hand, I have occasionly fallen back to using the proprietary graphics card drivers when needed. I think it could be useful to people to understand that even if the latter two arguments are valid, the first one wasn't: dtrace and ZFS are exactly as legally-portable-to-linux as are proprietary graphics card drivers.
Regards,
Zooko
P.S. Oh wait, I'm not sure if I agree with Argument 2. Argument 2 is a strong argument when we're talking about proprietary, closed-source software, but dtrace and ZFS are Free and Open source, so I'm not sure that it would be as fragile and problematic as proprietary drivers.
Posted Sep 21, 2008 18:38 UTC (Sun)
by njs (subscriber, #40338)
[Link]
It's still of no practical interest to kernel developers, distributors, enterprise users, and many others. Jon's (not bronson's) comment was totally reasonable in context -- a kernel developers' discussion about what enterprise-funded developers should work on!
But fair enough -- there may be (probably are) others who find linux-dtrace of practical interest.
But arguments 2 and 3 are linked to this -- to the extent that such people use linux-dtrace, the harms described in those arguments swing into effect. To the extent they avoid linux-dtrace, the harms are abated -- with a trade-off: then they lose dtrace's benefits. There's a tragedy of the commons danger here; the costs of supporting inscrutably broken systems and inflammatory bickering are borne by the community, while the benefits of dtrace are received only only by individuals. Plus, people using/supporting linux-dtrace are not doing themselves any favors in the long run, because it's clearly a dead-end; it's better than nothing, but getting a great solution will require abandoning it and switching to one of the other systems that linux-dtrace sucks the oxygen away from.
So I guess 2 & 3 are arguments for why if we encounter someone for whom linux-dtrace is of practical interest, we should attempt to stop them ;-).
>dtrace and ZFS are exactly as legally-portable-to-linux as are proprietary graphics card drivers.
As a side-point, I'm actually not convinced, at least for dtrace. The nvidia driver uses two tricks: it makes a serious attempt not to be a derived work of the kernel, by including a Free shim layer to basically a windows driver. And it's always distributed separately from the kernel -- otherwise you're distributing a combined, thus derived, thus un-distributable, work. Even the little distros that tried to play fast and loose seem to have given in on this point.
Dtrace is far more intrusive than a graphics driver, and in copyright relevant ways -- it needs to muck around with other people's code to put hooks in. That makes both of the above tricks hard to achieve. Maybe not impossible, I don't know. From his rhetoric about licenses, I haven't gotten the impression that Paul Fox is being that careful. I would not tell people that linux-dtrace as it exists is legal to distribute at all without knowing many more details.
>Argument 2 is a strong argument when we're talking about proprietary, closed-source software, but dtrace and ZFS are Free and Open source, so I'm not sure that it would be as fragile and problematic as proprietary drivers.
It's true the problems are worse for proprietary drivers, but they're quite bad even for plain old out-of-tree drivers. (Note part of the discussion above is about RH's systemtap team's trouble keeping sync with mainline!) And worries about license contamination are an extra burden on top of that.
Sorry for nattering on so!
Posted Sep 21, 2008 9:29 UTC (Sun)
by paulj (subscriber, #341)
[Link] (7 responses)
Uh, not really. DTrace is free software..
Posted Sep 21, 2008 11:22 UTC (Sun)
by Jonno (subscriber, #49613)
[Link] (5 responses)
Morally and technically it's another matter however, as the source *is*
Posted Sep 22, 2008 10:58 UTC (Mon)
by paulj (subscriber, #341)
[Link] (4 responses)
With DTrace being free-software, there isn't even much of a moral hazard...
Posted Sep 22, 2008 13:57 UTC (Mon)
by corbet (editor, #1)
[Link] (3 responses)
DTrace presents a different hazard; imagine a Sun-turns-SCO scenario, for example. The fact that Sun does not appear to be interested in taking that path now is irrelevant; neither was Caldera, once upon a time.
Posted Sep 22, 2008 14:54 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Sep 22, 2008 15:42 UTC (Mon)
by zooko (guest, #2589)
[Link] (1 responses)
I have a feeling that you already addressed this in your "What if Sun turns Evil?" article, but I don't recall any actual problems that could result from use of DTrace or ZFS source code.
Posted Sep 22, 2008 17:33 UTC (Mon)
by njs (subscriber, #40338)
[Link]
Unless they have changed their mind and answered this at some point. I hope so -- haven't followed closely.
But paulj is right re: copyrights; Sun wrote the CDDL in such a way that combining CDDL and GPLv2 violates the GPL but not the CDDL. This has the same effect in practice as not granting permission, but it means that for copyright issues we don't need to worry about Sun-turns-SCO -- we need to worry about SCO-turns-SCO.
Posted Sep 21, 2008 12:43 UTC (Sun)
by zooko (guest, #2589)
[Link]
However, my point here was that resulting restrictions on use and redistribution are similar:
The copyright holder on DTrace has granted permission to use it in Linux systems, but the GPL which governs redistribution of Linux source code forbids redistributing derived works which include non-GPL'ed code such as DTrace.
This winds up imposing the same sort of restriction on users and distributors that a proprietary driver does: the copyright holder of the proprietary driver grants you the right to use it in your Linux kernel, but the Linux licence forbids you to redistribute it (assuming the current standard interpretation of GPL applied to this issue).
dtrace on Linux
dtrace on Linux
dtrace on Linux
dtrace on Linux
dtrace on Linux
dtrace on Linux
-- Nathaniel
dtrace on Linux
The legal constraint on using dtrace or ZFS on Linux is exactly the same as the legal constraint on using a proprietary hardware driver on Linux.
dtrace on Linux
availible, and *can* be fixed if nessesary...
dtrace on Linux
The number of Linux distributions shipping binary-only drivers has gotten quite small; there are good reasons for that.
dtrace on Linux
dtrace on Linux
dtrace on Linux
dtrace on Linux
dtrace on Linux