What is Copyleft?

[Ian Lance Taylor]

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
glibc.

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.

Ian