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:28:38 GMT
@mark Of course. This is what we do as committers. Daily! And yes, we use
Rat too. :)
On May 23, 2014 10:23 AM, "Mark Struberg" <struberg@yahoo.de> wrote:

> SOME parts could be done via automated scripts. Like checking whether the
> key is correct.
> Other things like checking if a file is just not only labeled as ALv2 but
> really IS it (and not just copied and illegally 're-licensed') and various
> other things can only be checked by humans. Most times such things
> automatically already pop up because PMCs *should* also be subscribed to
> commits@xxx.a.o of their projects. But other things like checking
> dependencies and proper NOTICE files are really up for humans to visually
> verify the content.
>
> The creadur project [1] (formerly known as 'rat' - Apache Release Audit
> Tool) already helps with a few automated tasks if you have an ant or maven
> build. This project could btw need some additional helping hands...
>
> LieGrue,
> strub
>
> [1] http://creadur.apache.org/
>   On Friday, 23 May 2014, 17:02, 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.
>
>
> 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.
>
>
> ‚Äč
>
>
>
>
>
>

Mime
View raw message