Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft

[Paul H. Hargrove]

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 

Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft

[Ralf Wildenhues]

Hello Ralph,

* Ralph Castain wrote on Sat, Apr 25, 2009 at 05:09:01PM CEST:
> Just to be clear, Ralf - I'm not advocating that we change build  
> systems. I agree it has been a good relationship, and your participation 
> has been welcome and extremely helpful.

Understood; and thanks!

> My point was only that the GPL continues to evolve and seems to be  
> growing more aggressive in its "viral" clauses, which makes it harder to 
> work with those packages without getting "assimilated", as the Borg  
> would say.

(The following is of course my sole opinion only.)

Well, of course I cannot tell you how to view or judge the evolution of
the GPL either; and I understand that the anti-tivoization clause in
GPLv3 is one of the developments you seem to be hinting at.  I don't
claim that to be different from how you see it.  Of course, the FSF
would formulate that differently: they saw a "subversion" of the GPLv2
in intent if not in the letter of the license.  So they closed that
loophole.

However, with respect to the exception clauses that have been written
for GCC, and are being written for Autoconf, at least the *intent* has
not been to become any more "viral" than before at all.  For example,
the GCC Exception, as far as I understand it, has opened up the way to
write plugins for GCC; something, which the FSF did not want to allow
to happen at all with the GPLv2 Exception.

With the current Autoconf draft Exception, there are two goals: one, to
merely reformulate the current GPLv2 Exception in terms of GPLv3 Section
"7. Additional Terms", which has formalized the whole exception business
a bit.  Second, to address in some way the apparent loophole that one
could take the whole of Autoconf and clone it by the construction that
I have mentioned before.  Note that this "loophole" is something the
lawyers considered possible from reading the text of the old GPLv2
Exception, but it would pretty clearly already have been against the
intent of that old Exception (i.e., the loophole would be considered
a hack by any means).

To be honest, I don't see the tendency to get "more viral", rather, the
desire to clarify things where intention and letter of licenses differ.
I must admit though, that the newer license texts are longer, more
complicated, and may be intimidating on that basis along, which should
be taken into account, too.

Cheers,
Ralf

Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft

[Ralph Castain]

Just to be clear, Ralf - I'm not advocating that we change build  
systems. I agree it has been a good relationship, and your  
participation has been welcome and extremely helpful.


My point was only that the GPL continues to evolve and seems to be  
growing more aggressive in its "viral" clauses, which makes it harder  
to work with those packages without getting "assimilated", as the Borg  
would say.


Thus, it may at some point become necessary to change, even though  
nobody really wants to suffer the pain of doing so. I'm not sure if  
these new changes represent that point or not - but it is something we  
may need to consider, especially if the GPL continues to grow more  
viral in the future.


Ralph

On Apr 25, 2009, at 12:46 AM, Ralf Wildenhues wrote:


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.

Cheers,
Ralf
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] MPI Message Communication over TCP/IP

[Timothy Hayes]

I uploaded it to http://www.hotshare.net/file/131218-829472246c.html

I'm not sure if it's any good or even if it's 100% accurate; but if someone
gets any use out of it, that would be good.

Tim
2009/4/17 Jeff Squyres 

> On Apr 16, 2009, at 11:38 AM, Timothy Hayes wrote:
>
> From what I understand MPI_Send will hit 3 separate layers of code before
>> reaching the socket file descriptors you've found. The PML (Point to Point
>> Messaging Layer) is a layer that bridges the MPI semantics from the
>> underlying point to point communications. The standard PML implementation is
>> called 'ob1' which is what indirectly calls the code you found. MPI_Send
>> should go through pml_isend() or pml_send() which will request a BTL (Byte
>> Transfer Layer) modules from the BML (BTL Management Layer) and invoke the
>> BTL's btl_prepare_src() or btl_alloc() functions before calling the
>> btl_send(). It becomes clearer when you step through it all with a debugger
>> though ;-)
>>
>> If you're interested, I've recently implemented a BTL component of my own
>> and am now writing up a report on the process. It will be ready next week,
>> so if you think it might be useful, just let me know.
>>
>
> Ooohh... that would be positively yummy!  We can even host/link to that on
> www.open-mpi.org.  :-)
>
> --
> Jeff Squyres
> Cisco Systems
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>

[OMPI devel] Open MPI mirrors list

[Jeff Squyres]

We just added a mirror web site in Israel.  That one was fun because  
they requested to have their web tagline be in Hebrew.


Fun fact: with this addition, Open MPI now has 14 mirror web sites  
around the world.


