decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Lxrun - why wasn't it released under the GPL?
Wednesday, August 16 2006 @ 11:31 AM EDT

The other day, I wrote about ELF again, the most recent in our continuing series of articles on ELF, and the article mentioned lxrun, the Linux emulator Michael Davidson wrote for SCO. The main questions I had in my mind about lxrun were these:
1. Did lxrun use Linux ELF?

2. What license was lxrun released under?

The reason I wanted definite answers to those two questions is because if, as SCO claims, ELF header files are copyrightable, and if lxrun uses the Linux ELF header files, why wouldn't lxrun have to be licensed under the GPL? After a lot of digging, I believe I have found the answers to those questions.

When SCO first raised the ELF claims, the Linux community hooted, because header files are normally not considered part of the kernel and because they are essentially necessary, like 1, 2, 3 is necessary to count to ten and there is no other good way to get there (cf. Groklaw's July 22, 2004 article A Tall Tale About ELF,".) So no one here believed that ELF was subject to copyright, and in fact we burst out laughing. The rules for copyright on software, as you probably know, aren't exactly the same as for a novel. And in general terms, if there is only one way to do an essential step in computing, copyright won't apply.

So when I read the following on the lxrun page, I started to wonder:

Lxrun is a user-space program that allows users of SCO(r) OpenServer(tm), UnixWare(tm), and Sun(r) Solaris(tm) x86 operating systems to run ELF and a.out format Linux binaries. It was originally written by Mike Davidson of SCO. It is now maintained under the Mozilla license as an open-development effort .

I did some digging, and it turns out that originally, Davidson released it under a BSD-style license. SCO's intention was to open source it and not have to support it or be legally liable in any way. Here's a photo demonstrating that intent to open source lxrun:

When Davidson lost interest in the project, he turned the source over to Steve Ginzburg, who was a SCO intern at the time, and Steve added some things and ended up using the Mozilla license. Sun Microsystems also added some things and shipped lxrun for Solaris as well. Eventually, it ended up being put into Caldera's Skunkware, as you can see from this screenshot I took some years ago off of the then available page

Why, though, wasn't the GPL the license used? I took a look at the lxrun FAQ and found more material that added to my puzzlement:

Q0.2: How does lxrun work?

A: Quite well, actually. :-)
Seriously, it works by remapping system calls on the fly. As it turns out, there's not much difference between Linux and iBCS2 binaries. The main difference is the way in which system calls are handled. In Linux, an "int $0x80" instruction is used, which jumps to the system-call-handling portion of the Linux kernel. On other systems, "int $0x80" usually causes a SIGSEGV signal. Lxrun intercepts these signals and calls the native equivalent of the system call that the Linux program attempted. The result is that the Linux binary can be run (with the help of lxrun) with a small (usually negligible) performance penalty. All this is accomplished without modifying the kernel or the Linux binary.

Q0.2.1: What does "negligible performance penalty" mean?

A: Well, lxrun is not really an emulator, in that it's not really doing any emulation work. You can think of it more as a layer that sits between the Linux binary and the rest of the system doing a few translations here and there where it's necessary. When are these translations necessary? When the Linux binary attempts a system call. The rest of the time, lxrun is dormant and does not affect the performance of your application at all.

System calls are used for I/O, displaying things on the screen, accessing the network, etc. System calls are not used during computation. This means that computation-intensive applications (such as compilers, image processors, etc.) will show the least difference in performance....

Q0.7: Who wrote lxrun?

A: It was originally written by Michael Davidson, an engineer at SCO. In 1997, Michael released the lxrun source code to Steven Ginzburg who is continuing its development as an open source project under the Mozilla public license. Contributors to lxrun have included hobbyists and engineers from all over the world. In addition, the Santa Cruz Operation (SCO) and Sun Microsystems have both contributed engineering time and other resources to the project....

Q1.0: What does lxrun need in order to work?

A: To run most Linux programs, lxrun requires the help of the Linux dynamic loader (*) and whatever Linux shared libraries are required by the program. Effectively, you need to set up a "Linux environment" that looks enough like a real Linux system to fool the program you are trying to run. For more information, see the section below on Linux environments.

So, lxrun does not include any Linux kernel code per se but it does include copies of selected fragments of certain Linux kernel header files such as errno.h, signal.h etc which define the precise binary data structures and binary values that are used by the Linux system call interface. Yes, those are on the list of files SCO claims it has copyrights to and it claims are not allowed to be used in Linux. But here in the first photo, you can see that lxrun, which includes those very files, was open sourced, and by SCO itself. How can SCO, newSCO, not know that?

