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: <http://lists.gnu.org/archive/html/autoconf/2009-04/msg00081.html> 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 from, say, autoconf --verbose 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 GPL-compatible license? 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 restrictions. > 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. Cheers, Ralf
