Ralf Wildenhues wrote:
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.
[snip]
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.
I thank you for dealing with FSF legal on these issues.
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?
This is exactly the issue that, based on Ralph C.'s comments, is my
largest concern at the moment in relation to the Exception language. If
OMPI and other non-GPL projects were unable to get build-system support
from people like you due to a technicality like this one, I think that
everybody would lose. As you have mentioned, the OMPI and AC/AM/LT
relationship has historically been one of significant mutual benefit.
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.
This seems a fair summary of the concern that Jeff raised.
To add my own IANAL $0.02 to this one: there is a significant difference
from peeking at autoconf sources for the name of an internal variable
and things like cloning the source code for AC_CHECK_SIZEOF (while
perhaps changing the "AC" and "ac" prefixes and reindenting). I agree
w/ Ralf W that my preference would be to allow both practices w/o
creating license restrictions on the configure script or even on the
configure.ac and/or the foobar.m4 containing the cloned macro. However,
while I might not make myself popular outside the FSF with this
statement, I think that *if* the FSF wants to assert their rights to
prevent cloning AC_CHECK_SIZEOF then that is within their rights. What
needs to be considered is whether doing so is consistent with the AC
project's goals.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group Tel: +1-510-495-2352
HPC Research Department Fax: +1-510-486-6900
Lawrence Berkeley National Laboratory
