Dynamic linking, was: Re: Dispelling BSD License Misconceptions

[Chuck Swiger]

On Jan 25, 2007, at 5:52 PM, Ben Tilly wrote:
> On 1/25/07, Lawrence Rosen <lrosen at rosenlaw.com> wrote:
[ ... ]
>> Would someone here please explain how the mere act of statically  
>> linking,
>> which may automatically and without my interference take some  
>> bytes from
>> program A and some bytes from program B and combine them in a  
>> memory image,
>> result--without more--in a creative work suitable for independent  
>> copyright?

If you include all of someone else's copyrighted work into a new  
work, can the new work be considered "independent"?

Note that statically linking a program is not an "automatic" action,  
at least as far as the developer is concerned; a developer explicitly  
commands the compiler toolchain (perhaps via make, ant, or a fancy  
IDE) to produce an executable program by combining the program's  
compiled object modules with libraries to resolve all published  
global symbols found from any object being linked into the final result.

If there are unresolved symbols, the resulting output is not  
executable without additional linking (whether dynamic or static).   
Systems which support dynamic linking permit an executable to run so  
long as any unresolved global symbols can be resolved by dynamically  
linking in, at runtime, the necessary additional dynamic shared  
libraries (called .dll's [Dynamic Link Libraries] or .so's [Shared  
Objects]).

Dynamic linking happens automatically as far as the end-user running  
the program is concerned; however, the developer must still  
explicitly perform a linking stage which leaves dynamic relocation  
entries and shared library load commands even when creating a  
dynamically linked program.

[ ... ]
> However the complete compiled result is a single program.  You could
> try to argue that this is "mere aggregation", but I think you'd have a
> hard time of it.  (For one thing it isn't straightforward to determine
> what parts of the final result belong to the GPLed piece and what
> parts do not.  With mere aggregation that should be easy.)

With the appropriate parts of the compiler toolchain (ar, nm,  
objdump, etc), you can actually examine the contents, symbol headers,  
and timestamps of libraries, object files, and executables.  I would  
agree that the information is not readily accessible to a normal  
user, but the information is present and interpretable within certain  
limits (such as whether the executable has been stripped).

Without the right tools, even a normal filesystem is just a big  
collection of bits; the level of complexity required to understand a  
foreign filesystem's directory hierarchy is not significantly  
different from understanding a foreign binary executable format (ie,  
examining Dwarf or a.out or PE-COFF on a ELF-based system)...

>> I can't find any principled distinction in a copyright sense  
>> between static
>> and dynamic linking, although either kind of linking might be an  
>> indicator
>> of an intention to create a derivative work. You don't create a  
>> derivative
>> work unless you base one creative and expressive work on another,  
>> which you
>> can do equally easily (and equally hard) with static and dynamic  
>> linking.
>
> In an abstract copyright sense I agree with you, but I believe that
> the GPL's terms draw a practical distinction.  However (and this will
> be interesting to watch going forward) when you throw in various
> virtualization technologies, the GPL may have some unexpected
> consequences.  For instance suppose that I snapshot an image of a
> running system and copy that snapshot elsewhere.  If that snapshot
> included GPLed programs, does the whole snapshot have to be GPLed?

My first take would be no-- a disk image or snapshot falls under GPL  
clause 2:

"In addition, mere aggregation of another work not based on the  
Program with the Program (or with a work based on the Program) on a  
volume of a storage or distribution medium does not bring the other  
work under the scope of this License."

> Another case of interest is the web.  Suppose that I write GPLed
> software that produces a website.  There is no question that the web
> pages that I display include lots of stuff that is part of my
> codebase.  I think they should therefore be GPLed.  And every time you
> fetch a page, a derivative work has been distributed.  Does every
> page, therefore, need to include a copy of the GPL?

We'd discussed this back in the thread "GPL for JS libraries (Was:  
Re: Redefining GPL?)"  Care to pick the thread up from Message-Id:  
<8A1B049B-8C04-4857-A301-98FB1FD6B0E0 at codefab.com> or shall I excerpt  
the end of that message...?  :-)

-Chuck