So I started researching, to see if I could come up with an explanation. That reminds me: I have a request for information. If any company has requested and/or received clarification from (old)SCO (Santa Cruz Operation, now Tarantella) in the past regarding the use and distribution of statically linked binaries (COFF in particular), could you let us know, please?

As it happens, just as I was staying up too late researching, I got a wonderfully clear email from Ian Eure, Lead Developer, WebSprockets, LLC, explaining the subject. He gave me permission to share it with the rest of you. I know many of Groklaw's readers will already know what static libraries are, but because our readership is mixed between tech and nontech, it seemed important to explain to the nontech side. SCO also spoke about "static shared libraries" in the hearing. We'll be explaining that in the next article on this topic, when we've completed our digging.

Meanwhile, here's Ian's explanation about static and shared libraries:

********************************************

SCO's report on discovery in their AutoZone case has quite a bit of technical info, and I thought your readers could use some background to better understand their claims.

SCO seems to be claiming that statically-linked binaries compiled on SCO platforms are infringing their copyrights, since they were copied off the systems they were compiled for.

Libraries

Libraries are discrete units of related code, intended to be reused by other applications. The most common is the C library (libc), which is used by nearly every program written for a UNIX or UNIX-like platform. The C library contains a ton of low-level stuff for printing things to the screen, reading input, reading and writing files and so forth. Each library generally has a single purpose; for example libVorbis handles decoding Ogg Vorbis audio files, libm has math functions, and so forth.

Shared vs. static

When you write a program which uses functionality in a library, you have to link it to that library. This happens when the program is compiled from the source code to the executable binary.

Shared libraries are contained in a file on your hard disk. They also have a versioning system, so changes in a library won't break your application. Shared libraries have a ".so" extension. When a program which uses a shared library is executed, the operating system loads the shared library into memory so the program can use it.

Static libraries are also contained on your hard disk, but they are embedded into your program's binary when it is compiled. Therefore, when your operating system loads your program, it also loads the libraries it needs, since they are packaged up with your program.

Shared libraries are more memory- and disk- efficient, since you only need one copy on disk or in memory, and an unlimited number of programs can use that single copy.

Static libraries are the exact opposite. If you create two programs which use the same library, compiled statically, you must load two copies of the same code from disk, and into memory.

So why use static libraries at all? Portability. If you only want to run your program on a specific operating system (Debian 3.1, or OpenServer 5.0, for example), you need only compile it to use shared libraries. However, if you want to support an older version of that same OS, your program may not work. You must either compile it again, on the older OS, or compile it statically.

SCO seems to be claiming that binaries compiled statically on its OS infringe their copyright when copied to another system. This seems logical at first glance -- static binaries do contain their libraries -- but it seems pretty shaky given a closer look. ¹ For one, the whole point of statically-linked programs is that they can easily be copied (and work) on multiple systems. For another, they merely state that they found COFF binaries on AutoZone servers; they do not state that they contained statically-linked SCO code in them.

Additionally, it's difficult or impossible to make any use of a library which has been statically linked into a program. What I mean by this is that if one of AutoZone's apps did link a SCO library into it, it would only ever be useful for that single application. It's not like AutoZone copied this stuff thinking, "ha, we can use their code," while laughing all the way to the bank.

¹ AutoZone has stated the following: "Finally, we have reviewed the relevant OpenServer agreements between SCO and AutoZone. These agreements are still in place and do not include any prohibitions on AutoZone's use of OpenServer compiled code on Linux machines."