[Osmf-talk] New license proposal status II

Matija Nalis mnalis-openstreetmap-osmflist at voyager.hr
Sun Dec 20 20:02:34 UTC 2009


On Thu, Dec 10, 2009 at 01:37:26AM +0100, Matija Nalis wrote:
> I do understand the need for flexibility and reluctance to get into a
> detailed analysis and what-if game of each of the million possible different
> possibilities.
> 
> I do however feel that *SOME* hard rules *really should* be set way *before*
> the "week 9", ideally before "week 3" (as such information might impact some
> OSMF membership votes). I think it would much calm the people, and reduce
> pressure at later point in time when there will be enough pressure even
> without it (week 9-13).
> 
> The (hard) decision will HAVE to be done anyway (and not that far away in
> the future), and it would make (at least me, can't claim for others) much
> more at ease if it looked like we actually have some sort of plan and rough
> guidelines how things will proceed (currently it looks to me like all
> planning ended with the producing of the proposal, and that nobody knows
> what is or will be happening. I realize I'm probably wrong, but that's how 
> it looks to me ATM -- time is passing and Implementation wiki is not being
> updated, see below)
> 
> The additional advantage to doing that decision (that has to be done) now
> instead of at the last moment is that if the Board/LWG gets undecided on the
> gray area boundaries, they could poll opinions of OSMF members with much
> less stress and with some more time to act and hence come with better
> solution.
> 
> So I'm hoping for something that leaves gray areas unanswered (thus giving
> flexibility) but at least somewhat defined, and puts the boundaries on white
> and black areas. Nothing too detailed and most definitely something that is
> easy to quickly agree among all board members [1] and which leaves the grey
> area mostly undefined. For example (of course you'd change the numbers, I'm
> just giving rough idea of the *form* I'd very much like to see):
> 
> a) if the OSMF members vote give less than "50%" yes-votes, Board will not
>    proceed with any further licence-change activities and will instead work
>    with OSMF members to see what were the reasons against and what could be
>    changed to fix that; and come with another proposal if possible. (that
>    part have been defined already, right ? Or so it looked from some emails
>    on the list... If so, the numbers and info put on the wiki for
>    Implementation plan timeline)
> 
> b) if the OSMF members vote give more or equal of "50%" yes-votes, the Board
>    will proceed with up to the "week 9" timeplan, and then analyze OSM
>    contributor votes, and the weight of their contributions and depending on
>    that do one of the following:
> 
> b.1) if less than 80% of OSM contributors gives permission to change to ODbL, 
>      or if more than 15% of the data (nodes, ways, relations) is calculated 
>      that it would need to be deleted, the Board would abort the process, and try
>      to see with OSM community what are the reasons[2], and then try to fix
>      that. (AKA "black area", should be easily agreed upon all the Board members)
> 
> b.2) if more than 98% of OSM contributors gives their permission to change
>      to ODbL, and if less than 1% of the data is calculated would need be
>      deleted, the Board will proceed with the timeline to "week 13" and
>      backup+removal of data [3] (AKA "white area", should be easily agreed
>      upon all the Board members)
> 
> b.3) if the number of ODbL-accepting OSM contributors is between 80-98%, or
>      if the data to be removed is between 1-15% of all OSM data, the Board
>      will present the situation to OSMF membership (along with comments from
>      [2]), the timeline processing will be suspended, and the Board/LWG will
>      get in detailed analysis and discussion with OSMF membership on how to
>      proceed. (AKA "grey area", where Board members could not easily agree
>      upon the numbers and/or actions)
> 
> By reducing the what-if game to just a 3 choices (by leaving b.3 vague by
> design), it is made much more simple to define.
> 
> As I said, such a decision will HAVE TO BE MADE eventually anyway, and I at
> least would feel much more at ease knowing such hard decisions will not be
> happening "on the fly" in short timeframe, but that at least there will be
> such a boundaries agreed upon and published in advance, BEFORE the OSMF
> voting (much less OSM contributors counting!) is finished.
> 
> Also, the number are just examples, if the Board can only easily agree with
> "30%" instead of "80%" or with "50%" instead of "15%", or whatever, that is
> okay. But some numbers should be easily findable that everybody can quickly
> agree to, and you narrow them until you can't get unanimous decision any
> more.
> 
> So I think that is easily doable (at least easily compared to other
> decisions that will have to be made!), and that it should be done ASAP.
> 
> Thanks for listening,
> Matija
> 
> [1] or LWG members -- who is actually driving the action at the moment now
>     the license proposal is finished ?
> 
> [2] actually, it might be incorporated in the week4/5 OSM contributors
>     questions. When/if the contributor gives their final (second) "no",
>     they should be presented with a comment submission box so that can say
>     *why*.  So in the case the situation ends in b.1 or b.3, we'll already
>     have much of the comments why it failed and act accordingly. I think
>     that would be a very good idea to do. Do you agree ?
> 
> [3] the http://wiki.openstreetmap.org/wiki/Open_Data_License/Implementation_Plan
>     timeline says at "Week 13" that there will be a "Community Question...
>     What do we do with the people who have said no or not responded?"
>     Is that poll still the main idea ? Or is that decided that data would be
>     backed up and removed ?

So, would something like that have a chance to happen yet ?
Or if not, any reasoning why not ?

-- 
Opinions above are GNU-copylefted.




More information about the osmf-talk mailing list