www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Release Policy
Date Fri, 23 May 2014 15:23:19 GMT
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