LWN.net Weekly Edition for August 19, 2004

Parallel forks

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 Sylpheed-claws, which 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 OpenOffice.org.

What does the 1.3.0 release offer?

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)

Alternatives to cdrecord

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

Cdrdao

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

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.

The supported 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, 2004.

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 DVD-R(W) drives.

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.

DVD+RW-Tools

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 before use.

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.

Conclusions

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

Comments (22 posted)

IBM's summary judgment motion

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 is 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 Dynix.

• 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:

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, however.

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:

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, 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:

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.

Waivers

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:

If that isn't enough, IBM also claims that SCO, itself, has waived any enforcement rights through its own distribution of 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 activities.

License termination

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:

Even without this argument, however, Novell's waiver of enforcement rights should be adequate to counteract this "termination."

Conclusion

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)