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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"