[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Outdated GNU config (config.{sub,guess}) and autotools-dev



On Mon, Jul 23, 2001 at 12:56:40PM -0500, Steve Langasek wrote:
> 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.
> 

This should make you happy, the GPL FAQ explains that the "corresponding source
code" is the source code that allows the user to produce the same binary.

So, if you are positive that you can reproduce the same binary from a different
source (the one without your comments), then you are fine to ship that one.

However, in this case, you can just use this different source to build the
binary any way.  This is what I said earlier, that if it doesn't make a
differnce, the discussion is indeed mood.  What I am concerned about is
the case where the file in the source tar file is not recent enough for a given
architecture.

In this case, you said you want to refer the user to the autotools-dev package.
For this to work, we must make sure that two conditions are fulfilled.
1. The autotools-dev package must be absolutely and completely
   backwards compatible.
2. You must make sure you always provide the autotools-dev source
   package when you provide the source package of the program, and
   provide the instruction how they are related.  Also, you must
   provide user visible pointers to the autotools-dev package, that make
   clear that it contains a component of the source of the program
   (for example in the pools directory of that package).
   We also need to instruct our mirrors and distributors that this
   requirement exists.

If 1. is given, I take back my previous claim that you need all past
versions of the autotools-dev.  You made a good case why (in the case
of backwards compatibility) the same binary can be produced from a different
source.  It is not so hard to actually make sure that the scripts are
backwards compatible, but it has to be done.

If the above is done, this counts as "making the source available at
the same designated place as the binary" (they GPL FAQ explains that, too.
It doesn't need to be the same physical palce, but a pointer must be there).

I don't know how feasible the above approach is from an archive management
point of view.  It is certainly a challenge (and overkill for the effect
of the proposed feature, if you ask me).  Note that a similar approach would
be needed for GPL'ed libraries, I think... uh-oh, can of worms, anyone?

Thanks,
Marcus



Reply to: