Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Mon, 23 Jul 2001, Marcus Brinkmann wrote:
>> 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,
> In all cases where it matters, the GPL has been enforced. Dozens of times
> in the past. It is an exceptionally strong license, and it has been proved.
> All disputes could be settled outside of the court, and all have been
> settled in favour of the FSF.
An out-of-court settlement does not have the same strength as a legal
precedent.
>> 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?
> We should draw the line exactly where the GPL draws it, with the help of the
> interpretation of the FSF where it is necessary.
The thing that I find most troubling is that I can replace config.guess with
this short script:
---------------------
#!/bin/sh
cpu=`uname -m`
case "$cpu" in
i*86 )
cpu="$cpu-pc"
;;
* )
cpu="$cpu-unknown"
;;
esac
os=`uname -s`
case "$os" in
*inux )
os=linux
;;
*urd )
os=hurd
;;
esac
echo "$cpu-$os-gnu"
exit 0
---------------------
and I can replace config.sub with this:
---------------------
#!/bin/sh
echo $1
---------------------
and I can say to hell with all other architectures, and it will be
forwards-compatible with Linux for the foreseeable future, and as long as I
distribute these scripts, it's GPL-compliant; but if I reference an external
version of these scripts, providing machine-readable instructions for
accessing them, with the understanding that the script pointed to by that
reference will always be functionally-equivalent with respect to all platforms
that binaries are released for, this constitutes a GPL violation?
If a question of GPL compliance ever arose, I could just as surely take the
scripts I've included in-line above and provide them to the party demanding
full source code, and no one would be able to prove the difference in a court
of law. Nor can I imagine why anyone acting in good faith would ever want to.
>>> 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.
> Of course, because they are part of the source code. If you don't think so,
> you can try to remove them and build the source. If this works, we can just
> delete the files from all our packages and not worry about them at all.
So, what do you think if I create a modified work by replacing
config.{guess,sub} with my scripts above?
>> 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?
> Yes, it does.
>> 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?
> I don't see a difference.
But I do. Under these circumstances, I argue that the debian/rules script and
the Build-Dependencies list form part of the source code covered under the
GPL, and the autotools-dev package forms part of 'anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the executable
runs'.
Or does autotools-dev need to be given a higher priority before it can qualify
for this exemption? Perhaps it should be marked Priority: standard, as a
solution to this current problem?
> > 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 only read the GPL. The only section that is relevant for this is section
> 3. It defines what the source is (and config.guess/config.sub are part of
> the source following this definition). The license of the config. files is
> effectively GPL (as the exeption is uneffective for GPL programs). If you
> come with me so far, one of the requirements 3.a) - 3b) have to be met for
> the complete source of the bnary we distribute. I claim that in the
> discussed case, we are not fulfilling any of these three.
> If you think we fulfill any (or the "same designated place" exception at the
> end of 3.), please let me know which of the three we'd fulfill and why we do
> so.
I believe that a case can be made that we fulfill section 3 via the "same
designated place" exception by virtue of the fact that the autotools-dev
package we offer is *technologically and functionally indistinguishable* after
the fact from the version used to build the binaries in question. There is
only circumstantial evidence to support the argument that the version of
config.sub offered for GPL compliance in the Debian archive is not the version
of config.sub used in creation of the binary package.
Failing that, I believe autotools-dev can be considered part of the
distributed components of the operating system that are exempted from source
availability under the GPL; and if not, I believe that the priority of this
package should be raised so that it does qualify as such a normally
distributed component.
> This is still based on the assumption that distributing the sources split
> up in several parts in the same Debian ftp archive is enuogh to satisfy
> point 3 in the GPL ("same designated place"). This is not clear to me, but
> I included this specific question in the mail to the FSF.
> Also, if this is true, we must make distributors very aware that the
> autotools-dev is considered to be part of the source of many binaries!
> This is not obvious! And we have people only redistributing a part of the
> archive.
I agree. If autotools-dev must be considered part of the source under the GPL
in this circumstance, then there must be some way to better protect those who
redistribute parts of the Debian archive. Would raising the priority of
autotools-dev be useful here, as well?
> Also, this is still based on the assumption that redistributing the latest
> version suffices. I'd say that providing all versions of autotools-dev is a
> better strategy if you want to go this way, and somewhere in the binary
> should be a file mentioning which version was used (in the copyright file).
Given that the version of compiler you use has a more tangible effect on the
compiled program than the version of config.sub you use, I think it would be
a gross misuse of the GPL to demand access to the exact version of config.sub
that was present on the autobuilder at the time a binary was compiled.
Steve Langasek
postmodern programmer
Reply to: