Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Sun, Jul 22, 2001 at 11:07:20PM -0500, Steve Langasek wrote:
> 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.
This is not true, exceptionally not true in this specific case.
> 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.
> 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.
> >> 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.
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.
"Incorporation in the binary" (although you didn't define it, I think I
understand what you mean) is not what defines the source code for the GPL,
and I think you know that (if not, please read the GPL until you understood
it thoroughly). You are spreading confusion if you start to redefine terms
that are defined in the GPL and base your interpretation of the GPL on this
other definitions, which are not relevant. Please stop spreading confusion.
If you want to argue about the GPL, stick to the terms and conditions of the
GPL, and don't make up other criteria.
> > "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?
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.
> 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?
It would make the violation (as I see it) that occurs sometimes
(whenever an autobuilder updates the files for a binary) not go away.
In addition, we would be in violation for all binary packages that are build
from such a source (including the binary that is compiled by the source
maintainer etc). In fact, the source would not be a complete source anymore
for any binary.
I want to repeat here that there might be a way to comply to the license
even in such a situation. However, it will be much more difficult to comply
(we would, for a start, need to keep all autotools-dev package versions that
were used to compile any existing binary).
> > > 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.
This is considered sufficient for the LGPL, and it is written explicitely
there (section 6b), at least on a binary level. Libraries are not excempted
in any way in the GPL (if you ignore the notorious system-libs excemption),
so I doubt that there is any such relaxation.
As this poses significant problems for everyone who distributes libraries,
I sincerely hope that there is an easy answer by the FSF to this
complication. However, I don't have one. I will let you know when I
receive one from the FSF.
[...]
> 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.
[....]
> 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.
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.
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).
> > 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.
Yes. This is what gives the author right in the derived work in the first
place, and makes it possible to enforce the GPL. Are you still on the
position that I can't request the full source of a work derived from my
GPL'ed program? I don't have the legal right on the other source combined
with it, but you must distribute it under the terms of the GPL, or you are
not allowed to distribute the derived work in the first place (see section 7
of the GPL).
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: