What is Copyleft?

Ian Lance Taylor ian at airs.com
Fri Feb 23 22:51:56 UTC 2001

Dave J Woolley <david.woolley at bts.co.uk> writes:

> > So, since glibc is available as a dynamic library, most uses of glibc
> > do not conflict with the LGPL.  The only way to conflict would be link
> > against the static version of glibc and distribute the resulting
> > binary without distributing the unlinked objects.
> 	[DJW:]  
> 	But the whole point of this thread is that the FSF
> 	consider running ld against dynamic libraries to 
> 	create a derivative work, even though the bulk of
> 	the library is only accessed at run time.

Sure, and that is a problem if the library is licensed under the GPL,
but it is not a problem for a dynamic library licensed under the LGPL.
The LGPL has the appropriate escape clauses in the way it defines a
``work which uses the Library.''

> 	Moreover, if that ld step didn't create a derivative
> 	work, the unlinked object code would represent
> a "work that uses the Library", and clause 6(b) would never apply.
> The existence of clause 6(b) implies that the intention was that executables
> that are dynamically linked should still be subject to the first paragraph
> of
> section 6.

My reading is that section 6 only applies to binaries which are
distributed with the library, or after they are linked with the
library.  That is not the case of typical binaries linked against

I do think the binary which needs to be dynamically linked with glibc
is ``work that uses the Library.''

Clause 6(b) is an escape hatch similar to clause 6(a) if you provide a
way to replace the LGPL library which is being distributed with your
binary.  That is, you can provide unlinked objects, or you can provide
some dynamic library mechanism.


More information about the License-discuss mailing list