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: Paul H. Hargrove (PHHargrove_at_[hidden])
Date: 2009-04-25 18:34:28


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                          PHHargrove_at_[hidden]
Future Technologies Group                 Tel: +1-510-495-2352
HPC Research Department                   Fax: +1-510-486-6900
Lawrence Berkeley National Laboratory