What are the restrictions on distributing configure
scripts that Autoconf generates? How does that affect my
programs that use them?

There are no restrictions on how the configuration scripts that Autoconf
produces may be distributed or used. In Autoconf version 1, they were
covered by the GNU General Public License. We still encourage software
authors to distribute their work under terms like those of the GPL, but
doing so is not required to use Autoconf.

Of the other files that might be used with configure,
`config.h.in' is under whatever copyright you use for your
`configure.in', since it is derived from that file and from the
public domain file `acconfig.h'. `config.sub' and
`config.guess' have an exception to the GPL when they are used with
an Autoconf-generated configure script, which permits you to
distribute them under the same terms as the rest of your package.
`install-sh' is from the X Consortium and is not copyrighted.

Many m4 implementations have hard-coded limitations on the size
and number of macros, which Autoconf exceeds. They also lack several
builtin macros that it would be difficult to get along without in a
sophisticated application like Autoconf, including:

builtin
indir
patsubst
__file__
__line__

Since only software maintainers need to use Autoconf, and since GNU
m4 is simple to configure and install, it seems reasonable to
require GNU m4 to be installed also. Many maintainers of GNU and
other free software already have most of the GNU utilities installed,
since they prefer them.

If Autoconf requires GNU m4 and GNU m4 has an
Autoconf configure script, how do I bootstrap? It seems
like a chicken and egg problem!

This is a misunderstanding. Although GNU m4 does come with a
configure script produced by Autoconf, Autoconf is not required
in order to run the script and install GNU m4. Autoconf is only
required if you want to change the m4configure script,
which few people have to do (mainly its maintainer).

Several people have written addressing this question, so I include
adaptations of their explanations here.

The following answer is based on one written by Richard Pixley:

Autoconf generated scripts frequently work on machines which it has
never been set up to handle before. That is, it does a good job of
inferring a configuration for a new system. Imake cannot do this.

Imake uses a common database of host specific data. For X11, this makes
sense because the distribution is made as a collection of tools, by one
central authority who has control over the database.

GNU tools are not released this way. Each GNU tool has a maintainer;
these maintainers are scattered across the world. Using a common
database would be a maintenance nightmare. Autoconf may appear to be
this kind of database, but in fact it is not. Instead of listing host
dependencies, it lists program requirements.

If you view the GNU suite as a collection of native tools, then the
problems are similar. But the GNU development tools can be configured
as cross tools in almost any host+target permutation. All of these
configurations can be installed concurrently. They can even be
configured to share host independent files across hosts. Imake doesn't
address these issues.

Imake templates are a form of standardization. The GNU coding standards
address the same issues without necessarily imposing the same
restrictions.

Here is some further explanation, written by Per Bothner:

One of the advantages of Imake is that it easy to generate large
Makefiles using cpp's `#include' and macro mechanisms.
However, cpp is not programmable: it has limited conditional
facilities, and no looping. And cpp cannot inspect its
environment.

All of these problems are solved by using sh instead of
cpp. The shell is fully programmable, has macro substitution,
can execute (or source) other shell scripts, and can inspect its
environment.

Paul Eggert elaborates more:

With Autoconf, installers need not assume that Imake itself is already
installed and working well. This may not seem like much of an advantage
to people who are accustomed to Imake. But on many hosts Imake is not
installed or the default installation is not working well, and requiring
Imake to install a package hinders the acceptance of that package on
those hosts. For example, the Imake template and configuration files
might not be installed properly on a host, or the Imake build procedure
might wrongly assume that all source files are in one big directory
tree, or the Imake configuration might assume one compiler whereas the
package or the installer needs to use another, or there might be a
version mismatch between the Imake expected by the package and the Imake
supported by the host. These problems are much rarer with Autoconf,
where each package comes with its own independent configuration
processor.

Also, Imake often suffers from unexpected interactions between
make and the installer's C preprocessor. The fundamental problem
here is that the C preprocessor was designed to preprocess C programs,
not `Makefile's. This is much less of a problem with Autoconf,
which uses the general-purpose preprocessor m4, and where the
package's author (rather than the installer) does the preprocessing in a
standard way.

Finally, Mark Eichin notes:

Imake isn't all that extensible, either. In order to add new features to
Imake, you need to provide your own project template, and duplicate most
of the features of the existing one. This means that for a sophisticated
project, using the vendor-provided Imake templates fails to provide any
leverage--since they don't cover anything that your own project needs
(unless it is an X11 program).

On the other side, though:

The one advantage that Imake has over configure:
`Imakefile's tend to be much shorter (likewise, less redundant)
than `Makefile.in's. There is a fix to this, however--at least
for the Kerberos V5 tree, we've modified things to call in common
`post.in' and `pre.in'`Makefile' fragments for the
entire tree. This means that a lot of common things don't have to be
duplicated, even though they normally are in configure setups.