Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Mon, 23 Jul 2001, Marcus Brinkmann wrote:
> > 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?
That's not my intention, no. If I didn't care about GPL compliance, I don't
think I would be interested in debating the matter publically. :) My intended
point was that the question of whether this is a GPL violation depends so much
on legal minutiae and definitions of terms that it can never be satisfactorily
resolved from a /legal/ point of view without either a court challenge or a
clarification in the license itself. Bear in mind that there are those who
hold the legal opinion that the GPL is in fact not a legally enforceable
license at all, yet this doesn't seem to hinder Debian development overly
much. Why, therefore, should we draw the line for GPL compliance farther to
the conservative side than anyone in the community would ever require us to?
>> 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:
But config.sub and config.guess are only used during compilation, not
incorporated into the program (the binary), and you assert that any
modification to these scripts must be made available as part of the offer for
source code.
> "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."
Isn't the "preferred form of the work for making modifications to it", in the
case of Debian, the Debian source package, including debian/rules and the
build-time control fields of debian/control? IOW, does the Debian package
constitute a derived work of the original? If my preference is to include
in the source code a requirement -- in machine-readable form no less -- that
the most recent version of the autotools-dev package should be secured and
used during the build process, does that not have some bearing on GPL
compliance?
And if I remove config.sub and config.guess altogether (by means of .diff.gz),
and depend entirely on the files provided by autotools-dev, where would that
put us?
> > 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.
I will be interested in their answer. I would hope that providing a
*compatible*, *functionally-equivalent* version of these libraries is
considered sufficient.
> > > > 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.
I am concerned about all of the cases I listed, because your position has
possible implications for each. I'm also interested in understanding the
underlying reasoning you've used in concluding that this is a GPL violation,
because I cannot say I entirely follow it.
>> 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.
It is in fact the same issue. If two versions of config.sub that behave the
same with respect to the platform you're building for are equivalent wrt GPL
compliance as a result of this, and if including a copy of config.sub together
with the source in the Debian archive (not in the same .tar.gz, but on the
same ftp site -- which is what we do for /all/ of our Debian-specific changes)
satisfies the GPL's requirement for source availability, then the most current
version of autotools-dev in the archive should always be sufficient. Clearly,
if the version of config.sub that comes with the upstream source doesn't let
us compile on a given platform, then the version in the Debian archive must,
because it will be newer than or equal to the version that was used to compile
the binaries for that architecture!
There is the question of what happens if at some point autotools-dev is no
longer available in the archive; but that already has implications per policy,
because a package that build-depends on autotools-dev will then no longer
build from source on *any* arch.
> > > 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.
IANAL, but my understanding of copyright law is that only the actual holder
of the copyright on a particular piece of code has the legal right to
challenge someone's use of that code. This certainly seems to be part of the
reasoning behind why authors should assign copyrights to the FSF.
Steve Langasek
postmodern programmer
Reply to: