More DTrace envy
More DTrace envy
Posted Aug 31, 2008 20:10 UTC (Sun) by rlhamil (guest, #6472)In reply to: More DTrace envy by giraffedata
Parent article: More DTrace envy
> 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.