http://www.open-mpi.org/community/mirrors/

Interested in becoming an Open MPI mirror?  See this web page:

http://www.open-mpi.org/community/mirrors/become-a-mirror.php

--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft

[Ralf Wildenhues]

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 
> (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?

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

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

Thanks!

Cheers,
Ralf

[OMPI devel] MTT usage

[Jeff Squyres]

OMPI testing organizations:

*** This is an end-of-life announcement for the "ompi-core-testers"  
MTT SVN branch.  This branch will be deleted on 25 May, 2009.


*** Also note that new development will soon be occurring on the MTT  
SVN trunk such that it may become unstable at times.  We encourage all  
OMPI testing organizations using the MTT trunk to move to the  
official /v3.0/ branch (see below).


All organizations are strongly encouraged to do the following:

1. Migrate to use the new https://svn.open-mpi.org/svn/mtt/branches/v3.0/ 
 branch.  This branch is a copy of MTT's trunk as of 24 April 2009.   
This branch is therefore the newest version of MTT, but has been in  
production use by Cisco, Sun, and Indiana U. (and others) for many  
months.  It is quite stable and is the preferred version to use.  Its  
INI file syntax is slightly different than the old "ompi-core-testers"  
branch; you'll likely need to update your syntax.


2. If you are currently using the ompi-core-testers branch and cannot  
upgrade your INI file syntax, please move to the https://svn.open-mpi.org/svn/mtt/branches/v2.0/ 
 branch.  It is a copy of the ompi-core-testers branch as of 24 April  
2009, so nothing has changed.  The name is simply more consistent and  
allows a clear versioning path forward.


Thanks.

--
Jeff Squyres
Cisco Systems

[MTT devel] MTT SVN branches

[Jeff Squyres]

I have created two new MTT branches:

https://svn.open-mpi.org/svn/mtt/branches/v2.0/ -- the old "ompi- 
core-testers" branch
https://svn.open-mpi.org/svn/mtt/branches/v3.0/ -- a copy from  
the trunk as of yesterday


We are now encouraging everyone to use the v3.0 branch in production.   
New development is going to occur on the trunk that may potentially  
destabilize the trunk at times.  The old "ompi-core-testers" branch  
will be deleted on 25 May 2009 -- anyone still using that branch is  
highly encouraged to move to the new v3.0 branch (and update your INI  
file syntax to match), or move to the v2.0 branch if that is not  
possible.


I have also updated the "how to run OMPI regression with MTT" wiki  
page to point to the /v3.0/ branch:


https://svn.open-mpi.org/trac/mtt/wiki/OMPITesting

--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft

[Jeff Squyres]

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 

Re: [OMPI devel] Fwd: RFC: proposed GPLv3 license exception draft

[Ralf Wildenhues]

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.

> Ralf Wildenhues,
>  While I believe Jeff is the one that brought this discussion to  
> ompi-devel, I know you've posted on ompi-devel in the past.  Are you  
> seeing this?

Yes, I am casually reading this list.

>  Do you have a response to Ralph's concern, or can you  
> bring this to the attention of those who would?  Perhaps we are  
> rehashing a discussion already settled on some list we don't read?

Well, it brings up an interesting point; part of this has been discussed
already, part hasn't.  For those interested, most of the other
discussion has taken place on the autoconf list as part of this thread:


For the points brought up here, allow me to give a bit of background:

The whole language about "verbosity" and "non-debugging" output was
added to the Exception in the first place, in order to prevent something
like this to happen: somebody modifies autoconf to output all of the
macro input files that are part of the Autoconf software package itself;
then somebody else uses that output to create an Autoconf clone under
any license.  It was considered that this might be possible with the
current GPLv2 + Exception.  Note this all about somebody who wants to
create another "Autoconf", not about normal users of it.

Now, as the Exception is formulated currently, it certainly has the
chance to also impact normal users of Autoconf.  Finding out whether
this may be a problem for our users is one of the very reasons we posted
this draft Exception as an RFC; we would like to ensure that our users
are not impacted negatively by it.  This includes that it should
continue to be possible to produce configure scripts for non-free
software and distribute it alongside that, even without source code.

Here's the way I see it (and IANAL):

As long as you only deal with the configure script and output from that,
may that be debugging output, verbose output, whatever, you can do
anything with it that you want.  This Exception only ever deals with
what is done with the output of "autoconf", i.e., whatever happens
when "autogen.sh" is run on the Open MPI tree.

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.

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?

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.

> 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