Open Source license spats are often dismissed as hobbyist arcana, but this week's flap over a seemingly minor license change shows why enterprise users should do their homework. Intel buckles on x86-64 and announces Linux will lead the compiler pack. The SCO lawsuit clock ticks into overtime. We point to a collection of Linux distributions for everything from firewalls to wireless access points.

When we're not rounding up enterprise Unix news, we watch TV. Lately, we've come to admire the great TV enabler: TiVo.

Aside from its obvious virtues, TiVo is something of a design win for embedded Linux, and that's why we found a copy of the GNU Public License (GPL) printed in the back of our TiVo manual. The GPL requires enterprises distributing software under its jurisdiction (such as the Linux kernel), let users know they're entitled to see the changes made to the source code. In this case, you could write TiVo Inc. and ask for a CD of the source code used for some of the software that runs its machines. The company would be obligated to hook you up. This may seem a rather pointless requirement for something as non-fiddly as a TiVo (we're not even sure how or why we made it that far in the manual), but it's part of the world of open source/free software licenses.

We've looked into the question of these licenses before, and we're all for them. They work. People like to pick at whether there's a business model to be built around selling software under these licenses, but that's not a technical question; it's inside baseball for the day traders. We think the fact IBM, HP, Sun, Dell, and others sell Linux boxes is proof enough that free software works despite its license.

That said, it isn't always hummingbirds and flowers in the land of free software. Consider this week's flap
about XFree86: XFree86 is the software on which GUIs are run in much of the Linux and BSD world. Multiple Linux distributors (including Red Hat, Mandrake, Debian, and Gentoo) and even OpenBSD are dropping the latest version of the software (XFree86 4.4) like a hot potato because the license under which it has been released makes it incompatible with the GPL and thus problematic for most Linux distributions. It also seems to be creating issues with the BSD license.

At the root of the controversy is a change to the requirements about how and where credit for XFree86 must be given. The changes are seemingly trivial. However, they create an issue with any GPL-licensed software that builds against XFree86 libraries (xlib) and place an onerous burden on Linux distributors to ensure credit is given that is up to the license's standards. The changes, as one contributor to LinuxToday accurately noted, are called "advertising clauses," and they make the software less than completely free to reuse.

"It seems like every 8 years or so we have to go through some period where someone tries to take free software and makes it less free because they don't feel they are getting enough credit," said OpenBSD's ever outspoken Theo de Raadt, noting that if the group that works on XFree86 doesn't roll back to an older, less restrictive license, there will likely be a fork of the project.

For now, the net effect is that many Linux distributors and OpenBSD will not be including the latest and greatest XFree86 release in their products. They'll stick with XFree86 version 4.3 while they come to grips with the formidable challenges challenges that including another X Window implementation could pose. For most organizations, that decision might represent a nuisance (since hardware support in the new version will not be present in older versions) but nothing earth-shattering.

From an enterprise user's perspective, however, we think the following is worth keeping in mind.

Conventional wisdom about open source software holds that, in general, users don't (or shouldn't) care about how their software is licensed. This story is a good indication of why, perhaps, they should, even if the tendency among many is to dismiss open source licensing debates as obsession over minutiae. The license under which XFree software developed has been an area of concern in the past because it has always skirted close to the line of acceptability in comparison to the relative freedom of other open source packages. It's doubtful any enterprises will have to rethink a big Linux deployment because of this particular snafu, but it makes a case for ensuring due dilligence is performed where mission-critical open source apps are concerned.

We recommend IT managers using or considering Linux or other open source/free software (such as Apache, BIND, MySQL, and PHP) in their organizations be more than a little conversant in what these licenses mean. Borderline cases, such as XFree86's, could have an impact on the "out of the box" software users can expect from their Linux distributor. That doesn't mean binaries can't be built if a new feature is needed, but it does mean the distributor might not be able or willing to support the version if licensing incompatibilities end up requiring the distributor to stick with an older version, or an altogether different but equivalent piece of software.

In Other News

Intel said it, so it is indeed true: Customers want x86-64 chips, and the company's set the end of the 2004 as a target for adding 64-bit extensions to its Xeon processors. That's noteworthy to gear-heads and chip market watchers because it marks an instance of Intel being forced onto reactive footing by AMD, which is already plenty cozy with vendors.

This is noteworthy to Unix developers because it looks like several Linux distributions (Red Hat, SUSE, and embedded play MonteVista among them) will be getting compilers for the new chips first. The Windows version isn't expected until fall.

For HP, this news might be not so much noteworthy as alarming since, as an IDC analyst told our colleagues at internetnews.com, "If I'm HP, I would be worried. HP-UX and OpenView can only run on Itanium."

Internetnews.com this week ran an article exploring which Linux distribution is growing the fastest (Enterprise Unix Roundup tackled this a few weeks ago). Their conclusion? In the U.S. enterprise market, it's down to SUSE vs. Red Hat. Mandrake is holding out for growth in the enterprise desktop market this year (with plans to release a product for that niche soon), and TurboLinux is still holding on to turf in China and Japan, where it's been a strong contender for years.

Our apologies for missing this one earlier: SCO has released OpenServer 5.0.7 Update Pack 2. The update includes support for USB 2.0, updates to the printing system, and PostgresSQL.

At press time, it's "lawsuit day." SCO is expected to announce which major corporate Linux user it's taking to court over refusal to purchase a SCO Linux license.

Security Roundup

A bug in the Linux kernel, currently unexploited, could allow a local user to gain root privileges. Current Linux distributors with reported patches are Red Hat, Debian, Trustix, and Slackware. Others will be sure to follow.

A similarly widespread flaw has been found in XFree86. Buffer overflows in the GUI's font file parsing could allow local users to gain root privileges. Patches are in place from TurboLinux, Mandrake, Red Hat, Immunix, Slackware, and Gentoo.

Tips of the Trade

Sometimes, when we think about things we'll be pressed to defend to our children, the fundamentals of the floppy drive discourse stands out as a discussion that will begin, "Well, it was complicated."

How does one justify a medium that, in the waning years of its ubiquity, has an apparent failure rate of more than one in 10? Keeping files on a floppy is a really bad idea in an age of dirt-cheap writeable CDs, and we'll admit that our memory of floppies ever being very trustworthy is fading, although we do remember entrusting everything to them once upon a time.

Long after the average user had learned to forsake the sneakernet and "just store it on the network drive," admins and techies had their own uses for floppies: They made great rescue tools. It was always a fairly simple matter to stuff DOS or a tiny Linux distribution on a 1.44 MB floppy or two and boot up a system that had developed the inability to boot on its own. The average rescue disk couldn't do much, and it usually had to leverage whatever was available on the rescued system for very sophisticated work. Even we still have a few of these floating around in a shoebox somewhere.

Now, in the age of the cheap CD, we were reminded of that when we recently ran across a list of Linux-based "live" CDs: CD images that provide not just a stripped-down Linux distro for limited system recovery, but complete Linux distributions. Some of them allow a user to store custom configurations on a small USB keychain drive, making it possible to carry around a complete Linux install that can be loaded and used on any machine capable of booting from a CD, and "remembers" the user's preferences from machine to machine.

For Unix admins, the benefit of these distributions is clear: Linux provides a great set of tools for conducting all sorts of rescue operations, and it's conversant in dozens of filesystems. With 650 MB of storage space, a Linux rescue CD is able to provide a formidable array of tools to bring to bear on all sorts of ailing systems. One drawback for enterprises with Windows systems is that Linux support for Microsoft's NTFS is still effectively read-only, making it pretty hard to change things on a Windows system in the process of being rescued.

The Live CD list is pretty lengthy. If you're just looking for a rescue CD, they're labeled as such and generally come in smaller sizes (well under 100 MB). Besides basic rescue operations, some of the CDs can serve as a "firewall in a box," and there's one that provides for an instant Wi-Fi hotspot (which we've done in a pinch with an aging but functional laptop).