More DTrace envy [LWN.net]

More DTrace envy

Posted Jul 3, 2008 20:55 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: More DTrace envy by paulj
Parent article: More DTrace envy

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).

to post comments

More DTrace envy

Posted Jul 4, 2008 0:52 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

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 point

No, 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
own freedom, it restricts other freedoms that might have more immediate practical benefit.

I never saw how some could argue that BSD is _less_ free than GPL, especially the GPL
adherents, from whom there's usually the sucking sound of one-way transfers of code
from BSD to GPL. Someone creating a proprietary fork of a BSD licensed program takes
away _nothing_ from the freedom of those who continue to retain access to the pre-fork
original.

GPL strikes me as equivalent to the mandatory volunteerism one sees in high schools today
(community service as a requirement of passing). A great idea to _offer_ such a thing, but
apalling to require it. There _is_no_virtue_ when virtue is enforced rather than chosen
freely!

Nevertheless, I don't deny it serves a purpose, just that its purpose is not and should not
be the only one worth serving.

Sure would be nice if someone worked out a way to dual-license that required that
derivatives of the dual-licensed code remain subject to the choice of license, but
was otherwise clearly non-viral, so that neither side could lay claim to more than what
they brought to the table, allowing DTrace, and zfs (native, not FUSE) on Linux, for example.
The source file scope of CDDL seems to me useful in that regard, avoiding issues about
static vs dynamic linking and binaries altogether. Despite that having more practical benefit
to Linux (which could then receive dual-licensed code) than OpenSolaris (for which I doubt
GPL ideologues and Linux zealots would choose to return the favor by dual-licensing
anything), simply getting more input might well at least improve the software shared as
a result faster than the originators alone could do so.

IMO, the _real_ problem isn't license incompatibility so much as it is what causes a lot of
it: hardware with closed specifications and thus closed drivers. But given the often blurry
line between hardware and software, enouraging open hardware specs might require
tolerating at last _narrowly scoped_ software patents, which are landmines in their own
right.

There may not be any good answers given a range of perfectly legitimate if widely varying
interests. But I'd sure like to see an attempt to strike a different balance between
ideology (which carried to its logical conclusion is often self-contradictory) and pragmatic
concerns (which arguably are often short-sighted). And though they're not the same thing,
both cooperation _and_ competition serve a purpose; on the far side of Eternity, there may
be One True Answer, but until then, a selection of approaches remains useful, especially
given the power-tripping that those who think they have the One True Answer prematurely
tend to eventually descend to.