Intellectual property battles will wound Linux

As the battle escalates with SCO upping the ante -- seeking more than $3bn (£1.78bn) in damages for alleged copying of proprietary Unix intellectual property into Linux -- deep throats in the IX biz (Unix, Linux) are talking and, as reported earlier, the word on the street is that several organisations -- including IBM, Red Hat, Novell and the Open Source Initiative -- are preparing a vigorous defence against SCO's patent infringement claims.

Although I first considered Gartner's "limit Linux use" response to the suit to be an over-reaction, I'm beginning to reconsider -- but not for Gartner's reasons. The final merits of SCO's case may not be what pose the greatest risk to Linux. The problem, insiders worry, will be time.

For a fleeting moment, the destinies of IBM AIX, SCO OpenServer, and Caldera UnixWare (the latter two of which were Caldera products after that company acquired SCO's server software and professional services divisions) were intermingled under the auspices of an IBM-Caldera/SCO collaboration code-named Project Monterey. Going back to a story that was originally reported on ZDNet in 2000, Monterey's destiny was to be the assumption of UnixWare's /proc file system and System V printing system by an IA-64-compatible version of AIX. Had the project reached fruition, the final product would have retained the AIX name. An SCO employee at the time said, "From what I can tell, we exchanged several person-decades for the privilege of being an AIX VAR."

As it turns out, the basis of the patent infringement suit, and SCO's choice of target had nothing to do with IBM's deep pockets. Whereas a 64-bit version of Unix (an Intel-compatible one at that) may have been the focus of Project Monterey, the 32- and 64-bit versions of Linux will be front and centre in the patent infringement suit.

Whether or not the suit has to do with the aforementioned file and printing systems or something else from the person-decades of work that was "exchanged," SCO will be arguing in court that its intellectual property (IP) was surreptitiously and perhaps maliciously leaked into the currently distributed Linux kernels (including the 32-bit one that's in wide distribution). SCO picked on IBM because it thinks IBM, which had access to that IP during Project Monterey, was the culprit that did the leaking.

SCO's message to Linux customers was a warning shot across the bow to everyone that may have inherited that IP (from Linux distribution providers to customers) that they may be at risk. Now you know why Red Hat, Novell, the OSI, and others have their hackles raised.

The malicious aspect might be traced back to some sour grapes over Monterey's demise. The original aspirations of Project Monterey's backers were to gang up on Sun with a credible 64-bit offering. Emboldened by IBM as a partner and with a common enemy (Sun), SCO might have been on the verge of a rebirth. But reminiscent of the way Microsoft jilted IBM over OS/2, IBM saw greener pastures in the Linux world and left SCO standing at the altar, ready to falter. In a weird twist of fate, this decision could end up benefiting Sun, depending on how the case is resolved.

To beat back the SCO lawsuit, IBM and the others rising to the defence of the Linux kernel will have to prove that SCO doesn't have any intellectual property claims to the kernel. Many, including the Open Source Initiative's Eric Raymond, have suggested that SCO's claims are a farce. There's tough talk in public, but under the covers, some are nervously double checking that all their i's are dotted and t's crossed.

For example, Sun has already issued a couple of public statements. CEO Scott McNealy said "Sun probably will not be affected because the company signed a comprehensive licence for Unix years ago"

Jonathan Schwartz, executive vice president of software for Sun, said the company would indemnify any of its customers running Solaris and Linux for liability to SCO. But whereas company executives may be confident that Sun is in the clear, sources close to the situation told me that Sun lawyers paid a visit to SCO just to make sure.

Such caution is not surprising, given SCO chief executive Darl McBride's position. In a recent interview with News.com, he suggested that the entire food chain could be liable. "We can sit there and talk to IBM all day long, but if in fact users are running systems that have basically pirated software inside, or stolen software inside of their systems, they have liability. We're not saying that they created that liability; we think there are a number of parties along the way that generated that. But we feel like we have an absolute requirement to let them know what was going on as we went down this path."

Sun certainly falls into McBride's "along the way" part. One reason Sun might be in the clear, or at least not as high up in the food chain as others, is that the Linux distribution that ships with Sun's Intel-based systems is Red Hat's. This could force Red Hat to shoulder all burden of licensing responsibility even though Sun distributes those systems.

According to Schwartz, "We have all the rights to SCO we could possibly need. We bought them out 10 years ago; that's why we can indemnify customers running Solaris (or any other distribution of a Sun product). The only Linux we're shipping comes from Red Hat, and they, as far as I know, do not have the rights SCO claims they need. [Red Hat] has liability because they are exposed without a license. We, as a supplier, don't have that liability. Our customers do and Red Hat does, but by virtue of the expansiveness of our original license, we have rights that protect us (but not suppliers) from the fruit of the poisonous tree." Referring to the code that was "leaked" into the Linux kernel, Schwartz said, "IBM has liability independent of who delivers the product or who delivered IBM code into Linux."

Even so, Sun's lawyers no doubt saw the warning that SCO issued to Linux users and realised that if users downstream were receiving notice, then Sun wasn't necessarily safe. For Schwartz to indemnify its Solaris and Linux customers from liability to SCO, you can bet the lawyers double checked with SCO.

In the News.com interview, McBride said, "We have this intellectual property that we've started approaching vendors about. IBM is one we approached; Microsoft was another. We had about four big vendors in the last quarter that we talked with. With two of them, we signed deals." In mentioning Microsoft, McBride was referring to a move that some industry watchers have dismissed as little more than Linux subterfuge. Microsoft re-upped its Unix licence.

But suppose it's not subterfuge? Suppose it's just Microsoft's attorneys trying to keep the company's nose clean. The defense may not be the slam dunk many were hoping for. While it may ultimately prevail, that lack of a slam dunk could present another problem. Some who were counting on a royalty-free Linux kernel are now concerned about time. According to one source close to the legal discussions, "Unless a judge dismisses the case as being completely meritless, or a guardian angel like IBM comes along, acquires SCO, and drops the case in the early stages, I'm afraid that this could drag on for a minimum of three years and probably longer."

Given how competitive this industry is and how quickly things change, most companies can't afford to place bets on a technology whose future is uncertain. McBride acknowledged this when he said, "There's a big concern that if you just drag this out in a typical litigation path, where it takes years and years to settle anything, and in the meantime you have all this uncertainty clouding over the market, it's not a positive." In that light, Gartner's recommendation to limit Linux use may not be so conservative after all.

The next question is, "If not Linux, then what?" Conspiracy theorists argue that Microsoft's endorsement of SCO's claims is a clever way to nudge those that were considering the maligned Linux as an alternative platform. Obviously, Microsoft's preference would be for those users to pick Windows. But, the most natural option will most likely be situational.

For those committed to Linux, either because they're running it already or are too far down the path to turn back, the best option is likely the one that offers the least painful transition. Regardless of the reasons for originally committing to Linux -- such as comfort level, applications, or cost of the operating system or of Intel architecture-based systems -- one of the better alternatives (according to those I've spoken to) could end up being FreeBSD. Going from Linux to FreeBSD would indeed be a no-brainer for most. But, in the same way that many have accused Microsoft of subterfuge, Sun is the other company that is at peace with SCO and that also has a version of Unix that runs on Intel architecture. If users are looking for a commercial Intel-based version of Unix with a high degree of compatibility with Linux and the backing of one of the industry's top Unix providers, Sun is an obvious choice -- not to mention SCO itself. When Sun's Schwartz tells me that "Solaris, especially on Intel, is going to be such a hit when we start migrating HP/UX and AIX customers," he is clearly predicting a rosy future for Solaris on Intel. Any shadow cast across Linux will play quite well into Sun's hand.

For those not already committed to Linux, Windows is indeed the other commercial choice for the Intel platform. Suggesting that subterfuge was never an issue, McBride said, "We did a straight-up licensing deal around the intellectual property we had as well as the source code to allow them to tie in their Unix-related products."

The one company that's been surprisingly mum about the entire situation is Intel. But maybe I shouldn't be surprised. To Intel, it really doesn't matter how this turns out. Regardless of whether users go to FreeBSD, Intel-based Solaris, Windows, Intel-based HP-UX, or one of SCO's Unix-based products, it's all goodness for Intel. Could there be some defections to non-Intel systems such as AIX or Mac OS X or Solaris on Sparc? Sure. Is it enough for Intel to be concerned? Probably not.