Steven Vaughan-Nichols: “Over in the land of LAMP (Linux, Apache, MySQL and the scripting language of your choice that begins with P), they’re discovering that backward compatibility is a bear. Welcome to the world of serious software development.”
One of the big Debian stories of the week is that a company called Nexenta Systems has made a version of Ubuntu that’s based on OpenSolaris rather than the Linux kernel. Personally, I find the emergence of a Debian-based OpenSolaris distribution exciting, as it promises to vastly improve Solaris installation, packaging, and overall usability. Solaris is great technology with an incredible pedigree and some very compelling features (DTrace, in particular, sounds like a godsend, as I’m sure anyone who’s debugged kernel code via endless iterations of inserting printfs at strategic places would agree), not to mention that it’s now open source. However, when a Linux developer eager to have a look at all this neat new open source stuff boots up Solaris for the first time, it’s a bit of a throwback to an earlier time (not to mention the fact that apt-get is a hard habit to break..).
And, so, I’m more than a little embarrassed at how certain members of the Debian community reacted to Nexenta’s work. The vitriol surprised even me, knowing as much as I know about how, uh, strongly the Debian community feels about certain issues. The issue in this case: Nexenta links GPL-licensed programs (including dpkg) with the Sun C library, which is licensed under the GPL-incompatible but still free software/open source CDDL license. Granted, Nexenta didn’t go about introducing themselves to the Debian community in the best way, and there may (may) be issues around whether or not what they are doing is permitted by the GPL, but couldn’t we at least engage them in a more constructive manner?
In terms of the actual issue being discussed here, am I the only one who doesn’t get it? It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch—not to mention the fact that we’re talking about libc here, a library with a highly standard interface that’s been implemented any number of times and, heck, that’s even older than the GPL itself. It’s interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word. It’s one thing to ensure that actual derivative works of GPL code are themselves licensed under similar terms; it’s quite another to try to apply the same argument to code that clearly isn’t a derivative work in an attempt to spread free software at any cost. I’ve been a big GPL advocate for a long time, but that just strikes me as wrong.
More David Berlind: “Maybe I’m crazy. But if you ask me, there’s a super big picture that’s begining to form when you start to look at all of this week’s announcements, or maybe-announcements involving Google, AOL, Real, Microsoft, Apple, Yahoo, Sun and more. If I’m not mistaken, just about everyone is taking sides in preparation for what appears to be a two-way show down with an odd-man out.”
David Berlind: “One of the things that has made Microsoft fantastically successful is the way the company’s development tools make child’s play out of developing Windows applications.”
Following time-honored tradition, “DCC” is now a recursive acronym that stands for “DCC Common Core”. Importantly, “DCC” no longer stands for “Debian Common Core”, and we’ve updated the FAQ accordingly. If you see further references to “Debian Common Core” in the press, feel free to send them a link to this page or ask them to contact me.
Why are we doing this? The DCC is a truly important initiative for Debian, and we don’t want continued controversy over what we chose to call it to overshadow the real message of the DCC, namely that Debian is ready for enterprise use.
In related news, we’re in the process of trying to make the DCC (or at least the technical aspects of it) an official Debian subproject—see the debian-enterprise Alioth project if you’re interested in Debian in the enterprise and want to get involved.
Matthew: Is the DCC a fork? Not by the standard definition of the term:
[A] fork is what occurs when two (or more) versions of a software package’s source code are being developed in parallel which once shared a common code base, and these multiple versions of the source code have irreconcilable differences between them.
Perhaps you use a different definition, so I’ll outline the differences between Debian and the DCC, and you (and others) can decide for yourself:
The following kernel images are provided: 586tsc (standard x86), p4-smp (Pentium 4 with SMP support), k7-smp (Athlon with SMP support), mckinley-smp (Itanium II with SMP support), and amd64-generic (AMD64 and EM64T).
That’s it. Does that constitute a fork? Given that nearly 90% is bit-identical with sarge and the vast majority of the remainder are very lightly modified backports from etch, I wouldn’t call it a fork, but that’s just me.
Furthermore, there’s no parallel development going on, just integration work, and the differences that do exist are very minor and certainly aren’t irreconcilable.
By the way, as I’ve said before, I have no problems with forking, as long as it’s done with compatibility in mind, something the DCC is clearly doing:
My suggestions are a simple way to mitigate the inevitable compatibility problems of a fork without taking away the freedom to fork (which has never been a problem from my point of view, by the way—unlike most people in the free software world, I don’t spend a lot of time wringing my hands over the forking issue—it is, after all, one of the fundamental freedoms of free software).
Back to work. Again.
Things have been quiet on the DCC Alliance front lately, but that’s because we’ve been working to deliver what we said we’d deliver at LinuxWorld last month—we certainly don’t want to come across as big on talking about how much we’re going to help Debian, but lacking any actual contributions yet. After all, code talks and bullshit walks.
In that spirit, here’s an update on our progress:
First and foremost, the first preview release of the DCC, DCC 3.0 PR1, was made available late last week. PR1 supports the i386 architecture.
DCC 3.0 PR2 will be made available late this week or early next week. PR2 adds support for the ia64 and amd64 architectures and fixes a handful of bugs in PR1.
We expect to achieve full LSB 3.0 compliance with PR2 and be very close to the final DCC 3.0 ready for LSB 3.0 certification.
Technical details as of PR1 are in the release announcement; I’ll post the PR2 release announcement with final technical details here.
Technical issues are being discussed on an open mailing list. Feel free to join and participate:
http://lists.dccalliance.org/mailman/listinfo/dcc-devel
We’ve also created a general discussion list for non-technical issues, including, but not limited to, our flagrant misappropriation of the letter D:
http://lists.dccalliance.org/mailman/listinfo/dcca-discuss
Back to work.
August 16, 1993: “Please note that this release is not yet completed and may not be for several more weeks.” Ok, so I was a bit off. (Note: A “release” was what we called a distribution in 1993.)
Joe Brockmeier: “I’d also like to see Novell become part of the Debian consortium that Ian Murdock and others are working on, but I suspect that’s highly unlikely.”
David Berlind: “When a proprietary (often patented) technology earns the status of de facto standard (aka: practically unchallenged market dominance), the licensor of that technology (usually the patent holder) is basically afforded a legal monopoly and an unprecedented amount of market control.”
