Leading items

The Xouvert project

[This article was contributed by Joe 'Zonker' Brockmeier]

After the much-publicized controversy earlier this year about the XFree86 Project's development process, it seemed inevitable that there would eventually be a fork of the project. Though it's not exactly a fork, an experimental branch of XFree86 is now in the works. Called "Xouvert," the project wasn't officially announced so much as outed on Slashdot.

The Xouvert project (pronounced "Zoo-vaire") is looking to allow developers to add driver support and new features to XFree86 in a modular fashion that should be easy to track and re-apply to the official XFree86 tree. One complaint raised by Keith Packard, and others, is that it has been difficult for developers outside the core team to contribute to XFree86. Xouvert project coordinator Jonathan Walther says that a main goal of the Xouvert project is to make it easier:

Xouvert is being hosted on Savannah, though it's not an official GNU project. The project is not officially connected to XFree86 either. Walther says that the only communication between the XFree86 team and the Xouvert team, thus far, was when David Dawes "asked us to capitalize XFree86 correctly" and indicate that XFree86 is a trademark. Walther says he'd like to work with the XFree86 team in the long run, however.

The project is designed so that it is both easier to contribute to, and easier to download and install. Walther mentioned that compiling XFree86 has "often been a source of frustration," so Xouvert's Cameron Berkenpas is working on a HOWTO to make it easier on users looking to compile their X server from source. Walther also says that the Xouvert lead developer, William Lahti, is working on a developer's handbook that will cover Xouvert's overall architecture and API's, though it may not be ready until the second stable release.

Right now, there's no real difference between the XFree86 codebase and Xouvert's. Users eager to see the first release of Xouvert don't have too long to wait -- the first release is slated for October 1, and stable releases are expected every six months after that. According to Walther, the first release will only contain "small additions and changes" but the second release next April should contain more comprehensive changes like the DRI/DRM and Utah-glx projects.

New projects often fizzle before they reach maturity, so it's too soon to say whether the Xouvert project will become a mainstay of the Linux and open source community. However, given the importance of a free X Server to the long-term (and short-term, for that matter) health and success of Linux, one hopes that the project will be successful.

Comments (10 posted)

No escape from SCO

Here at LWN, we start each week in the hope that we'll be able to keep SCO off the front page. Each week, the company finds some way to make that impossible. This time around, there are two separate episodes which require attention, and thus two articles to look at them.

First, we look at the interesting claim from SCO's lawyers that the GPL is not enforceable, since it is preempted by federal copyright law. This would appear to be a very difficult argument to back up, as has been established by a number of people. But a sinister agenda may yet lurk behind this goofy attack on the GPL; it bears watching.

Then, of course, there is our article on SCO's disastrous (for them) demonstration of "stolen" code. This article is responsible for the busiest day LWN's server has ever experienced. As this Weekly Edition goes to "press," this situation is still developing. SCO has not, yet, managed a response beyond the one they sent to us:

Look for the inevitable "Chris and Darl" teleconference in the near future.

It is worth noting that the inclusion of BSD-licensed code into the Linux kernel without the accompanying copyright notice is, indeed, a copyright violation. It is something that absolutely should not be done; in cases where it has happened, it needs to be fixed. We need to take greater care with the licensing of code that we use.

But this has never been SCO's point. You don't hire brand-name lawyers over a missing attribution; a simple "please restore my copyright" email will do. A missing attribution does not justify billions of dollars in damages, or even a $699 license fee. There may well have been a copyright violation when BSD-licensed code was used without attribution. But SCO has managed to undermine its own case anyway.

(For more information on SCO's Las Vegas slide show, see this article by Bruce Perens, who gained access to the full set of slides presented there).

Comments (2 posted)

Aiming at the GPL?

It is time to have a look at some statements by Mark Heise of Boies, Schiller, & Flexner - SCO's outside law firm - which were initially reported in the Wall Street Journal and extensively repeated thereafter. According to Mr. Heise, the General Public License (GPL), under which the Linux kernel (and much other code) is licensed, is invalid because it is preempted by federal copyright law. The problem, it is said, is that the GPL allows unlimited copying of the software it covers (as long as its other terms are met) while federal law only allows the creation of a single copy for backup purposes.

This is a breathtaking bit of legal reasoning. In one quick blow, Mr. Heise has blown away every free software license, every proprietary site license, and many other end user agreements that have been made over the years. We tried to discuss Mr. Heise's pathbreaking legal work with him, but he didn't feel the need to return our phone calls. So let's just have a quick look at the law he is talking about.

The relevant bit of law is section 117 of the U.S. copyright law. It reads (in part):

In other words, the "backup copy" language is an additional right granted to users of copyrighted material. Nothing in the GPL attempts to restrict this right. The biggest danger posed by Mr. Heise's argument would seem to be the potential for contempt of court findings against those who are unable to control their laughter. (See this article by Eben Moglen for a more complete demolition of the preemption argument).

Bizarre statements out of the SCO camp are nothing new. But we should not let the clownish aspect of the SCO Group take attention away from what, increasingly, appears to be part of their real agenda: an attack on the GPL. Consider the latest from CEO Darl McBride, as reported in eWeek:

The "GPL and all it stands for" has made life difficult for SCO, and they want to take it out. The GPL stands for software which is free, software which is under the control of no company - not even SCO. It stands for a world where nobody can collect large taxes for the concept of "Unix-like systems on commodity hardware." The SCO Group evidently sees such taxes as its birthright. No wonder it wants to destroy "the GPL and all it stands for."

This campaign is off to an amateurish start, but it may not stay that way. It bears watching. The GPL is strong, and so are its defenders; it is telling that, over the better part of twenty years, nobody has thought it worthwhile to challenge the GPL in court. The GPL will almost certainly prove far stronger than SCO. But every trip to court has its dangers, and the community cannot affort to be complacent with this one. If SCO follows through on its rhetoric, we have a big and important fight ahead of us.

Comments (21 posted)

Why SCO won't show the code

At SCO's annual reseller show, the company's executives put up a couple of slides as a way of demonstrating how Unix code had been "stolen" and put into Linux. The two slides were photographed and have since appeared on Heise Online; see them here and here. The escape of these slides has allowed the Linux community to do something it has been craving since the beginning of the SCO case: track down the real origins of the code that SCO claims as its own. The results, in this case, came quick and clear. They do not bode well for SCO.

The code in question is found in arch/ia64/sn/io/ate_utils.c in the 2.4 tree. It carries an SGI copyright. It seems that SGI was not entirely forthcoming in documenting the source of its source; some of the code in question was, indisputably, not written at SGI. So where does it really come from?

This code is from sys/sys/malloc.c in V7 Unix. It has been widely published; among other things, it can be found in Lion's Commentary on Unix (if you can get a copy). It was featured in this 1984 Usenet posting. And, crucially, it has been circulated with the V7 Unix source, which was released by Caldera (now the SCO Group) under the BSD license. SCO would like the world to forget about that release now, but the Wayback Machine remembers.

So...SCO's code demonstration, the one that it put up to convince its resellers of its case, comes from a version of Unix which first came out in 1979. The code was publicly circulated in the 1980's, and explicitly released under the BSD license by [the company now known as] SCO at the beginning of 2002. SCO might well have a complaint that SGI did not properly give credit for the code it used. But there is no possible way the company can argue that this code's presence in Linux is an infringement of its copyrights.

And this, of course, is why SCO refuses to show the code that, it claims, is copied. These claims do not stand up to even a few hours' scrutiny on the net. SCO may yet have an interesting contract dispute with IBM, but, from what we have seen so far, its claims of direct copying of code are hollow.

(Many thanks to those who commented on an earlier LWN posting on this subject - those comments are the source for just about everything that appears in this article. Many thanks are due to LWN's readers; you have shown the best of what the community can do. Update: see also: this analysis of SCO's code by Bruce Perens.)

Comments (71 posted)