Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Mon, Jul 23, 2001 at 09:47:31AM -0500, Steve Langasek wrote:
> > 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.
We are really leaving the topic, but let me assure you that only
weak licenses are discussed in the court. The fact that people
(including all big companies) respect and use the GPL for their
software, and reach settlement out of court makes it a very strong
license. Sure, at some point it will probably have to be tested in
front of a court, but that this has not happened yet is a sign
of strength, not of weakness.
There are many ways to enforce a license. Going to court is the very
last way, if everything else fails.
> The thing that I find most troubling is that I can replace config.guess with
> this short script:
Well, apart from the obvious bugs in it (on the Hurd, it is GNU, not
Hurd, what uname -s returns), I get the idea.
> 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.
> 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.
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.
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.
> >> 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'.
You can not pull this excemption in Debian. We have refused to pull this
in the past (for example, for KDE), and it was the correct decision.
This excemption is only plausibly used for operating systems which
are tightly controlled by a single vendor, where you can guarantee that
the major components are delivered.
> I believe that a case can be made that we fulfill section 3 via the "same
> designated place" exception
This is indeed our only hope.
> 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?
BTW, even if one were to accept this, there is still the issue of GPL'ed
libraries, which is not so "easily" brushed away.
> 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.
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.
A last note about system components and priorities: This is a dead end.
Debian is not only distributing a whole operating system, but also individual
packages on the ftp site.
> 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.
Thanks,
Marcus
Reply to: