[Osmf-talk] New license proposal status II
kakrueger at gmail.com
Tue Dec 8 13:35:57 UTC 2009
Henk Hoff wrote:
> 2009/12/8 Matija Nalis <mnalis-openstreetmap-osmflist at voyager.hr
> <mailto:mnalis-openstreetmap-osmflist at voyager.hr>>
> The question is: provided OSMF members give >50% "yes" vote for the
> change, is there any "abort percentage" if the non-trivial number or OSM
> contributors is against change ?
> There is not a distinct answer to your question. We could get into a lot
> of what-if scenario's. The problem with those what-if scenario's is that
> reality is always different. That's why the "week 9" and "week 13" are
> in the timeline, to give us a feeling of the direction of the most
> likely scenario and act accordingly.
As much as I understand the need for flexibility in the process of
deciding how to deal with the loss of data and deal with what-if cases,
I would still be strongly in favour of a hard "abort criterion" set
_before_ the results are out. I.e. agree on some measures that if they
aren't met the license change can't go ahead in this form and things
have to be reconsidered until they are met. I think it is important for
several reasons that they are decided upon before the results of who
will allow re licensing and who not are known to anyone.
It is far too easy to get biases into the process otherwise. Biases of
the form "Oh, we are so close to the result we want, can't we just shift
the boundary a little so that it fits the outcome we want? The boundary
is completely arbitrary anyway, so moving it is no more arbitrary than
before". Now I am not accusing the LWG or anyone else involved in the
decision of deliberately being biased in any way, in fact I highly trust
them and think nearly all of them are as rational as one can get,
knowing some of the LWG members personally, but there is always the
chance of subconscious bias, or influenced by "lobbying", that is just
human nature and nothing anyone can do about it. That is why you
sometimes do need strict rules and criteria, even though they may
restrict the necessary flexibility.
Secondly, even if the decisions aren't in anyway biased or influenced
which is despite what I just said definitely the more likely case,
people will accuse those that made the decision of being biased, putting
guns to peoples head or what ever other nasty conspiracy theories one
can think of. So I think in the own interest of everyone, I think it
would be better to have the inevitable flame ware about the criteria now
than latter on, when we will need to concentrate all our effort on
minimizing the fallout of the actual licence change. Which I am
convinced we can do if we all then pull together in one or at least a
similar direction, rather than fight amongst each other. If the
criterion are set before the results, then it is much harder for people
to argue for unfair processes by the OSMF or LWG.
And the third reason, well, I have said it already, is that I rather
have the discussion now (or at least soon) and clear up the later time
stage for the technical work still ahead of us.
I have no idea at the moment what those criterion should be, but I
believe they must be set such that the majority believes that there will
be no long term damage done to the project due to lost data, lost
contributors or worst substantial forks.
Something along the lines of perhaps, No more than 10% of contributors
may be lost as well as no more than 5% (corrected for Tiger) node / ways
lost completely or 10% of nodes / ways rolled back to earlier versions.
Those numbers are arbitrary, but it is probably roughly the ball park I
would want them to be in, though probably on the high side and this
clearly needs some debate.
All that said, I would probably be in favour to set the criterion a
little loser than my true believe, just to leave some room for
flexibility that we will also no doubt need.
> Although one clear answer I can give you: the change will not proceed no
> matter what the casualties.
> You will be able to follow the progress during the acceptance fase.
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
More information about the osmf-talk