Why SCO is Wrong
Stephen Leibowitz
December 3, 2003


The purpose of this writing is to express my view on the controversy concerning The SCO Group and the Linux operating system. Like most independent observers, I disagree with SCO’s claims in this area. The next four sections discuss why I think that SCO is wrong. The last section makes suggestions to the Linux community on how to face this problem.


Market Issues

SCO has a section in its complaint against IBM titled, “Marketplace Value of UNIX” (paragraphs 71–75). That section, combined with the rest of the complaint, tries to paint a picture of UNIX as a very valuable property of SCO that has been unfairly damaged.

In particular, SCO contends that Linux has infringed on its intellectual property (IP) since version 2.4, which was released in January 2001. But SCO’s business of licensing UNIX to OEMs and end-users had already faded by then. One reason was that major UNIX OEM vendors Sun Microsystems, IBM, and Hewlett Packard had previously purchased fully paid-up licenses and were no longer paying royalties.

Additionally, starting in the mid-1990’s, a number of UNIX OEM licensees embraced Microsoft Windows NT and its successors. A similar shift to Windows was occurring with application and system software vendors, and users. Windows was gaining market share in those areas where UNIX primarily sold: servers and workstations.

Even before version 2.4, Linux developed into a popular choice for servers. It also enjoyed strong growth on the desktop, although its market share was still much less than that of Windows. It gained traction largely because of things that UNIX lacked or was weak in: open-source, no license fees, and a mechanism of development and support that mobilized substantial volunteer resources over the Internet. As computer users expressed a willingness to pay for Linux support and additional software, commercial vendor activity developed.

SCO’s complaint puts particular emphasis on its UnixWare product, for which there has been no OEM royalty buy-out. UnixWare runs on Intel-compatible machines (x86). SCO theorizes that had it not been for UNIX “protected code” misappropriated into Linux, UnixWare would have sold much better. But even in an alternate reality where Linux was less popular, UnixWare would have faced intense competition for those “in-play” users from products for which SCO was not collecting royalties. Most directly, on x86 hardware, UnixWare faces competition from two UNIX-like products besides Linux: BSD and Sun Solaris. A less popular Linux would have likely motivated Sun to put additional emphasis on the x86 version of its highly regarded Solaris software. UnixWare also faces powerful competition from Windows on x86. And for what SCO labels enterprise computing, non-x86 hardware tends to dominate. UnixWare does not run on these competing platforms. But there are UNIX-like products free of SCO royalties and other operating system software that do run on non-x86 hardware.

Given these circumstances, I believe that even if the additions to Linux that SCO is complaining about had not occurred, SCO would not have done much better. A less popular Linux would mostly have meant more users of operating systems for which SCO was not collecting royalties, such as Windows or BSD (including Apple’s Mac OS X) or UNIX from a vendor with a fully paid-up license.


SCO UNIX and Linux

In the next section, I will discuss “derivative works.” I will concentrate in this section on SCO’s allegation that Linux infringes on their copyright of UNIX System V.

It should be noted that not all the source code in UNIX System V is proprietary to SCO. Under previous management, SCO, then known as Caldera, released earlier versions of UNIX to the public as free software. Earlier versions were also released by previous owners of UNIX. It is likely that a significant part of System V is this released code. Also, in litigation some years ago concerning UNIX (then owned by AT&T) and BSD, it was discovered that some UNIX code had been taken from BSD. It may even turn out that some UNIX code has been taken from Linux.

In order to detect copyright infringement of UNIX System V by Linux, SCO has compared the two code bases. But first, it is necessary to filter out the portions of System V that its owners had released as free software, or that they had copied from free software. Additionally, some sections of the two code bases may innocently be similar, if they were independently programmed. SCO’s presentation at a trade show indicates that its comparison of the code bases has not taken these things into account.

At the SCO Forum trade show in August 2003, SCO presented two examples of alleged improper copying of System V source code into Linux. SCO masked some of the code shown by using a Greek font, and did not initially distribute copies of the projector slides, but an attendee photographed two of the slides, which was part of the first example. The Linux community deciphered the masking and looked into the history of the code. The result was a convincing analysis that the code on the two slides was not proprietary to SCO.

SCO then distributed the entire presentation, with the masking, to the press. With this additional information, the Linux community performed a more detailed analysis, which now also included the second example. But the overall conclusion was the same: that Linux developers have the legal right to use the code in question.

SCO’s second example, shown on slide 15, contended that “obfuscated” code had been copied from System V into Linux. The code in question implements the Berkeley Packet Filter (BPF). The System V code had been copied from BSD. So even if Linux had used that code, it would have been legal. But the Linux community determined that the Linux version had been programmed independently, and was similar, but not identical, to it because they both had been programmed from the same detailed specifications created by Lawrence Berkeley Labs. SCO does not own the specifications, and the independently programmed Linux version of BPF does not infringe on System V.

SCO backed off on their BPF allegation, but with an especially graceless explanation in which they denied having intended to present the BPF as an example of stolen code. An examination of slide 15, within the context of the entire presentation, makes it clear that their denial is ridiculous.

It is useful to consider how SCO’s proprietary code could have gotten into Linux. System V UNIX is not open-source, but over time many developers have seen the code. Developers could have seen it while working for SCO, or a previous owner of UNIX (AT&T, Novell, Santa Cruz Operation, and Caldera), or an OEM licensee. The source code has often been made available to academicians. Some other organizations also have source code licenses. Conceivably, one or more developers with access to the code could have made an improper contribution from the proprietary portion of System V to Linux. If these developers pass the contribution off as their own work, it could be accepted and some time could pass before its true origins are discovered, since System V is not open-source.

But other operating systems could also have received improper contributions of System V code. Consider this possibility as an example: Windows is the result of thousands of developers working for Microsoft. No doubt, a number of these developers had previously seen System V source code while at previous organizations. It seems possible that some of these Microsoft developers succumbed to temptation and took a shortcut by copying SCO’s proprietary code in System V to Windows, passing it off as code they developed while working at Microsoft. I don’t believe that Microsoft’s management would have condoned this, but how would they have known?

SCO has in a court filing criticized the Linux development process, saying that it has inadequate safeguards against software developers making improper contributions of “protected UNIX code.” But the conclusion I draw is that, contrary to SCO’s complaints, the open-source nature of Linux guards against infringements in ways that closed-source systems cannot. Because the Linux source code is publicly available for inspection, improper contributions to it are more likely to be discovered and removed. Also, the public record identifies who contributed what code. This further serves as a deterrent to making an improper contribution to Linux. The public record facilitated the community’s investigation of SCO’s copying charges in its trade show presentation.

The Linux community generally does not accept SCO’s derivative works claims, but is willing to consider the possibility that some of SCO’s proprietary code was copied into Linux. There is a suspicion in the community that the amount of such code is small, and very possibly none. Senior Linux people have asked SCO to publicly identify this code in Linux. This is so that the Linux community can investigate and replace the code that they agree infringes. SCO has refused. They have only been willing to show examples under a non­disclosure agreement that is not suitable for the investigate-and-replace objective. SCO has said that they have internally identified the copying, but that publicly identifying it would reveal their closed-source code.

SCO is not even willing to publicly say what specific parts of Linux they believe to be proprietary SCO code. If they were to do this, it would probably not provide enough information to enable the Linux community to fully investigate all of these instances of alleged infringement. For a full investigation, the community would also need access to SCO’s code, its development history, and any other information SCO has to support its contention. But even a partial investigation would probably result in at least an agreement on some relevant facts. This approach would not provide the public with more access to any infringing code than they already have, given that Linux is open-source.

If the Linux community did know what to replace, it would be interesting to see how long it takes to develop a replacement, and at what cost. SCO contends that Linux contains SCO’s intellectual property. A common way that appraisers use to value property is the replacement cost approach, which in this case might have to be adjusted because code is donated to Linux. Another appraisal approach is the income approach, which would probably involve time-to-market considerations and the importance of the code being replaced. Basically, if the value of SCO’s IP in Linux is low, it would be difficult to argue that SCO deserves a high compensatory damage award.

SCO published an “introductory, promotional” price list in August 2003 for their IP in Linux. The prices are supposed to double after October 2003. They are demanding that users of non-SCO Linux distributions (version 2.4 and later) buy a license from SCO, in order to legally use the non-SCO distribution. For example, they are demanding $32 for each copy of an embedded version of Linux (such as TiVo set-top boxes). These prices would be very high, even if SCO owned all of Linux. Also, embedded Linux, and to a slightly lesser extent desktop Linux, generally do not even use the code that forms the part of SCO’s complaint based on derivative works. SCO is engaging in price gouging.

SCO probably came to realize by about six months into the litigation that their allegation of misappropriation of their proprietary code into Linux was in serious trouble. In November 2003, SCO made an apparently desperate attempt to breathe new life into the charge, through an indirect route. SCO announced that it had found infringements in BSD. SCO’s CEO said, “With our limited energies and what our guys are going through, we probably won’t file any suits against BSD until sometime in the first half of next year.”

But the real target appears to be Linux. The two examples of misappropriation that SCO showed at the trade show foundered partially because the code was also in BSD. The Linux community could argue that it was legitimate to use BSD code in Linux, because of BSD’s open-source license. After that debacle, SCO probably realized that BSD could similarly shield Linux in other instances. So it appears that SCO’s strategy is to argue that BSD did not properly implement the 1994 settlement between AT&T and BSD, resulting in infringing code in BSD. The settlement would not shield Linux for any infringing BSD code copied into Linux. SCO may also attempt to cast the 1994 settlement as a licensing of some UNIX code to BSD, with BSD not allowed to license that code for “derivative works” of BSD, such as Linux. Apple’s Mac OS X makes heavy use of BSD code, and may also be a target in SCO’s attack against BSD.


Derivative Works

SCO has a better chance for a substantial monetary judgment with their claim in the murky area of derivative works. This is because the part of Linux that SCO contends is derivative works code is at about 1.1 million lines. In contrast, I would hazard a guess that the amount of proprietary SCO code in Linux is less than 1,000 lines (this assumes that SCO’s BSD legal maneuver fails). To further put this in perspective, the Linux kernel has more than 5 million lines of code. So far, SCO has sued only IBM for contributing derivative works, although they have threatened to sue SGI for contributing the SGI XFS software.

It is worth repeating that many Linux installations use little or none of the alleged derivative works code. This is especially true for embedded, and to a slightly lesser extent, desktop Linux. Even many server installations of Linux, particularly single-CPU servers, use little or none of this code.

SCO’s derivative works claim against IBM is bold, since the code and supporting documentation in question were written and copyrighted by IBM or Sequent (a company that IBM had acquired). SCO is in effect claiming a right to control this software, based on contract provisions. In particular, they are claiming that IBM needed SCO’s permission to contribute it to Linux and that SCO did not give permission. SCO has at least said what software they are complaining about, from Sequent’s DYNIX/ptx: NUMA, RCU, and SMP.

SCO is also complaining that IBM contributed the AIX Journaling File System to Linux. But IBM’s JFS contribution to Linux was derived from its OS/2 version of JFS. SCO and the previous owners of UNIX have never contended that any part of OS/2 was a derivative work of System V.

In its complaint, SCO attempts the following justification: “Were it not for UNIX System V, there would be no UNIX technology or derivative works available for IBM and others to copy into Linux.”

But there appears to be little or no technical reason why the movement of code could not have gone in the other direction. The developer companies were simply working on UNIX before Linux. It is doubtful that they would have used UNIX as a development platform for the code in question if they had known that SCO would later take such an expansive view of what constituted derivative works.

SCO complains of Linux scaling up to enterprise-level computing capabilities by the misappropriation of UNIX technology. This is ironic in view of the history of UNIX. The original design of UNIX was heavily influenced by Multics. Multics was jointly developed by MIT, GE/Honeywell, and AT&T, with AT&T dropping out of the project in 1969. AT&T then starting work on UNIX. Using the standard that SCO is applying now to Linux, UNIX is a derivative work of Multics. The early versions of UNIX were below enterprise-level. UNIX later benefitted by the addition of enterprise technologies that had been used previously in commercial operating systems, such as IBM’s mainframe operating systems and DEC’s non-UNIX systems. UNIX’s enterprise capabilities also benefitted from academic/government research & development. Other aspects of UNIX’s capabilities, such as real-time and GUI, also originated elsewhere. It appears that SCO and the previous owners of UNIX paid the pioneering organizations little or nothing for their innovations.

The lack of payments mentioned in the last sentence may change. IBM itself has an impressive history of developing software technology, some of which it has patented. IBM has filed four counterclaims alleging that SCO’s UNIX products infringe upon IBM’s software patent portfolio. In total, IBM has filed 13 counterclaims against SCO, including some alleging software copyright infringement by SCO.

While I have not examined the “derivative works” code (e.g. NUMA), I expect that the developers took care to keep it separate from SCO’s proprietary code. (Keep in mind that not all of the System V code is proprietary to SCO, as explained in a section above.) The separation would be for legal reasons and to more easily use it with newer releases of SCO’s code. Also, they are likely to be separate because computer software, especially large software such as operating systems, typically have a modular organization. I expect that the connection between SCO’s proprietary code and the code in question is by communication via UNIX interfaces (APIs) and protocols.

A problem for SCO is that UNIX APIs and protocols have been publicly available for some time. Earlier versions of UNIX were released to the public as free software. Also, independent standards organizations have published interoperability specifications. An example is the IEEE publication of POSIX, which is based on UNIX APIs. POSIX compatibility is present in a number of non-UNIX operating systems, such as Windows NT and later, and VAX/VMS. Even the U.S. government mandates POSIX on many of their non-UNIX systems.

It would be difficult for SCO to successfully claim that the interoperability specifications infringe on its IP. This would be if for no other reason than that SCO and the previous owners of UNIX did not complain at the time of publication. In fact, AT&T contributed to the POSIX standards effort while it owned UNIX.

Also, SCO could have complained about derivative works at the time IBM announced its intention to contribute the software to Linux, before the contribution actually occurred to the Linux development process. Instead, SCO delayed until a considerable time after the code was in the production version of Linux. This delay further weakens SCO’s case.

More generally, SCO’s derivative works claim challenges the long-standing notion of software portability. If their claim was upheld, it might also bring the legal portability of other software not directly owned by SCO into question, such as GUI, shell, DBMS, and computer language compiler software. I would suggest that the contributions to Linux that SCO contends are infringing derivative works are instead non-infringing “compatible works.”


General Public License

In its counterclaims against SCO, IBM has raised the issue of the GPL. Ironically, SCO was itself commercially distributing Linux, under the GPL. Not only did SCO distribute Linux before it came to believe that Linux infringed on its IP, but it continued to distribute Linux for some time afterwards. IBM argues that, “The GPL prohibits SCO from, among other things, asserting certain proprietary rights over, or attempting to restrict further distribution of any program distributed by SCO under the terms of the GPL, except as permitted by the GPL.”

With respect to the previous paragraph, a timeline is useful. SCO’s CEO has said that they first saw IP “problems” in fall 2002. He has also said that they started talking to IBM about infringements in December 2002. In January 2003, SCO formed their SCOsource business unit for IP matters, hired a famous litigation attorney, and started to publicly contend that Linux infringed on their IP. The talks with IBM did not produce a resolution, and SCO sued IBM in March 2003, formally contending that UNIX works were misappropriated into Linux. But it was not until May 2003 that SCO stopped selling Linux.

SCO apparently recognizes the danger that the GPL poses to their case. They have countered by contending that the GPL conflicts with US copyright law, and is unenforceable. Since the time IBM filed its counterclaims, SCO has devoted a sizeable portion of their public pronouncements on the case to attacking the GPL. But an argument similar to SCO’s argument against the GPL could be used against their own derivative works claim. In each case, you have an agreement (GPL or the UNIX System V contract) for the use of copyrighted software bumping up against the rights of users with respect to their own copyrighted works.

It is interesting to note that before IBM used the GPL as a basis for its counterclaims, SCO made a public attempt to use the GPL to support SCO’s case. In a June 2003 interview, SCO’s Chris Sontag said, “GPL has the same derivative rights concept [as UNIX].”


Suggestions to the Linux Community


© 2003 Stephen Leibowitz