Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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 and acinclude.m4 are from a non-GPL
>> project such as OMPI.
> 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 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 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