Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Mon, 23 Jul 2001, Marcus Brinkmann wrote:
>> 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?
> The scripts you posted are probably too small to have any effect on the
> program. It is questionable if they are copyrightable at all.
> But in case they would be copyrightable, then yes, their inclusion
> in the program as source code (you say "reference", it is not clear to me
> what you mean. In our case, we copy the scripts in the source, replacing
> the existing source files. I assume you mean that, rather than using the
> scripts like gcc is used) would mean that the whole work is a derived
> work from these scripts, too.
When I say "reference", I refer to a theoretical situation where these scripts
reside elsewhere in the Debian archive and are pulled into the source package
at build time but are not distributed with the source.
>> 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.
> If you can prove that a violation has happened is an entirely different
> question from the question if a violation has happened or not. Just to
> elaborate on your example, you could have the testimony of someone in the
> party, who made the built of the program and saw your files being used.
> The findings of fact could then probably produce hard disks from the party
> with more evidence.
You would have to prove not only that the source package behaved in this
manner at the time the binary package was built, but also that the version of
autotools-dev used to build the package is different than the one currently in
the Debian archive (i.e., prove that it differs in something more than the
version number). Since you cannot prove this by looking at the end-result,
you must have some other way of proving this -- a snapshot of the archive from
the time the package was built?
Well, if someone has a snapshot of the archive from the time the package was
built, then we can arrange to provide the version of autotools-dev from that
snapshot to people who are interested, thereby allowing us the means of
complying with the GPL (though not under 3a or the related exception).
> This is completely irrelevant in our case, as we do not hide what we do.
> Again, I have to stress two things. First, a violation remains a violation
> even if it doesn't make a difference in the outcome. The outcome might have
> an impact on the penalty imposed by a judgement in court. It doesn't change
> the fact that a violation has happened. This is also true if there
> is another way to get the same result which is not in violation with the
> license.
True. But what is a violation that does no material damage, leaves no trail
in the software, is not contrary to the spirit of the GPL, will not be
prosecuted by anyone involved, and could not be proven in a court of law? It
sounds like something that belongs firmly to the realm of theory.
If this is a violation that has no tangible impact and is not counter to the
intent of the GPL license, then the only people who would attempt to prosecute
such a violation would be those acting in bad faith. It's enough for me that
a court of law would not find in favor of those acting in bad faith, I don't
think it's necessary that the GPL prevent altogether the *possibility* of
someone acting in bad faith.
> Second, if there is another way which produces the same result (so there isn't
> any difference, as you say), we can just scrap the way that is in violation
> and just do whatever does not violate the license.
True.
>> by virtue of the fact that the autotools-dev
>> package we offer is *technologically and functionally indistinguishable*
> You are still making up your own terms, definitions and requirements.
> As such you are still trying to confuse the issues and cloud the discussion.
> Why are you doing this?
Because I'm more interested in creating a working distribution that satisfies
the DFSG and the Social Contract than I am in gaining the blessing of law
professors.
> Why are you bothered about evidence? If you really believe that replacing
> the files is not a violation, you should make your case on that ground.
> If you believe it is a violation, and just want to argue why nobody
> can prove it, I don't want to take part of it. I don't want to violate the
> license even if nobody can find out.
I believe it is not a violation in any meaningful sense of the word, because:
* I do not believe it was the intention of the authors of the GPL, or the
intention of the programmers who have licensed their code under the GPL, to
prevent this situation; and
* I do not believe a court of law would find in favor of anyone who argued
that providing a distinct but functionally-equivalent version of a script
fails the requirements of the GPL.
Do you disagree with me about one of the above points, or do you believe
there's another issue I've overlooked that makes it wrong or dangerous for
this to be done in Debian packages?
>> 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.
> I have answered this in the past, so often already (in variations) that it
> make me think we will not be able to make progress on this issue.
> The compiler is not part of the source. The code produced by the compiler
> is either output of the compiler program (and as such not subject to the
> compilers copyright), or it is excempted by the gcc copyright (which has
> a special exception for small parts of its own code it copies into the binary,
> if I recall correctly).
> Au contrair, the config.* files are part of the source code. As such, their
> license has an impact on the derived work.
I did not say here that config.* were not part of the source. What I am
saying is that changes in the version of the compiler (or bison, or external
header files) have a tangible impact on the resulting binary programs, and
changes in the version of config.* do not. Therefore, I do not feel bound to
distribute my personal version of config.guess which matches the version in
the source package in every way except for my comment at the top that I am
annoyed by goats, even if this was the version of the file I had in the
directory at the time I built the binaries.
Since differing versions made available from autotools-dev are similarly
indistinguishable in all ways that matter, I am equally unconcerned about GPL
violations in this case, both from an ethical standpoint and from a legal one.
Steve Langasek
postmodern programmer
Reply to: