On Apr 25, 2009, at 2:46 AM, Ralf Wildenhues wrote:
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?
Yes, this would be good to clear up. I'll throw in my own question --
this may be foolish, but IANAL and I always misunderstand this stuff,
so bear with me.
We OMPI developers ask people to send the stdout/stderr of configure
and their config.log to us to help figure out problems (http://www.open-mpi.org/community/help/
). As I understand your explanations, this is still perfectly fine --
these scenarios are long after running AC/AM/LT, so all that data is
covered by the exception and is therefore effectively licensed under
Open MPI's license.
Is that correct?
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.
Yes, this is also a good point. There are a small number of places in
OMPI's build system where we are using internal / unpublished AC/AM
mechanisms (e.g., global shell variables that have the output of
various tests that are not documented). We *needed* to use these
because we deviated a bit from what AC/AM normally provides (obviously
not because we're trying to create an AC/AM clone or anything like
that). Are these problematic from a licensing point of view? (of
course, all the standard technical "this isn't part of the published
interface and may change at any time" stuff applies as well)
I don't recall where these places are in OMPI's configure system, so I
can't cite them easily, but I'm sure we have some that have crept in
over the years. It might be difficult to find them all and root them
out, if they are problematic, license-wise.
> 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.
Agreed.
At one point, we investigated switching away from AM/LT and using
scons as a building tool (still using AC as the configuring tool). As
a technology, there were certain distinct advantages to using scons --
some aspects of it were downright cool, actually. But even after
producing a functional prototype, we decided to stick with AM/LT for
two reasons:
1. LT had support for far more compilers than scons
2. The support we get from Ralf and the AC/AM/LT community has been
great; I don't know if we'd get that level of support from the scons
community
#1 may have changed since we looked at scons (this was several years
ago now). But we continue to enjoy pretty good support from the AC/AM/
LT community, and, as Ralf mentioned, we have a somewhat symbiotic
relationship. I, too, believe that we both have benefitted. So while
I'd love to have some of those cool features from scons, the
advantages of moving are outweighed by the functionality, knowledge
base, and rapport that we have built up in our AC/AM/LT usage.
Perhaps we should start lobbying for some of the scons features we
liked in AM/LT. :-)
All that being said, our next major disruptive Open MPI developer
change will be moving to Mercurial, and that'll likely take a few
months. I wouldn't want to have a massive change in the configure/
build system at the same time.
--
Jeff Squyres
Cisco Systems
