You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Lawrence Rosen <lr...@rosenlaw.com> on 2014/05/24 21:08:48 UTC
Clarification about D&O insurance and bad acts
[This is an aside for the "ASF Release Policy" discussion.]
I wrote this earlier:
> I can assure you that there are things that individuals could do here that
would get them in trouble. :-)
One of the first plaintiffs I ever represented was a welfare recipient who
was sexually abused by her county social worker. Although this was obviously
outside the scope of his official responsibilities, the defendant county was
forced to pay for legal counsel to protect itself from civil damages. That
California county was self-insured; ASF buys D&O insurance for similar
reasons.
A few years ago there was discussion on various FOSS lists about how women
are sometimes harassed at technical conferences. That is an example of a bad
act that can force ASF to defend its own official anti-harassment policies
using its D&O insurance (assuming that such alleged bad acts are covered by
the specific insurance policy), but the bad actor himself has his own
individual legal problems too! That is why ASF directors and officers are
encouraged to behave themselves at our conferences, for their own sake and
for the sake of our insurance deductible!
You obviously are more concerned here about what ASF projects do with their
software, and our "Release Policy" (as revised) has had a long thread here.
But as long as individual PMC members comply in good faith with an approved
ASF release policy, it shouldn't matter much what policy we finally approve.
Courts don't usually fault non-profits for developing their own rational
policies, and we have D&O insurance to protect us - and our directors and
officers doing their official acts - if we follow a rational release policy.
This is a long and partly rambling message to suggest that the discussion
about the ASF Release Policy isn't really a legal issue at all and probably
doesn't belong on this list. Define a rational policy and the law won't
interfere.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
Cell: 707-478-8932 eFax: 707-485-1243
From: Lawrence Rosen [mailto:lrosen@rosenlaw.com]
Sent: Saturday, May 24, 2014 11:10 AM
To: legal-discuss@apache.org
Cc: Lawrence Rosen
Subject: RE: Release Policy
'Twas written on this list:
> "But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release manager
already for all bona fides cases. End of story."
Is the above statement incorrect also?
The above statement is only part of the story. ASF has a fully-functioning
board of directors and complies (AFAIK) with all relevant laws. ASF obtains
D&O insurance to protect itself and its directors and officers from many
kinds of liability for negligence and to provide legal representation if
necessary. That is enough to encourage us to proceed with our activities
without worrying about random lawsuits.
"Bona fide cases" is not useful terminology in this context. I can assure
you that there are things that individuals could do here that would get them
in trouble. :-) If there is something specific you are worried about, speak
up.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
Cell: 707-478-8932 Fax: 707-485-1243
From: Dave Fisher [ <ma...@comcast.net>
mailto:dave2wave@comcast.net]
Sent: Saturday, May 24, 2014 10:41 AM
To: <ma...@apache.org> legal-discuss@apache.org
Subject: Re: Release Policy
On May 23, 2014, at 1:51 PM, Brian LeRoux wrote:
Ok, so end user software needs a vote to be a release and all projects are
doing this without exception. If they are that is bad. Got it.
Earlier:
"But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release manager
already for all bona fides cases. End of story."
Is the above statement incorrect also?
On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <markt@apache.org
<ma...@apache.org> > wrote:
On 23/05/2014 21:04, Joe Bowser wrote:
> On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pescetti@apache.org
<ma...@apache.org> > wrote:
>> On 23/05/2014 Brian LeRoux wrote:
>>>
>>> Furthermore some projects such as OpenOffice mentioned
>>> earlier do not follow the policy.
>>
>>
>> OpenOffice does follow the policy. The only "special" thing OpenOffice
did
>> is to advertise development snapshots towards version 4.1 (these are NOT
>> releases! we conduct formal votes on ALL releases, including beta
releases!)
>> outside the dev mailing list since we have a dedicated QA mailing lists
and
>> a testers community that does not coincide with our developers. And this
was
>> discussed in advance with both the board and the infrastructure lists.
>>
>
> So, a snapshot is not a release?
A snapshot is a release if only if it has been voted on as such by the
PMC. It would also have to be tagged as part of the release which to my
mind means it isn't really a snapshot. However the label that is
attached to the release (RC, beta, stable, snapshot, etc.) is
irrelevant. What matters is did the PMC vote on it. It the PMC voted
(and assuming the rest of the release policy was followed) and the vote
passed, it is a release. If that didn't happen then it isn't a release.
> The problem is that there is one rule
> for certain projects that have the board's favour and another for
> projects that the board chooses to pick on for unknown reasons.
Please provide some evidence to back up that assertion. I have been
following a reasonable proportion if the discussion around Cordova and
releases and, while I have seen plenty of evidence that the Cordova
community doesn't like the constraints imposed by the ASF release
policy, I have seen no evidence of the board doing anything other than
requiring Cordova to follow the same release policy every other ASF
project is expected to follow.
If you are aware of any other ASF project not following the ASF release
policy then please make the board aware. The board does not actively
monitor the day to day activities of every project. If there are
problems they rely on the VP to make them aware via the quarterly
reports and if that route fails they rely on others in and around the
project to bring the problem to their attention.
> Why isn't a snapshot build a release?
Short answer - because the PMC didn't vote. Long answer - see above.
In this particular case this was not an OpenOffice release because it
was not advertised to the end-user community for that software. It is
perfectly within the intent of the current policy to include members of
dedicated QA and test lists in the same category as members of the dev
list. It is to the credit of the OpenOffice community that they went as
far as checking that their understanding of the policy was correct
before they did anything.
The snapshots are very carefully fenced as a developer / qa resource in
order to assure that when a release was made it would be of the highest
quality.
The PMC waited for complete consensus on the process and that took time - a
number of weeks.
Andrea did a very careful job communicating well within the ASF.
What would not be acceptable would be for OpenOffice to start
advertising snapshots to their end-user community unless votes had taken
place and those snapshots had been formally released.
Exactly.
Regards,
Dave
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org
<ma...@apache.org>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
But when the "final" QA is done, it tests the entity as a
whole. So it's not so much the individual "bits" that
get tested, but the completed and combined work.
For us, the normal day-to-day effort of how we develop
and backport/commit changes are the sort of "piece part"
QA tests... The release is the whole shebang.
In this way, a comparison with an automobile, not a toy,
would be closer to the truth. Or a craft beer:
"All the hops are fine: +1; All the malt is good: +1;
Water passes all purity tests: +1; fermentation going
as planned: +1... etc...
Geez. This tastes like shit."
:)
On May 29, 2014, at 12:00 PM, Stephen Connolly <st...@gmail.com> wrote:
> On 29 May 2014 16:55, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On May 29, 2014, at 11:50 AM, Stephen Connolly <st...@gmail.com> wrote:
>
> > On 29 May 2014 16:07, Jim Jagielski <ji...@jagunet.com> wrote:
> > Except we don't make a "batch" of toys... Just one.
> >
> > I think you are counting wrong!
> >
> > The release.src.tar.gz is the batch...
> >
> > Depending on how you look at it, it is either a batch of files or a batch of commits.
>
> That's like looking at "a toy" and saying it's a batch of parts... :)
>
> Well a file is a batch of bytes... you put the bytes together to make the file... Oh and you can play with a file and break it into its constituent parts... and if you break it into all its parts and jumble them up again it can be very hard to put the file back together the way it was before you broke it apart (you should see my son play with Lego)
>
> I think the "release == batch" analogy still holds ;-)
>
>
> >
> > So the QA analogy is that you inspect some (or none... it's a random thing ;-) ) of the files to ensure that they have the license details and that the commit history of the file is good and ... etc
> >
> > Or if you want to view as a batch of commits, you pick some/none (random sampling again) of the commits that is new to the release and trace them.
> >
> > Our releases are not toys ;-)
> >
> >
> > Which makes the QA job easier... right? The reason they don't
> > QA all is because they don't have the time and resources.
> >
> > And we don't have the time and resources to do the full set of checks that we need to do... heck I'm not even 100% certain of the full set of checks... mostly I just:
> >
> > * checks the commits since the last release to see if there is anything strange or an atypical committer
> > * check the RAT report
> > * check that it matches source control + the files generated via consistent repeatable processes
> > * check that it builds and (where present) tests pass
> > * maybe give it a sanity test
> > * cross my fingers and hope I have remembered everything that I am supposed to do.
> >
> > Worse still, I'm the PMC chair and I remember reading that the PMC chair role has added responsibilities from a legal perspective (I am sure these are covered by the insurance... but it's a worry)
> >
> > And some places *do* QA each and every thing that
> > goes out, and take great pride in doing so.
> >
> > On May 29, 2014, at 10:54 AM, Stephen Connolly <st...@gmail.com> wrote:
> >
> > > Actually I like the QA analogy ;-)
> > >
> > > And a QA department is not going to check every toy in every batch of toys.... instead they will do a random check... either checking one toy at random in each batch (or a fraction of batches), or checking all toys in a small fraction of batches.
> > >
> > > So following the QA analogy, if each PMC member does some random spot-checks as a QA assurance that the required buts are present... would that be OK?
> > >
> > >
> > > On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
> > > +1
> > >
> > > Think about it like a QA department of a production line in a company building children toys.
> > >
> > > Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
> > >
> > > Now what would happen if such a failure really appears? They would sue the hell out of this company...
> > >
> > > By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
> > >
> > > LieGrue,
> > > strub
> > >
> > > --------------------------------------------
> > > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> > >
> > > Subject: Re: Clarification about D&O insurance and bad acts
> > > To: legal-discuss@apache.org
> > > Date: Thursday, 29 May, 2014, 13:49
> > >
> > > Not sure what you mean by
> > > that... One of the aspects
> > > of verifying a
> > > release is checking that the bits going out
> > > are, in fact, the expected and correct bits...
> > > which sounds
> > > like src verification to me.
> > > And is, obviously, appropriate
> > > and
> > > necessary.
> > >
> > > On May 28, 2014,
> > > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Agreed! That said, src
> > > verification for releases is not always appropriate or
> > > necessary. (Depending on the project, the people and their
> > > unique attributes.)
> > > >
> > > > On May 28, 2014 1:01 PM, "Jim
> > > Jagielski" <ji...@jagunet.com>
> > > wrote:
> > > > That is true. But doing normal
> > > work-in-progress, and the
> > > > oversight
> > > thereof, is a different thing than doing a
> > > > release.
> > > >
> > > > One does not negate the other, nor does it
> > > remove the
> > > > need for the other. Saying
> > > "we do X oversight for our day
> > > > to
> > > day development" does not mean that no oversight is
> > > > needed for a release, simply because
> > > it's a different
> > > > kind of oversight
> > > for a different kind of activity.
> > > >
> > > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > > <b...@brian.io> wrote:
> > > >
> > > > > We could both
> > > wax hypothetical about the merit of humans and error
> > > proneness. My point is whatever is work-in-progress is a
> > > daily responsibility and not something to be left for the
> > > last minute check by others. Ever.
> > > >
> > > >
> > > > >
> > > > > On
> > > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> > > wrote:
> > > > > Brian, you are absolutely
> > > correct. However, SVN is not the release and so having
> > > reviewed commits is not the same as having reviewed the
> > > release. In a well run project where people are reviewing
> > > code commits there should be no problem. But people make
> > > errors and you would be surprised how often those errors
> > > slip through.
> > > > >
> > > >
> > > > Furthermore, since I (as a committer) cannot guarantee
> > > that I reviewed every change to every file between release a
> > > and release b I cannot, as a PMC member, be certain that the
> > > necessary files are present and correct. If I were to vote
> > > +1 without having reviewed the release then my vote would be
> > > worthless when it comes to demonstrating that our policy has
> > > been followed for that release.
> > > > >
> > > > > Ross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 27 May
> > > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > > From my perspective this is a daily
> > > requirement of a responsible committer. That final check
> > > isn't hurting anything but it is not even remotely
> > > acceptable for a committer to not be constantly vigilant
> > > when landing commits to our source.
> > > >
> > > >
> > > > >
> > > > > On
> > > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > > wrote:
> > > > > Ross Gardler wrote:
> > > > >
> > > > > > In my
> > > mind (and I am not a lawyer so that means almost nothing in
> > > these situations) the requirement to have 3 PMC members
> > > indicate that, to the best of their knowledge, the release
> > > is compliant with the policy is sufficient.
> > > > >
> > > > >
> > > > >
> > > > > Leaving my
> > > lawyer hat off for a bit, it seems so to me too. I'm not
> > > worried. I wasn't even worried about that when I served
> > > on the board. /Larry
> > > > >
> > > > >
> > > > >
> > > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > > Sent: Saturday, May 24, 2014 8:08
> > > PM
> > > > > To: legal-discuss@apache.org;
> > > Larry Rosen
> > > > > Subject: Re:
> > > Clarification about D&O insurance and bad acts
> > > > >
> > > > >
> > > <snip>
> > > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > > For additional commands, e-mail: legal-discuss-help@apache.org
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Stephen Connolly <st...@gmail.com>.
On 29 May 2014 16:55, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On May 29, 2014, at 11:50 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 29 May 2014 16:07, Jim Jagielski <ji...@jagunet.com> wrote:
> > Except we don't make a "batch" of toys... Just one.
> >
> > I think you are counting wrong!
> >
> > The release.src.tar.gz is the batch...
> >
> > Depending on how you look at it, it is either a batch of files or a
> batch of commits.
>
> That's like looking at "a toy" and saying it's a batch of parts... :)
>
Well a file is a batch of bytes... you put the bytes together to make the
file... Oh and you can play with a file and break it into its constituent
parts... and if you break it into all its parts and jumble them up again it
can be very hard to put the file back together the way it was before you
broke it apart (you should see my son play with Lego)
I think the "release == batch" analogy still holds ;-)
>
> >
> > So the QA analogy is that you inspect some (or none... it's a random
> thing ;-) ) of the files to ensure that they have the license details and
> that the commit history of the file is good and ... etc
> >
> > Or if you want to view as a batch of commits, you pick some/none (random
> sampling again) of the commits that is new to the release and trace them.
> >
> > Our releases are not toys ;-)
> >
> >
> > Which makes the QA job easier... right? The reason they don't
> > QA all is because they don't have the time and resources.
> >
> > And we don't have the time and resources to do the full set of checks
> that we need to do... heck I'm not even 100% certain of the full set of
> checks... mostly I just:
> >
> > * checks the commits since the last release to see if there is anything
> strange or an atypical committer
> > * check the RAT report
> > * check that it matches source control + the files generated via
> consistent repeatable processes
> > * check that it builds and (where present) tests pass
> > * maybe give it a sanity test
> > * cross my fingers and hope I have remembered everything that I am
> supposed to do.
> >
> > Worse still, I'm the PMC chair and I remember reading that the PMC chair
> role has added responsibilities from a legal perspective (I am sure these
> are covered by the insurance... but it's a worry)
> >
> > And some places *do* QA each and every thing that
> > goes out, and take great pride in doing so.
> >
> > On May 29, 2014, at 10:54 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> >
> > > Actually I like the QA analogy ;-)
> > >
> > > And a QA department is not going to check every toy in every batch of
> toys.... instead they will do a random check... either checking one toy at
> random in each batch (or a fraction of batches), or checking all toys in a
> small fraction of batches.
> > >
> > > So following the QA analogy, if each PMC member does some random
> spot-checks as a QA assurance that the required buts are present... would
> that be OK?
> > >
> > >
> > > On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
> > > +1
> > >
> > > Think about it like a QA department of a production line in a company
> building children toys.
> > >
> > > Of course all employees take care to not introduce a failure which
> might harm children. But even then it _might_ happen.
> > >
> > > Now what would happen if such a failure really appears? They would sue
> the hell out of this company...
> > >
> > > By having a QA department which does an independent check if all is
> fine over and over again this risk might get reduced. And even if a failure
> still slips through it will help the company to not get hit too hard at
> least.
> > >
> > > LieGrue,
> > > strub
> > >
> > > --------------------------------------------
> > > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> > >
> > > Subject: Re: Clarification about D&O insurance and bad acts
> > > To: legal-discuss@apache.org
> > > Date: Thursday, 29 May, 2014, 13:49
> > >
> > > Not sure what you mean by
> > > that... One of the aspects
> > > of verifying a
> > > release is checking that the bits going out
> > > are, in fact, the expected and correct bits...
> > > which sounds
> > > like src verification to me.
> > > And is, obviously, appropriate
> > > and
> > > necessary.
> > >
> > > On May 28, 2014,
> > > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Agreed! That said, src
> > > verification for releases is not always appropriate or
> > > necessary. (Depending on the project, the people and their
> > > unique attributes.)
> > > >
> > > > On May 28, 2014 1:01 PM, "Jim
> > > Jagielski" <ji...@jagunet.com>
> > > wrote:
> > > > That is true. But doing normal
> > > work-in-progress, and the
> > > > oversight
> > > thereof, is a different thing than doing a
> > > > release.
> > > >
> > > > One does not negate the other, nor does it
> > > remove the
> > > > need for the other. Saying
> > > "we do X oversight for our day
> > > > to
> > > day development" does not mean that no oversight is
> > > > needed for a release, simply because
> > > it's a different
> > > > kind of oversight
> > > for a different kind of activity.
> > > >
> > > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > > <b...@brian.io> wrote:
> > > >
> > > > > We could both
> > > wax hypothetical about the merit of humans and error
> > > proneness. My point is whatever is work-in-progress is a
> > > daily responsibility and not something to be left for the
> > > last minute check by others. Ever.
> > > >
> > > >
> > > > >
> > > > > On
> > > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <
> rgardler@opendirective.com>
> > > wrote:
> > > > > Brian, you are absolutely
> > > correct. However, SVN is not the release and so having
> > > reviewed commits is not the same as having reviewed the
> > > release. In a well run project where people are reviewing
> > > code commits there should be no problem. But people make
> > > errors and you would be surprised how often those errors
> > > slip through.
> > > > >
> > > >
> > > > Furthermore, since I (as a committer) cannot guarantee
> > > that I reviewed every change to every file between release a
> > > and release b I cannot, as a PMC member, be certain that the
> > > necessary files are present and correct. If I were to vote
> > > +1 without having reviewed the release then my vote would be
> > > worthless when it comes to demonstrating that our policy has
> > > been followed for that release.
> > > > >
> > > > > Ross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 27 May
> > > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > > From my perspective this is a daily
> > > requirement of a responsible committer. That final check
> > > isn't hurting anything but it is not even remotely
> > > acceptable for a committer to not be constantly vigilant
> > > when landing commits to our source.
> > > >
> > > >
> > > > >
> > > > > On
> > > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > > wrote:
> > > > > Ross Gardler wrote:
> > > > >
> > > > > > In my
> > > mind (and I am not a lawyer so that means almost nothing in
> > > these situations) the requirement to have 3 PMC members
> > > indicate that, to the best of their knowledge, the release
> > > is compliant with the policy is sufficient.
> > > > >
> > > > >
> > > > >
> > > > > Leaving my
> > > lawyer hat off for a bit, it seems so to me too. I'm not
> > > worried. I wasn't even worried about that when I served
> > > on the board. /Larry
> > > > >
> > > > >
> > > > >
> > > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > > Sent: Saturday, May 24, 2014 8:08
> > > PM
> > > > > To: legal-discuss@apache.org;
> > > Larry Rosen
> > > > > Subject: Re:
> > > Clarification about D&O insurance and bad acts
> > > > >
> > > > >
> > > <snip>
> > > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > > For additional commands, e-mail: legal-discuss-help@apache.org
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 29, 2014, at 11:50 AM, Stephen Connolly <st...@gmail.com> wrote:
> On 29 May 2014 16:07, Jim Jagielski <ji...@jagunet.com> wrote:
> Except we don't make a "batch" of toys... Just one.
>
> I think you are counting wrong!
>
> The release.src.tar.gz is the batch...
>
> Depending on how you look at it, it is either a batch of files or a batch of commits.
That's like looking at "a toy" and saying it's a batch of parts... :)
>
> So the QA analogy is that you inspect some (or none... it's a random thing ;-) ) of the files to ensure that they have the license details and that the commit history of the file is good and ... etc
>
> Or if you want to view as a batch of commits, you pick some/none (random sampling again) of the commits that is new to the release and trace them.
>
> Our releases are not toys ;-)
>
>
> Which makes the QA job easier... right? The reason they don't
> QA all is because they don't have the time and resources.
>
> And we don't have the time and resources to do the full set of checks that we need to do... heck I'm not even 100% certain of the full set of checks... mostly I just:
>
> * checks the commits since the last release to see if there is anything strange or an atypical committer
> * check the RAT report
> * check that it matches source control + the files generated via consistent repeatable processes
> * check that it builds and (where present) tests pass
> * maybe give it a sanity test
> * cross my fingers and hope I have remembered everything that I am supposed to do.
>
> Worse still, I'm the PMC chair and I remember reading that the PMC chair role has added responsibilities from a legal perspective (I am sure these are covered by the insurance... but it's a worry)
>
> And some places *do* QA each and every thing that
> goes out, and take great pride in doing so.
>
> On May 29, 2014, at 10:54 AM, Stephen Connolly <st...@gmail.com> wrote:
>
> > Actually I like the QA analogy ;-)
> >
> > And a QA department is not going to check every toy in every batch of toys.... instead they will do a random check... either checking one toy at random in each batch (or a fraction of batches), or checking all toys in a small fraction of batches.
> >
> > So following the QA analogy, if each PMC member does some random spot-checks as a QA assurance that the required buts are present... would that be OK?
> >
> >
> > On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
> > +1
> >
> > Think about it like a QA department of a production line in a company building children toys.
> >
> > Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
> >
> > Now what would happen if such a failure really appears? They would sue the hell out of this company...
> >
> > By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
> >
> > LieGrue,
> > strub
> >
> > --------------------------------------------
> > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > Subject: Re: Clarification about D&O insurance and bad acts
> > To: legal-discuss@apache.org
> > Date: Thursday, 29 May, 2014, 13:49
> >
> > Not sure what you mean by
> > that... One of the aspects
> > of verifying a
> > release is checking that the bits going out
> > are, in fact, the expected and correct bits...
> > which sounds
> > like src verification to me.
> > And is, obviously, appropriate
> > and
> > necessary.
> >
> > On May 28, 2014,
> > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Agreed! That said, src
> > verification for releases is not always appropriate or
> > necessary. (Depending on the project, the people and their
> > unique attributes.)
> > >
> > > On May 28, 2014 1:01 PM, "Jim
> > Jagielski" <ji...@jagunet.com>
> > wrote:
> > > That is true. But doing normal
> > work-in-progress, and the
> > > oversight
> > thereof, is a different thing than doing a
> > > release.
> > >
> > > One does not negate the other, nor does it
> > remove the
> > > need for the other. Saying
> > "we do X oversight for our day
> > > to
> > day development" does not mean that no oversight is
> > > needed for a release, simply because
> > it's a different
> > > kind of oversight
> > for a different kind of activity.
> > >
> > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > <b...@brian.io> wrote:
> > >
> > > > We could both
> > wax hypothetical about the merit of humans and error
> > proneness. My point is whatever is work-in-progress is a
> > daily responsibility and not something to be left for the
> > last minute check by others. Ever.
> > >
> > >
> > > >
> > > > On
> > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> > wrote:
> > > > Brian, you are absolutely
> > correct. However, SVN is not the release and so having
> > reviewed commits is not the same as having reviewed the
> > release. In a well run project where people are reviewing
> > code commits there should be no problem. But people make
> > errors and you would be surprised how often those errors
> > slip through.
> > > >
> > >
> > > Furthermore, since I (as a committer) cannot guarantee
> > that I reviewed every change to every file between release a
> > and release b I cannot, as a PMC member, be certain that the
> > necessary files are present and correct. If I were to vote
> > +1 without having reviewed the release then my vote would be
> > worthless when it comes to demonstrating that our policy has
> > been followed for that release.
> > > >
> > > > Ross
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 27 May
> > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > From my perspective this is a daily
> > requirement of a responsible committer. That final check
> > isn't hurting anything but it is not even remotely
> > acceptable for a committer to not be constantly vigilant
> > when landing commits to our source.
> > >
> > >
> > > >
> > > > On
> > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > wrote:
> > > > Ross Gardler wrote:
> > > >
> > > > > In my
> > mind (and I am not a lawyer so that means almost nothing in
> > these situations) the requirement to have 3 PMC members
> > indicate that, to the best of their knowledge, the release
> > is compliant with the policy is sufficient.
> > > >
> > > >
> > > >
> > > > Leaving my
> > lawyer hat off for a bit, it seems so to me too. I'm not
> > worried. I wasn't even worried about that when I served
> > on the board. /Larry
> > > >
> > > >
> > > >
> > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > Sent: Saturday, May 24, 2014 8:08
> > PM
> > > > To: legal-discuss@apache.org;
> > Larry Rosen
> > > > Subject: Re:
> > Clarification about D&O insurance and bad acts
> > > >
> > > >
> > <snip>
> > > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Stephen Connolly <st...@gmail.com>.
On 29 May 2014 16:07, Jim Jagielski <ji...@jagunet.com> wrote:
> Except we don't make a "batch" of toys... Just one.
>
I think you are counting wrong!
The release.src.tar.gz is the batch...
Depending on how you look at it, it is either a batch of files or a batch
of commits.
So the QA analogy is that you inspect some (or none... it's a random thing
;-) ) of the files to ensure that they have the license details and that
the commit history of the file is good and ... etc
Or if you want to view as a batch of commits, you pick some/none (random
sampling again) of the commits that is new to the release and trace them.
Our releases are not toys ;-)
>
> Which makes the QA job easier... right? The reason they don't
> QA all is because they don't have the time and resources.
>
And we don't have the time and resources to do the full set of checks that
we need to do... heck I'm not even 100% certain of the full set of
checks... mostly I just:
* checks the commits since the last release to see if there is anything
strange or an atypical committer
* check the RAT report
* check that it matches source control + the files generated via consistent
repeatable processes
* check that it builds and (where present) tests pass
* maybe give it a sanity test
* cross my fingers and hope I have remembered everything that I am supposed
to do.
Worse still, I'm the PMC chair and I remember reading that the PMC chair
role has added responsibilities from a legal perspective (I am sure these
are covered by the insurance... but it's a worry)
> And some places *do* QA each and every thing that
> goes out, and take great pride in doing so.
>
> On May 29, 2014, at 10:54 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > Actually I like the QA analogy ;-)
> >
> > And a QA department is not going to check every toy in every batch of
> toys.... instead they will do a random check... either checking one toy at
> random in each batch (or a fraction of batches), or checking all toys in a
> small fraction of batches.
> >
> > So following the QA analogy, if each PMC member does some random
> spot-checks as a QA assurance that the required buts are present... would
> that be OK?
> >
> >
> > On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
> > +1
> >
> > Think about it like a QA department of a production line in a company
> building children toys.
> >
> > Of course all employees take care to not introduce a failure which might
> harm children. But even then it _might_ happen.
> >
> > Now what would happen if such a failure really appears? They would sue
> the hell out of this company...
> >
> > By having a QA department which does an independent check if all is fine
> over and over again this risk might get reduced. And even if a failure
> still slips through it will help the company to not get hit too hard at
> least.
> >
> > LieGrue,
> > strub
> >
> > --------------------------------------------
> > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > Subject: Re: Clarification about D&O insurance and bad acts
> > To: legal-discuss@apache.org
> > Date: Thursday, 29 May, 2014, 13:49
> >
> > Not sure what you mean by
> > that... One of the aspects
> > of verifying a
> > release is checking that the bits going out
> > are, in fact, the expected and correct bits...
> > which sounds
> > like src verification to me.
> > And is, obviously, appropriate
> > and
> > necessary.
> >
> > On May 28, 2014,
> > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Agreed! That said, src
> > verification for releases is not always appropriate or
> > necessary. (Depending on the project, the people and their
> > unique attributes.)
> > >
> > > On May 28, 2014 1:01 PM, "Jim
> > Jagielski" <ji...@jagunet.com>
> > wrote:
> > > That is true. But doing normal
> > work-in-progress, and the
> > > oversight
> > thereof, is a different thing than doing a
> > > release.
> > >
> > > One does not negate the other, nor does it
> > remove the
> > > need for the other. Saying
> > "we do X oversight for our day
> > > to
> > day development" does not mean that no oversight is
> > > needed for a release, simply because
> > it's a different
> > > kind of oversight
> > for a different kind of activity.
> > >
> > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > <b...@brian.io> wrote:
> > >
> > > > We could both
> > wax hypothetical about the merit of humans and error
> > proneness. My point is whatever is work-in-progress is a
> > daily responsibility and not something to be left for the
> > last minute check by others. Ever.
> > >
> > >
> > > >
> > > > On
> > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> > wrote:
> > > > Brian, you are absolutely
> > correct. However, SVN is not the release and so having
> > reviewed commits is not the same as having reviewed the
> > release. In a well run project where people are reviewing
> > code commits there should be no problem. But people make
> > errors and you would be surprised how often those errors
> > slip through.
> > > >
> > >
> > > Furthermore, since I (as a committer) cannot guarantee
> > that I reviewed every change to every file between release a
> > and release b I cannot, as a PMC member, be certain that the
> > necessary files are present and correct. If I were to vote
> > +1 without having reviewed the release then my vote would be
> > worthless when it comes to demonstrating that our policy has
> > been followed for that release.
> > > >
> > > > Ross
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 27 May
> > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > From my perspective this is a daily
> > requirement of a responsible committer. That final check
> > isn't hurting anything but it is not even remotely
> > acceptable for a committer to not be constantly vigilant
> > when landing commits to our source.
> > >
> > >
> > > >
> > > > On
> > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > wrote:
> > > > Ross Gardler wrote:
> > > >
> > > > > In my
> > mind (and I am not a lawyer so that means almost nothing in
> > these situations) the requirement to have 3 PMC members
> > indicate that, to the best of their knowledge, the release
> > is compliant with the policy is sufficient.
> > > >
> > > >
> > > >
> > > > Leaving my
> > lawyer hat off for a bit, it seems so to me too. I'm not
> > worried. I wasn't even worried about that when I served
> > on the board. /Larry
> > > >
> > > >
> > > >
> > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > Sent: Saturday, May 24, 2014 8:08
> > PM
> > > > To: legal-discuss@apache.org;
> > Larry Rosen
> > > > Subject: Re:
> > Clarification about D&O insurance and bad acts
> > > >
> > > >
> > <snip>
> > > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
Except we don't make a "batch" of toys... Just one.
Which makes the QA job easier... right? The reason they don't
QA all is because they don't have the time and resources.
And some places *do* QA each and every thing that
goes out, and take great pride in doing so.
On May 29, 2014, at 10:54 AM, Stephen Connolly <st...@gmail.com> wrote:
> Actually I like the QA analogy ;-)
>
> And a QA department is not going to check every toy in every batch of toys.... instead they will do a random check... either checking one toy at random in each batch (or a fraction of batches), or checking all toys in a small fraction of batches.
>
> So following the QA analogy, if each PMC member does some random spot-checks as a QA assurance that the required buts are present... would that be OK?
>
>
> On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
> +1
>
> Think about it like a QA department of a production line in a company building children toys.
>
> Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
>
> Now what would happen if such a failure really appears? They would sue the hell out of this company...
>
> By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
>
> LieGrue,
> strub
>
> --------------------------------------------
> On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Subject: Re: Clarification about D&O insurance and bad acts
> To: legal-discuss@apache.org
> Date: Thursday, 29 May, 2014, 13:49
>
> Not sure what you mean by
> that... One of the aspects
> of verifying a
> release is checking that the bits going out
> are, in fact, the expected and correct bits...
> which sounds
> like src verification to me.
> And is, obviously, appropriate
> and
> necessary.
>
> On May 28, 2014,
> at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Agreed! That said, src
> verification for releases is not always appropriate or
> necessary. (Depending on the project, the people and their
> unique attributes.)
> >
> > On May 28, 2014 1:01 PM, "Jim
> Jagielski" <ji...@jagunet.com>
> wrote:
> > That is true. But doing normal
> work-in-progress, and the
> > oversight
> thereof, is a different thing than doing a
> > release.
> >
> > One does not negate the other, nor does it
> remove the
> > need for the other. Saying
> "we do X oversight for our day
> > to
> day development" does not mean that no oversight is
> > needed for a release, simply because
> it's a different
> > kind of oversight
> for a different kind of activity.
> >
> > On May 27, 2014, at 5:22 PM, Brian LeRoux
> <b...@brian.io> wrote:
> >
> > > We could both
> wax hypothetical about the merit of humans and error
> proneness. My point is whatever is work-in-progress is a
> daily responsibility and not something to be left for the
> last minute check by others. Ever.
> >
> >
> > >
> > > On
> Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> wrote:
> > > Brian, you are absolutely
> correct. However, SVN is not the release and so having
> reviewed commits is not the same as having reviewed the
> release. In a well run project where people are reviewing
> code commits there should be no problem. But people make
> errors and you would be surprised how often those errors
> slip through.
> > >
> >
> > Furthermore, since I (as a committer) cannot guarantee
> that I reviewed every change to every file between release a
> and release b I cannot, as a PMC member, be certain that the
> necessary files are present and correct. If I were to vote
> +1 without having reviewed the release then my vote would be
> worthless when it comes to demonstrating that our policy has
> been followed for that release.
> > >
> > > Ross
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 27 May
> 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > From my perspective this is a daily
> requirement of a responsible committer. That final check
> isn't hurting anything but it is not even remotely
> acceptable for a committer to not be constantly vigilant
> when landing commits to our source.
> >
> >
> > >
> > > On
> Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> wrote:
> > > Ross Gardler wrote:
> > >
> > > > In my
> mind (and I am not a lawyer so that means almost nothing in
> these situations) the requirement to have 3 PMC members
> indicate that, to the best of their knowledge, the release
> is compliant with the policy is sufficient.
> > >
> > >
> > >
> > > Leaving my
> lawyer hat off for a bit, it seems so to me too. I'm not
> worried. I wasn't even worried about that when I served
> on the board. /Larry
> > >
> > >
> > >
> > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > Sent: Saturday, May 24, 2014 8:08
> PM
> > > To: legal-discuss@apache.org;
> Larry Rosen
> > > Subject: Re:
> Clarification about D&O insurance and bad acts
> > >
> > >
> <snip>
> > >
> >
> >
> > >
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Stephen Connolly <st...@gmail.com>.
On 29 May 2014 15:54, Stephen Connolly <st...@gmail.com>
wrote:
> Actually I like the QA analogy ;-)
>
> And a QA department is not going to check every toy in every batch of
> toys.... instead they will do a random check... either checking one toy at
> random in each batch (or a fraction of batches), or checking all toys in a
> small fraction of batches.
>
Oh! and if they find a failure then they will obviously call halt and start
checking more... and only reduce the level of checks once things return to
normal.
>
> So following the QA analogy, if each PMC member does some random
> spot-checks as a QA assurance that the required buts are present... would
> that be OK?
>
>
> On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
>
>> +1
>>
>> Think about it like a QA department of a production line in a company
>> building children toys.
>>
>> Of course all employees take care to not introduce a failure which might
>> harm children. But even then it _might_ happen.
>>
>> Now what would happen if such a failure really appears? They would sue
>> the hell out of this company...
>>
>> By having a QA department which does an independent check if all is fine
>> over and over again this risk might get reduced. And even if a failure
>> still slips through it will help the company to not get hit too hard at
>> least.
>>
>> LieGrue,
>> strub
>>
>> --------------------------------------------
>> On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Subject: Re: Clarification about D&O insurance and bad acts
>> To: legal-discuss@apache.org
>> Date: Thursday, 29 May, 2014, 13:49
>>
>> Not sure what you mean by
>> that... One of the aspects
>> of verifying a
>> release is checking that the bits going out
>> are, in fact, the expected and correct bits...
>> which sounds
>> like src verification to me.
>> And is, obviously, appropriate
>> and
>> necessary.
>>
>> On May 28, 2014,
>> at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > Agreed! That said, src
>> verification for releases is not always appropriate or
>> necessary. (Depending on the project, the people and their
>> unique attributes.)
>> >
>> > On May 28, 2014 1:01 PM, "Jim
>> Jagielski" <ji...@jagunet.com>
>> wrote:
>> > That is true. But doing normal
>> work-in-progress, and the
>> > oversight
>> thereof, is a different thing than doing a
>> > release.
>> >
>> > One does not negate the other, nor does it
>> remove the
>> > need for the other. Saying
>> "we do X oversight for our day
>> > to
>> day development" does not mean that no oversight is
>> > needed for a release, simply because
>> it's a different
>> > kind of oversight
>> for a different kind of activity.
>> >
>> > On May 27, 2014, at 5:22 PM, Brian LeRoux
>> <b...@brian.io> wrote:
>> >
>> > > We could both
>> wax hypothetical about the merit of humans and error
>> proneness. My point is whatever is work-in-progress is a
>> daily responsibility and not something to be left for the
>> last minute check by others. Ever.
>> >
>> >
>> > >
>> > > On
>> Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
>> wrote:
>> > > Brian, you are absolutely
>> correct. However, SVN is not the release and so having
>> reviewed commits is not the same as having reviewed the
>> release. In a well run project where people are reviewing
>> code commits there should be no problem. But people make
>> errors and you would be surprised how often those errors
>> slip through.
>> > >
>> >
>> > Furthermore, since I (as a committer) cannot guarantee
>> that I reviewed every change to every file between release a
>> and release b I cannot, as a PMC member, be certain that the
>> necessary files are present and correct. If I were to vote
>> +1 without having reviewed the release then my vote would be
>> worthless when it comes to demonstrating that our policy has
>> been followed for that release.
>> > >
>> > > Ross
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On 27 May
>> 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
>> > > From my perspective this is a daily
>> requirement of a responsible committer. That final check
>> isn't hurting anything but it is not even remotely
>> acceptable for a committer to not be constantly vigilant
>> when landing commits to our source.
>> >
>> >
>> > >
>> > > On
>> Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
>> wrote:
>> > > Ross Gardler wrote:
>> > >
>> > > > In my
>> mind (and I am not a lawyer so that means almost nothing in
>> these situations) the requirement to have 3 PMC members
>> indicate that, to the best of their knowledge, the release
>> is compliant with the policy is sufficient.
>> > >
>> > >
>> > >
>> > > Leaving my
>> lawyer hat off for a bit, it seems so to me too. I'm not
>> worried. I wasn't even worried about that when I served
>> on the board. /Larry
>> > >
>> > >
>> > >
>> > > From: Ross Gardler [mailto:rgardler@opendirective.com]
>> > > Sent: Saturday, May 24, 2014 8:08
>> PM
>> > > To: legal-discuss@apache.org;
>> Larry Rosen
>> > > Subject: Re:
>> Clarification about D&O insurance and bad acts
>> > >
>> > >
>> <snip>
>> > >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
Re: Clarification about D&O insurance and bad acts
Posted by Stephen Connolly <st...@gmail.com>.
Actually I like the QA analogy ;-)
And a QA department is not going to check every toy in every batch of
toys.... instead they will do a random check... either checking one toy at
random in each batch (or a fraction of batches), or checking all toys in a
small fraction of batches.
So following the QA analogy, if each PMC member does some random
spot-checks as a QA assurance that the required buts are present... would
that be OK?
On 29 May 2014 13:14, Mark Struberg <st...@yahoo.de> wrote:
> +1
>
> Think about it like a QA department of a production line in a company
> building children toys.
>
> Of course all employees take care to not introduce a failure which might
> harm children. But even then it _might_ happen.
>
> Now what would happen if such a failure really appears? They would sue the
> hell out of this company...
>
> By having a QA department which does an independent check if all is fine
> over and over again this risk might get reduced. And even if a failure
> still slips through it will help the company to not get hit too hard at
> least.
>
> LieGrue,
> strub
>
> --------------------------------------------
> On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Subject: Re: Clarification about D&O insurance and bad acts
> To: legal-discuss@apache.org
> Date: Thursday, 29 May, 2014, 13:49
>
> Not sure what you mean by
> that... One of the aspects
> of verifying a
> release is checking that the bits going out
> are, in fact, the expected and correct bits...
> which sounds
> like src verification to me.
> And is, obviously, appropriate
> and
> necessary.
>
> On May 28, 2014,
> at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Agreed! That said, src
> verification for releases is not always appropriate or
> necessary. (Depending on the project, the people and their
> unique attributes.)
> >
> > On May 28, 2014 1:01 PM, "Jim
> Jagielski" <ji...@jagunet.com>
> wrote:
> > That is true. But doing normal
> work-in-progress, and the
> > oversight
> thereof, is a different thing than doing a
> > release.
> >
> > One does not negate the other, nor does it
> remove the
> > need for the other. Saying
> "we do X oversight for our day
> > to
> day development" does not mean that no oversight is
> > needed for a release, simply because
> it's a different
> > kind of oversight
> for a different kind of activity.
> >
> > On May 27, 2014, at 5:22 PM, Brian LeRoux
> <b...@brian.io> wrote:
> >
> > > We could both
> wax hypothetical about the merit of humans and error
> proneness. My point is whatever is work-in-progress is a
> daily responsibility and not something to be left for the
> last minute check by others. Ever.
> >
> >
> > >
> > > On
> Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> wrote:
> > > Brian, you are absolutely
> correct. However, SVN is not the release and so having
> reviewed commits is not the same as having reviewed the
> release. In a well run project where people are reviewing
> code commits there should be no problem. But people make
> errors and you would be surprised how often those errors
> slip through.
> > >
> >
> > Furthermore, since I (as a committer) cannot guarantee
> that I reviewed every change to every file between release a
> and release b I cannot, as a PMC member, be certain that the
> necessary files are present and correct. If I were to vote
> +1 without having reviewed the release then my vote would be
> worthless when it comes to demonstrating that our policy has
> been followed for that release.
> > >
> > > Ross
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 27 May
> 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > From my perspective this is a daily
> requirement of a responsible committer. That final check
> isn't hurting anything but it is not even remotely
> acceptable for a committer to not be constantly vigilant
> when landing commits to our source.
> >
> >
> > >
> > > On
> Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> wrote:
> > > Ross Gardler wrote:
> > >
> > > > In my
> mind (and I am not a lawyer so that means almost nothing in
> these situations) the requirement to have 3 PMC members
> indicate that, to the best of their knowledge, the release
> is compliant with the policy is sufficient.
> > >
> > >
> > >
> > > Leaving my
> lawyer hat off for a bit, it seems so to me too. I'm not
> worried. I wasn't even worried about that when I served
> on the board. /Larry
> > >
> > >
> > >
> > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > Sent: Saturday, May 24, 2014 8:08
> PM
> > > To: legal-discuss@apache.org;
> Larry Rosen
> > > Subject: Re:
> Clarification about D&O insurance and bad acts
> > >
> > >
> <snip>
> > >
> >
> >
> > >
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
Of course. I have specifically said that we should take
advantage of as many advances as possible. My point is
that there is a difference between what tools are used
and how/if they address the social implications behind
the process.
On Jun 2, 2014, at 5:53 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Thu, May 29, 2014 at 7:25 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> ...We have these policies in place because over the last ~19 years
>> (including pre-ASF days), they have proven to work...
>
> The world of IT has changed in 19 years, including the tools that we
> use and the nature and shape of the software that we release.
>
> While the root invariants of how we release software don't need to
> change, the *process* that we use to release can certainly be adapted
> to modern tools and practices like continuous integration, very
> frequent releases of very small modules, etc.
>
> This requires going back to what the invariants that govern releases
> actually are, as opposed to fighting on the details of the actual
> release processes.
>
> I have suggested a list of those invariants elsethread, at
> http://markmail.org/message/lal5ouukuoi5jvik
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, May 29, 2014 at 7:25 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> ...We have these policies in place because over the last ~19 years
> (including pre-ASF days), they have proven to work...
The world of IT has changed in 19 years, including the tools that we
use and the nature and shape of the software that we release.
While the root invariants of how we release software don't need to
change, the *process* that we use to release can certainly be adapted
to modern tools and practices like continuous integration, very
frequent releases of very small modules, etc.
This requires going back to what the invariants that govern releases
actually are, as opposed to fighting on the details of the actual
release processes.
I have suggested a list of those invariants elsethread, at
http://markmail.org/message/lal5ouukuoi5jvik
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 29, 2014, at 12:31 PM, Brian LeRoux <b...@brian.io> wrote:
> Ultimately I'm really, truly, striving to help the ASF streamline our ultimate premise: shipping software.
>
But the premise itself is based on, and guided by, other premises.
And they are "just" as important.
For example, one could argue that the whole equal-merit
concept bogs down development. To streamline shipping
software, we should do away with merit and have a BDFL.
Or that public discussion and transparency hinders our
ability to ship software, so we drop that. Or that poisonous
people are just fine, and we don't worry about them being
part of the community... etc.
But such things are part of who and what we are. They are
part of our DNA. They are part of what makes Apache, Apache.
Removing those, or changing those has significant effects
on things.
We have these policies in place because over the last ~19 years
(including pre-ASF days), they have proven to work. It's
not the only way to "ship software", but it's the way we've
chosen and it's been successful. Now sure we want to avoid
fluff and stupid, meaningless procedure, but it's been explained
that the reasoning has real, concrete rationale behind it.
It's disingenuous to suggest changing process with no knowledge
of why things are the way they are, or because you don't value
or understand the rationale. You fail to appreciate the *social*
importance of, for example, the 3 +1 vote for a release rule,
and hence see it as needless. Only by understanding the social
principles of the ASF can one then realistically see where
valid and potential changes can be made.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
My point is that disregarding the existing rules because one
doesn't agree with them, or thinks they are "old fashioned"
or because "other places do it differently" is NOT acting
in good faith.
As I said countless times: you are confusing our normal
day-to-day responsibility for the special and unique
circumstance of doing a release. It is not unnecessary
nor is it redundant.
On May 29, 2014, at 12:31 PM, Brian LeRoux <b...@brian.io> wrote:
> Quoting Larry, "..as long as individual PMC members comply in good faith with an approved ASF release policy, it shouldn't matter much what policy we finally approve "
>
> The reason we vote is to ensure compliance with our src legal requirements. The rational I question as an unnecessary redundancy given this is our daily responsibility for every commit we land. I deeply respect the history here. Do not confuse that. Ultimately I'm really, truly, striving to help the ASF streamline our ultimate premise: shipping software.
>
> On May 29, 2014 11:29 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Sure it is helpful. We have learned from them, and they
> have learned from us. However, the very fact that they
> do something different isn't sufficient for us to change
> a policy that we've had since before 1999... especially
> if the reason and rationale behind the policy has not
> changed at all.
>
> On May 29, 2014, at 11:18 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > It can be helpful to learn from contemporaries. I've found our dialogue instructive, for another direct example, and do not begrudge it. Willful ignorance of our colleagues here and elsewhere is not at all in the spirit of ASF aims. At least, I hope so!
> >
> > On May 29, 2014 10:48 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> > Who cares how *they* do it? This is *our* policy.
> > Certainly you understand that, right? And we've gone out
> > of our way to explain the reason and rationale behind it.
> > But simply because others don't do it is hardly a reason
> > for us to change what we do, or how we do it, in and
> > of itself.
> >
> > I believe that the moon landing actually happened. I can point
> > to people who are direct contrasts to that belief. Does that
> > mean that I should change my mind? The existence of direct
> > contrasts is moot.
> >
> > On May 29, 2014, at 10:35 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > No need to construct vapid analogies when direct contrasts exist.
> > >
> > > - fsf
> > > - software freedom conservancy
> > > - mozilla
> > >
> > > Etc.
> > >
> > > On May 29, 2014 8:15 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> > > +1
> > >
> > > Think about it like a QA department of a production line in a company building children toys.
> > >
> > > Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
> > >
> > > Now what would happen if such a failure really appears? They would sue the hell out of this company...
> > >
> > > By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
> > >
> > > LieGrue,
> > > strub
> > >
> > > --------------------------------------------
> > > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> > >
> > > Subject: Re: Clarification about D&O insurance and bad acts
> > > To: legal-discuss@apache.org
> > > Date: Thursday, 29 May, 2014, 13:49
> > >
> > > Not sure what you mean by
> > > that... One of the aspects
> > > of verifying a
> > > release is checking that the bits going out
> > > are, in fact, the expected and correct bits...
> > > which sounds
> > > like src verification to me.
> > > And is, obviously, appropriate
> > > and
> > > necessary.
> > >
> > > On May 28, 2014,
> > > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Agreed! That said, src
> > > verification for releases is not always appropriate or
> > > necessary. (Depending on the project, the people and their
> > > unique attributes.)
> > > >
> > > > On May 28, 2014 1:01 PM, "Jim
> > > Jagielski" <ji...@jagunet.com>
> > > wrote:
> > > > That is true. But doing normal
> > > work-in-progress, and the
> > > > oversight
> > > thereof, is a different thing than doing a
> > > > release.
> > > >
> > > > One does not negate the other, nor does it
> > > remove the
> > > > need for the other. Saying
> > > "we do X oversight for our day
> > > > to
> > > day development" does not mean that no oversight is
> > > > needed for a release, simply because
> > > it's a different
> > > > kind of oversight
> > > for a different kind of activity.
> > > >
> > > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > > <b...@brian.io> wrote:
> > > >
> > > > > We could both
> > > wax hypothetical about the merit of humans and error
> > > proneness. My point is whatever is work-in-progress is a
> > > daily responsibility and not something to be left for the
> > > last minute check by others. Ever.
> > > >
> > > >
> > > > >
> > > > > On
> > > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> > > wrote:
> > > > > Brian, you are absolutely
> > > correct. However, SVN is not the release and so having
> > > reviewed commits is not the same as having reviewed the
> > > release. In a well run project where people are reviewing
> > > code commits there should be no problem. But people make
> > > errors and you would be surprised how often those errors
> > > slip through.
> > > > >
> > > >
> > > > Furthermore, since I (as a committer) cannot guarantee
> > > that I reviewed every change to every file between release a
> > > and release b I cannot, as a PMC member, be certain that the
> > > necessary files are present and correct. If I were to vote
> > > +1 without having reviewed the release then my vote would be
> > > worthless when it comes to demonstrating that our policy has
> > > been followed for that release.
> > > > >
> > > > > Ross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 27 May
> > > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > > From my perspective this is a daily
> > > requirement of a responsible committer. That final check
> > > isn't hurting anything but it is not even remotely
> > > acceptable for a committer to not be constantly vigilant
> > > when landing commits to our source.
> > > >
> > > >
> > > > >
> > > > > On
> > > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > > wrote:
> > > > > Ross Gardler wrote:
> > > > >
> > > > > > In my
> > > mind (and I am not a lawyer so that means almost nothing in
> > > these situations) the requirement to have 3 PMC members
> > > indicate that, to the best of their knowledge, the release
> > > is compliant with the policy is sufficient.
> > > > >
> > > > >
> > > > >
> > > > > Leaving my
> > > lawyer hat off for a bit, it seems so to me too. I'm not
> > > worried. I wasn't even worried about that when I served
> > > on the board. /Larry
> > > > >
> > > > >
> > > > >
> > > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > > Sent: Saturday, May 24, 2014 8:08
> > > PM
> > > > > To: legal-discuss@apache.org;
> > > Larry Rosen
> > > > > Subject: Re:
> > > Clarification about D&O insurance and bad acts
> > > > >
> > > > >
> > > <snip>
> > > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > > For additional commands, e-mail: legal-discuss-help@apache.org
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Brian LeRoux <b...@brian.io>.
Quoting Larry, "..as long as individual PMC members comply in good faith
with an approved ASF release policy, it shouldn't matter much what policy
we finally approve "
The reason we vote is to ensure compliance with our src legal requirements.
The rational I question as an unnecessary redundancy given this is our
daily responsibility for every commit we land. I deeply respect the history
here. Do not confuse that. Ultimately I'm really, truly, striving to help
the ASF streamline our ultimate premise: shipping software.
On May 29, 2014 11:29 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Sure it is helpful. We have learned from them, and they
> have learned from us. However, the very fact that they
> do something different isn't sufficient for us to change
> a policy that we've had since before 1999... especially
> if the reason and rationale behind the policy has not
> changed at all.
>
> On May 29, 2014, at 11:18 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > It can be helpful to learn from contemporaries. I've found our dialogue
> instructive, for another direct example, and do not begrudge it. Willful
> ignorance of our colleagues here and elsewhere is not at all in the spirit
> of ASF aims. At least, I hope so!
> >
> > On May 29, 2014 10:48 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> > Who cares how *they* do it? This is *our* policy.
> > Certainly you understand that, right? And we've gone out
> > of our way to explain the reason and rationale behind it.
> > But simply because others don't do it is hardly a reason
> > for us to change what we do, or how we do it, in and
> > of itself.
> >
> > I believe that the moon landing actually happened. I can point
> > to people who are direct contrasts to that belief. Does that
> > mean that I should change my mind? The existence of direct
> > contrasts is moot.
> >
> > On May 29, 2014, at 10:35 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > No need to construct vapid analogies when direct contrasts exist.
> > >
> > > - fsf
> > > - software freedom conservancy
> > > - mozilla
> > >
> > > Etc.
> > >
> > > On May 29, 2014 8:15 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> > > +1
> > >
> > > Think about it like a QA department of a production line in a company
> building children toys.
> > >
> > > Of course all employees take care to not introduce a failure which
> might harm children. But even then it _might_ happen.
> > >
> > > Now what would happen if such a failure really appears? They would sue
> the hell out of this company...
> > >
> > > By having a QA department which does an independent check if all is
> fine over and over again this risk might get reduced. And even if a failure
> still slips through it will help the company to not get hit too hard at
> least.
> > >
> > > LieGrue,
> > > strub
> > >
> > > --------------------------------------------
> > > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> > >
> > > Subject: Re: Clarification about D&O insurance and bad acts
> > > To: legal-discuss@apache.org
> > > Date: Thursday, 29 May, 2014, 13:49
> > >
> > > Not sure what you mean by
> > > that... One of the aspects
> > > of verifying a
> > > release is checking that the bits going out
> > > are, in fact, the expected and correct bits...
> > > which sounds
> > > like src verification to me.
> > > And is, obviously, appropriate
> > > and
> > > necessary.
> > >
> > > On May 28, 2014,
> > > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Agreed! That said, src
> > > verification for releases is not always appropriate or
> > > necessary. (Depending on the project, the people and their
> > > unique attributes.)
> > > >
> > > > On May 28, 2014 1:01 PM, "Jim
> > > Jagielski" <ji...@jagunet.com>
> > > wrote:
> > > > That is true. But doing normal
> > > work-in-progress, and the
> > > > oversight
> > > thereof, is a different thing than doing a
> > > > release.
> > > >
> > > > One does not negate the other, nor does it
> > > remove the
> > > > need for the other. Saying
> > > "we do X oversight for our day
> > > > to
> > > day development" does not mean that no oversight is
> > > > needed for a release, simply because
> > > it's a different
> > > > kind of oversight
> > > for a different kind of activity.
> > > >
> > > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > > <b...@brian.io> wrote:
> > > >
> > > > > We could both
> > > wax hypothetical about the merit of humans and error
> > > proneness. My point is whatever is work-in-progress is a
> > > daily responsibility and not something to be left for the
> > > last minute check by others. Ever.
> > > >
> > > >
> > > > >
> > > > > On
> > > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <
> rgardler@opendirective.com>
> > > wrote:
> > > > > Brian, you are absolutely
> > > correct. However, SVN is not the release and so having
> > > reviewed commits is not the same as having reviewed the
> > > release. In a well run project where people are reviewing
> > > code commits there should be no problem. But people make
> > > errors and you would be surprised how often those errors
> > > slip through.
> > > > >
> > > >
> > > > Furthermore, since I (as a committer) cannot guarantee
> > > that I reviewed every change to every file between release a
> > > and release b I cannot, as a PMC member, be certain that the
> > > necessary files are present and correct. If I were to vote
> > > +1 without having reviewed the release then my vote would be
> > > worthless when it comes to demonstrating that our policy has
> > > been followed for that release.
> > > > >
> > > > > Ross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 27 May
> > > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > > From my perspective this is a daily
> > > requirement of a responsible committer. That final check
> > > isn't hurting anything but it is not even remotely
> > > acceptable for a committer to not be constantly vigilant
> > > when landing commits to our source.
> > > >
> > > >
> > > > >
> > > > > On
> > > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > > wrote:
> > > > > Ross Gardler wrote:
> > > > >
> > > > > > In my
> > > mind (and I am not a lawyer so that means almost nothing in
> > > these situations) the requirement to have 3 PMC members
> > > indicate that, to the best of their knowledge, the release
> > > is compliant with the policy is sufficient.
> > > > >
> > > > >
> > > > >
> > > > > Leaving my
> > > lawyer hat off for a bit, it seems so to me too. I'm not
> > > worried. I wasn't even worried about that when I served
> > > on the board. /Larry
> > > > >
> > > > >
> > > > >
> > > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > > Sent: Saturday, May 24, 2014 8:08
> > > PM
> > > > > To: legal-discuss@apache.org;
> > > Larry Rosen
> > > > > Subject: Re:
> > > Clarification about D&O insurance and bad acts
> > > > >
> > > > >
> > > <snip>
> > > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > > For additional commands, e-mail: legal-discuss-help@apache.org
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
Sure it is helpful. We have learned from them, and they
have learned from us. However, the very fact that they
do something different isn't sufficient for us to change
a policy that we've had since before 1999... especially
if the reason and rationale behind the policy has not
changed at all.
On May 29, 2014, at 11:18 AM, Brian LeRoux <b...@brian.io> wrote:
> It can be helpful to learn from contemporaries. I've found our dialogue instructive, for another direct example, and do not begrudge it. Willful ignorance of our colleagues here and elsewhere is not at all in the spirit of ASF aims. At least, I hope so!
>
> On May 29, 2014 10:48 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Who cares how *they* do it? This is *our* policy.
> Certainly you understand that, right? And we've gone out
> of our way to explain the reason and rationale behind it.
> But simply because others don't do it is hardly a reason
> for us to change what we do, or how we do it, in and
> of itself.
>
> I believe that the moon landing actually happened. I can point
> to people who are direct contrasts to that belief. Does that
> mean that I should change my mind? The existence of direct
> contrasts is moot.
>
> On May 29, 2014, at 10:35 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > No need to construct vapid analogies when direct contrasts exist.
> >
> > - fsf
> > - software freedom conservancy
> > - mozilla
> >
> > Etc.
> >
> > On May 29, 2014 8:15 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> > +1
> >
> > Think about it like a QA department of a production line in a company building children toys.
> >
> > Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
> >
> > Now what would happen if such a failure really appears? They would sue the hell out of this company...
> >
> > By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
> >
> > LieGrue,
> > strub
> >
> > --------------------------------------------
> > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > Subject: Re: Clarification about D&O insurance and bad acts
> > To: legal-discuss@apache.org
> > Date: Thursday, 29 May, 2014, 13:49
> >
> > Not sure what you mean by
> > that... One of the aspects
> > of verifying a
> > release is checking that the bits going out
> > are, in fact, the expected and correct bits...
> > which sounds
> > like src verification to me.
> > And is, obviously, appropriate
> > and
> > necessary.
> >
> > On May 28, 2014,
> > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Agreed! That said, src
> > verification for releases is not always appropriate or
> > necessary. (Depending on the project, the people and their
> > unique attributes.)
> > >
> > > On May 28, 2014 1:01 PM, "Jim
> > Jagielski" <ji...@jagunet.com>
> > wrote:
> > > That is true. But doing normal
> > work-in-progress, and the
> > > oversight
> > thereof, is a different thing than doing a
> > > release.
> > >
> > > One does not negate the other, nor does it
> > remove the
> > > need for the other. Saying
> > "we do X oversight for our day
> > > to
> > day development" does not mean that no oversight is
> > > needed for a release, simply because
> > it's a different
> > > kind of oversight
> > for a different kind of activity.
> > >
> > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > <b...@brian.io> wrote:
> > >
> > > > We could both
> > wax hypothetical about the merit of humans and error
> > proneness. My point is whatever is work-in-progress is a
> > daily responsibility and not something to be left for the
> > last minute check by others. Ever.
> > >
> > >
> > > >
> > > > On
> > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> > wrote:
> > > > Brian, you are absolutely
> > correct. However, SVN is not the release and so having
> > reviewed commits is not the same as having reviewed the
> > release. In a well run project where people are reviewing
> > code commits there should be no problem. But people make
> > errors and you would be surprised how often those errors
> > slip through.
> > > >
> > >
> > > Furthermore, since I (as a committer) cannot guarantee
> > that I reviewed every change to every file between release a
> > and release b I cannot, as a PMC member, be certain that the
> > necessary files are present and correct. If I were to vote
> > +1 without having reviewed the release then my vote would be
> > worthless when it comes to demonstrating that our policy has
> > been followed for that release.
> > > >
> > > > Ross
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 27 May
> > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > From my perspective this is a daily
> > requirement of a responsible committer. That final check
> > isn't hurting anything but it is not even remotely
> > acceptable for a committer to not be constantly vigilant
> > when landing commits to our source.
> > >
> > >
> > > >
> > > > On
> > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > wrote:
> > > > Ross Gardler wrote:
> > > >
> > > > > In my
> > mind (and I am not a lawyer so that means almost nothing in
> > these situations) the requirement to have 3 PMC members
> > indicate that, to the best of their knowledge, the release
> > is compliant with the policy is sufficient.
> > > >
> > > >
> > > >
> > > > Leaving my
> > lawyer hat off for a bit, it seems so to me too. I'm not
> > worried. I wasn't even worried about that when I served
> > on the board. /Larry
> > > >
> > > >
> > > >
> > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > Sent: Saturday, May 24, 2014 8:08
> > PM
> > > > To: legal-discuss@apache.org;
> > Larry Rosen
> > > > Subject: Re:
> > Clarification about D&O insurance and bad acts
> > > >
> > > >
> > <snip>
> > > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Brian LeRoux <b...@brian.io>.
It can be helpful to learn from contemporaries. I've found our dialogue
instructive, for another direct example, and do not begrudge it. Willful
ignorance of our colleagues here and elsewhere is not at all in the spirit
of ASF aims. At least, I hope so!
On May 29, 2014 10:48 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Who cares how *they* do it? This is *our* policy.
> Certainly you understand that, right? And we've gone out
> of our way to explain the reason and rationale behind it.
> But simply because others don't do it is hardly a reason
> for us to change what we do, or how we do it, in and
> of itself.
>
> I believe that the moon landing actually happened. I can point
> to people who are direct contrasts to that belief. Does that
> mean that I should change my mind? The existence of direct
> contrasts is moot.
>
> On May 29, 2014, at 10:35 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > No need to construct vapid analogies when direct contrasts exist.
> >
> > - fsf
> > - software freedom conservancy
> > - mozilla
> >
> > Etc.
> >
> > On May 29, 2014 8:15 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> > +1
> >
> > Think about it like a QA department of a production line in a company
> building children toys.
> >
> > Of course all employees take care to not introduce a failure which might
> harm children. But even then it _might_ happen.
> >
> > Now what would happen if such a failure really appears? They would sue
> the hell out of this company...
> >
> > By having a QA department which does an independent check if all is fine
> over and over again this risk might get reduced. And even if a failure
> still slips through it will help the company to not get hit too hard at
> least.
> >
> > LieGrue,
> > strub
> >
> > --------------------------------------------
> > On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > Subject: Re: Clarification about D&O insurance and bad acts
> > To: legal-discuss@apache.org
> > Date: Thursday, 29 May, 2014, 13:49
> >
> > Not sure what you mean by
> > that... One of the aspects
> > of verifying a
> > release is checking that the bits going out
> > are, in fact, the expected and correct bits...
> > which sounds
> > like src verification to me.
> > And is, obviously, appropriate
> > and
> > necessary.
> >
> > On May 28, 2014,
> > at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Agreed! That said, src
> > verification for releases is not always appropriate or
> > necessary. (Depending on the project, the people and their
> > unique attributes.)
> > >
> > > On May 28, 2014 1:01 PM, "Jim
> > Jagielski" <ji...@jagunet.com>
> > wrote:
> > > That is true. But doing normal
> > work-in-progress, and the
> > > oversight
> > thereof, is a different thing than doing a
> > > release.
> > >
> > > One does not negate the other, nor does it
> > remove the
> > > need for the other. Saying
> > "we do X oversight for our day
> > > to
> > day development" does not mean that no oversight is
> > > needed for a release, simply because
> > it's a different
> > > kind of oversight
> > for a different kind of activity.
> > >
> > > On May 27, 2014, at 5:22 PM, Brian LeRoux
> > <b...@brian.io> wrote:
> > >
> > > > We could both
> > wax hypothetical about the merit of humans and error
> > proneness. My point is whatever is work-in-progress is a
> > daily responsibility and not something to be left for the
> > last minute check by others. Ever.
> > >
> > >
> > > >
> > > > On
> > Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> > wrote:
> > > > Brian, you are absolutely
> > correct. However, SVN is not the release and so having
> > reviewed commits is not the same as having reviewed the
> > release. In a well run project where people are reviewing
> > code commits there should be no problem. But people make
> > errors and you would be surprised how often those errors
> > slip through.
> > > >
> > >
> > > Furthermore, since I (as a committer) cannot guarantee
> > that I reviewed every change to every file between release a
> > and release b I cannot, as a PMC member, be certain that the
> > necessary files are present and correct. If I were to vote
> > +1 without having reviewed the release then my vote would be
> > worthless when it comes to demonstrating that our policy has
> > been followed for that release.
> > > >
> > > > Ross
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 27 May
> > 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > > From my perspective this is a daily
> > requirement of a responsible committer. That final check
> > isn't hurting anything but it is not even remotely
> > acceptable for a committer to not be constantly vigilant
> > when landing commits to our source.
> > >
> > >
> > > >
> > > > On
> > Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > wrote:
> > > > Ross Gardler wrote:
> > > >
> > > > > In my
> > mind (and I am not a lawyer so that means almost nothing in
> > these situations) the requirement to have 3 PMC members
> > indicate that, to the best of their knowledge, the release
> > is compliant with the policy is sufficient.
> > > >
> > > >
> > > >
> > > > Leaving my
> > lawyer hat off for a bit, it seems so to me too. I'm not
> > worried. I wasn't even worried about that when I served
> > on the board. /Larry
> > > >
> > > >
> > > >
> > > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > > Sent: Saturday, May 24, 2014 8:08
> > PM
> > > > To: legal-discuss@apache.org;
> > Larry Rosen
> > > > Subject: Re:
> > Clarification about D&O insurance and bad acts
> > > >
> > > >
> > <snip>
> > > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
Who cares how *they* do it? This is *our* policy.
Certainly you understand that, right? And we've gone out
of our way to explain the reason and rationale behind it.
But simply because others don't do it is hardly a reason
for us to change what we do, or how we do it, in and
of itself.
I believe that the moon landing actually happened. I can point
to people who are direct contrasts to that belief. Does that
mean that I should change my mind? The existence of direct
contrasts is moot.
On May 29, 2014, at 10:35 AM, Brian LeRoux <b...@brian.io> wrote:
> No need to construct vapid analogies when direct contrasts exist.
>
> - fsf
> - software freedom conservancy
> - mozilla
>
> Etc.
>
> On May 29, 2014 8:15 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> +1
>
> Think about it like a QA department of a production line in a company building children toys.
>
> Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
>
> Now what would happen if such a failure really appears? They would sue the hell out of this company...
>
> By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
>
> LieGrue,
> strub
>
> --------------------------------------------
> On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Subject: Re: Clarification about D&O insurance and bad acts
> To: legal-discuss@apache.org
> Date: Thursday, 29 May, 2014, 13:49
>
> Not sure what you mean by
> that... One of the aspects
> of verifying a
> release is checking that the bits going out
> are, in fact, the expected and correct bits...
> which sounds
> like src verification to me.
> And is, obviously, appropriate
> and
> necessary.
>
> On May 28, 2014,
> at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Agreed! That said, src
> verification for releases is not always appropriate or
> necessary. (Depending on the project, the people and their
> unique attributes.)
> >
> > On May 28, 2014 1:01 PM, "Jim
> Jagielski" <ji...@jagunet.com>
> wrote:
> > That is true. But doing normal
> work-in-progress, and the
> > oversight
> thereof, is a different thing than doing a
> > release.
> >
> > One does not negate the other, nor does it
> remove the
> > need for the other. Saying
> "we do X oversight for our day
> > to
> day development" does not mean that no oversight is
> > needed for a release, simply because
> it's a different
> > kind of oversight
> for a different kind of activity.
> >
> > On May 27, 2014, at 5:22 PM, Brian LeRoux
> <b...@brian.io> wrote:
> >
> > > We could both
> wax hypothetical about the merit of humans and error
> proneness. My point is whatever is work-in-progress is a
> daily responsibility and not something to be left for the
> last minute check by others. Ever.
> >
> >
> > >
> > > On
> Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> wrote:
> > > Brian, you are absolutely
> correct. However, SVN is not the release and so having
> reviewed commits is not the same as having reviewed the
> release. In a well run project where people are reviewing
> code commits there should be no problem. But people make
> errors and you would be surprised how often those errors
> slip through.
> > >
> >
> > Furthermore, since I (as a committer) cannot guarantee
> that I reviewed every change to every file between release a
> and release b I cannot, as a PMC member, be certain that the
> necessary files are present and correct. If I were to vote
> +1 without having reviewed the release then my vote would be
> worthless when it comes to demonstrating that our policy has
> been followed for that release.
> > >
> > > Ross
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 27 May
> 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > From my perspective this is a daily
> requirement of a responsible committer. That final check
> isn't hurting anything but it is not even remotely
> acceptable for a committer to not be constantly vigilant
> when landing commits to our source.
> >
> >
> > >
> > > On
> Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> wrote:
> > > Ross Gardler wrote:
> > >
> > > > In my
> mind (and I am not a lawyer so that means almost nothing in
> these situations) the requirement to have 3 PMC members
> indicate that, to the best of their knowledge, the release
> is compliant with the policy is sufficient.
> > >
> > >
> > >
> > > Leaving my
> lawyer hat off for a bit, it seems so to me too. I'm not
> worried. I wasn't even worried about that when I served
> on the board. /Larry
> > >
> > >
> > >
> > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > Sent: Saturday, May 24, 2014 8:08
> PM
> > > To: legal-discuss@apache.org;
> Larry Rosen
> > > Subject: Re:
> Clarification about D&O insurance and bad acts
> > >
> > >
> <snip>
> > >
> >
> >
> > >
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Brian LeRoux <b...@brian.io>.
No need to construct vapid analogies when direct contrasts exist.
- fsf
- software freedom conservancy
- mozilla
Etc.
On May 29, 2014 8:15 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> +1
>
> Think about it like a QA department of a production line in a company
> building children toys.
>
> Of course all employees take care to not introduce a failure which might
> harm children. But even then it _might_ happen.
>
> Now what would happen if such a failure really appears? They would sue the
> hell out of this company...
>
> By having a QA department which does an independent check if all is fine
> over and over again this risk might get reduced. And even if a failure
> still slips through it will help the company to not get hit too hard at
> least.
>
> LieGrue,
> strub
>
> --------------------------------------------
> On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Subject: Re: Clarification about D&O insurance and bad acts
> To: legal-discuss@apache.org
> Date: Thursday, 29 May, 2014, 13:49
>
> Not sure what you mean by
> that... One of the aspects
> of verifying a
> release is checking that the bits going out
> are, in fact, the expected and correct bits...
> which sounds
> like src verification to me.
> And is, obviously, appropriate
> and
> necessary.
>
> On May 28, 2014,
> at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Agreed! That said, src
> verification for releases is not always appropriate or
> necessary. (Depending on the project, the people and their
> unique attributes.)
> >
> > On May 28, 2014 1:01 PM, "Jim
> Jagielski" <ji...@jagunet.com>
> wrote:
> > That is true. But doing normal
> work-in-progress, and the
> > oversight
> thereof, is a different thing than doing a
> > release.
> >
> > One does not negate the other, nor does it
> remove the
> > need for the other. Saying
> "we do X oversight for our day
> > to
> day development" does not mean that no oversight is
> > needed for a release, simply because
> it's a different
> > kind of oversight
> for a different kind of activity.
> >
> > On May 27, 2014, at 5:22 PM, Brian LeRoux
> <b...@brian.io> wrote:
> >
> > > We could both
> wax hypothetical about the merit of humans and error
> proneness. My point is whatever is work-in-progress is a
> daily responsibility and not something to be left for the
> last minute check by others. Ever.
> >
> >
> > >
> > > On
> Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
> wrote:
> > > Brian, you are absolutely
> correct. However, SVN is not the release and so having
> reviewed commits is not the same as having reviewed the
> release. In a well run project where people are reviewing
> code commits there should be no problem. But people make
> errors and you would be surprised how often those errors
> slip through.
> > >
> >
> > Furthermore, since I (as a committer) cannot guarantee
> that I reviewed every change to every file between release a
> and release b I cannot, as a PMC member, be certain that the
> necessary files are present and correct. If I were to vote
> +1 without having reviewed the release then my vote would be
> worthless when it comes to demonstrating that our policy has
> been followed for that release.
> > >
> > > Ross
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 27 May
> 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > > From my perspective this is a daily
> requirement of a responsible committer. That final check
> isn't hurting anything but it is not even remotely
> acceptable for a committer to not be constantly vigilant
> when landing commits to our source.
> >
> >
> > >
> > > On
> Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> wrote:
> > > Ross Gardler wrote:
> > >
> > > > In my
> mind (and I am not a lawyer so that means almost nothing in
> these situations) the requirement to have 3 PMC members
> indicate that, to the best of their knowledge, the release
> is compliant with the policy is sufficient.
> > >
> > >
> > >
> > > Leaving my
> lawyer hat off for a bit, it seems so to me too. I'm not
> worried. I wasn't even worried about that when I served
> on the board. /Larry
> > >
> > >
> > >
> > > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > > Sent: Saturday, May 24, 2014 8:08
> PM
> > > To: legal-discuss@apache.org;
> Larry Rosen
> > > Subject: Re:
> Clarification about D&O insurance and bad acts
> > >
> > >
> <snip>
> > >
> >
> >
> > >
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Mark Struberg <st...@yahoo.de>.
+1
Think about it like a QA department of a production line in a company building children toys.
Of course all employees take care to not introduce a failure which might harm children. But even then it _might_ happen.
Now what would happen if such a failure really appears? They would sue the hell out of this company...
By having a QA department which does an independent check if all is fine over and over again this risk might get reduced. And even if a failure still slips through it will help the company to not get hit too hard at least.
LieGrue,
strub
--------------------------------------------
On Thu, 29/5/14, Jim Jagielski <ji...@jaguNET.com> wrote:
Subject: Re: Clarification about D&O insurance and bad acts
To: legal-discuss@apache.org
Date: Thursday, 29 May, 2014, 13:49
Not sure what you mean by
that... One of the aspects
of verifying a
release is checking that the bits going out
are, in fact, the expected and correct bits...
which sounds
like src verification to me.
And is, obviously, appropriate
and
necessary.
On May 28, 2014,
at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> Agreed! That said, src
verification for releases is not always appropriate or
necessary. (Depending on the project, the people and their
unique attributes.)
>
> On May 28, 2014 1:01 PM, "Jim
Jagielski" <ji...@jagunet.com>
wrote:
> That is true. But doing normal
work-in-progress, and the
> oversight
thereof, is a different thing than doing a
> release.
>
> One does not negate the other, nor does it
remove the
> need for the other. Saying
"we do X oversight for our day
> to
day development" does not mean that no oversight is
> needed for a release, simply because
it's a different
> kind of oversight
for a different kind of activity.
>
> On May 27, 2014, at 5:22 PM, Brian LeRoux
<b...@brian.io> wrote:
>
> > We could both
wax hypothetical about the merit of humans and error
proneness. My point is whatever is work-in-progress is a
daily responsibility and not something to be left for the
last minute check by others. Ever.
>
>
> >
> > On
Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>
wrote:
> > Brian, you are absolutely
correct. However, SVN is not the release and so having
reviewed commits is not the same as having reviewed the
release. In a well run project where people are reviewing
code commits there should be no problem. But people make
errors and you would be surprised how often those errors
slip through.
> >
>
> Furthermore, since I (as a committer) cannot guarantee
that I reviewed every change to every file between release a
and release b I cannot, as a PMC member, be certain that the
necessary files are present and correct. If I were to vote
+1 without having reviewed the release then my vote would be
worthless when it comes to demonstrating that our policy has
been followed for that release.
> >
> > Ross
> >
> >
> >
> >
> >
> >
> > On 27 May
2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > From my perspective this is a daily
requirement of a responsible committer. That final check
isn't hurting anything but it is not even remotely
acceptable for a committer to not be constantly vigilant
when landing commits to our source.
>
>
> >
> > On
Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
wrote:
> > Ross Gardler wrote:
> >
> > > In my
mind (and I am not a lawyer so that means almost nothing in
these situations) the requirement to have 3 PMC members
indicate that, to the best of their knowledge, the release
is compliant with the policy is sufficient.
> >
> >
> >
> > Leaving my
lawyer hat off for a bit, it seems so to me too. I'm not
worried. I wasn't even worried about that when I served
on the board. /Larry
> >
> >
> >
> > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > Sent: Saturday, May 24, 2014 8:08
PM
> > To: legal-discuss@apache.org;
Larry Rosen
> > Subject: Re:
Clarification about D&O insurance and bad acts
> >
> >
<snip>
> >
>
>
> >
> >
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
Not sure what you mean by that... One of the aspects
of verifying a release is checking that the bits going out
are, in fact, the expected and correct bits... which sounds
like src verification to me. And is, obviously, appropriate
and necessary.
On May 28, 2014, at 2:47 PM, Brian LeRoux <b...@brian.io> wrote:
> Agreed! That said, src verification for releases is not always appropriate or necessary. (Depending on the project, the people and their unique attributes.)
>
> On May 28, 2014 1:01 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> That is true. But doing normal work-in-progress, and the
> oversight thereof, is a different thing than doing a
> release.
>
> One does not negate the other, nor does it remove the
> need for the other. Saying "we do X oversight for our day
> to day development" does not mean that no oversight is
> needed for a release, simply because it's a different
> kind of oversight for a different kind of activity.
>
> On May 27, 2014, at 5:22 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > We could both wax hypothetical about the merit of humans and error proneness. My point is whatever is work-in-progress is a daily responsibility and not something to be left for the last minute check by others. Ever.
> >
> >
> > On Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com> wrote:
> > Brian, you are absolutely correct. However, SVN is not the release and so having reviewed commits is not the same as having reviewed the release. In a well run project where people are reviewing code commits there should be no problem. But people make errors and you would be surprised how often those errors slip through.
> >
> > Furthermore, since I (as a committer) cannot guarantee that I reviewed every change to every file between release a and release b I cannot, as a PMC member, be certain that the necessary files are present and correct. If I were to vote +1 without having reviewed the release then my vote would be worthless when it comes to demonstrating that our policy has been followed for that release.
> >
> > Ross
> >
> >
> >
> >
> >
> >
> > On 27 May 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > From my perspective this is a daily requirement of a responsible committer. That final check isn't hurting anything but it is not even remotely acceptable for a committer to not be constantly vigilant when landing commits to our source.
> >
> >
> > On Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> > Ross Gardler wrote:
> >
> > > In my mind (and I am not a lawyer so that means almost nothing in these situations) the requirement to have 3 PMC members indicate that, to the best of their knowledge, the release is compliant with the policy is sufficient.
> >
> >
> >
> > Leaving my lawyer hat off for a bit, it seems so to me too. I'm not worried. I wasn't even worried about that when I served on the board. /Larry
> >
> >
> >
> > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > Sent: Saturday, May 24, 2014 8:08 PM
> > To: legal-discuss@apache.org; Larry Rosen
> > Subject: Re: Clarification about D&O insurance and bad acts
> >
> > <snip>
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Brian LeRoux <b...@brian.io>.
Agreed! That said, src verification for releases is not always appropriate
or necessary. (Depending on the project, the people and their unique
attributes.)
On May 28, 2014 1:01 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> That is true. But doing normal work-in-progress, and the
> oversight thereof, is a different thing than doing a
> release.
>
> One does not negate the other, nor does it remove the
> need for the other. Saying "we do X oversight for our day
> to day development" does not mean that no oversight is
> needed for a release, simply because it's a different
> kind of oversight for a different kind of activity.
>
> On May 27, 2014, at 5:22 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > We could both wax hypothetical about the merit of humans and error
> proneness. My point is whatever is work-in-progress is a daily
> responsibility and not something to be left for the last minute check by
> others. Ever.
> >
> >
> > On Tue, May 27, 2014 at 2:59 PM, Ross Gardler <
> rgardler@opendirective.com> wrote:
> > Brian, you are absolutely correct. However, SVN is not the release and
> so having reviewed commits is not the same as having reviewed the release.
> In a well run project where people are reviewing code commits there should
> be no problem. But people make errors and you would be surprised how often
> those errors slip through.
> >
> > Furthermore, since I (as a committer) cannot guarantee that I reviewed
> every change to every file between release a and release b I cannot, as a
> PMC member, be certain that the necessary files are present and correct. If
> I were to vote +1 without having reviewed the release then my vote would be
> worthless when it comes to demonstrating that our policy has been followed
> for that release.
> >
> > Ross
> >
> >
> >
> >
> >
> >
> > On 27 May 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> > From my perspective this is a daily requirement of a responsible
> committer. That final check isn't hurting anything but it is not even
> remotely acceptable for a committer to not be constantly vigilant when
> landing commits to our source.
> >
> >
> > On Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>
> wrote:
> > Ross Gardler wrote:
> >
> > > In my mind (and I am not a lawyer so that means almost nothing in
> these situations) the requirement to have 3 PMC members indicate that, to
> the best of their knowledge, the release is compliant with the policy is
> sufficient.
> >
> >
> >
> > Leaving my lawyer hat off for a bit, it seems so to me too. I'm not
> worried. I wasn't even worried about that when I served on the board. /Larry
> >
> >
> >
> > From: Ross Gardler [mailto:rgardler@opendirective.com]
> > Sent: Saturday, May 24, 2014 8:08 PM
> > To: legal-discuss@apache.org; Larry Rosen
> > Subject: Re: Clarification about D&O insurance and bad acts
> >
> > <snip>
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Jim Jagielski <ji...@jaguNET.com>.
That is true. But doing normal work-in-progress, and the
oversight thereof, is a different thing than doing a
release.
One does not negate the other, nor does it remove the
need for the other. Saying "we do X oversight for our day
to day development" does not mean that no oversight is
needed for a release, simply because it's a different
kind of oversight for a different kind of activity.
On May 27, 2014, at 5:22 PM, Brian LeRoux <b...@brian.io> wrote:
> We could both wax hypothetical about the merit of humans and error proneness. My point is whatever is work-in-progress is a daily responsibility and not something to be left for the last minute check by others. Ever.
>
>
> On Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com> wrote:
> Brian, you are absolutely correct. However, SVN is not the release and so having reviewed commits is not the same as having reviewed the release. In a well run project where people are reviewing code commits there should be no problem. But people make errors and you would be surprised how often those errors slip through.
>
> Furthermore, since I (as a committer) cannot guarantee that I reviewed every change to every file between release a and release b I cannot, as a PMC member, be certain that the necessary files are present and correct. If I were to vote +1 without having reviewed the release then my vote would be worthless when it comes to demonstrating that our policy has been followed for that release.
>
> Ross
>
>
>
>
>
>
> On 27 May 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> From my perspective this is a daily requirement of a responsible committer. That final check isn't hurting anything but it is not even remotely acceptable for a committer to not be constantly vigilant when landing commits to our source.
>
>
> On Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Ross Gardler wrote:
>
> > In my mind (and I am not a lawyer so that means almost nothing in these situations) the requirement to have 3 PMC members indicate that, to the best of their knowledge, the release is compliant with the policy is sufficient.
>
>
>
> Leaving my lawyer hat off for a bit, it seems so to me too. I'm not worried. I wasn't even worried about that when I served on the board. /Larry
>
>
>
> From: Ross Gardler [mailto:rgardler@opendirective.com]
> Sent: Saturday, May 24, 2014 8:08 PM
> To: legal-discuss@apache.org; Larry Rosen
> Subject: Re: Clarification about D&O insurance and bad acts
>
> <snip>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification about D&O insurance and bad acts
Posted by Brian LeRoux <b...@brian.io>.
We could both wax hypothetical about the merit of humans and error
proneness. My point is whatever is work-in-progress is a daily
responsibility and not something to be left for the last minute check by
others. Ever.
On Tue, May 27, 2014 at 2:59 PM, Ross Gardler <rg...@opendirective.com>wrote:
> Brian, you are absolutely correct. However, SVN is not the release and so
> having reviewed commits is not the same as having reviewed the release. In
> a well run project where people are reviewing code commits there should be
> no problem. But people make errors and you would be surprised how often
> those errors slip through.
>
> Furthermore, since I (as a committer) cannot guarantee that I reviewed
> every change to every file between release a and release b I cannot, as a
> PMC member, be certain that the necessary files are present and correct. If
> I were to vote +1 without having reviewed the release then my vote would be
> worthless when it comes to demonstrating that our policy has been followed
> for that release.
>
> Ross
>
>
>
>
>
>
> On 27 May 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
>
>> From my perspective this is a daily requirement of a responsible
>> committer. That final check isn't hurting anything but it is not even
>> remotely acceptable for a committer to not be constantly vigilant when
>> landing commits to our source.
>>
>>
>> On Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>wrote:
>>
>>> Ross Gardler wrote:
>>>
>>> > In my mind (and I am not a lawyer so that means almost nothing in
>>> these situations) the requirement to have 3 PMC members indicate that, to
>>> the best of their knowledge, the release is compliant with the policy is
>>> sufficient.
>>>
>>>
>>>
>>> Leaving my lawyer hat off for a bit, it seems so to me too. I'm not
>>> worried. I wasn't even worried about that when I served on the board. /Larry
>>>
>>>
>>>
>>> *From:* Ross Gardler [mailto:rgardler@opendirective.com]
>>> *Sent:* Saturday, May 24, 2014 8:08 PM
>>> *To:* legal-discuss@apache.org; Larry Rosen
>>> *Subject:* Re: Clarification about D&O insurance and bad acts
>>>
>>> <snip>
>>>
>>>
>>>
>>
>>
>
Re: Clarification about D&O insurance and bad acts
Posted by Ross Gardler <rg...@opendirective.com>.
Brian, you are absolutely correct. However, SVN is not the release and so
having reviewed commits is not the same as having reviewed the release. In
a well run project where people are reviewing code commits there should be
no problem. But people make errors and you would be surprised how often
those errors slip through.
Furthermore, since I (as a committer) cannot guarantee that I reviewed
every change to every file between release a and release b I cannot, as a
PMC member, be certain that the necessary files are present and correct. If
I were to vote +1 without having reviewed the release then my vote would be
worthless when it comes to demonstrating that our policy has been followed
for that release.
Ross
On 27 May 2014 10:25, Brian LeRoux <b...@brian.io> wrote:
> From my perspective this is a daily requirement of a responsible
> committer. That final check isn't hurting anything but it is not even
> remotely acceptable for a committer to not be constantly vigilant when
> landing commits to our source.
>
>
> On Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>wrote:
>
>> Ross Gardler wrote:
>>
>> > In my mind (and I am not a lawyer so that means almost nothing in
>> these situations) the requirement to have 3 PMC members indicate that, to
>> the best of their knowledge, the release is compliant with the policy is
>> sufficient.
>>
>>
>>
>> Leaving my lawyer hat off for a bit, it seems so to me too. I'm not
>> worried. I wasn't even worried about that when I served on the board. /Larry
>>
>>
>>
>> *From:* Ross Gardler [mailto:rgardler@opendirective.com]
>> *Sent:* Saturday, May 24, 2014 8:08 PM
>> *To:* legal-discuss@apache.org; Larry Rosen
>> *Subject:* Re: Clarification about D&O insurance and bad acts
>>
>> <snip>
>>
>>
>>
>
>
Re: Clarification about D&O insurance and bad acts
Posted by Brian LeRoux <b...@brian.io>.
>From my perspective this is a daily requirement of a responsible committer.
That final check isn't hurting anything but it is not even remotely
acceptable for a committer to not be constantly vigilant when landing
commits to our source.
On Sun, May 25, 2014 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com>wrote:
> Ross Gardler wrote:
>
> > In my mind (and I am not a lawyer so that means almost nothing in these
> situations) the requirement to have 3 PMC members indicate that, to the
> best of their knowledge, the release is compliant with the policy is
> sufficient.
>
>
>
> Leaving my lawyer hat off for a bit, it seems so to me too. I'm not
> worried. I wasn't even worried about that when I served on the board. /Larry
>
>
>
> *From:* Ross Gardler [mailto:rgardler@opendirective.com]
> *Sent:* Saturday, May 24, 2014 8:08 PM
> *To:* legal-discuss@apache.org; Larry Rosen
> *Subject:* Re: Clarification about D&O insurance and bad acts
>
> <snip>
>
>
>
RE: Clarification about D&O insurance and bad acts
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Ross Gardler wrote:
> In my mind (and I am not a lawyer so that means almost nothing in these
situations) the requirement to have 3 PMC members indicate that, to the best
of their knowledge, the release is compliant with the policy is sufficient.
Leaving my lawyer hat off for a bit, it seems so to me too. I'm not worried.
I wasn't even worried about that when I served on the board. /Larry
From: Ross Gardler [mailto:rgardler@opendirective.com]
Sent: Saturday, May 24, 2014 8:08 PM
To: legal-discuss@apache.org; Larry Rosen
Subject: Re: Clarification about D&O insurance and bad acts
<snip>
Re: Clarification about D&O insurance and bad acts
Posted by Ross Gardler <rg...@opendirective.com>.
So how do we demonstrate that 'individual PMC members comply in good faith
with an *approved* ASF release policy"?
In my mind (and I am not a lawyer so that means almost nothing in these
situations) the requirement to have 3 PMC members indicate that, to the
best of their knowledge, the release is compliant with the policy is
sufficient.
Personally, I cannot be certain I have reviewed every single commit between
release X and release Y and therefore I will never vote +1 on a release
unless I have spent the time reviewing the license, upstream license
compatibility, NOTICE file etc. By voting +1 I am saying that I have done a
review against our agreed policy and thus believe it is a valid release.
If I were ever pulled up in court I'd probably point to this mail (and many
others I have posted like it over the years, including at least one of my
board nomination statements) and claim it demonstrates a good faith effort
to be in compliance with the policy. I'd hope that the evidence of myself
and other mentors communicating this to podlings (and the board to TLPs)
would further demonstrate good faith efforts.
For me this is why a +1 is more than the tick box many people think it is.
Ross
On 24 May 2014 12:08, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> [This is an aside for the "ASF Release Policy" discussion.]
>
>
>
> I wrote this earlier:
>
> > I can assure you that there are things that individuals *could do* here
> that would get them in trouble. :-)
>
>
>
> One of the first plaintiffs I ever represented was a welfare recipient who
> was sexually abused by her county social worker. Although this was
> obviously outside the scope of his official responsibilities, the defendant
> county was forced to pay for legal counsel to protect itself from civil
> damages. That California county was self-insured; ASF buys D&O insurance
> for similar reasons.
>
>
>
> A few years ago there was discussion on various FOSS lists about how women
> are sometimes harassed at technical conferences. That is an example of a
> bad act that can force ASF to defend its own official anti-harassment
> policies using its D&O insurance (assuming that such alleged bad acts are
> covered by the specific insurance policy), but the bad actor himself has
> his own individual legal problems too! That is why ASF directors and
> officers are encouraged to behave themselves at our conferences, for their
> own sake and for the sake of our insurance deductible!
>
>
>
> You obviously are more concerned here about what ASF projects do with
> their software, and our "Release Policy" (as revised) has had a long thread
> here. But as long as individual PMC members comply in good faith with an
> *approved* ASF release policy, it shouldn't matter much what policy we
> finally approve. Courts don't usually fault non-profits for developing
> their own rational policies, and we have D&O insurance to protect us - and
> our directors and officers doing their official acts - if we follow a
> rational release policy.
>
>
>
> This is a long and partly rambling message to suggest that the discussion
> about the ASF Release Policy isn't really a *legal* issue at all and
> probably doesn't belong on this list. Define a rational policy and the law
> won't interfere.
>
>
>
> /Larry
>
>
>
> Lawrence Rosen
>
> Rosenlaw & Einschlag (www.rosenlaw.com)
>
> 3001 King Ranch Road, Ukiah, CA 95482
>
> Cell: 707-478-8932 eFax: 707-485-1243
>
>
>
> *From:* Lawrence Rosen [mailto:lrosen@rosenlaw.com]
> *Sent:* Saturday, May 24, 2014 11:10 AM
> *To:* legal-discuss@apache.org
> *Cc:* Lawrence Rosen
> *Subject:* RE: Release Policy
>
>
>
> 'Twas written on this list:
>
> > "But the point already got covered and answered dozens of times imo.
> The answer is that the ALv2 protects the foundation and also the release
> manager already for all bona fides cases. End of story."
>
> Is the above statement incorrect also?
>
> The above statement is only part of the story. ASF has a fully-functioning
> board of directors and complies (AFAIK) with all relevant laws. ASF obtains
> D&O insurance to protect itself and its directors and officers from many
> kinds of liability for negligence and to provide legal representation if
> necessary. That is enough to encourage us to proceed with our activities
> without worrying about random lawsuits.
>
>
>
> "Bona fide cases" is not useful terminology in this context. I can assure
> you that there are things that individuals *could do* here that would get
> them in trouble. :-) If there is something specific you are worried about,
> speak up.
>
>
>
> /Larry
>
>
>
> Lawrence Rosen
>
> Rosenlaw & Einschlag (www.rosenlaw.com)
>
> 3001 King Ranch Road, Ukiah, CA 95482
>
> Cell: 707-478-8932 Fax: 707-485-1243
>
>
>
> *From:* Dave Fisher [mailto:dave2wave@comcast.net <da...@comcast.net>]
>
> *Sent:* Saturday, May 24, 2014 10:41 AM
> *To:* legal-discuss@apache.org
> *Subject:* Re: Release Policy
>
>
>
>
>
> On May 23, 2014, at 1:51 PM, Brian LeRoux wrote:
>
>
>
> Ok, so end user software needs a vote to be a release and all projects are
> doing this without exception. If they are that is bad. Got it.
>
> Earlier:
>
> "But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release
> manager already for all bona fides cases. End of story."
>
> Is the above statement incorrect also?
>
>
>
> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
>
> On 23/05/2014 21:04, Joe Bowser wrote:
> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org>
> wrote:
> >> On 23/05/2014 Brian LeRoux wrote:
> >>>
> >>> Furthermore some projects such as OpenOffice mentioned
> >>> earlier do not follow the policy.
> >>
> >>
> >> OpenOffice does follow the policy. The only "special" thing OpenOffice
> did
> >> is to advertise development snapshots towards version 4.1 (these are NOT
> >> releases! we conduct formal votes on ALL releases, including beta
> releases!)
> >> outside the dev mailing list since we have a dedicated QA mailing lists
> and
> >> a testers community that does not coincide with our developers. And
> this was
> >> discussed in advance with both the board and the infrastructure lists.
> >>
> >
> > So, a snapshot is not a release?
>
> A snapshot is a release if only if it has been voted on as such by the
> PMC. It would also have to be tagged as part of the release which to my
> mind means it isn't really a snapshot. However the label that is
> attached to the release (RC, beta, stable, snapshot, etc.) is
> irrelevant. What matters is did the PMC vote on it. It the PMC voted
> (and assuming the rest of the release policy was followed) and the vote
> passed, it is a release. If that didn't happen then it isn't a release.
>
>
>
> > The problem is that there is one rule
> > for certain projects that have the board's favour and another for
> > projects that the board chooses to pick on for unknown reasons.
>
> Please provide some evidence to back up that assertion. I have been
> following a reasonable proportion if the discussion around Cordova and
> releases and, while I have seen plenty of evidence that the Cordova
> community doesn't like the constraints imposed by the ASF release
> policy, I have seen no evidence of the board doing anything other than
> requiring Cordova to follow the same release policy every other ASF
> project is expected to follow.
>
> If you are aware of any other ASF project not following the ASF release
> policy then please make the board aware. The board does not actively
> monitor the day to day activities of every project. If there are
> problems they rely on the VP to make them aware via the quarterly
> reports and if that route fails they rely on others in and around the
> project to bring the problem to their attention.
>
>
> > Why isn't a snapshot build a release?
>
> Short answer - because the PMC didn't vote. Long answer - see above.
>
> In this particular case this was not an OpenOffice release because it
> was not advertised to the end-user community for that software. It is
> perfectly within the intent of the current policy to include members of
> dedicated QA and test lists in the same category as members of the dev
> list. It is to the credit of the OpenOffice community that they went as
> far as checking that their understanding of the policy was correct
> before they did anything.
>
>
>
> The snapshots are very carefully fenced as a developer / qa resource in
> order to assure that when a release was made it would be of the highest
> quality.
>
>
>
> The PMC waited for complete consensus on the process and that took time -
> a number of weeks.
>
>
>
> Andrea did a very careful job communicating well within the ASF.
>
>
>
>
> What would not be acceptable would be for OpenOffice to start
> advertising snapshots to their end-user community unless votes had taken
> place and those snapshots had been formally released.
>
>
>
> Exactly.
>
>
>
> Regards,
>
> Dave
>
>
>
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>
>