[Bug-gnulib] licenses again

[Simon Josefsson]

Some of my packages are LGPL (because there are free competing
projects), but using a gnulib scheme for compatibility files is rather
useful.  One approach I have considered is this: state that my core
package, which is LGPL, require C89 and POSIX:2001.  If people don't
have POSIX:2001 compliant systems, they can still build my package,
but doing so will link with compatibility files from gnulib, which are
GPL.  Consequently, building my package on non-POSIX systems will
force you to use it as GPL (or replace the gnulib code...).  On "good"
platforms my project would still be LGPL in practice.  This would
penalize old systems, and might even get someone to switch to a free
operating system, to be able to use my code as LGPL.

At first, I thought this was a neat idea, but then I realized a
potential problem: the LGPL code would still contain #include of GPL
header files.  The gnulib header files shouldn't (ideally) do anything
on compliant systems, but perhaps that's not relevant.  The point is
that they are included, and the interface of those GPL header files
are used by my LGPL code.  No code is linked, though, except possibly
for dummy.c (which, incidentally, is LGPL even in gnulib CVS).  Would
this force all programs that #include gnulib header files to follow
GPL?

Somewhat risking making this into a regular license flame war, perhaps
clause 3 in GPL about "system components" is relevant.  I guess it
could be argued that "snprintf" is a system component.  I have no idea
whether that modify the conclusion though.

Finally, there is also the option (for maintainers) to run
srclist-update but disable the license fixing part, to get gnulib
files licensed under LGPL.  At least those files which are synced
from, e.g., LGPL'd projects like glibc.

Thanks,
Simon