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 Sat, 24 May 2014 06:53:34 GMT
Mark you mix up the legal aspect and the practical one.

The legal side is that the ALv2 pretty much ensures that you as author and as RM are not to
blame. 

Or course this only is true for parts which we do _not_ injure the rules of the ALv2.


Think about it: 
* how many Linux repos take our exact sources and binaries without adding patches etc? I'm
not aware of any. They all do their own 'release'
* how many $BIGCO JavaEE vendors take some apache sources (even 'random' snapshots^^) modify
them and 'release' em on their own?
* how many projects are around on github, sourceforge etc which are not getting sued?

As a further food of thoughts: if some person adds the ALv2 header to secret code of his customer
and publishes it on github, what would this mean? And there is no RM involved yet... 



The practical side is that due to the voting process we say "all the stuff in our SVN which
is not voted on yet is not yet checked and did not pass our marks". And with the VOTE (beside
_trying_ to ensure the quality) we spread the risk from a single RM to many people plus the
foundation. And this reduces the risk _in practice_! So it IS important.


Because the truth is: any person or company can sue anyone at anytime. It's really only a
matter of how big the chances are that he succeeds and how big the costs are in comparison
to the expected benefit. And it's also of course a matter of the public perception. If $BIGCO
sues a single person then there will only be a few who take notice. If $BIGCO sues the ASF,
then there would be pretty huge rumble. So yes, from a practical aspect it really matters.

Regarding the bona fides vs mala fides example I brought and seemed to have confused people.


What I meant is: if some person knowingly adds a backdoor then he might (and hopefully will)
get sued. And in this case neither the ALv2 nor the ASF can and will help.
And the opposite is also true. A RM acting in good faith and carefully doing his job has not
that much to fear.

Also the spectrum of suites which might follow is pretty broad. This might range from criminal
prosecution (backdoor case) over civil compensation (money) to just having us to remove the
code in question ('Unterlassungsklage', the most likely case).

I wont go into further details because we are really far away from the original topic of this
thread.
For interested people I suggest to start a law study - it's really fun and interesting most
of the time...

LieGrue,
strub



On Friday, 23 May 2014, 23:49, Mark Thomas <markt@apache.org> wrote:
 

>
>
>On 23/05/2014 21:51, Brian LeRoux wrote:
>
><snip/>
>
>> 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."
>
>I have not seen that statement expressed in any previous discussion I
>can recall about the release policy by a board member, V.P. Legal or one
>of our lawyers.
>
>It also appears to me (as a non-lawyer) to be obviously false.
>
>If $BigCo decides tomorrow that some Tomcat feature infringes one or
>more patents that $BigCo owns and therefore $BigCo decides to sue me as
>the release manager then I don't see anything in the ALv2 that helps me.
>
>However, I do so the release policy allowing me to say "Hang on. I
>didn't release that, the ASF did. Take this up with them." as well as
>the ASF saying "You did everything you were meant to. We'll do
>everything we can to redirect this hassle from you to us."
>
>Now there is the question of whether the court in question would allow
>the ASF to step in in my place (I'm sure there is a legal term for that
>but I forget what it is) but I do recall discussions that concluded that
>the release policy makes it much, much more likely that the court would
>allow that.
>
>> Is the above statement incorrect also?
>
>It appears so to me.
>
>Mark
>
>
>> 
>> 
>> 
>> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <markt@apache.org
>> <mailto: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 <mailto: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
>>     <mailto:legal-discuss-unsubscribe@apache.org>
>>     For additional commands, e-mail: legal-discuss-help@apache.org
>>     <mailto:legal-discuss-help@apache.org>
>
>> 
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>
Mime
View raw message