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.

Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal

User Functions



Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

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


SCO v. AutoZone - What Are Statically Linked Libraries, Anyway? | 262 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT comments here
Authored by: fat_wombat on Thursday, June 16 2005 @ 04:25 AM EDT
Don't forget to link properly ;-)

[ Reply to This | # ]

Corrections Here Please
Authored by: fat_wombat on Thursday, June 16 2005 @ 04:27 AM EDT
Put them here to find them easier ;-)

[ Reply to This | # ]

Normal Usage
Authored by: Anonymous on Thursday, June 16 2005 @ 04:27 AM EDT
The use of staticly linked libraries is to generate standalone executables. In
this way they are really part of the development tools like the compiler. The
compiler/linker will put some 'library' code into an executable even if it is
not linked to any libraries at all. This is code to initiailise and start a
process when it executes. It is usual for standard libraries to be linked
automatically without listing the libraries explicitly to give basic things like
dynamic memory support, standard I/O etc. If SCO is talking abut all of the
standard system libraries then they would normally be considered part of the
normal development environment as you can't really build code sensibly without
them. It is obviously critical what the license agreements actually said but I
would be suprise dif SCO did not give at least implicit authority to use these
libraries and generate executables as part of the compiler/linker documentation
and as part of the normal operating practice with all of their customers over
many years.

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: codswallop on Thursday, June 16 2005 @ 04:41 AM EDT
For a start, you want a copy of the license from the SCO Universal Development
Kit (UDK), preferably an older one. This is the license that is mentioned in the

IANAL This is not a legal opinion.
SCO is not a party to the APA.
Discovery relevance is to claims, not to sanity.

[ Reply to This | # ]

Here's my analogy...
Authored by: Anonymous on Thursday, June 16 2005 @ 04:51 AM EDT
Complex machanical devices are assembled by building subassemblies deisgned to
function together, and then connecting up the subassemblies.

In the same way, software programs are "compiled" from source code
(detailed designs) to functional form in separate pieces, which are then
"linked" to the final "executable."

The original way to do this linking was to assemble everything needed at once.
Even standard parts were included.

More recently, dynamic linking has been developed. This is like a device
supplied without batteries. Since batteries are standardized, the device itself
can be smaller. Another equivalent would be selling a saucepan without an
attached range. The saucepan is sold assuming the purchaser has some means of
delivering heat to the bottom of it. Since most people have a standard cooking
range, it makes saucepans considerably less bulky.

On the other hand, such "dynamic linking" does depend on a widely
agree-on standard for the user-supplied parts. A device that expects the user
to supply 220 V at 50 Hz will be unhappy with 120V at 60 Hz, and vice versa.
Similarly, a program that is dynamically (i.e. when needed) linked to a shared
library is vulnerable to changes in that library. (Rather like page references
to a reference book could be misleading when the looked up in the second
edition.) Static linking, including all the necessary pieces in the program
itself, is a good way to make the program less dependent on outside factors.

Static linking is also the historical norm, as dynamic linking requires a more
complex process of finding and attaching all the externally-supplied components
before a program can be executed.

Note that every Unix and Unix-like system has come with a large "standard
library" of useful subroutines that are explicitly intended to be used by,
and linked to, the user's own software. Even in modern operating systems, a
versin designed for static linking is supplied as well as the more commonly
used, dynamically linked, shared form.

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: jmc on Thursday, June 16 2005 @ 05:06 AM EDT

Given that we understand the binaries are third party ones, it is possible that some or all of the libraries might have been supplied by the third party. Because they are statically linked, it is hard to say. (It is actually quite hard to generate dynamically-linked binaries on a SCO system that are at all reliable).

I have a number of SCO binaries on my machine which I've built on customer sites, looking at them "what" doesn't help us a great deal as the main "#ident" symbols (which put comments into the binaries) are in all the header files so you have hundreds of "unistd.h 20.5 95/09/27" and the like.

The only stuff I find in the binaries (for OpenServer 5.0.*) relating to libraries are things like:

pmap_gtprt.c,v 4.5 1991/09/20
10:12:50 wmv Exp System V NFS source
pmap_prot.c,v 4.4 1991/01/02 17:55:58 maf
Exp System V NFS source
pmap_comdat.c,v 4.4 1991/01/02 17:59:05 maf Exp System V
NFS source
rpc_dtabsz.c,v 4.5 1991/11/13 13:08:44 wmv Exp System V NFS
rpc_prot.c,v 4.5 1991/09/20 10:20:09 wmv Exp System V NFS source
4.5 1991/09/20 14:07:06 wmv Exp System V NFS source

On Legend most of this stuff has been stripped out.

The dates of all these things are in the early 90s. The libraries with #idents in are mostly to do with YP and NFS which SCO has an even more dubious claim to than usual IMO.

I don't think SCO's lawyers know what they're talking about here so heaven help the judge.

[ Reply to This | # ]

What COFF is
Authored by: Anonymous on Thursday, June 16 2005 @ 05:46 AM EDT
I read this excelent explanation of static libraries and felt that the crucial argument at the end about COFF was glossing over what COFF is. I felt this could potentially weaken the argument, until I looked it up:

Here is a good explanation

[ Reply to This | # ]

Remember that the same rule applies to GPL libaries
Authored by: Anonymous on Thursday, June 16 2005 @ 05:49 AM EDT
If you duplicate a GPL libarary by distributing* a work that's linked against
it, then you need a license to perform that duplication, and the license is the

We expect people to comply with the GPL, and SCO have every right to expect
Autozone to comply with the terms of their license when doing the same thing.
We don't get to argue one rule for us, and one for them. That's SCO's way, not

And so this is going to come down what Autozone's license actually is, what SCO
did and didn't put in it, and what the lawyers on both sides can argue is
implicit and prohibited.

Without seeing that license, all we can do is speculate, but let's be honest
that SCO does, in this specific instance, have a case here, and let it serve as
a warning to all of their current, past and potential customers that what seems
reasonable fair use to you doesn't necessarily seem that way to SCO.

Note that the FSF have clarified that "copy and distribute" in the GPL
means giving copies to third parties. They do not intend the license to require
you to GPL and give away the source to your own code if you link it with GPL
libraries and make copies of the resultant work for your own use, including
making copies for people inside your own organisation. That is what Autozone
have done here, and SCO are punishing them for it and holding them to a far
stricter standard than even the big bad GPL requires.

So the next time someone calls the GPL "viral", feel free to say
"Sure, but it's got nothing on the SCO license."

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Anonymous on Thursday, June 16 2005 @ 06:14 AM EDT
A function in a library might do something like 'evaluate a square root'. Too complicated to be worth putting in the electronics of a processor chip; and yet sufficiently generally useful that programmers shouldn't have to implement it out of building blocks every time they write a program that needs to do it.

When you 'link' a program ... normally done as a stage after compiling it and before leaving it on disk so it is ready to use ... you can either copy the 'square root' function from the library into the program, or mark the program so that the function will be found in the library later on when someone tries to run the program.

The former is 'static linking'; the latter is 'dynamic linking'

In many ways, it's a minor technical detail. If you statically link a square root function, your program can run on a computer which does not have the library installed. If you dynamically link, then suppose the library gets modified (someone figures a faster or more accurate way to work out the square root, or fixes a bug), the user of the program will pick up the modified version next time they run the program.

Horses for courses, really, you cannot say that one way is better than the other. 'Differently good', maybe.

Techies think that squabbling about it is like arguing about how many angels can dance on the head of a pin. 'It does not matter'.

Lawyers, however, might have their own opinions.

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Anonymous on Thursday, June 16 2005 @ 06:17 AM EDT
A statically linkable library *must* be copied when put to its intended use,
because a copy is embedded in any application it is linked with. Thus, any
product conaining statically linkable libraries must come with a license
allowing them to be copied for that purpose. The use of a binary linked with
SCO's statically linkable libraries on linux would only be illegal if the
license which allows you to copy the libraries during link then restricts the
use of *your own program* to SCO's OS.

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: rongage on Thursday, June 16 2005 @ 06:38 AM EDT

Think of "static" vs "shared" libraries in the form of a book...

Say you have the body of your new book, called 'x'. This new book references material from another publication, called 'y'.

If you include the contents of 'y' into 'x' (perhaps, as an appendix), then you have greated a 'static library'. The pieces ('x' and 'y') are attached to each other and will probably stay that way absent major effort. However, if you leave the reference material as a seperate book and just refer to it in your book, then you have created a 'shared library'. Book 'x' still needs/relies on book 'y', yet the two books are seperate entities.

Hope this helps!

Ron Gage - Linux Consultant
Pontiac, Michigan

[ Reply to This | # ]

Another take: the difference is the copy time
Authored by: DaveJakeman on Thursday, June 16 2005 @ 07:43 AM EDT
When a program is built using a static library, copying of library code takes
place. The code generated from the program source is bundled together with code
copied from the static library, both being stored in the executable file (the
bit that is run). So the copying of parts of the static library occurs as the
program is being built. This copying is an automatic, intentional stage of the
build process.

When a shared library is used, there is no copying of library components. But
in order for the program to run on another computer, a copy of the shared
library would need to be present on that computer.

To get the "statically built" program running on another computer, you
would only need to copy the executable file onto the target system and run it.
The migration might be a long time after the program was built, so it might not
be apparent during the migration that the executable file contained code copied
from the static library.

In the case of the shared library, it would be possible to transfer the
executable file to another computer without transferring the shared library.
But the program would only work if a replacement shared library, of identical
functionality (written by someone else) were present. Otherwise, you would need
to knowingly copy the original shared library onto the target computer for the
transferred program to work. Any potential copyright issues would naturally
become apparent at that time.

In the case of the static library, the right to copy the executable file would
be dictated by the terms of the license. And the only way to eliminate the
copied code would be to rebuild the program from its source file on the target

Should one hear an accusation, first look to see how it might be levelled at the

[ Reply to This | # ]

Linkers & Loaders
Authored by: Anonymous on Thursday, June 16 2005 @ 07:48 AM EDT
Your one-stop-shop for everything Linkers and Loaders (amazon)

[ Reply to This | # ]

Beware all ye who develope on SCO platform !
Authored by: Anonymous on Thursday, June 16 2005 @ 07:57 AM EDT
Your product may never run on anything else !!!

If you keep on developping on SCO, you might lose your rights to distribute your
own code.

[ Reply to This | # ]

Statically Linked Libraries, by example?
Authored by: kb8rln on Thursday, June 16 2005 @ 07:58 AM EDT

Let define what libraries are and why they exist.

Let go back to a simple computer like a Commodore 64. If I wanted to write a program to the say "Hello". Here is the code in basic.

10 print "Hello"
20 end

Now if I did not want to use basic. I could call a kernel subroutine like this.

lda #"h" ; load letter h.
jsr stdout ; put it on the screen.
jsr stdout
lda #"l"
jsr stdout
lda #"l"
jsr stdout
lda #"o"
jsr stdout
; return to os

I really would not do it this way, just wanted to make it simple to understand.

Now printing to the screen is needed no mater what platform you are using. In C there is a stander library that can be called on Windows, Linux, UNIX, OS2 , etc... Because of this, this code will work on any system that has a C compiler. This make the code platform indepented, to the dismaded of tSCOg.


main ()

Now because I used stdio.h (stander input/output) I do not have to care what type of display you have (VGA, SVGA, XVGA or just a teletype machine in the corner of your house) the program will still work if the stdio libary is written right. Since every program need to print to the screen, to save ram the OS just load the share libary once so any program can call it. Now what happen if you compile a program?

Well you make object code (I call this the working code with the logic code for the program) then you link it to the libaries and executable database of the platform that you want it to run on.

Note: I have develop and compiled programs under Linux that links to libaries so they can run on the Windows OS. It funny to see GCC make an EXE file using all opensource.
The COFF/PE(UNIX/NT) (Note: SCO was the base OS for Windows NT 3.1 - I was in the BETA program. PE stander for Portable Executable File Format and CO is Common Object File Format.), EXE*(DOS,Windows), ELF(Linux), etc excutables formats and what it really is in plain english. All these excutables headers are is a database format to talk to the OS. The compiler add them doing the linking stage. The basic information in them is: Share libraries needed to run, amount of ram needed, data space, start of program, debuging information, tables to talk to share libraries. There is more to tell just trying to keep is simple. What tSCOg is saying because your have a database table so you can run on our platform it belongs to us. The reason to use static link libraries you do not need to worry if the library of the version that you need it there. This allow your binaries programs to run on wider range version of the OS. Case and point like RedHat 7,8,9,Enterprise 1,2,3.
I hope this help
Richard Rager

Director Of Infrastructure Technology (DOIT)
Really this is my Title so I not a Lawyer.

[ Reply to This | # ]

An important difference with Statically Linked Libraries...
Authored by: raiford on Thursday, June 16 2005 @ 08:29 AM EDT
It is important to understand that static libraries exist in two forms:

* As an object file (ready to be linked with an application at compile time)

* As part of an application in compiled form

When a static library exists as an object file, all of the functions are
available to applications (as long as you have the header file(s) for it) that
links to it at compile time. After an application has been compiled (and the
library statically linked to it), the application only contains the parts of the
library that it uses! It does NOT contain the other bits that were left


[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Anonymous on Thursday, June 16 2005 @ 08:50 AM EDT
There's also nothing technically to stop you 'unlinking' a computer program ... it's a bit like unpicking the stitches on a shirt, maybe with a view to sewing on different sleeves, or using the existing sleeves for an as-yet-undreampt-of purpose.

Nothing to stop you from converting a library between 'static' and 'shared' forms.

Nothing to stop you from using a computer program for a different use than originally intended; for example the 'Hello World' program can be used to say 'Hello World'; to test the correctness of a compiler; to teach programming to a novice; and so on.

[ Reply to This | # ]

Windows Equivalent
Authored by: DL on Thursday, June 16 2005 @ 09:26 AM EDT
The same works in Windows, but the terms are different.

In Windows, dynamically linked code is placed in DLL files. That's what DLL
stands for: Dynamic Link Library.

Statically linked code is placed in the program's EXE file.

Windows programs use a mix of the two. All(?) of the Windows functions (API)
must be accessed via DLLs, and many third-party libraries too, but it's up to
you whether you link your own code dynamically or statically.

That's the simple explanation. It leaves out a bunch of special cases.


[ Reply to This | # ]

Shared heaven v.s. DLL hell. GPL v. LGPL
Authored by: tz on Thursday, June 16 2005 @ 09:45 AM EDT
On Windows, a DLL is a shared library. Windows managed to get this wrong too,
and someone else can provide a full rant on the problems with their idea of
shared libraries.

But many people are (usually through some cybertrauma) familiar with DLLs on
Windows so I thought I would mention that they are just shared libraries.

These generally provide functionality necessary for many programs, e.g. a math
library to compute sines and cosines, something to draw lines or circles.

A shared library works something like web pages where it would provide a
hyperlink to a reference so people reading your article can go read the linked
article (and any updates or corrections to that article could be made
independently), v.s. quoting the article as a whole on your page - that would be
"static linkage".

And that is where a copyright or licensing problem might come up. If there was
a shared SCO libc and a shared GNU libc, and you copied the program over, and
they were compatible so it worked on both, there would be no problem. But if
you "statically link", you would be grabbing portions of the SCO libc
and including them in your program executable image. Those portions would
retain the license or copyright that applied to SCO's libc. Normally it is easy
just to copy things over to Linux (or BSD, etc.) and rebuild them, it just has
to be done.

Also note there is the GPL, and the LGPL for that reason - if you just link to
GPL code, or use GPL include or macro files, or use a GPL program to generate a
program (which almost by definition will write out parts of itself), is the
result GPL? I'll let others go into detail if they want, but the general idea
of the LGPL is to allow for non-GPL code to use GPL libraries and code
generators without the full GPL requirements of releasing the source just
because it touches (links to, but does not directly include) GPLed code (the
typical MS "GPL is a virus" claim).

[ Reply to This | # ]

Statically Linked Libraries, but probably useless
Authored by: darkonc on Thursday, June 16 2005 @ 09:48 AM EDT
The article mentions that statically linked libraries are more portable than dynamically linked, but despite this fact, the SCO static binaries that were found on Linux were most probably useless there.

Statically linked libraries depend on the kernel being built in a certain way and -- as other techies pointed out early on in the SCO code debacle, UNIX and Linux are different enough internally that UNIX code would be so hard to toss into a Linux kernel that you'd be far better off to just rewrite it from scratch.

Since static libraries are built with knowledge of that internal structure, they're unlikely to survive the transition from SCO to Linux (unless there's infrastructure loaded onto those machines to support the use of those binaries -- something like the SCO version of WINE).

It would be rather like pulling a (english speaking) french lawyer into a US courtroom and not bothering to tell him that the rules had changed. Yes, he'd still be in a courtroom, but chances are that he'd get laughed out of court unless he was really lucky in terms of having an issue that translated directly from the Napoleonic system to the Common Law system.

Powerful, committed communication. Touching the jewel within each person and bringing it to life..

[ Reply to This | # ]

The Compiling and Linking Process
Authored by: DL on Thursday, June 16 2005 @ 09:50 AM EDT
The process goes something like this:

You compile your source code. This converts your (theoretically) human-readable
text file (.c, .pas, .cpp, etc) into machine code and puts it in an "object
file" (.obj on Windows, .o on Unix/Linux). The code in this file would run
on your computer, but calls to any functions not created in your source code are
left unresolved. The compiler creates the list of these unresolved calls and
places them in the object file.

Once all of your source code have been compiled, you link it. You provide the
linker with a list of object files and libraries, and it attempts to match
unresolved calls in the object files with a) each other and b) with the library
files. If all the unresolved calls can be matched, the linker creates the final
program files (.exe or .dll on windows, no extension on Unix/Linux for programs
and .so for libraries).

This is another simplication of the process that leaves out all sorts of
configuration work, trying again (and again), hair pulling, physical violence,
and unkind words of a sort not permitted on this site.

Just because you've done all of this, and ended up with an executable program
does not mean that the program is going to actually run let alone do what you
expected it to do. Getting it to compile and link is the easy part. Getting it
to work right is another matter entirely.


[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Kevin on Thursday, June 16 2005 @ 10:12 AM EDT

There actually were static shared libraries on several platforms, but I don't recall whether SCO ever used them. (Seeing the phrase in the briefs, though, makes me suspect that perhaps SCO did.)

They worked a bit differently from dynamic shared libraries, the kind used on virtually all modern systems. Let me try to explain the difference.

All Unix systems that I'm aware of use a "flat" address space (or nearly flat - the original PDP/7 and PDP/11 Unix had separate "instruction" and "data" segments). "Flat" refers to the fact that a program's memory occupies contiguously-numbered memory locations, and there is no segmentation imposed on it by the hardware. (By contrast, Multics had an address space divided into a great many segments - in fact, all files on the system were segments of its enormous virtual memory.)

A shared library is brought into a process, generally when the process is initialized, by allocating a block of the flat memory that is large enough to hold it, and mapping the instructions and data from the library into that block. There may actually be more than one block; it's pretty typical to have a library organized into four or five pieces: program instructions, constant data, variable data, uninitialized data, string pool, and so on.

When I say, "mapping" the file into the block, it does not, generally speaking, mean simply reading the file. The instructions and constant data within the file do not need to be copied - in fact, one of the major advantages of shared libraries is that there is no need to copy them. Instead, the machine's virtual memory is organized so that every process using a shared library actually has the same physical memory assigned to that block of virtual memory locations; they all share the same copy of the library, hence the name, "shared library."

Once the shared library has been mapped, the "dynamic linking" process has only begun. There is a following step where the references within the calling program to the code and data in the shared library have to be resolved to the actual memory locations. A dynamically linked shared library has, as part of its file structure, a table of the named objects that it contains and the memory locations at which they reside. A program using the shared library has a table of the names of the objects it uses and the memory locations that contain references to them. The dynamic linker's job is to pair off the two to allow the program to call the library.

This whole scheme depends on "position independent code" inside the shared library. Position independent code uses special features of the hardware (often called "base register addressing" or "program counter relative addressing,") so that no memory addresses actually appear in the code within the library; they are all designated relative either to the location of the code that refers to them or relative to the base of the library in memory. In this way, the code can run from whatever memory location it finds itself. It does not need to be modified to run at a different location. All the processes that use the library can therefore map it into memory in different places, and everything will still work.

Static shared libraries are ones that run without the services of a dynamic linker, and do not require position independent coding. Instead, they are coded to run at a fixed position in memory. Every process that uses a static shared library must block out its memory locations in advance, and the static linker can resolve all the references between the program and the library. All that needs to happen at run time is that the library gets mapped into the appropriate locations.

There are some design points between the two extremes. For instance, Windows has dynamically linked libraries that are (mostly) unshared - each process gets memory locations for its own copy of the library (hence, the libraries do not need to be position independent), but the references between the calling program and the library are not resolved until run time, and the calling program's image on the disc does not contain the library. (This is a trifle oversimplified - Windows DLL's can behave as either shared or unshared, or any mix of the two, depending on details of how they're compiled.)

The advantages to static shared libraries are that they initialize faster (no dynamic linking needed), they run faster on some machines (because position independent code is less efficient on some architectures), and they can be used on machines where position independence is inconvenient or impossible. The disadvantages are legion. They mostly stem from the fact that the memory locations for shared libraries must be planned in advance. No two shared libraries that could ever occupy the same memory locations can be loaded in the same process, ever. This usually means that an effort is made to allocate the memory locations (manually) system-wide. Moreover, a static shared library usually will have up to several times its actual address space assigned to it; the reason is that the code in future versions of the library may be bigger, and so there needs to be headroom so that a newer version will not collide with some other library. All this bookkeeping is a nightmarish job, which is why we don't see static shared libraries very often.

What mystifies me is the briefs' statements that the COFF files found on AutoZone's Linux systems "contain" the "static shared libraries." The whole point of shared libraries is that the calling program need not contain the library, but can find a single shared copy at run time. The shared libraries are also stored as COFF files (on systems that use COFF), but in a real sense, those files are the libraries, and in any case, the briefs are unquestionably referring to the calling programs.

One possibility, I suppose, is that SCO is claiming exclusive rights over the mapping between symbolic name and memory address within the static shared library. This mapping is somewhat arbitrary - a static shared library typically begins with a "jump table" where the addresses of procedures within the library are stored, and then associates the names with locations in the jump table, so that its export list becomes, "procedure a is at address 0, procedure b is at address 8, procedure c is at address 16, ..." There is no need for the jump table to be organized in any particular way, although it needs to be the same between one version of the library and the next; often, the names in the first version are listed in alphabetical order, and then the names in later versions are added to the end haphazardly. Since two development cycles of the same functionality would be unlikely to come up with the same ordering, SCO could, I suppose, claim that the ordering is a creative work, and that the calling program is making unauthorized use of it.

This is directly analogous to SCO's laying claim to the definitions in <signal.h> and <errno.h> -- an attempt to copyright the fact that a given symbol is assigned a certain arbitrary number. It has a precise counterpart in the Feist case - the mapping between procedure and jump table location is exactly analogous to the mapping between a subscriber's name and a telephone number in the telephone directory.

This is enough of a stretch, though, that I think the lawyers who referred to "static shared libraries" simply made a mistake. Ordinary, unshared, static libraries, are "shared" in the sense that more than one program can incorporate them; I suspect that the lawyers simply didn't realize that "shared library" is a term of art. Given that, I further speculate that the lawyers may not understand what a static library is, either, or that the license for static libraries typically allows redistribution (otherwise, static libraries would be of no use to an independent software vendor).

As I've written here on Groklaw before, non-redistributable libraries and object code were once the norm in the microcomputer industry, but the marketplace in the early 1980's came to demand redistributable ones. If SCO actually had "no redistribution" license terms on the libraries that shipped with its developers' kit, it would greatly surprise me.

73 de ke9tv/2, Kevin (P.S. My surname is not McBride!)

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Anonymous on Thursday, June 16 2005 @ 10:25 AM EDT
Static object files or libraries are in exectly the same position as fonts; they
HAVE to be copied! Being copied is what they are for, it is the esential
character of a static object as oposed to a `shared' or 'dynamic' one.

Fonts are the best equivalent I can think of, and they are the odd case in law
as they can not be copyrighted, because their purpose is to be copied.

[ Reply to This | # ]

oldSCO by their actions waived any right to complain
Authored by: gdeinsta on Thursday, June 16 2005 @ 10:52 AM EDT

It is important to realize that, in the beginning, statically linking a program did not mean that it would operate on some other version of Unix, even one using the same type of central processor. Hence to begin with application programs compiled and linked on SCO Unix could not run on, say, NCR Unix, even though both forms of Unix ran on Intel x86 family processor.

At some point the makers of x86 Unix systems got together and agreed on a technical standard to make application program cross-operable. This was quite a while ago, back in the days of Xenix, early to mid 1980s. At that time Xenix at least did not even allow dynamic linking; when I used it static linking was all we had.

OldSCO was one of the companies that joined in that effort. OldSCO also advertised this as a feature of their Unix. Since static linking was the norm, and OldSCO advertised this as a feature, it seems to me they waived any right to complain - even if they never gave explicit permission.

[ Reply to This | # ]

SCO v. AutoZone: the case is over
Authored by: elcorton on Thursday, June 16 2005 @ 11:07 AM EDT

Let's not lose sight of the most important fact about this case: it's over.

By declining to move for a preliminary injunction, SCO implicitly acknowledged that it has no likelihood of prevailing at trial (the standard under which such relief is granted.) SCO tried to disguise this fact by mischaracterizing the court's order staying the case; viz., that the stay somehow inhibited SCO from seeking an injunction against copying the Linux kernel. It did not. SCO didn't seek such an injunction because it doesn't want the judge to evaluate its claims.

The stay will remain in effect until SCO is in receivership, and the trustee will drop the case.

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Anonymous on Thursday, June 16 2005 @ 11:08 AM EDT
You can own your own hammer and carry it with you all the time, static library,
or you can borrow one as you need it from the community tool chest, dynamic


[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: seanzig on Thursday, June 16 2005 @ 11:43 AM EDT
I've seen a couple of good analogies for static vs. dynamic linking posted here,
including books and batteries.

I think an even better analogy might be self-assembled furniture; you know, when
you buy a cabinet or a table from e.g., Wal-Mart, and it comes as a kit that you
must put together yourself.

In this case, I'm thinking of the assembly instructions as the "executable
program," the pieces of wood and screws as "input data," and a
table as the "output." Obviously, you are the "CPU" that
executes the instructions.

The "libraries" are the tools you need to complete the job. You are
often expected to have some of those libraries, like a screwdriver, for example.
That would be like a dynamic library. It's nice, because they don't have to
ship screwdrivers with every furniture kit, and everyone should have a
screwdriver. The down side is that maybe someone actually doesn't have a
screwdriver, or their screwdriver has the wrong head.

However, some of these furniture kits come with tools - the static libraries.
I've seen them come with "Allen wrenches," little L-shaped rods that
can be inserted into a screw with a hexagonal-hole in the head. Not everyone
has every size of Allen wrench for any job, and they're so cheap to make, it's
best just to include it.

Let's take it a step further. What if you need a very special, complex tool to
assemble your new special piece of furniture. What if the same company that
produces the furniture kit, created this tool just for this kit, and they even
patented it. There is no chance you'll have the tool already. They give you
the tool in the kit, but of course, they don't include the design plans for
making the tool (the "source").

Things become complicated though, since you are of above-average intelligence,
and you figure out how to use the tool to do other things. The company finds
out and sues you for using their patented tool beyond its intended use without
their permission.

You would say that, since you bought the furniture kit, you bought the tool too,
and it's yours.

The big question is, does the original box that contained the kit, have a
license agreement on it that states that you will only use the tool to assemble
the furniture? Does it say that you will discard the tool when you are

[ Reply to This | # ]

SCO v. AutoZone - What Are Statically Linked Libraries, Anyway?
Authored by: Anonymous on Thursday, June 16 2005 @ 12:30 PM EDT
My overly simple description:
Programs and libraries must eventually come together to produce a functional

If this occurs at compile time the library becomes part of the object file. This
is "static". (compile time linking)

If the coming together occurs at the time the object is load ed in memory, the
library is "dynamic". (load time linking)

Static includes a copy of the library dynamic does not.

I have the SCO development system,and have looked at the license... It doesn't
say much.
run development on one system.
no copying of development system.
copyright SCO....

No reference to running on other systems at all.
HOWEVER It can compile code for MS-DOS (yeah it's old) Now since SCO Never
released a DOS and the complier will compile and link for DOS. It would appear
to me,that running on "non SCO" system was an inherent feature,and not
prohibited by the license.

It's a pretty safe bet that DOS uesrs won't have a SCO license of any type.

[ Reply to This | # ]

  • BUT ... - Authored by: Anonymous on Thursday, June 16 2005 @ 01:42 PM EDT
Implied license
Authored by: Nick Bridge on Thursday, June 16 2005 @ 01:49 PM EDT
IANAL - This is not legal advice.

I'd suggest that, absent any specific terms, there is an implied license to copy
and distribute any statically linked code included by the development tools.

This is because the libraries included with the development environment are
designed and provided for specifically that purpose.

If you compile and link a program in a development environment, then load the
program on production systems, but exclude the libraries, they won't work.

[ Reply to This | # ]

Other legal contexts for static vs shared libraries
Authored by: cffk on Thursday, June 16 2005 @ 05:23 PM EDT
In order to understand better the implications of shared vs static libraries in the context of the SCO-Autozone legal dispute. It might be worth researching the standard legal practice of companies that sell just libraries. I'm thinking of companies such as IMSL, NAG, Disspla, which sell (or used to sell) software for mathematics and graphics. In the pre-PC era, this functionality was usually sold as a library that you linked your good old FORTRAN code against.

Aside from the "standard" usage of the library (you write your code and you run it), the license then needed to deal with two other situations:

  • You create a code and sell the executable to others.
  • You create a code and then need to run it after your license has expired.
I believe that most reasonable software vendors allowed for both of these by requiring that the code be statically linked.

Thus for "standard" usage you used the shared library and the library needed to reside on a local disk when the code ran. For the other usage of your code which takes place "outside" the license (either on a machine belonging to a third party or on your machine after you've terminated your license and deleted all the libraries), then the library is not available and the subset of functionality of the library that the code needs resides within the executable.

As I recall this was a more-or-less accepted way that libraries were licensed. The ability freely to run the statically linked code was part of what you bought when you licensed the library. The library vendor was protected from being ripped off because

  • the statically linked code only contained the handful of routines required and
  • it was inconvenient to extract this code and use it in another code.

I don't have up-to-date knowledge on the licenses that library vendors currently use. But perhaps some readers do?

[ Reply to This | # ]

Marc Williams Coherent: A COFF development environment
Authored by: Anonymous on Friday, June 17 2005 @ 05:39 AM EDT
Hello all, I remember that one advantage of the now dead Coherent was, that it could generate COFF binaries compatible with SCO operating systems. I don't know whether this is important in the current context, but developing on Coherent and deploying on SCO Unix was one of there sales pitches.

[ Reply to This | # ]

Re: More patent madness
Authored by: Anonymous on Friday, June 17 2005 @ 08:20 AM EDT
It's because software patents allow the patenting of abstract concepts, wheras a
hardware patent only covers the particular implementation. I see hardware
patents as being the equivalent of copyright in software, and software patents
being something far further reaching.

[ Reply to This | # ]

Redistributable Code
Authored by: jbolden1517 on Sunday, June 26 2005 @ 09:30 AM EDT
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.
Pamela I think you are missing a crucial point here regarding redistribution rights for compilers. Compilers almost always have very generous redistribution rights for their output. To pick some standard examples:
Microsoft/Visual Studio) Redistributable Code. Microsoft grants you a nonexclusive, royalty-free right to reproduce and distribute the object code form of any portion of the Product listed in REDIST.TXT....
Borland/Delphi) If you are a licensed user of Delphi 4 Client/server or Enterprise, redistributable runtime packages include the following...
Intel/MKL) with your purchase of the Intel MKL product (and updates through the support service subscription), redistribution rights are provided. The static library files and the dynamic library files can be redistributed as outlined in the end-user license agreement.... In general, the redistributable files include the linkable files (.DLL and .LIB files for Windows*, .SO and .A files for Linux*). With your purchase of the Intel® MKL product (and updates through the support service subscription), the redist.txt file outlines the list of files that can be redistributed.
Sun/Java) License to Distribute Redistributables. Subject to the terms and conditions of this Agreement, including but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non- exclusive, non-transferable, limited license without fees to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables")
If you can get a copy of Unixware I'm sure the C compiler has a similar clause. In other words is not that a statically linked library isn't a copy or isn't subject to copyright but rather that AutoZone has specific permission to copy the particular files that they are copying as part of their compiler license.

[ Reply to This | # ]

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 )