LWN.net Weekly Edition for April 17, 2003

Will the real Firebird please stand up?

One of the many changes called for in the new Mozilla roadmap was a new emphasis on the Phoenix browser - and a new name. The Phoenix name, it seems, has a number of trademark problems. So the Mozilla project, after some thought, came up with a new name for its to-be flagship browser: Firebird.

There's only one problem: the Firebird relational database project has been using that name since 2000. This project is working on a fork of the InterBase code; it just announced the availability of the first Firebird 1.5 release candidate. The Firebird developers are, needless to say, less than impressed with Phoenix's new name.

The response from the Mozilla project, to the extent that there has been one, seems to be that the two projects exist in different spaces, so there is no naming conflict. The fact that "Firebird" is the name of an automobile made by Pontiac is not a concern; a relational database with that name is no more of a problem. Mozilla and its corporate sponsor may have a defensible argument with regard to trademark law, but this is clearly not a good way to treat other members of the free software community. The Firebird name is not yet established - in the browser domain, anyway. The Mozilla project should pick a new one now, when it is still easy.

Comments (14 posted)

A new SCO distribution

SCO has sent out a press release on a new version of SCO Linux Server 4.0. It is a fairly mundane offering; SCO, too, wants to sell high-priced "enterprise" version of its distribution; the version just released starts at $999 and runs on the Itanium architecture. It is only "licensed" for up to four processors, however; bigger machines will cost more.

If you go to the product page on SCO's site, though, you see some interesting things. They advertise all sorts of "next-generation enterprise features" including logical volume management, asynchronous I/O, the O(1) scheduler, journaling filesystems (including JFS), PCI hotplugging, high availability features, etc. All the sort of stuff that an aspiring business distribution with a (probably) Red Hat-derived kernel should have.

The only problem, of course, is that these are all features that, according to SCO's suit against IBM, could not exist in Linux unless SCO's proprietary technology had been stolen and put there illegally. SCO is even advertising features (JFS, EVMS) that were directly developed and contributed by IBM; JFS was even listed explicitly in the company's complaint. This is all stuff that, according to SCO, is destroying SCO's Unix business and depriving the company of a billion dollars (minimum) worth of intellectual property.

The proprietary technology that, according to SCO, was misappropriated is certainly contained in this new distribution. And SCO is shipping it with source, licensed under the GPL. Before filing suit, SCO might have been able to claim that they didn't know that "their" property was contained within their Linux distribution. But they have no "plausable deniability" now. SCO is, itself, shipping the code that, it claims, is destroying its business. The company is trying to have it both ways, selling Linux while claiming that the product is tainted. It would be interesting to hear how SCO justifies this position. Unfortunately, SCO did not respond to questions sent by LWN, so we can't tell you.

Comments (7 posted)

What's happening with SPI?

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

What is Software in the Public Interest (SPI) up to these days, and does anybody care? If you're newish to the Linux Community, it wouldn't be surprising if you hadn't heard of SPI, though SPI and the Open Source Initiative (OSI) were big news back in 1998 when they were squabbling over the Open Source trademark.

SPI is a non-profit organization that acts as a kind of umbrella organization for Free Software projects like Debian, the Linux Standard Base and GNOME. SPI is a non-profit organization, and it accepts donations for the projects and holds the trademarks for supported projects that have them. SPI has two classes of membership, non-contributing and contributing. The only requirement for a non-contributing membership is a valid e-mail address, but it does not confer voting rights. Contributing membership is reserved for "people who are actively contributing to the free software community."

Recently SPI added three new members to its board of directors, Bruce Perens, John Goerzen, and Benjamin Mako Hill. Perens, who originally helped found SPI, left the organization in 1998 to work with the OSI and was part of the big dust up over the Open Source trademark. SPI board members are elected by contributing members of SPI.

Prior to the recent election, Perens said that the group was having problems making a quorum at board meetings. In fact, V.P. Martin Schulze resigned his position as V.P. because several other members were not donating enough time to their positions. Ean Schuessler is now V.P., and the position of president is still vacant after Nils Lohner stepped down last December.

Recently, there had also been some concerns about allocation of funds by SPI, but the new board passed a resolution to clarify how donations would be earmarked. SPI will also no longer be taking a five percent cut of donations for overhead, because it was not clear that part of a donation for a specific project, like Debian, would be going towards SPI.

For the most part, SPI's functions are pretty low-key. Perens says that SPI's function is basically to "handle funds well" for its organizations. According to Schulze, one of the things that SPI is currently working on is counting votes for the Open and Free Technology Community election, and working against "reasonable and non-discriminatory" patent policies in several standards organizations.

Perens says that board is now making quorum at meetings and that things should go more smoothly in the future. "Can't say there's a ton of news. There used to be problems, but they're not problems anymore."

Comments (3 posted)

An installation nightmare story

The installation nightmare story was a fairly common feature of the late-90's press. Some reporter who had never tried to install any sort of operating system before would write about his or her horrifying week trying to get Linux running on some system or other. The conclusion, invariably, was that Linux wasn't ready for the masses.

You don't often see that sort of story anymore; the mainstream distributions have become ridiculously easy to install. And, if you don't want to worry about installation, plenty of companies will happily sell you a system with Linux already on it. But that doesn't mean that all the problems have now been solved...

Your editor recently needed to replace a failing inkjet printer. Some time spent wandering the detailed information at LinuxPrinting.org turned up a reasonably inexpensive model which, according to the information there, "works perfectly." That is music to a Linux user's ears, of course. So, a quick trip and some minor credit card damage later, the printer sat on the table, ready to start burning through expensive ink cartridges.

I'll not inflict upon you the details of what it took to make this printer work on an almost-current Red Hat Linux system. In general terms, it required building new versions of CUPS and gimp-print from source, editing the PPD file by hand, and several other hacks. It took a couple days of effort. Now, your editor has been making printers work on Unix (and other) systems for a good twenty years. Printers have always been a pain. But this was worse than many.

It should be pointed out that, in a lot of ways, things are better than they have ever been. It is possible to put an inexpensive printer onto a Linux box, get top-quality output in all of the modes that the printer supports, and make it available over the network. Only a few years ago, doing this required hacking on filter scripts and learning more about strange ghostscript options than one would ever want to know. Now, most of the hard work has been done; it's mostly a matter of getting the right software running in the right place. The people working on Linux printing have done an impressive amount of great work.

But it's not yet enough. Users should not have to rip out their print system by the roots and rebuild it from source just to plug in an off-the-shelf printer. They should not have to navigate a complex array of software with names like foomatic, gimp-print, ghostscript, etc. and figure out how it all goes together. They should not even have to upgrade to a bleeding-edge distribution to make their printer work.

Windows users don't have to go through that sort of process. Of course, they have the advantage that their new printer comes with a CD containing the software needed to make that printer work. Linux users do not (yet!) receive any such courtesy. So we have to come up with a different way.

Some of the work has been done. The PPD files used by modern free printing systems contain much of the information needed to present an interface to the user. What's missing is a description of how to drive the printer. We need a means of describing printers in data, so that support for any printer is just a text file away. This was done for terminals a good twenty years ago; getting vi to work on a terminal was just a matter of setting an environment variable. Printers are harder to describe than ASCII terminals, but we've solved a lot of hard problems over the years.

Imagine a world where any Linux user can go to the store and buy a nice looking printer, along with plenty of spare flesh-tone, DMCA-protected ink cartridges. The system, once it notices that a new printer has been plugged in, goes out on the net and grabs the right description files. And the printer just works. That would be a system that is ready for desktop and home users. And it's something that we should be able to achieve.

Comments (13 posted)