When I first heard this past January that Red Hat was about to make a significant announcement with respect to the SCO Group's lawsuits over Linux, I thought for sure the company was going to fall in place with the others who were offering some form of indemnification to their customers. After all, indemnification seems like such an obvious service to offer. Surely, SCO's threat to sue enterprise users of Linux would rattle those users (many of whom are Red Hat customers), and the major distributors of Linux would respond with indemnification programs to keep customers from cutting bait.

As I read about the announcement, two issues came to mind. First, whether Red Hat would have any choice but to replace the code should it be found to be guilty of copyright infringement (sort of like humans having little choice but to breathe). Second, I wondered whether, by falling short of offering indemnification, if Red Hat was worried. Indemnification could end up being a costly proposition, but replacing code isn't as potentially costly. If Red Hat wasn't willing to put its money where it's mouth was, then maybe the rest of the Linux community should be reading something into that.

In terms of what other choice Red Hat might have besides replacing code, this turned out to be a little more complicated that I realized. I learned that someone who was found guilty of copyright infringement had three choices. First, replace the infringing code and maybe pay some damages to the copyright holder for the period of time it benefited from the free use of that copyright. Second, work out a settlement with the copyright holder that allowed the code to remain, but that guaranteed the copyright holder a licensing fee. Third, go out of business. In looking at Red Hat, whose Linux-oriented story is all about reducing the total cost of ownership of information technologies, the first choice (replace the infringing code) seems like the best choice. After all, if it ends up paying for a license to SCO, it will have to pass that cost along to its customers and that will drive the cost of Linux up and then, one of Linux's value propositions is greatly diminished unless the license fee is nominal. On first, blush, for obvious reasons, the third choice doesn't appear to be an option.

But, I may have guessed wrong. Red Hat may say that it's willing to replace infringing code, but based on my understanding of the case, if the code is found to be infringing, that will mean that SCO was given the green light to continue its pursuit of an infringement case. The implication of that scenario is that the issues of ownership may have been worked out, perhaps in entirety, to SCO's favor.

If that's the case, and any part of Linux is found to have been derived out of anything but a clean-room development process (whereby all of its developers had no exposure or influence from Unix or one of its derivatives), just about all Linux distributions, including Red Hat's, could be subject to the whims of SCO. I said "could be" because a judge would still have to agree with SCO's interpretation of AT&T's original intellectual property rights (IPR) language when it comes to the licensing of derivative works.

I'm not saying this is what is going to transpire. What I am saying is, should Red Hat be found to have infringed on SCO's IPR, it's possible that a promise to replace infringing code is not a promise that will satisfy SCO. In other words, since replacing infringing code may not be enough to satisfy SCO, it probably may not be enough to satisfy Red Hat's customers. At the very least, Red Hat could be asked to pay damages and enter into a licensing agreement with SCO if it wants to continue selling Linux. Additionally, Linux at that point might no longer be available from Red Hat or other distributors under the GNU General Public License as it is today.

If the idea of Linux not being available under the GPL sounds preposterous, then one need only read Red Hat's January 6, 2004 10-Q filing with the SEC. The document indicates that a ruling in SCO's favor is at the very least possible and goes on to describe the potential consequences should that possibility become a reality. According to the filing, "Any ruling by a court that these licenses [GPL-based licenses] are not enforceable, or that Linux-based operating systems, or significant portions of them, may not be liberally copied, modified or distributed, would have the effect of preventing us from selling or developing our products." The 10-Q goes on to say, "Claims of infringement could require us to seek to obtain licenses from third parties in order to continue offering our products, reengineer our products, or discontinue the sale of our products in the event reengineering could not be accomplished on a timely basis."

Here's my interpretation. Provided that a court upholds SCO's infringement claims as well as SCO's interpretation of what constitutes an illegitimately derived derivative of Unix, the worst possible case scenario is that in order for an distributor to continue distributing Linux, it would either have to license the technology from SCO, or come up with a 100 percent clean-room developed version of the kernel. This gives some context to the 10-Q's stated possibility that such reengineering might not be possible on a timely basis.

