I hate to say it, but I can't help feeling that SCO is behaving rather like a belligerent child who has had its lollipop stolen. You could say that SCO is doing nothing more than protecting its intellectual property, and doing that in the most obvious way: by calling in the lawyers. Well, it's the lawyers who tend to lend that belligerent quality to any argument. It always ends in tears, and there's never, really, a good excuse.
In the meantime, a lot of companies who have bought SCO Linux from none other than the new SCO Group in the understandable belief that they were buying a legitimate operating system over the counter are getting worried, as are companies who bought Linux from IBM, Red Hat and others. We understand that SuSE customers are safe, but in an interview last year, SCO's then-incoming chief executive Darl McBride indicated to me that the company's intellectual property (from the Unix code base) was likely to be many more places. You can bet that right now over at HP teams of lawyers and engineers are scouring the source code of HP UX and Tru64 to check for liabilities, while up at IBM the same will be going on with AIX and Dynix. Even Sun and Apple are likely to be asking themselves -- even if only for a sanity check -- "Are we safe?" Indeed, is anybody?
There is a simple -- and naive -- solution to all this. SCO could do the grown-up thing and say, hey, we've got UnixWare and OpenServer, and people are still buying them (which they are), and if other people can make money from Linux then maybe we can too, after all (which they haven't been). I suspect that Doug Michels, who founded the original SCO and is now chief executive of that part that was not sold off to Caldera, might have taken that attitude. Michels has always been one of those people known for his love of Unix. Lawyers, on the other hand, have not -- unless it involves lawsuits and money.
So what's going on at SCO? Well, SCO's lollipop was something called Project Monterey, and the big bully who snatched it was IBM -- now the focus of SCO's $1bn lawsuit. Project Monterey was around at the time of Doug Michels' SCO; the old SCO. The new SCO Group, headed by Darl McBride, is a different animal altogether, and was created when Caldera bought the operating systems and professional services division of the old SCO. That is, the Linux company bought two Unix operating systems: UnixWare and OpenServer.
The two SCOs are separated by four years, the coming of age of Linux, and the theft of one giant lollipop.
That lollipop, Project Monterey, was all the rage among the marketing departments in the old SCO, in IBM and in Sequent (before it was bought by IBM) just four years ago as they began repositioning their Unix offerings to reflect their convergence on the single version of 64-bit Unix.
Project Monterey, we were told, would provide full compatibility with SCO's UnixWare products, and at the same time IBM was to release DB2 for the platform. SCO would also supplement its UnixWare 7 products with initial AIX libraries and headers for application support, as well as AIX system management enhancements.
Applications that were currently running on UnixWare on IA-32 platforms would be binary and source-compatible on IA-64-based systems, said the companies, and should compile with minimal rewrites for the IA-64 version of Monterey, which would be more heavily based on IBM's AIX operating system.
SCO and Sequent were both very important companies to IBM back then. Sequent for its big 64-way Intel servers and the associated technology, which IBM had it eye on as Intel continued to make inroads into traditional RISC strongholds, and SCO for its developer base, which IBM needed to help bolster AIX in advance of 64-bit Windows.
That was 1999. Skip forward just one year, to September 2000, and the tech world was a very different place. The old SCO, headed by Michaels, announced that its server and professional services divisions would be sold to Linux distributor Caldera, but something much more significant had happened: Linux had 'arrived'.
Whether the first move spooked IBM is doubtful -- IBM already had a partnership with Caldera to develop a common 'personality' across Linux and Unix operating systems. But it was the coming of age of Linux, which manifested itself in the support of Linux by all the big (one notable exception aside) application vendors, together with what IBM interpreted at the time as a mass desertion of developers from Unix (and UnixWare in particular) to Linux. In addition to that, it seemed that barely a single graduate from a single computing course in any university you cared to look at was even allowed out of the doors until they had done their bit on the Linux kernel.
IBM's response was to drop plans to offer binary compatibility for applications across UnixWare and future versions of IBM's 64-bit AIX operating system. IBM executives could barely be brought to acknowledge that any such entity as Project Monterey had ever existed. At the time, the best I could get out of IBM's director of Unix strategy Deepak Advanti was that where IBM would have talked about UnixWare in 1999, by mid-2000 it would talk about Linux.
IBM's strategy had switched dramatically. The company's Unix strategy now had three key elements -- none of which included UnixWare. It was to push AIX as an open enterprise-class strategic operating system, push Linux as the pervasive high volume operating system, and create a common application programming interface across Linux and AIX. The result was that work such as that to transfer AIX technology such as the IP stack into UnixWare stumbled.
Publicly, SCO/Caldera put on a brave face, saying that the decision to abandon binary compatibility was sound because companies moving to 64-bit computing would want to run applications natively, because they would run faster and be more reliable.
And at IBM, the public message was that AIX 5L (the L stood for Linux) was the finished Project Monterey. Everybody who had been eagerly awaiting the Project Monterey operating systems accused IBM of rewriting history. Unix users flooded online forums to discuss the controversy. Many said they were unhappy over IBM's apparent attempt to whitewash the fact that Project Monterey had changed course. Some likened the debacle to OS/2, a project on which IBM never officially pulled the plug, but which was simply left to wither in solitude, with no major upgrades.
But in pulling the rug out from under UnixWare, it seems that IBM had not bargained for the fact that SCO/Caldera could be just as calculated.
When the new SCO Group was created by Caldera's purchase of the old SCO's operating system division, it was bankrolled by an investment firm called the Canopy Group to the tune of $18m. The Canopy Group is controlled by Ray Noorda, who used to be Novell chief executive in the days before Novell sold UnixWare to SCO. Indeed, SCO/Caldera's relationship with UnixWare goes way back beyond 2000; Caldera co-founders Ransom Love (who last year stood aside for new chief executive Darl McBride at SCO) and Bryan Sparks also used to work at Novell when it still owned UnixWare. So there are plenty of people at the new SCO who have good reason to smart over the treatment of UnixWare.
And now, it seems, SCO is looking for payback.
So is SCO's decision to send in the lawyers a valid and sensible business decision to realise previously undeveloped (from SCO's point of view) assets a slightly bitter retribution to settle old scores and defend the honour of UnixWare, or a petulant reprisal at the playground bully?
Judging from the postings that have appeared online recently, it would appear that SCO has about the same grasp of reality as did the infamous Iraqi information minister, Mohammed Saeed al-Sahaf, in the closing days of the war in Iraq. Indeed, pity SCO's PR boss who has to explain why that code distributed by SCO under the GPL licence contained code that SCO has the rights to, and they'd like it back now, please. It really is hard to see this as anything other than a playground spat. While the lawyers go fight it out, the rest of us should carry on as usual, buying, using and developing Linux.