rtld + static linking

[Terry Lambert]

Marcel Moolenaar wrote:
> On Thu, Nov 27, 2003 at 03:41:14AM -0800, Terry Lambert wrote:
> > > If you can get gcc and binutils to add the necessary support, then
> > > we can talk further. Until then it's academic.
> >
> > I think there are political reasons for not doing this.  The
> > number one reason would be that you could load GPL'ed code as
> > a module into a non-GPL'ed program, and then use it without
> > neding to change your own license to GPL.
> 
> The use of dlopen() does not circumvent that you're creating a
> modified version. The GPL-incompatible code and the GPL code do
> not communicate at arms length. Hence, the GPL-incompatible code
> is to be relicensed if the modified work is to be distributed.

No.  IF you separately distibute your code and the GPL'ed module
code, AND you have an alternate user of the interface, THEN you
can distribute the code at will without GPL'ing it, even if the
intent is to link against the GPL'ed code at runtime.  Be, Inc.
did this with GPL'd Linux device drivers, and the one lawsuit the
FSF began to bring on the basis of a GPL'ed library was resolved
when the authors of the original code provided their own non-GPL'ed
library, thus putting the GPL'ed code at arms length, legally, with
regard to whether or not the combined code was a derivative work of
the GPL'ed code.

Like it or not, being able to dlopen a GPL'ed module means that you
can circumvent the intent of the GPL.  In fact, there are a number
of PAM modules that are GPL'ed (go ahead and check).


> Alternatively, ask the license holder for an exception or see if
> the library can be relicensed under the LGPL.

Why ask, when you can simply circumvent?  The only thing it would
buy you is the ability to not redistribute "modularized source",
which is of questionable benefit.

> From a GPL licensing point of view dlopen() is no different than
> static linking.

Incorrect.  The linking occurs at the behest of the person running
the program, rather than at the behest of the person distributing
the program,.  As distributed, the program and the module together
constitute a "mere agregation", and therefore the program itself is
not subject to the module's GPL nature.


> > Well, it specifically mentions being able to do something like
> > linking libc to libresolv, so that you implicitly get the resolver
> > library when you explicitly link in the C library. That doesn't
> > work with static linking of ELF binaries, so I think we can either
> > say static linking is completely broken and needs to be fixed before
> > it is allowed to be used, or static linking is undefined by the ELF
> > standard.
> 
> Recording dependencies in ELF files is specific to dynamic linking.

No, it's specific to all relocatable ELF objects, at least according
to the specification.

> In fact, there's nothing that you need to add to ELF headers or
> sections to make static linking work. It's irrelevant to an ELF
> specification. That's why it's not mentioned. Dynamic linking needs
> special headers and/or sections in the ELF file to make it work.
> 
> I don't think you can infer from the ELF specification that static
> linking is undefined.

I don't think that you can infer that it's defined.  8-).  Anything
that's not defined is, by definition, undefined.

-- Terry