www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Release Policy
Date Fri, 23 May 2014 15:33:10 GMT
C'mon Sebb. This is circular false logic.
On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com> wrote:

> On 23 May 2014 16:01, Brian LeRoux <b@brian.io> wrote:
> > @mark agree, there are many layers to the stated legal perception and
> indeed
> > most other OSS projects do not require a VOTE. It was communicated to me
> > that the VOTE specifically mitigated risk to the releasing individual
> > (publishing artifacts to ./dist). This, and human error, are mitigated by
> > not using humans to perform those actions susceptible to human error.
> That
> > is the point of a CI system and automated builds. All the actions of a
> > release could be done by a machine and ensuring the policy will allow
> that
> > is what I'm looking for.
>
> However, the CI and automated build systems are created by fallible humans.
>
> This is why it is important to ensure that the release vote contains
> sufficient details for an independent check of the source release
> contents against the SCM tag.
>
> >
> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <struberg@yahoo.de>
> wrote:
> >>
> >> Brian, we only specifically talked about whether we should be allowed to
> >> give_intermediate_ build artifacts like nightly builds, etc to
> interested
> >> people. I personally find it a bit too restrictive to not allow to
> publish
> >> those for user testing. We (the foundation) already do this via our
> >> snapshots maven repos...
> >>
> >> And there are also different layers of 'legal'. There is no law in the
> US
> >> nor otherwhere in the world who requires a VOTE before an opensource
> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >>
> >> BUT: it is an ASF policy and thus binding for all our projects to VOTE
> on
> >> releases.
> >> And it is a really good one as it increases the technical and legal
> >> quality of our products! It's really a good thing to have 10+ people
> looking
> >> at a release and e.g. discovering that a file has the wrong license and
> >> should get removed again for example. And of course it helps reducing
> the
> >> risk from getting sued because we obviously try to minimize human
> errors.
> >>
> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> list,
> >> maybe it is enough if we just rise awareness.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@brian.io> wrote:
> >>
> >>
> >>
> >>
> >>
> >> "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."
> >>
> >>
> >> Interesting for myself to note that it was communicated very directly to
> >> Cordova that this *was not* the case. Votes are a necessary component
> for a
> >> valid (aka legal) release. Also interesting for me to discover in this
> >> thread that the release policy is not adhered to by all ASF projects. We
> >> were lead to believe the rules are immutable, all projects obey them.
> End of
> >> story.
> >>
> >> I am dismayed to discover this is not the case and Cordova was singled
> >> out.
> >>
> >> However, clarity here is a great starting to amending the rules, and I
> >> recognize this effort is not forum for that. My perspective: the vote
> is a
> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> computer
> >> (aka CI system) and not a human and I am very happy to hear there is
> >> precedent for this with other projects.
> >>
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Mime
View raw message