Commercially viable operating system kernels, as it turns out, are not that easy to develop. If they were, then many more of them would exist. After three to four decades of kernels coming and going, one can probably count the number of commercial successes with less than 10 fingers. Thus, Red Hat's revelation that one its options, should reengineering not be possible on a timely basis, is discontinuing the sale of its products. Red Hat would be completely devastated in the event that this happened.

It's fair to mention at this point that, by law, public companies are required to disclose, to the best of their knowledge, any risks that present a material threat to their business. Given the extent to which Red Hat relies on the ongoing availability of Linux under the GPL to conduct its business, it had no other choice but to clearly articulate any and all possible risks and their potential consequences to the business.

With respect to SCO's case, Red Hat is in a very interesting and unique position. It is the only public company that I know of that relies almost entirely on the ability to distribute Linux under the GPL. To that extent, I liken it to being the canary in SCO's coal mine. If suffering is ahead, Red Hat will be the first to show symptoms of that distress. Nevertheless, in no way should Red Hat's disclosure of this possibility be treated as an indicator of its likelihood. It's just one of several risks that could materially affect its business.

Whereas the simple disclosure of this risk doesn't shed light on its likelihood, Sun Microsystems Executive Vice President of Software, Jonathan Schwartz, who originally suggested that I take at look at Red Hat's 10-Qs, believes that the evolution of the text that addresses the SCO situation over a series of 10-Q's is worth considering.

In other words, whereas the 10-Q filed to the SEC by Red Hat on June 27, 2003 (well after SCO's legal activities began) makes absolutely no mention of the risk presented to Red Hat's business by virtue of SCO's claims, the subsequent 10-Q on Oct 15, 2003 discusses Red Hat's efforts to seek "a declaratory judgment that the Company is not infringing any of SCO's intellectual property rights" and SCO's opposition to that motion. The 10-Q goes on to say, "At this early stage of the proceedings no assurance can be given as to the outcome." Oddly, even though Red Hat obviously realized that SCO's actions posed a threat to Red Hat's business (by virtue of the pre-emptive strike it filed suit against SCO in August 2003), it's October 2003 10-Q doesn't reflect on the material threat at all in terms of the risks or consequences. It wasn't until almost a year after the risk originally surfaced and arguably posed a threat to Red Hat's business, that the company suddenly acknowledged the risk and the potential consequences in the recent January filing. To Schwartz, and admittedly to me, the canary is beginning to show signs that something could be amiss.

While it cannot be said for sure whether the ongoing evolution of the text in Red Hat's SEC filings that addresses the SCO situation is a reflection of the company's waning confidence in the outcome, the sudden change of heart in combination with the company's offer to replace infringing code (which may also turn out to not be enough to satisfy SCO and which the Red Hat admits in its 10-Q may not be possible on a timely basis) in combination with Red Hat's failure to offer any indemnification to it's customers tells me that no matter how confident Red Hat CEO Matthew Szulik appears in public, the company is being much more cautious about that confidence with its shareholders and customers.

To gauge Red Hat's assessment of my theory regarding the value, or lack thereof, in its software warranty, I checked in with Red Hat spokesperson Leigh Day at LinuxWorld in January 2004. Not surprisingly, Day refuted my assertion that replacement of infringing code falls short of indemnification and spun it in the opposite way. "If you look at what the other companies are doing with indemnification, all they are doing is offering to cover the legal costs," said Day. "Instead, we're saying we're going to solve the problem. Isn't that the most important thing to say? That the platform is protected? We feel that our warranty is a comprehensive solution."

But nothing rattles a business like a lawsuit. It's one thing to promise that the software will work. But what good is a guarantee to replace infringing code if that turns out to not be enough to satisfy SCO or the courts? So, I asked Day what happens if SCO sues one of Red Hat's customers. "We can't comment on the hypothetical," Day said. " In talking with customers, they didn't demand indemnification. They just wanted assurances they could continue to use code. The best way to address this need was for us to announce that if a problem comes up, that Red Hat will replace the infringing code at no additional cost, thereby allowing customers to continue with uninterrupted use of the code." Day later summed up Red Hat's position by saying, "We're extremely confident that this is not an issue."

But apparently, not confident enough to protect its customers from liability. Am I dreaming, or was that a black dust ball that the canary just coughed up?

You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.