The free software world generally sees a fork in a development project as a
bad thing. The ability
to fork is a crucial freedom, but the
exercise of that ability is seen much like initiating a divorce. Sometimes
it is necessary, but it is rarely an event which brings joy.
Little attention, however, has been paid to the idea of a parallel
fork, which we will define as a fork which continues to follow the
changes in the original project. The Linux kernel has been the subject of
large numbers of parallel forks over the years; distributor kernels,
architecture-specific trees, and development trees have diverged widely
from the mainline kernel and each other, but they also track the updates to
the mainline. Projects which are patched by distributors (such as
cdrecord) can also be seen as parallel forks. Yet another example might be
functions as a testing ground for bleeding-edge Sylpheed features.
Parallel forks can be the best of both worlds: they retain a tie to the
original project, but also are responsive to whatever forces created the
fork in the first place.
A parallel fork worthy of some attention is ooo-build, a version of
OpenOffice.org maintained by the folks at Ximian. Version 1.3.0 of
ooo-build was announced on August 18.
This fork was motivated by several issues, which are explained in depth at
the project web site. What it comes down to, however, is that the
OpenOffice.org process is slow, bureaucratic, and difficult for outsiders
to contribute to. As the web site says, "this is no way to create
excitement and provide fast problem fixes." So ooo-build was set up
as a place where would-be contributors can get their changes in quickly
and, with luck, see those changes used and possibly propagated back into
What does the 1.3.0 release offer?
This package contains Desktop integration work for OpenOffice.org,
several back-ported features & speedups, and a much simplified
build wrapper, making an OO.o build / install possible for the
There is a detailed list, which includes a number of bug fixes, GTK+ and
KDE file selector support, Lotus 123 importing, improved icons, and much
more. Oh, and the obnoxious business where OOo calls your file "modified"
every time you print it has been fixed.
The ooo-build parallel fork is a good thing: it brings the notoriously
unapproachable OpenOffice.org development process closer to what the rest
of the community expects to deal with. It can be a useful staging ground
which gets new features to users quickly, and enables stability testing
which can help smooth the eventual merging of those features into OpenOffice.org. It is
not the sort of acrimonious separation which normally comes to mind when
the word "fork" is mentioned; it is, instead, more of an impedance matching
mechanism. ooo-build should result in a better OpenOffice.org experience
for everybody involved.
Comments (8 posted)
After last week's
discussion of cdrecord,
and concerns that recent releases of cdrecord may not be free software, we
decided to take a look and see what alternatives exist for Linux users. The
answer, unfortunately, is "not many."
While there are quite a few front-ends for recording CDs under Linux, there
are very few actual CD and DVD-burning applications available to Linux
users. Applications like K3b, MP3Roaster, BashBurn and others all use
cdrecord to burn CDs.
In all, we were only able to find three suitable candidates for users
looking to find a replacement for cdrecord. Projects that were obviously
abandoned or with no new releases in more than one year were not
For users with no interest in recording DVDs, Cdrdao is available under the GPL
and is a good alternative to cdrecord. This utility will perform
disk-at-once recording for audio and data CD-R/CD-RWs. The primary focus of
the Cdrdao project seems to be audio or mixed-mode CDs. In fact,
documentation on burning ISO images with cdrdao seems to be non-existent.
However, it is possible to burn ISOs with cdrdao with a little extra
effort. Burning CDs with cdrdao requires a description file (either a
native toc-file or a cue file from a Windows burning utility) in addition
to the actual data to be burned to CD. In the case of ISO images, users
must create the toc-file by hand to provide cdrdao with the necessary
information to burn a disk from an ISO. The cdrdao utility is also used to
make an image of a disk, and to create a toc-file to burn the image back to
Aside from the extra bit of effort required to create a toc-file, cdrdao
works well and is probably preferable to cdrecord for users who primarily
burn audio CDs. One note of caution, users should specify an appropriate
writing speed for their device. This writer neglected to specify a writing
speed the first time out of the gate, and cdrdao elected to shoot for a
rather optimistic 40x writing speed -- which produced a coaster rather than
a bootable KNOPPIX disk on the Sony DRU-530A DVD+RW/-RW, CD-RW
drive. Theoretically, this drive is rated for 40x burns with CD-R media,
but much better success has been had with lower burn rates.
drives page gives a list of drives that are known to work with cdrdao,
though it is not exhaustive. Version 1.1.9 of cdrdao was released on June 7,
OSS DVD Extensions
Though not a standalone program, the OSS DVD extensions are
worth mentioning. This project provides extensions to cdrecord for users
who would like to be able to burn DVDs as well as CDs. There is little
difference between using cdrecord and cdrecord with the OSS DVD extensions,
with the exception that the OSS DVD extensions enable DVD burning from
The OSS DVD website includes patches for several releases of cdrecord, as
well as RPMs for several versions of Fedora Core, Mandrake, Red Hat, and
SUSE Linux. The last patch for cdrtools was released in May. The OSS DVD
Extensions should work with any drive supported by cdrecord.
Another project for DVD-burning is the DVD+RW-Tools
project. Despite the name, the DVD+RW-Tools project actually supports
DVD+RW and DVD-RW drives.
This writer has been happily using DVD+RW-Tools since investing in a DVD
burner back in February. The DVD+RW-Tools project includes a utility called
growisofs, which is used to master images and burn them to disk. Growisofs
can also be used "on the fly" to burn directly to DVD without the
intermediate step of creating a image file. The project also includes a
utility called dvd+rw-format to, not surprisingly, format DVD+RW media
The DVD+RW-Tools are used only for burning DVDs. Users who want to burn CDs
and DVDs must depend on cdrecord or cdrdao for CD burning. The project
seems to be a fairly healthy one, with the latest
release being a little more than a month old at the time of this
writing. According to the DVD+RW-Tools website, any MMC-compliant drive
should be supported.
While it's not unusual for people to complain that there are too many
programs that handle a given task (e-mail clients, for example), the Linux
community could do with a choice of CD and DVD recording programs. The
existing programs are suitable enough, but users are left with a
disappointing number of options when they need to utilize CD and DVD
Comments (22 posted)
The core of the suit filed by the SCO Group against IBM is a set of
breach-of-contract allegations. SCO is saying that IBM, through its
contributions to Linux, has violated the Unix licensing contracts signed
with ATT years ago. SCO's rather broader public claims have tended to
overshadow the much more restricted nature of the actual case at hand, but
that is what the real issue is. IBM has concluded that the time has come
to put an end to those charges, however, and has filed for a partial
summary judgment which would dispose of the contract case. The supporting memorandum
available as a 100-page PDF file. Your editor, who has not had a chance to
rip into this sort of meaty legal document for a while, has been through
the whole thing; the following is a summary of what IBM is saying.
IBM goes on at great length on why it believes the judgment should be
entered. The core of the argument reads this way:
- There is very little of the original Unix code in either AIX or
- Of that code which remains, IBM has contributed none of it to Linux.
- SCO's interpretation of the license, which would give SCO rights over
any code which ever went near AIX or Dynix, is nonsensical. SCO has
no rights over IBM's code which it developed itself.
- Even if the license agreement did, somehow, give SCO those rights,
Novell has the right to waive licensing enforcements, and has done so
in this case.
- SCO, by virtue of continuing to publish the contested code itself, has
forfeited any rights it may have had to keep others from doing so.
- SCO's right to terminate IBM's AIX and Dynix license (the basis of two
of SCO's charges) does not exist, and, if it did, it would be
overridden by Novell's waiver.
As followers of the flotilla of SCO cases have been reminded many
times by now: a motion for a summary judgment must show that there are no disputed
facts at issue. For IBM to prevail here (and avoid a longer trial on these
charges), it must show that all the facts are on the table and are not
contested. The standards are high for this sort of motion; if you want to
short out a real trial and dump a set of charges against you, you must have
a truly convincing argument.
Direct copying of code
The first two points above (direct copying of code) are argued early on, in ¶7:
SCO alleges that it has found approximately 74,000 lines of UNIX
System V code in AIX and approximately 78,000 lines of UNIX System
V code in Dynix... SCO does not contend (and in any case has no
evidence) that IBM has misused any of these lines of code.
One of the best ways of establishing an "undisputed" fact, obviously, is to
use the opposite side's statements against them. IBM does not stop there,
however; the company brought in its own MIT scientist (and a high-profile
one at that: Randall Davis) to compare IBM's Linux contributions against
the SYSV code base. Mr. Davis concluded that, as one might expect, there
is no SYSV code (or even similarities to SYSV code) in IBM's work, which
is, thus, not a derived work of SYSV. The memorandum does not state
whether Mr. Davis developed a deep semantic theory to that effect,
Finally, IBM repeatedly points out that SCO was never able to provide any
examples of SYSV-derived code contributed to Linux, and that SCO is not
arguing that such a contribution has occurred:
Moreover, SCO's responses to IBM's interrogatories do not identify
any UNIX System V source code from which any of the code IBM
contributed to Linux is allegedly derived. Indeed, SCO refused to
provide such information because it "is not part of SCO's
Thus, says IBM, the lack of any direct use of SYSV-derived code in violation of the
license agreement is undisputed.
What the license says
SCO still seems to believe that it has a case, however. That case depends
on a very broad reading of the Unix license contract signed between ATT and
IBM almost 20 years ago. From ¶62:
SCO's contract claims instead rest entirely on the proposition that
"[t]he AIX work as a whole and the Dynix/ptx work as a whole are
modifications of, or are derived from [UNIX] System V". Under
SCO's theory of the case, all of the tens of millions of
lines of code ever associated with any technology found in AIX or
Dynix, even if that code does not contain any UNIX System V code,
is subject to the restrictions of the IBM and Sequent Software
SCO, in other words, claims to own anything which ever might have breathed
the same air as SYSV Unix. This interpretation has been clear for some
time, and IBM has gone to great lengths to get SCO to commit itself (in
court) to that
position. IBM now hopes to demonstrate that, beyond any possibility of
dispute, the license contracts do not give SCO the rights it thinks it has.
The first step in that process was to hold depositions with all of the
people involved in the writing and signing of those contracts. So they
tracked down all of the IBM, Sequent, and (crucially) ATT people who were
involved in the process and queried them about the intent of the license
language. Everybody involved, on both sides of the table, agreed that the
contract was never intended to give ATT (or any of its successors) power
over code which it did not
develop. There are many pages of quotes to this effect. Here is one
example, from Michael DeFazio, who ran ATT's Unix product management,
marketing, and licensing group, and who said:
The [software] agreements did not (and do not) give AT&T, USL,
Novell, or any of their successors or assigns the right to assert
ownership or control over modifications and derivative works
prepared by its licensees, except to the extent of the original
Unix System V source code included in such modifications and
derivative works.... I do not believe that our licensees would
have been willing to enter into the software agreement if they
understood Section 2.01 to grant AT&T, USL, Novell, or their
successors or assigns the right to own or control source code
developed by or for the licensee. (¶90).
Several of the ATT people involved are also quoted as stating, flat out,
that SCO's claims are wrong.
IBM notes that, under New York law (which is the law governing its
agreement with ATT), sworn statements from both parties to a contract are
the most compelling evidence with regard to the intent of the contract.
So, if there were any ambiguity in what the contract means (which, says
IBM, there is not), the testimony from the relevant IBM, Sequent, and ATT
people would be more than sufficient to straighten things out.
Not content with that, however, IBM argues this issue from several other
points. It brings up the old issue of $ echo describing ATT's
intent, and the "side letter" signed with IBM and various other licensees.
ATT also redrafted the paragraph in question at some point; the people
involved stated that the change was only to make the intent clearer, and
did not actually change the license terms. IBM states that SCO's
interpretation of the contract is simply absurd and unreasonable, and thus
not enforceable. And
finally, IBM cites federal copyright law and its provisions regarding
rights over derivative works.
IBM believes that it has shown that there is no possible interpretation of
the ATT license contract which favors SCO's position. But, says IBM, even
if that argument were to fall apart entirely, it doesn't matter: Novell has
waived any alleged breaches by IBM. The agreement between Novell and the
Santa Cruz Operation ("old SCO") is murky in several ways, but it seems
clear that Novell retained the right to shut down enforcement of Unix
license agreements at its will. Says IBM:
Novell's letters to SCO establish as a matter of law that even if
SCO had the right under the IBM and Sequent Software Agreements to
prevent IBM from disclosing its or Sequent's original code, Novell
explicitly waived that right.
If that isn't enough, IBM also claims that SCO, itself, has waived any
enforcement rights through its own distribution of Linux.
In this case, SCO's acts and conduct are plainly inconsistent with
an intention to assert a breach of contract against IBM based on
the code allegedly at issue. Both before and even after SCO sued
IBM, SCO sold to customers and made publicly available on the
Internet the code that it claims IBM improperly contributed to
Linux. Indeed, this code was still available on SCO's website as
recently as August 4, 2004. SCO cannot on the one hand market
and sell the source code IBM contributed to the Linux operating
system, and on the other hand claim that IBM was prohibited by its
licensing agreements from contributing that code to Linux.
In support of this position, IBM has dug up old SCO press releases and such
proclaiming features like journaling filesystems, SMP scalability,
asynchronous I/O, etc. As many people have pointed out over the last year,
SCO has dug itself into a deep hole with its own Linux distribution
Two of SCO's charges against IBM have to do with SCO's "termination" of
IBM's Unix licenses. This termination, says SCO, deprives IBM of the right
to distribute AIX or Dynix. It also, incidentally, is said to deprive all
users of those operating systems the right to keep running them - a risk of
proprietary code that, one assumes, most users were not expecting to have
to deal with.
IBM's motion deals with these actions almost as an afterthought. If IBM
has truly not breached the Unix agreements, then SCO's "termination" is
clearly beyond its powers. IBM states that SCO has no right to terminate
the license in this way in any case, however; quoting Novell:
Pursuant to Amendment No. X, however, Novell and SCO granted IBM
the 'irrevocable, fully paid-up, perpetual right' to exercise of of
the rights under the IBM SVRX Licenses that IBM then held. IBM
paid $10,125,000 for the rights under Amendment No. X. Novell
believes, therefor, that SCO has no right to terminate IBM's SVRX
Licenses, and that it is inappropriate, at best, for SCO to be
threatening to do so.
Even without this argument, however, Novell's waiver of enforcement rights
should be adequate to counteract this "termination."
IBM's motion for a partial summary judgment is thoroughly and
comprehensively argued; the company would appear to have covered all of the
bases. If IBM's argument holds water with the judge, the core of SCO's
case will have been demolished, and the collapse of the entire house of
cards will not be far away. This motion is an ambitious attempt to put an
end to this whole affair.
It is interesting to see which arguments do not appear in this
memorandum. In particular, there is no reference to the whole issue of who
really owns the Unix copyrights other than little digs like saying that SCO
"purports" to have acquired them. The copyright ownership issue could, by
itself, torpedo everything SCO is trying to accomplish. But the ownership
of the copyrights is very much a disputed fact, and, as such, it is not a
useful argument in support of a summary judgment.
If IBM succeeds with this motion, the SCO case is done. It would be far
too soon to conclude that this will come to pass, however. The next step
will be a response from SCO, followed by arguments in front of the judge.
SCO will do its best to drag up facts which, it will claim, remain in
dispute. We may see expert witnesses claiming that, testimony from the
principals involved notwithstanding, the ATT license agreements have a
broader meaning than IBM is claiming. SCO may try to claim that it hasn't
been able to come up with the facts because IBM has been "stalling
discovery." And so on. If SCO can create enough fog around IBM's
arguments, it might just succeed in defeating this motion and forcing the
whole thing to go to a full trial. In that case, we would have to wait
until next year for the outcome.
Comments (22 posted)
Page editor: Jonathan Corbet
Next page: Security>>