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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
