Re: RFC: proposed GPLv3 license exception draft

[Ralf Wildenhues]

First off, thanks for everyone who provided comments on this issue,
<http://lists.gnu.org/archive/html/autoconf/2009-04/msg00081.html>,
on this list or off-list!

Below, I try to summarize the issues that have been brought up, and
will ask the FSF legal dept. about them; I'm writing the text mostly
as I will send it to them, adding some explanations.  If I missed out
anything important, or formulated wrongly, then please by all means
correct me.  Thanks!

1) The Exception does not take into account some types of outputs from
programs that Autoconf distributes, namely Autotest testsuite scripts
which are generated in a similar fashion as configure scripts; maybe
even other current or future script products; and also the output of
the autoheader, autoupdate, and autoscan programs.

Autotest testsuite and other scripts are created by the autom4te program
similar to configure scripts (the autoconf program is just a wrapper
around autom4te).  It is our intention that all scripts be treated
similarly to configure scripts.  Would it be sufficient to change
"configure scripts" to just "scripts" in the Exception, or would that be
too general?

The autoheader program generates, from the same input files as Autoconf,
a template header file config.h.in which contains stubs for symbols.
This template is then converted by the configure script into a header
file config.h containing system-specific details.  The template should
be treated just like its accompanying configure script.

The autoscan program produces, from information gathered about project
source files, an initial stub configure.ac file that then serves as
input file to autoconf.  The autoupdate program takes an existing
configure.ac file, and change somes constructs in them for conventions
and names which change from one version of Autoconf to a newer one.
For these two programs, it too would be desirable that their output be
covered by the Exception as well: the user should be able to use their
output in the same way as she would be able to use self-written
configure.ac files.


2) The definitions of both Covered Code and Eligible Output Material
could used some clarification, maybe informally.  Recall that the text
for them was:

  "Covered Code" is any source code and/or object code of Autoconf that is a
  covered work under this License.

  "Eligible Output Material" is Covered Code that is included in the
  standard, minimally verbose, non-debugging and non-tracing output of the
  version of Autoconf distributed to you under this License.  Moreover,
  "Eligible Output Material" may be comprised only of Covered Code that (a)
  must necessarily appear in Autoconf-generated configure scripts and (b) is
  required for those configure scripts to function.

It is not clear what "minimally verbose" means, and whether that may
just be a generalization of "non-debugging" and "non-tracing".  More
generally, it is not clear that the "verbosity" concept deals with the
contents of the produced script, as opposed to, say, warning messages
output during on standard error a run of the autoconf program.

The "must necessarily appear" makes for several questions:

- What about trivial additions like comments and white space, which
  aren't necessary for the functioning of a script, but certainly
  helpful to have; it would not be good if the Exception required us
  to remove them.  Are they Covered by the Exception?

- It may even be construed that any extra code added to configure.ac
  besides AC_INIT and AC_OUTPUT (two macros that cause a minimal
  configure script to be generated) may fall outside of this, if the
  meaning of "necessarily" is read suitably narrow.  So it seems some
  kind of dependency upon the user- and third-party-provided input to the
  configure script should be acknowledged, as in: "must necessarily appear
  in Autoconf-generated configure scripts that provide the functionality
  desired by the user/specified in the input files" or similar.

Further, it is unclear whether the formulation is strict or specific
enough to really prevent abuses.  More precisely, could it be necessary
to specify the intended semantics of the script produced by autoconf,
for example as "functionality required to configure a software project"
or so, in order to prevent that a third party takes Autoconf, modifies
its purpose as "to create a configure script and also copy all of its
input to its output" and thereby circumvent the Exception.

3) It is unclear whether configure scripts which fall under this
Exception really can be treated as they could with the old GPLv3
exception clause.  Specifically, while the second introductory sentence
of the Exception states

  The purpose of this Exception is to allow distribution of Autoconf's
  typical output under terms of the recipient's choice (including
  proprietary).

clause 1. only speaks of "permission to propagate output".  Is that
enough to allow

- relicensing,

- distribution of the relicensed configure script without having to
  distribute alongside a copy of the GPLv3 and of the Exception text,
  if only to make it clear that this distribution is permitted?
  A requirement to provide a copy of these texts alongside would be
  very undesirable for users, as their project may not otherwise need
  to contain any GPL-related text at all.