At the time lxrun was written, no one at SCO thought about elements that are necessary to define system call interfaces, and which by then were at least in part described in public standards, as being protectable under copyright, obviously, so they felt free to use Linux ELF and then put a BSD-like license on the lxrun project. If those header files were really copyrightable, lxrun would, I believe, have to be GPL'd. At a minimum, the headers would have to be.

At the moment, I think SCO stands alone in making the claim that ELF can be copyrighted, but the point I'm making is this: there is a serious disjoint in this picture. If ELF can, in fact, be copyrighted, then the Linux ELF files are copyrighted and then licensed under the GPL, so SCO would have violated the GPL when it released lxrun under a BSD license instead. You can still get lxrun, of course, as a free download.

Now SCO might tell me that those ELF headers were theirs to begin with. Groklaw has amply answered that claim. And recall that Sun also released lxrun. HP has its own Linux affinity project.1 So any copyright infringement claims over headers in lxrun seem dead in the water. But even if what SCO says were true, we now see that it itself released those very same ELF files under a BSD license with lxrun. They are still available from the man SCO handed the source code to, now under the Mozilla license. It was oldSCO's intent to open source lxrun, which includes the Linux ELF header files, or parts thereof.

So, no matter how we slice and dice it, SCO has painted itself into yet another tight corner. Their ELF claim is not only doomed, from all I can see, but SCO appears to be vulnerable to a claim of copyright infringement with respect to lxrun, if SCO's copyright theories regarding ELF ever were to stand.

Ironic, no? SCO just can't win for losing.

So, the answers I came up with to my two questions are, yes, Linux ELF is in lxrun, and it was released first under a BSD-like license and then under the Mozilla license. It wasn't released under the GPL because a) header files aren't part of the Linux kernel, b) SCO didn't think header files were copyrightable, and c) I think they were absolutely right about that.

1 Google cache provides this paper, "Linux Affinity", which tells a bit about lxrun, and IBM's, Sun's and HP's approaches to Linux emulation:

The three vendors have taken similar approaches to Linux affinity. HP-UX provides libhplx, which is a library that contains about 200 Linux-compatible APIs, related file headers, and their sources. This library is a set of APIs not available with HP-UX, taken from GNU 2.1.3, and is available under the GNU Public License (GPL). At LinuxWorld Expo in February, HP announced that they will be shipping the open source Ximian GNOME Desktop as their default desktop for HP-UX workstations. HP also announced they will be using GNOME as the open standard to provide a common desktop for both their HP-UX and HP Linux workstations. Similarly, Sun has announced that it will be using a GNOME-based desktop for Solaris. Gnome provides Solaris with programming libraries, and access to Sun's Star Office desktop office suite. The intent is that the user will not be able to tell if he's running RedHat Linux or Solaris under the hood (ZDNet). As the result of collaboration between Sun and the open source lxrun project, the lxrun utility allows Linux binaries to run without modification on Solaris Operating Environment on Intel platforms. lxrun is a software layer that sits between Solaris and the Linux Intel binary executable and remaps system calls "on the fly" allowing them to run unmodified on Solaris ( lxrun appears to provide a robust environment, supporting such diverse applications as WordPerfect, GNOME, GIMP, and Quake III.

If you visit HP's site, you will find libhplx for download, and this page tells us a bit about what is in there [Note update below, for working links as of 2010]:

Description: libhplx contains almost 200 Linux-compatible APIs in, the related header files, and the library sources. These Linux-compatible APIs were derived from the GNU libc 2.2.4, and are not currently available on HP-UX, and can be used in concert with the existing HP-UX libraries and the HP-UX development tools.

It's released under the GPLv2. More details here. My question for HP is, when SCO made its public claim to copyright over ELF and all the other claims, exactly when were you going to stand up and tell the world that SCO was wrong on the tech? I think it's time to make manifest where HP stands. HP sponsored SCOforum, and it's time to begin to notice, I think, how HP is presenting itself on the SCO issue. Ditto for Sun. When SCO claimed ownership of ELF, why didn't Sun speak up too and inform us that it too released lxrun and that ELF was in there? Here's where you can find info on lxrun from Sun's website. For example, here's their technical paper on lxrun. Folks may say, it's just business. But FOSS business isn't done the way proprietary business is done, not if you wish to make money. The community believes in ethical behavior, and it will notice who does and who does not honor FOSS ethics. Just so you know.

Update: The HP page I linked to has changed. You can still find the information, however, on Internet Archive. Here's how it looked in February of 2002. And here's the same page exactly one year later. And here's the last link for that page, in December 2005. For the licensing information regarding the LGPL, you can still find it here.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )