MIT license vs Dynamic Linking

[Mark Wells]

On Wed, 17 Nov 1999, Andrew J Bromage wrote:

> One could argue that the interface/import file is a derived work of the
> original source, but it'd be hard to argue that a special interface or
> import file is "copied into the executable" in such languages.  Taking
> the example to absurd extremes, as is the custom at this point in any
> such example, does what consitiutes a "derived work" now depend on how
> the compiler performs its job?  Could it vary from compiler to compiler
> for source written in the same language, depending on whether or not 
> your compiler uses textual inclusion to implement module importing?

I don't suppose it would be possible to argue that the GPL's 'derived
work' rules take effect at link-time rather than at compile-time, would
it?  That is, if you're just writing code that's eventually going to link
to a GPL'd library, it doesn't become a derived work until you link it?

This seems like just about the only interpretation that works for dynamic
linking, runtime linking, the existence of both GPL and non-GPL
implementations of the library, and all the other pathological cases we've
invented.

But it's a bit of a problem because the GPL requires source distribution,
and it's plausible that the person linking the program against a GPL'd
library wouldn't even have the source code.

> > RMS' law school instructor argues that dynamic linking is a device to
> > deliberately circumvent copyright law, and thus should be considered the
> > same as static linking. That interpretation could win in court, or not.

That's the kind of thing that Java programmers and other legalists who are
obsessed with 'control' would worry about.

> Strange, I thought it was a device to control use of system resources. :-)

And to allow bug fixes and enhancements in libraries to propagate up to
all the programs that use them, without having to relink everything.
That's pretty important.