decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
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
SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Thursday, June 16 2005 @ 04:12 AM EDT

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, 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. 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 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.


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."


  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 )