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-24 15:17:20


Ralph,
  I am not going to defend the GPL. Like you I just want to use the
tools to do my work while doing my best to respect the works of others.

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

-Paul

Ralph Castain wrote:
> Okay, so here is a typical scenario that we have engaged in
> occasionally. We have a problem in our build system, and the autotools
> folks ask us to do a debugging and/or verbose run and send them the
> output. We do that, but it goes out over the mailing list and/or hits
> some gmail accounts.
>
> So now we have effectively distributed that output, yes? And so now we
> have violated the new license?
>
> 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.
>
> Count me frustrated with GPL nonsense.
>
>
> On Apr 24, 2009, at 12:21 PM, Paul H. Hargrove wrote:
>
>> Thanks for getting expert review on this, Jeff.
>>
>> <IANAL>
>> For the record, it is my understanding that the autotools, gcc and
>> similar projects have all been very careful in the GPL3 transition to
>> ensure that *use* of their respective tools will continue to be as
>> "free" as it has always been: no restrictions on what one can do with
>> the normal "output" from these tools.
>>
>> I believe concern of the forwarded posting was to ensure that
>> "output" was properly classified to avoid excluding any valid uses.
>> For instance, there is a clear statement that "verbose", "debugging"
>> and "tracing" outputs from autoconf are *not* eligible for the
>> license exception, and this is a tighter definition than used
>> previously. Is that restriction a problem for anybody? For OMPI I
>> would say NO, but only for lack of knowing otherwise.
>>
>> So, while Jeff has checked that his Lawyers are all happy, there is
>> still a burden on us geeks. We need to look at how we are *using*
>> the various GNU software packages to see if we are distributing under
>> a non-GPL license anything the revised license exceptions would say
>> we cannot. This is not something we can expect our lawyers to do for
>> us.
>> </IANAL>
>>
>> -Paul
>>
>> Jeff Squyres wrote:
>>> To follow up for the web archives, I chatted with Cisco legal about
>>> this and they were fine with it.
>>>
>>> On Apr 21, 2009, at 3:12 PM, Jeff Squyres (jsquyres) wrote:
>>>
>>>> IANAL and don't understand most of what is listed below.
>>>>
>>>> If the GNU Autotools go to GPL3, will we be unable to upgrade beyond
>>>> the last versions that are GPL2? I see the phrase "we still want to
>>>> allow people to distribute the normal output of Autoconf under any
>>>> license they want", but I'm wondering if Cisco will be afraid of
>>>> GPL3...
>>>>
>>>> I think I'll need to ask Cisco's lawyers about this. Can others ask
>>>> their corporate overlords as well?
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>> > From: "Ralf Wildenhues" <Ralf.Wildenhues_at_[hidden]>
>>>> > Date: April 21, 2009 2:46:37 PM EDT
>>>> > To: <autoconf_at_[hidden]>, <automake_at_[hidden]>, <libtool_at_[hidden]>,
>>>> <autotools-announce_at_[hidden]
>>>> > >
>>>> > Subject: RFC: proposed GPLv3 license exception draft
>>>> > Reply-To: <autoconf_at_[hidden]>
>>>> >
>>>> > [ cross-posted to several groups; please followup on the autoconf
>>>> > list ]
>>>> >
>>>> > In order to complete the GNU Project's migration to GPLv3, every GNU
>>>> > program that has exceptions to its license needs to have those
>>>> > exceptions updated for GPLv3. We've prepared draft text for an
>>>> > updated
>>>> > version of the Autoconf exception, and we're interested in hearing
>>>> > your
>>>> > feedback on it.
>>>> >
>>>> > The primary purpose of this update is to have the exception build on
>>>> > top
>>>> > of the framework for Additional Permissions that GPLv3 provides in
>>>> > section 7. We are not trying to change the exception's underlying
>>>> > policy: we still want to allow people to distribute the normal
>>>> > output of
>>>> > Autoconf under any license they want. However, the new draft
>>>> does try
>>>> > to address new issues that have come up since the current
>>>> GPLv2-based
>>>> > exception was written.
>>>> >
>>>> > The new exception grants people permission to distribute Eligible
>>>> > Output
>>>> > Material under terms of their choice. In short, Eligible Output
>>>> > Material is a more formally defined way of talking about the
>>>> > "configure
>>>> > scripts" that are the subject of the old GPLv2-based exception. One
>>>> > change of note is that it is defined to explicitly exclude tracing
>>>> > output, to prevent people from using that mechanism to be able to
>>>> > distribute more source under the terms of the exception than they
>>>> are
>>>> > supposed to be able to. If anyone causes Autoconf to output stuff
>>>> > that
>>>> > is not Eligible Output Material, then they will not be able to take
>>>> > advantage of the exception: they would have to distribute the
>>>> > configure
>>>> > scripts under the terms of GPLv3 alone.
>>>> >
>>>> > Another benefit of the new exception is that it is not
>>>> FSF-specific in
>>>> > any way. When other copyright holders make modified versions of
>>>> > Autoconf, they can apply the exact same permission text to their
>>>> > changes, and it will work the way people want.
>>>> >
>>>> > We hope that this new exception will help make Autoconf's
>>>> licensing a
>>>> > little more clear and robust -- if also a little more verbose -- in
>>>> > the
>>>> > same way that GPLv3 has done for the entire free software
>>>> > community. We
>>>> > are interested in hearing feedback from Autoconf developers about
>>>> > whether there might be intended good uses of the software that
>>>> are not
>>>> > covered by this exception -- or conversely, known bad uses of the
>>>> > software that might be covered. We're also interested in hearing if
>>>> > there are particular parts of the text that you think might be
>>>> > misunderstood by developers: it may not always be possible, but we'd
>>>> > like for this exception to be as clear as possible to as many people
>>>> > as
>>>> > possible. If you're interested, please review the text and let us
>>>> > know
>>>> > what you think.
>>>> >
>>>> > Below is the text of the proposed exception.
>>>> >
>>>> > Thanks to Brett Smith for help in preparing this message.
>>>> >
>>>> > --- cut ---
>>>> >
>>>> > This Exception is an additional permission under section 7 of the
>>>> GNU
>>>> > General Public License, version 3 ("GPLv3").
>>>> >
>>>> > The purpose of this Exception is to allow distribution of Autoconf's
>>>> > typical output under terms of the recipient's choice (including
>>>> > proprietary).
>>>> >
>>>> > 0. Definitions
>>>> >
>>>> > "Covered Code" is any source code and/or object code of Autoconf
>>>> > that is a
>>>> > covered work under this License.
>>>> >
>>>> > "Eligible Output Material" is Covered Code that is included in the
>>>> > standard, minimally verbose, non-debugging and non-tracing output of
>>>> > the
>>>> > version of Autoconf distributed to you under this License.
>>>> Moreover,
>>>> > "Eligible Output Material" may be comprised only of Covered Code
>>>> > that (a)
>>>> > must necessarily appear in Autoconf-generated configure scripts and
>>>> > (b) is
>>>> > required for those configure scripts to function.
>>>> >
>>>> > "Ineligible Output Material" is Covered Code that is not Eligible
>>>> > Output
>>>> > Material.
>>>> >
>>>> > 1. Grant of Additional Permission.
>>>> >
>>>> > You have permission to propagate output of Autoconf, even if such
>>>> > propagation would otherwise violate the terms of GPLv3. However, if
>>>> > you
>>>> > cause Autoconf to output any Ineligible Output Material, you do not
>>>> > have
>>>> > permission to convey the resulting covered work under this Exception
>>>> > and
>>>> > you must remove this Exception in accordance with the second
>>>> > paragraph of
>>>> > GPLv3's Section 7.
>>>> >
>>>> > 2. No Weakening of Autoconf Copyleft.
>>>> >
>>>> > The availability of this Exception does not imply any general
>>>> > presumption
>>>> > that third-party software is unaffected by the copyleft requirements
>>>> > of
>>>> > the license of Autoconf.
>>>> >
>>>> > --- cut ---
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> Jeff Squyres
>>>> Cisco Systems
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>
>>
>> --
>> 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
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

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