incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Sun, 26 Aug 2012 14:26:15 GMT
No.  There is NO WAY IN HELL the org can indemnify
a volunteer who produces a binary build themselves.

Please don't bother asking legal-discuss to tackle this.

The way liability works in an incorporated volunteer
charity is that you are not liable for "club" activities
performed without negligence on your part.  IANAL but
this is the whole point of the law surrounding this
area of human activity in the US.

Building software on 3rd party hosts which are not
operated by the org exposes you to the possibility
that your system may be compromised beyond what
is in source, and should you publish those artifacts
to ASF mirrors you could be held liable for any damages
your inattentiveness towards the system that produced
those packages may have caused.  Nothing the org can
do other than adopt an insane indemnity policy will
absolve a volunteer of that personal risk at this point.
However, if the org decides on a method of producing
production-quality builds itself and signs off on them itself
as an org, then clearly only the ASF, and any malicious or negligent
party, is exposed to any risks associated with widescale distribution.

If the software is built by an ASF host using ASF-maintained
software,  you might be able to make the case before a judge
that is was the ASF's fault for producing vulnerable builds
on a compromised host.  But you will have to plead that
before a judge at this point should you be named in a suit,
because we don't currently offer that level of management
in our build farms.

> From: Marvin Humphrey <>
>Sent: Sunday, August 26, 2012 10:09 AM
>Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
>On Sun, Aug 26, 2012 at 4:26 AM, Branko Čibej <> wrote:
>> On 26.08.2012 13:15, Tim Williams wrote:
>>> Marvin gave the link earlier in this thread. 4th para is the relevant bit.
>> The relevant part is in the last paragraph. However, that says
>> "convenience" and defines version numbering requirements, but it does
>> /not/ state that the binaries are not sanctioned by the ASF and are not
>> part of the official ASF release.
>> It would be very useful if that paragraph were amended to say so
>> explicitly. I've had no end of trouble trying to explain to managers and
>> customers that any binaries that come from the ASF are not "official".
>> Regardless of the policy stated numerous times in this thread and on
>> this list, this is not clear anywhere in the bylaws or other online
>> documentation (that I can find).
>The possibility exists that when the question is put to legal-discuss, we will
>find that Roy's missives have been misinterpreted, and that so long as the
>imperative of a clean source release (uncontaminated by e.g. embedded jar
>files) is satisfied, it is permissible for a PMC to sanction accompanying
>binary artifacts which are wholly derived from said clean source.
>It is also possible that the V.P. of Legal (who is a Board member) will kick
>the question up to the Board and that they will take up a full-blown
>resolution clarifying the policy.  Perhaps they will impose restrictions going
>forward such as the requirement that binaries to be blessed must be created
>via automatic processes kicked off by Infra on sterile build machines.  Or
>perhaps there won't be a resolution, but the discussion will produce a new
>common understanding that PMCs have so much autonomy they can "release" a
>peanut butter and jelly sandwich alongside the source code as an "act of the
>And yet another possibility is that the Legal VP will issue a narrowly
>tailored rulying stating that AOO may release blessed binaries while
>incubating, but that after graduation only binaries produced on sterile build
>machines may be blessed.
>Who knows?  We aren't going to resolve these questions on this list.
>In any case, I do not believe that it is in the best interests of either the
>ASF or the AOO podling (particularly those contributing towards the binary
>artifacts) for ambiguity to persist around issues of indemnification, and I
>don't think it's good for the ASF to walk backwards into a policy on binary
>releases accidentally.
>Apologies for keeping the zombie thread alive.  If it were up to me, it would
>have hopped forums some time ago.
>Marvin Humphrey
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message