Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
Hi Marcus,
On Mon, 23 Jul 2001, Marcus Brinkmann wrote:
> On Sun, Jul 22, 2001 at 05:03:56PM -0500, Steve Langasek wrote:
> > However, I think a makefile rule that allows the source code to be
> > self-modifying by grabbing newer copies of config.{guess,sub} poses a problem,
> > if the changes are also reverted as part of the build process in the 'clean'
> > rule.
> You think it poses a problem? Or did you want to say it doesn't?
Yes, I meant to say I don't think it poses a problem. Mistype, sorry.
> > I don't particularly want to be carrying around the entire text of
> > config.* in my Debian diff.gz,
> For me, compliance with licenses and a transparent build system matters
> more than a short Debian diff.gz.
I also believe license compliance is important, but the GPL is as much a
social covenant as it is a license; if you violate the letter of the GPL but
not the spirit, the FSF is not likely to ever take you to court, and if you're
never taken to court, the letter of the license is not important. Thus, I
think it's possible for us to be too literal when trying to understand the
GPL. If anything, this is a bug to be fixed in the GPL, nothing more.
> > and I don't see this as necessary if you have a
> > Makefile that provides a proper recipe for reproducing this feat. We don't
> > know what version of libc headers the package will be built against, nor is
> > a trail of this left in the final binary package; if we have a patch that
> > causes 'autoconf' to be invoked at build-time to incorporate changes to
> > configure.in, we don't know what version of autoconf will be used.
> However, the license of the C library is the LGPL, which poses no problem
> (see 6 b) in the LGPL). For autoconf, well, I think you are right. If
> you read my past emails on this issue, then you will know that I am against
> calling autoconf in debian/rules.
> You had a point if you would mention a GPL'ed library, like libreadline.
> In fact, this is a serious problem, and I will contact RMS about it.
> We are probably in violation with the GPL in all programs that use
> GPL'ed libraries.
This is a very unwieldly interpretation of the GPL. This suggests that anyone
who distributes binary versions of GPL works, not just those who distribute
such binaries as part of a Debian distribution, must make available not only
the source of the work they compiled, but also the source to the exact version
of any GPLed works that were used in the compilation. What implications does
this have for all of the independent projects that provide precompiled
versions of GTK (Gnome) or QT (KDE) apps?
> > Note that the configure script itself is used by the autobuilders to make
> > 'automatic changes to the source' (generated header files),
> Just as you say, they are generated files in the build process, they don't
> belong to the source code of the program.
Then let me pose a series of scenarios.
If I add a comment to my local copy of the CREDITS file for a package, then
rebuild the package and distribute the binary, do I have an obligation to make
available a copy of the source containing my modified CREDITS file?
If I make changes to the Makefile structure which have no impact on the
binaries produced, but which speed up the compilation on my Beowulf cluster
by better distributing the load, do I have to make those Makefile changes
available?
If the Makefiles provided don't allow me to specify an alternate compiler, and
I therefore decide to build and link all the objects by hand from the
commandline instead, what obligations do I have if I distribute the binaries
I've compiled?
If I hand-hack configure.h (which, according to what you have said above, is
not part of the source code because it's generated at build time), in order to
correct a misdetected header, but I make no attempt to fix the configure
script itself, is there 'modified source code' that I have an obligation to
make available with the binaries, or can I just distribute the upstream source
code?
Each of these situations has aspects in common with the idea of silently
upgrading config.{guess,sub}, and each of these situations is something that
may happen regularly in the Free Software community (though not in Debian,
where the exact build tree is snapshotted in the source package, complete with
all changes made), so I will be very interested to know your answers.
I emphasize again that, in the vast majority of autoconf-using packages, the
exact version of config.sub that's used has no impact on the compiled binary,
so long as it's a version of config.sub that supports the target platform.
The target name doesn't cause different switches to be passed to the compiler,
nor does it cause the selection of a different compiler based on
subarchitecture[0]. I would be happy to run some comparisons of my packages
to show you that the md5sums match when different versions of config.sub are
used.
> > Moreover, the package author can't claim copyright on config.sub and
> > config.guess -- these scripts may /ship/ with the various packages, but
> > they're not a part of the software being built.
> You are correct at the beginning of the sentence, but wrong at the end of it.
> The fiels are part of the software as a whole, which is a derived work
> composed of the authors work and the config.* files (and probably other
> works, too).
Then you believe the author of the derived work has some legal rights with
regard to the autoconf scripts contained in the source directory? This is an
interesting assertion, and one probably best left for debian-legal (or legal
counsel) to decide the truth of. For my part, this doesn't make much sense
from a technical POV; they simply aren't part of my definition of the 'source
code'.
Steve Langasek
postmodern programmer
[0] The effect in a cross-compiling environment may be different, but even
there, the effect is invariant with respect to the config.sub version.
Reply to: