[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:
- Back of the envelope, the DCC contains 234 packages, of which 205 (87.6%) are taken from Debian sarge unmodified (as of DCC 3.0 PR1).
- Of the remaining 29 packages, 4 are the LSB 3.0 compatibility environment, which adds LSB 3.0 compliance in such a way that the sarge glibc and pam packages don’t need to be modified (the sarge versions aren’t LSB 3.0 compliant—see Jeff Licquia’s weblog for details here and here). Note that the only applications that use the LSB compatibility environment are LSB applications—the default application environment is the standard Debian environment.
- Of the remaining 25 packages, 19 are a backport of X.org from etch (again, as of DCC 3.0 PR1—there will be additional X.org packages in PR2). The DCC X.org environment is fully compatible with the standard Debian XFree86 environment—in other words, packages built on DCC-based distros will install and run on standard Debian sarge unless they use X.org-specific features (in which case they will link to one of the new X.org packages, such as libxcomposite1 or libxdamage1, not shipped in the DCC itself).
- The remaining 6 packages are backports of the LSB 3.0 packages from etch (lsb, lsb-base, lsb-core, lsb-cxx, lsb-graphics, and lsb-release), modified to 1. not manage the LSB dynamic linker symlinks (these are managed by the DCC LSB compatibility environment); and 2. add LSB_VERSION=3.0 to /etc/lsb-release, since DCC 3.0 is LSB 3.0 compliant.
The kernel is Linux 220.127.116.11 from etch built using the standard Debian kernel build tools and with the following additional patches applied: acpi, bootsplash, ppp_mppe, sk98lin, and win4lin.
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.