Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft
From: Ralf Wildenhues (Ralf.Wildenhues_at_[hidden])
Date: 2009-04-25 08:33:44

Hi Jeff,

* Jeff Squyres wrote on Sat, Apr 25, 2009 at 01:27:24PM CEST:
> We OMPI developers ask people to send the stdout/stderr of configure and
> their config.log to us to help figure out problems
> ( 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?

Yes, that is 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)

Well, the question whether they are problematic or not, is one where in
the end, only a lawyer can provide a definite answer for you. Whether
for the current GPLv2 + the simple Autoconf Exception, or with a future
GPLv3 + Exception.

I brought this up now precisely because I'm not quite sure of this
myself, but I'd like the next Autoconf license to be clear here, and
in a way that this works for you. Please note that I'm not the person
to decide this, in the end, it is the FSF.

> 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.

I don't actually think there is much relevant code of this form at all
in Open MPI. I haven't done an analysis, though. And if there would
turn out to be relevant portions, _and_ the license question can't be
cleared up, then I'd see it as next step on my TODO list to help redo
the Open MPI macros in a clean fashion.

>> 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 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.

I hardly know scons. What's cool about it that autotools don't have?

Just in case less verbose build output (a la Linux kernel builds) is one
of them, Automake-1.11 will have that (and its release is only waiting
for the license stuff to be resolved).

> 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