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 21:38:47 GMT
Brian, you mixed up quite a few things. 


I'll try to explain again:
> 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. 

Yes, all ASF projects need a VOTE on their official releases. The question is rather whether
a nightly build or a published snapshot is a 'release' in this sense.

This is also something which Joe Bowser got wrong it seems.

There is a difference between "ASF Release" and 'release' in the sense of 'making something
technically available on the internet'. There is a huge difference in the quality we guarantee.
That's like having a publicly accessible water pipe which says "only for gardening, this water
is not for drinking!" vs a "drinking water" shield on it. 


> "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."


It is correct from a LEGAL perspective but the factum that some code is really ALv2 might
be in question .

I have to elaborate on this a bit.

Whether a certain piece of code you *originary* produced is [insertlicensehere] or not depends
only on YOUR will. If you knowingly and willingly define it should be ALv2 then this is it.
You don't even need to publish it. You don't even need to type it into a computer. Just writing
it on a toilet paper would be enough *from a legal perspective*. So far so good. But this
is not good enough from a FOUNDATION point of view!
How should other project members, e.g. the release manager know that you originally wrote
the code yourself? What if someone checks in code which has a GPLv2 or other Category X [1]
license? Legally a single release manager which is 100% sure that he knows all this would
be enough. But who likes to be that guy who puts all the weight on his own shoulders? To not
let such things slip through to an *official* ASF project release and to lay this weight on
many shoulders we do the VOTE stuff. 10 pair of eyes just see much more than a single one.


summary: Amongst other things the VOTE is for checking whether the code REALLY is ALv2. Because
only then the aforementioned legal statement comes into effect.

And once again, there is a difference between what law requires us to do (as a bare minimum)
and the quality level aka release policy we gave ourselves (for good reasons). And to make
it even more complicated: there re legal rules which are required to get fulfilled in some
cases which are NOT covered by our release policy. E.g. the security export restriction paperwork
for all parts which contain or use encryption of a certain kind...


LieGrue,
strub


PS: hope I do not confuse people even more
PPS: legal stuff is like permute - it always looks slightly different depending on the angle




[1] http://www.apache.org/legal/3party.html



On Friday, 23 May 2014, 22:52, 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
>>
>>
>
>
>
Mime
View raw message