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
