The SCO Report Regarding Discovery in the AutoZone case talks a great deal about statically linked libraries. Reading that Report, I kept thinking that I surely hope the judge knows some tech. Naturally, that made me start to hyperventilate, because there are many judges who do not understand technical topics.
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,
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 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
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.
1 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
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
1 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."