Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Sun, Jul 22, 2001 at 08:27:15PM -0500, Steve Langasek wrote:
> > > 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.
In all cases so far we have tried to meet the letter and the spirit of a
license. I hope you are not suggesting that if we are knowingly violating
the letter (but believe not to violate the spirit) of a license, we are ok?
> > 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.
Not used, but incorporated into the programs. Please read the GPL. I quote
some interesting snippets here:
"The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable."
Note the "associated interface definition files". BTW, you are too narrow
in your interpretation. Providing all these sources i one way to comply
with the license. This is 3. a). There are also 3. b) and 3. c) [the
latter is not usable for Debian because of non-commercial restrictions].
> What implications does
> this have for all of the independent projects that provide precompiled
> versions of GTK (Gnome) or QT (KDE) apps?
It's indeed a very interesting question, and I have sent mail to the FSF
about it. It might be necessary (and sufficient) for Debian to put the
versions of the libraries used at compile time in a file in the doc
directory. It might be necessary also to keep those versions in the Debian
archive.
> > > 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.
It is not useful to raise a series of scenarios. Each case is different,
and needs to be considered carefully. I don't have time for that. It's
better to just stick with the one case you are concerned about. Especially
since any particula scenario described in a few words is often ambiguous
because of incompleteness.
Please forgive me that I don't respond to your scenarios for these reasons.
If there is any real world case you have a legal question about, you can
ask the FSF, which provide answers to such questions as a service to the
community. Mail to gnu@gnu.org, and be as explicit as possible in what
happens.
> 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.
Yes, those are exactly the cases where the whole issue doesn't apply to. If
those were the only cases, we would need this feature in the first place!
You are clouding the real issue, which is what happens when it makes a
difference.
> > > 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?
No, he has a legal right in the derived work. Again, you are confusing the
issue. All authors of parts of the software have a legal right in the
derived work, which is the composition of the parts, and can request the
whole source code, because this is what the GPL requires you to provide.
Otherwise you could just incorporate GPL code in proprietary code, and tell
the original author of the GPL code to go away because he has no legal
rights in the proprietary code. You would just have found a way to entirely
circumvent the GPL ;)
All this confusion and attempts to duck the issue make me more and more
confident we should completely avoid changing the source at binary build
time.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: