www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Release Policy
Date Fri, 23 May 2014 23:20:40 GMT
The protection of individual action is codified by the agent acting at the will of the committee.
 You don't need AL protections, BSDL decades ago introduced a shield.  But that shield is
not effective in every jurisdiction, so acting on behalf of the Foundation according to the
direction of the PMC is the fallback security blanket.  And an effective one, at that, if
the acts of the Chair or an RM are shown to be in good faith to the foundation.

Davanum Srinivas <davanum@gmail.com> wrote:

>Brian,
>
>IANAL. I do not remember seeing it as a goal when ALv2 was drafted
>("to protect the foundation argument") [1], i don't see any reference
>to the foundation in the ALv2 text itself and i dont see it any of the
>FAQ or web pages from the legal committee.
>
>[1] http://apache.markmail.org/thread/p6xtxoqb5n4juhfd
>
>On Fri, May 23, 2014 at 5:20 PM, Brian LeRoux <b@brian.io> wrote:
>> Actually, no that doesn't clear it up. To me that says, the PMC exists to
>> thwart individual liability. Fair enough. A PMC initiated robot that presses
>> a button to launch a release on ./dist should suffice then.
>>
>> The earlier statement made here:
>>
>>
>> ""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.""
>>
>> …seems to contradict that is even necessary.
>>
>> Sorry I'm not trying to be difficult (REALLY!) but this is very unclear, and
>> obviously it is very crucially important to be clear. The purpose of the
>> thread and initiative for clarity.
>>
>>
>>
>> On Fri, May 23, 2014 at 4:14 PM, Davanum Srinivas <davanum@gmail.com> wrote:
>>>
>>> Brian,
>>>
>>> This really old email from Roy may help -
>>> http://markmail.org/message/ofxh3lkygcxiigf3
>>>
>>> -- dims
>>>
>>> On Fri, May 23, 2014 at 4:51 PM, Brian LeRoux <b@brian.io> 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> wrote:
>>> >>
>>> >> On 23/05/2014 21:04, Joe Bowser wrote:
>>> >> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>>> >> > <pescetti@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.
>>> >>
>>> >> 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.
>>> >>
>>> >> Mark
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>
>
>
>-- 
>Davanum Srinivas :: http://davanum.wordpress.com
>
>On Fri, May 23, 2014 at 5:20 PM, Brian LeRoux <b@brian.io> wrote:
>> Actually, no that doesn't clear it up. To me that says, the PMC exists to
>> thwart individual liability. Fair enough. A PMC initiated robot that presses
>> a button to launch a release on ./dist should suffice then.
>>
>> The earlier statement made here:
>>
>> ""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.""
>>
>> …seems to contradict that is even necessary.
>>
>> Sorry I'm not trying to be difficult (REALLY!) but this is very unclear, and
>> obviously it is very crucially important to be clear. The purpose of the
>> thread and initiative for clarity.
>>
>>
>>
>> On Fri, May 23, 2014 at 4:14 PM, Davanum Srinivas <davanum@gmail.com> wrote:
>>>
>>> Brian,
>>>
>>> This really old email from Roy may help -
>>> http://markmail.org/message/ofxh3lkygcxiigf3
>>>
>>> -- dims
>>>
>>> On Fri, May 23, 2014 at 4:51 PM, Brian LeRoux <b@brian.io> 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> wrote:
>>> >>
>>> >> On 23/05/2014 21:04, Joe Bowser wrote:
>>> >> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>>> >> > <pescetti@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.
>>> >>
>>> >> 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.
>>> >>
>>> >> Mark
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>
>
>
>-- 
>Davanum Srinivas :: http://davanum.wordpress.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
Mime
View raw message