Download PDF version of this article PDF

Closed Source Fights Back
Greg Lehey

SCO vs. The World—What Were They Thinking?

In May 2003, the SCO Group, a vendor of the Linux operating system, sent a letter to its customers. Among other things, it stated, “We believe that Linux is, in material part, an unauthorized derivative of Unix.”1 What would make SCO do that?

The action wasn’t completely unexpected. In March, SCO had filed a suit against IBM for giving away trade secrets.2 In that complaint, it made a number of accusations against IBM, including the claim that IBM intended to use Linux to kill Unix.

For most people in the industry, Linux is Unix. Admittedly, it was developed independently of Unix, but the similarities are marked and intentional. So how can Linux kill Unix? That depends on your interpretation of the word “Unix.” There are a number of ways to view Unix: You can take the genealogical approach (‘‘It was derived from the same code base.’’), the standards-based approach (‘‘It complies with Unix 03.’’), the legal approach (‘‘It has been certified as being Unix 03.’’), or the technical approach (‘‘It looks like Unix, smells like Unix, so it must be Unix.’’). Based on the last criterion, many people would say that Linux is indeed Unix.

Unix Genealogy

The Unix family has hundreds of members, some of which have been disowned by their parents. Éric Lévénez maintains a Unix family tree3 which, printed out in miniscule type, is about 10 feet long. In brief, though, there have been three main versions based on the original source code:

1. Research Unix was the original Unix developed at Bell Labs.

2. BSD (for Berkeley Software Distribution), also known as Berkeley Unix, is the version developed at the University of California, Berkeley. It was the predominant Unix in the 1980s, helped by the development of the Internet and its adoption by a number of workstation manufacturers, notably Sun Microsystems, Inc. and Digital Equipment Corporation.

3. In the early ‘80s, AT&T developed System III and then System V. It persuaded a number of workstation manufacturers to switch from Berkeley Unix to System V.

During the ‘80s, a number of things happened:

What was wrong with System V? To quote a button depicted on the front cover of Peter H. Salus’ A Quarter Century of Unix (Wiley, 1994), ‘‘System V does everything Unix does, only not as well.’’ More technical reasons were a lack of good memory management, almost nonexistent support for multiple processors, and an installation procedure that paid more attention to licensing dozens of individual components than it did to ease of use. In January 1992, the German magazine iX had planned a review of no less than five different versions of Unix System V.4.4 At that time, all versions of Unix sold as ‘‘System V.4’’ ran on the PC platform.5 Over several weeks, iX tried multiple machines, but it was only able to get one of the five systems to boot. The magazine gave up on the review.

Hardware vendors had their own problems. The initial release of System V.4, the agglomeration of System V.3, Microsoft’s (later SCO’s) XENIX, and 4.3BSD was so buggy that those vendors who based their Unix offerings on System V.4 had to spend up to two years debugging before they could ship a product. They also adapted the code to their systems—fixing technical weaknesses in the process—addressed the administrative issues, and gave the product a distinct name. It’s not surprising that the market share of stock System V began to dwindle. The most recent System V implementation was UnixWare, created by Unix System Laboratories (USL) and Novell in 1992. It successfully addressed the weaknesses listed above, but it was too late. Stock System V had started to gradually disappear even before Linux and the free BSD versions became widespread.

Who Owns Unix?

We’ve already seen that ‘‘Unix’’ means many things, some of which are associated with a monetary value. In particular, the trademark, the source code base, and associated patents are considered valuable. Each of these belongs to a different organization:

It’s interesting to note that, of these three organizations, only SCO shows any opposition to open source. In addition to its Unix certification, The Open Group also provides Linux certification in accordance with the Linux Standards Base—obviously a pro-Linux stance. And Novell has openly stated its support for Linux.12

Why Is SCO Attacking Open Source?

SCO is acting as if it is the most important player in the Unix game. In fact, it is relatively insignificant. System V was last licensed to a third party in 1994, when Hewlett-Packard (HP) upgraded HP-UX to release 10. HP-UX has been based on System III and System V since its initial release in 1982, so it wasn’t exactly a new customer. The time before that was in 1991 when Sun created SunOS 5.13 SCO’s own products do not comply with the latest Unix specification. Its most up-to-date product, UnixWare, is certified as conforming to the Single Unix Standard Version 1, or Unix 95.14 SCO OpenServer, introduced in 1988, was based on Unix System V.3.2 and certified as Unix 93.15 By all accounts, they are not selling well. (I don’t know where I could buy UnixWare, other than directly from SCO.) Sun announced Unix System V.5 in 1997, but so far the only implementation is UnixWare 7.16 Like many other Linux vendors, SCO has not found a way to be profitable distributing and supporting Linux. Its unique asset is the System V code base, the basis of nearly all current commercial Unix distributions.

So what are those distributions doing? They’re gradually going away. There are really only four major Unix vendors left: HP, IBM, SGI, and Sun. All of them are actively developing Linux. SCO sees its revenue streams going away. You can’t get revenue from free software. (See Mike Karels’ “Commercializing Open Source Software” on p. 46 of this issue.)

On the other hand, Linux is a lot like Unix. It certainly builds on a third of a century of experience with Unix. But is that all? Might it not also have benefited from Unix source code? If that were the case, SCO could profit from it, so it spent a lot of time investigating whether there is any Unix code in Linux. And, it seems, it found some.

What do you do when you find somebody abusing your intellectual property? The most obvious thing is to get them to stop. But SCO isn’t doing that. It has refused to show enough evidence for people to even voluntarily remove the offending code. Instead it requires a draconian nondisclosure agreement before it will show the code.17 It doesn’t seem to want it removed. Chris Sontag, senior vice president of SCO, is on record as having said, ‘‘Once contributed, code cannot be removed.’’18 This is nonsense, of course. Operating systems’ sources undergo continual development, and that involves replacement of code. SCO’s legal predecessors have fought lawsuits to get people to remove Unix code from their sources. But this attitude suggests that SCO wants the code to stay there; If Linux contains Unix source code, it can charge royalties.

This would explain a lot of SCO’s actions. But is it true that SCO wants royalties from Linux? And if it does, can it get them?

The Effects

SCO’s approach is causing a lot of damage, not the least to SCO.

The most obvious effect of SCO’s actions is FUD: fear, uncertainty, and doubt. The letter it sent to its customers appeared to be calculated to cause maximum damage, sparking conspiracy theories that Microsoft was behind the actions, and that the real intention was to kill Linux. These theories gained additional fuel a couple of days later when Microsoft announced that it was licensing SCO technology.19

Other effects are more damaging to SCO. In the complaint it filed against IBM in March, it wrote:

84. Prior to IBM’s involvement, Linux was the software equivalent of a bicycle. Unix was the software equivalent of a luxury car. To make Linux of necessary quality for use by enterprise customers, it must be redesigned so that Linux also becomes the software equivalent of a luxury car. This redesign is not technologically feasible or even possible at the enterprise level without:(1) a high degree of design coordination, (2) access to expensive and sophisticated design and testing equipment, (3) access to Unix code, methods, and concepts, (4) Unix architectural experience, and (5) a very significant financial investment.

It’s hardly necessary to state that this stretches the truth to the breaking point. But there is a further-reaching implication. Long before IBM became involved with Linux, SCO was actively trying to make a “luxury car” out of Linux. This implies that SCO was incapable of doing so. It makes it pretty clear that SCO no longer intends to be in the Linux business, but it also weakens SCO’s case about its technical expertise.

This is only part of the story. On its Web site,20 SCO still advertises its own ‘‘enterprise-grade Linux.’’ This kind of crass contradiction weakens both its case against IBM and its own credibility. Combined with other actions, it also fuels additional conspiracy theories: SCO has shown source code common both to UnixWare and Linux under a nondisclosure agreement (NDA), both to the press and to a small number of programmers. It claims that the code was stolen from UnixWare and put into Linux.

SCO is not going to great lengths to convince people. Reportedly, the terms of the NDA were quite stringent:

[The NDA] essentially permitted SCO to declare any information it provided to be confidential, regardless of whether the signer already knew it, and it offered no circumstances under which that information could be revealed. Most Linux developers are unable to sign such an NDA as it easily could prevent them from ever again working on the kernel. Similarly, employees of any company that works with Linux cannot sign such an NDA. 21

A small number of programmers have seen the code and have confirmed that there were significant similarities in some areas, similarities that can really only be explained by code copying. SCO has an explanation. In its complaint, it claims that:

86. It is not possible for Linux to rapidly reach Unix performance standards for complete enterprise functionality without the misappropriation of Unix code, methods, or concepts to achieve such performance.

It would not be impossible for someone to come to the conclusion that SCO itself inserted the code into Linux: It had both the motivation and the ability.

Could this action, however, improve sales of System V? That’s not very likely. SCO has been selling Unix all this time, and sales are declining. The big vendors are suffering too. That’s why they are moving to Linux. They wouldn’t do that if they thought they could make money out of commercial Unix.

What about getting royalties for Linux? This seems highly unlikely, but it’s up to a court to decide on that. It’s difficult to charge royalties on code that is not identified. If it is identified, it can be removed. In any case, Linux isn’t the only free Unix-like operating system. There are the BSDs as well, genuine descendants of Unix. They had their lawsuits 10 years ago, and they have long been settled.

The Return of BSD?

Around the time that Linus Torvalds started developing Linux, Bill Jolitz of the CSRG in Berkeley was working to extricate the code that had been written in Berkeley from the AT&T base on which it had been built. That wasn’t as ridiculous as it might sound. In over 10 years of development, just about all the AT&T code had been replaced. The code that hadn’t was relatively simple and easy to replace. Since it was developed at a university, a BSD without AT&T code could be released under a much more liberal license, one that required no royalties.

This project was not completed in Berkeley. Instead, some CSRG members formed a company, Berkeley Software Design (BSDI), to market the new operating system, called BSD/386. Independently, Bill Jolitz released a free version called 386BSD. AT&T had received a copy of the Berkeley release, but it didn’t pay much attention until BSDI started advertising its toll-free phone number: 1-800-ITS-UNIX. Then its subsidiary, USL, acted quickly, and within weeks the phone number was changed. But the incident woke the sleeping dogs, and they investigated and subsequently sued.

It’s instructive to revisit the results of that action:

Could this lawsuit have similar results? Anything’s possible, but there are a number of significant differences. In the AT&T case, it was a big company suing a small Colorado startup and it involved a couple of user groups. SCO is a small company with a shaky financial foundation22 suing the world’s largest computer company. In a situation where the ability to finance expensive litigation is important, it’s clear that SCO is in a much worse position.

The real mistake

No matter what the outcome of the suit, however, SCO is wrong. The real key to survival is not a few algorithms or lines of source code. Open source has demonstrated this.

The big lesson of open source is that software development works better in the open, where people can discuss things. This benefit far outweighs the commercial value of the source code. Unix was originally developed in this way, even if access to the source was more restricted than the modern open source approach. The problems began in the 1980s; startup companies tried to outdo each other in a quest for market share. Companies developed their own proprietary extensions to Unix to lock customers into their implementation, and they guarded the source code closely, elevating its perceived value far beyond anything that was justifiable. In truth, Unix source code is no better than Linux source code.

IBM, in particular, has recognized these mistakes. IBM’s corporate culture is about as far from the open source ethos as you could find. It’s not embracing Linux or releasing the source for its own products out of altruism; it’s doing it because it believes it makes commercial sense. In so doing, it is gaining an advantage over companies that resist change, a fair advantage. If SCO wants to survive, it needs to understand this lesson. Litigation won’t save it.

REFERENCES

1. SCO published this letter on its website (http://www.sco.com), but was obliged to remove it due to legal action taken in Germany.

2. http://www.sco.com/scosource/complaint3.06.03.html

3. http://www.levenez.com/unix/history.html

4. Der große Frust, iX January 1992, page 75.

5. The systems were AT&T, Interactive, Esix, Microport, and Consensys. SCO did not have a System V.4 offering until much later.

6. http://www.opengroup.org/

7. http://www.unix.org/version3/

8. Compaq is now called Hewlett-Packard, but the registration is in the name of Compaq. No HP product is certified as Unix 98.

9. http://www.opengroup.org/openbrand/register/xx.htm

10. http://www.opengroup.org/comm/press/who-owns-unix.htm

11. http://www.novell.com/news/press/archive/2003/05/pr03033.html

12.Simply put, Novell is an ardent supporter of Linux and the open source development community. This support will increase over time. http://www.novell.com/news/press/archive/2003/05/pr03033.html

13.There’s also a derivation to Venix 4.2 in 1993, but it never seems to have been distributed. http://www.levenez.com/unix/history.html, http://www.sco.com/scosource/unixtree/unixhistory01.html

14. http://www.opengroup.org/openbrand/register/xu.htm

15. http://www.opengroup.org/openbrand/register/xt.htm, http://www.opengroup.org/products/cert/certprods.htm

16. http://www.levenez.com/unix/history.html, http://www.sco.com/scosource/unixtree/unixhistory01.html

17. http://www.linuxjournal.com/article.php?sid=6956&mode=thread&order=0

18. http://www.byte.com/documents/s=8276/byt1055784622054/0616_marshall.html

19. http://www.sco.com/unitedlinux/

20. http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=109360

21. http://www.linuxjournal.com/article.php?sid=6956&mode=thread&order=0

22. http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=102627

GREG LEHEY <[email protected]> is an independent Unix consultant living in South Australia. In the course of 30 years in the industry, he has performed jobs ranging from kernel development to product management, from systems programming to systems administration, from processing satellite images to programming gasoline pumps, and from the production of CD-ROMs of ported free software to DSP instruction set design. Lehey was the manager of Tandem Computers’ European Unix technical support and has worked in Unix development at Siemens-Nixdorf and Linux development at IBM. He has been developing BSD code for 10 years and is author of the Vinum Volume Manager, a free volume manager for BSD. He is the president of the Australian Unix User’s Group and a member of the FreeBSD core team. He is the author of Porting UNIX Software (O’Reilly and Associates, 1995) and The Complete FreeBSD (fourth edition, O’Reilly and Associates, 2003). He is maintaining an ongoing analysis of the SCO affair at http://www.lemis.com/grog/sco.html.

acmqueue

Originally published in Queue vol. 1, no. 5
Comment on this article in the ACM Digital Library





More related articles:

Amanda Casari, Julia Ferraioli, Juniper Lovato - Beyond the Repository
Much of the existing research about open source elects to study software repositories instead of ecosystems. An open source repository most often refers to the artifacts recorded in a version control system and occasionally includes interactions around the repository itself. An open source ecosystem refers to a collection of repositories, the community, their interactions, incentives, behavioral norms, and culture. The decentralized nature of open source makes holistic analysis of the ecosystem an arduous task, with communities and identities intersecting in organic and evolving ways. Despite these complexities, the increased scrutiny on software security and supply chains makes it of the utmost importance to take an ecosystem-based approach when performing research about open source.


Guenever Aldrich, Danny Tsang, Jason McKenney - Three-part Harmony for Program Managers Who Just Don't Get It, Yet
This article examines three tools in the system acquisitions toolbox that can work to expedite development and procurement while mitigating programmatic risk: OSS, open standards, and the Agile/Scrum software development processes are all powerful additions to the DoD acquisition program management toolbox.


Jessie Frazelle - Open-source Firmware
Open-source firmware can help bring computing to a more secure place by making the actions of firmware more visible and less likely to do harm. This article’s goal is to make readers feel empowered to demand more from vendors who can help drive this change.


Marshall Kirk McKusick, George V. Neville-Neil - Thread Scheduling in FreeBSD 5.2
A busy system makes thousands of scheduling decisions per second, so the speed with which scheduling decisions are made is critical to the performance of the system as a whole. This article - excerpted from the forthcoming book, “The Design and Implementation of the FreeBSD Operating System“ - uses the example of the open source FreeBSD system to help us understand thread scheduling. The original FreeBSD scheduler was designed in the 1980s for large uniprocessor systems. Although it continues to work well in that environment today, the new ULE scheduler was designed specifically to optimize multiprocessor and multithread environments. This article first studies the original FreeBSD scheduler, then describes the new ULE scheduler.





© ACM, Inc. All Rights Reserved.