|
|
| 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."
|
|
|
|
| Authored by: fat_wombat on Thursday, June 16 2005 @ 04:25 AM EDT |
| Don't forget to link properly ;-) [ Reply to This | # ]
|
| |
| Authored by: fat_wombat on Thursday, June 16 2005 @ 04:27 AM EDT |
| Put them here to find them easier ;-) [ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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
depositions.
---
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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
source
rpc_prot.c,v 4.5 1991/09/20 10:20:09 wmv Exp System V NFS source
xdr.c,v
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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
GPL.
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
ours.
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 | # ]
|
- Yes, but what compiler were they using? - Authored by: jplatt39 on Thursday, June 16 2005 @ 06:45 AM EDT
- GPL vs. LGPL - Authored by: Anonymous on Thursday, June 16 2005 @ 07:29 AM EDT
- GPL vs. LGPL - Authored by: Ninthwave on Thursday, June 16 2005 @ 07:31 AM EDT
- GPL vs. LGPL - Authored by: Anonymous on Thursday, June 16 2005 @ 08:10 AM EDT
- GPL vs. LGPL - Authored by: Anonymous on Thursday, June 16 2005 @ 01:00 PM EDT
- GPL vs. LGPL - Authored by: Arker on Thursday, June 16 2005 @ 01:13 PM EDT
- GPL vs. LGPL - Authored by: Anonymous on Thursday, June 16 2005 @ 02:10 PM EDT
- GPL vs. LGPL - Authored by: Christian on Thursday, June 16 2005 @ 03:34 PM EDT
- NO!!!!!! - Authored by: Anonymous on Thursday, June 16 2005 @ 07:14 PM EDT
- GPL vs. LGPL - Authored by: Arker on Thursday, June 16 2005 @ 08:17 PM EDT
- GPL vs. LGPL - Authored by: Anonymous on Friday, June 17 2005 @ 04:25 AM EDT
- GPL vs. LGPL - Authored by: Arker on Friday, June 17 2005 @ 08:32 PM EDT
- GPL vs. LGPL - Authored by: Anonymous on Saturday, June 18 2005 @ 04:57 AM EDT
- GPL vs. LGPL - Authored by: Anonymous on Friday, June 17 2005 @ 03:43 AM EDT
- Parent is seriously misleading - Authored by: Anonymous on Thursday, June 16 2005 @ 08:51 AM EDT
- GPL vs. LGPL - Authored by: DL on Thursday, June 16 2005 @ 09:32 AM EDT
- I think that's incorrect - Authored by: Anonymous on Thursday, June 16 2005 @ 10:54 AM EDT
- LGPL not GPL - Authored by: Anonymous on Thursday, June 16 2005 @ 05:11 PM EDT
- LGPL not GPL - Authored by: Anonymous on Thursday, June 16 2005 @ 08:04 PM EDT
- Oops - Authored by: Anonymous on Thursday, June 16 2005 @ 08:06 PM EDT
- GPL libraries - Authored by: Anonymous on Thursday, June 16 2005 @ 10:32 AM EDT
- GPL vs. LGPL - Authored by: seanzig on Thursday, June 16 2005 @ 11:02 AM EDT
- GPL vs. LGPL - Authored by: Anonymous on Friday, June 17 2005 @ 12:10 PM EDT
- Autozone does claim their license allows this (n/t) - Authored by: Anonymous on Thursday, June 16 2005 @ 08:14 AM EDT
- So is it or is it not permissible to develop proprietary applications that run under Linux? - Authored by: dilireus on Thursday, June 16 2005 @ 11:41 AM EDT
- The second-last paragraph is the only relevant one in parent post... - Authored by: artp on Thursday, June 16 2005 @ 02:54 PM EDT
- CLIB is LGPL (nt) - Authored by: Anonymous on Thursday, June 16 2005 @ 04:40 PM EDT
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
LPI1, MCP, A+, NET+
Pontiac, Michigan [ Reply to This | # ]
|
| |
| 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
system.
---
Should one hear an accusation, first look to see how it might be levelled at the
accuser.[ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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.
lda
#"e"
jsr stdout
lda #"l"
jsr stdout
lda #"l"
jsr stdout
lda #"o"
jsr stdout
rts
; 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.
#include
main ()
{
printf("Hello");
return
0;
}
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
Penguinman.com---
Director Of
Infrastructure Technology (DOIT)
Really this is my Title so I not a Lawyer.
[ Reply to This | # ]
|
| |
| 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
unused.
Jon[ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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.
---
DL[ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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.
---
DL[ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
library.
Robert[ Reply to This | # ]
|
| |
| 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
finished?
[ Reply to This | # ]
|
| |
| 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
program.
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
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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")
etc...
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 | # ]
|
|
|
|
|
