Hello Open MPI developers,
* Paul H. Hargrove wrote on Fri, Apr 24, 2009 at 09:17:20PM CEST:
> I think your specific example of public posting of the debug or verbose
> output might be a valid concern, but perhaps not exactly in the way
> you've stated it. The act of "distributing" the debug/verbose output is
> not forbidden, but distributing it under a *non-GPL* license is. If by
> posting the debug or verbose output one was now required to offer, under
> GPL terms, *all* the source code that generated said output, then I'd say
> we have a problem when configure.ac and acinclude.m4 are from a non-GPL
> project such as OMPI.
> Ralf Wildenhues,
> While I believe Jeff is the one that brought this discussion to
> ompi-devel, I know you've posted on ompi-devel in the past. Are you
> seeing this?
Yes, I am casually reading this list.
> Do you have a response to Ralph's concern, or can you
> bring this to the attention of those who would? Perhaps we are
> rehashing a discussion already settled on some list we don't read?
Well, it brings up an interesting point; part of this has been discussed
already, part hasn't. For those interested, most of the other
discussion has taken place on the autoconf list as part of this thread:
For the points brought up here, allow me to give a bit of background:
The whole language about "verbosity" and "non-debugging" output was
added to the Exception in the first place, in order to prevent something
like this to happen: somebody modifies autoconf to output all of the
macro input files that are part of the Autoconf software package itself;
then somebody else uses that output to create an Autoconf clone under
any license. It was considered that this might be possible with the
current GPLv2 + Exception. Note this all about somebody who wants to
create another "Autoconf", not about normal users of it.
Now, as the Exception is formulated currently, it certainly has the
chance to also impact normal users of Autoconf. Finding out whether
this may be a problem for our users is one of the very reasons we posted
this draft Exception as an RFC; we would like to ensure that our users
are not impacted negatively by it. This includes that it should
continue to be possible to produce configure scripts for non-free
software and distribute it alongside that, even without source code.
Here's the way I see it (and IANAL):
As long as you only deal with the configure script and output from that,
may that be debugging output, verbose output, whatever, you can do
anything with it that you want. This Exception only ever deals with
what is done with the output of "autoconf", i.e., whatever happens
when "autogen.sh" is run on the Open MPI tree.
Still, I can see that there may be two problematic issues, and I would
like to thank you for bringing them up; I will talk to the FSF legal
dept. about them. Here's my summary of them, formulated in a way that I
will present them to the FSF; please correct me if I have misrepresented
or forgotten anything, thanks.
1) While developing your build system, you might have some problem which
is Autoconf-related. Autoconf developers ask you to provide output
and now, since you are going to publish it on a mailing list such as the
bug-autoconf one, thus effectively distributing it, there are
restrictions on the produced text. Since the output will likely depend
on both code from Autoconf, and also code from your build system, can
this now require you to provide your build system bits under a
2) While developing a complex autotools-based build system such as the
one that Open MPI uses, it might be quite helpful to peek at internals
of Autoconf macros, and in some cases copy constructs from them and use
them in Open MPI's macros, to the point that it's unclear whether one
code is derived from another in a legally significant way.
In such a case, I'm personally not sure what the *desired* stance of
the FSF would be about the required license of those copied macros
(my personal preference would be to allow this, as long as the intent
is clear to not create an Autoconf clone). However, even if the FSF
were to intend to make those honor the GPL, then it should still be
possible to distribute the produced configure script without
> Ralph Castain wrote:
>> Frankly, this all seems absurd to me. The GPL continues to grow in its
>> unfriendliness. Perhaps it is time we reconsider our use of these
>> tools - we had given some consideration in the past to moving, and
>> maybe we need to do so again.
Of course I am not in a position to tell you what build system to use,
but in my view, both autotools and Open MPI have profited quite a bit
from each other (I hope!), in that the former has gained support for
several new systems since, squashed lots of bugs, and the latter has
been a very good stress test example, and as a result, the former now
has several improvements for large packages (faster config.status,
less bloat in Makefile.in files, threaded automake execution) from which
the latter may profit.