[Strategic] Fwd: Subject: Forks and such

[Grant Slater]

On 30 August 2010 17:16, TimSC <mappinglists at sheerman-chase.org.uk> wrote:
> I'd have to disagree with you there. Of course if there was a single user
> with a single objective, there would be a single database which was the most
> suited to that user. But this doesn't reflect our current situation. We have
> different regional situations for mapping contributors, and different users
> with differing legal demands. For example, some Australian contributors have
> used a CC-BY-SA import source to create mapping. If we then have an
> alternative ODbL dataset, which is much more sparse, can you say which is
> best: the CC-BY-SA densely mapped or the ODbL sparsely mapped database? I am
> not arguing that the CC-BY-SA database is most appropriate in all cases. For
> users who operate only in Australia, the CC-BY-SA is legally ok and much
> more complete. An international user who is legally cautious might prefer
> the ODbL version. The same differing requirements also is seen for
> contributors. A big CC-BY-SA import can't go into a CT/ODbL database but it
> could be usefully added to a CC-BY-SA fork. And perhaps OSMF might negotiate
> data imports that are only compatible with CT/ODbL and not with CC-BY-SA.
>

1) CC-BY-SA licensing:
The Australian govement data that was imported is CC-BY licensed,
which is a much easier problem to deal with. The License Working Group
is working with legal to clarify that it is acceptable under ODbL. I
am confident a solution will be found.

The Australian aerial imagery provider NearMap is currently insisting
on dervived features "tracing" being made under the CC-BY-SA license.
The License Working Group has a positive ongoing direct discussion
with NearMap and I'm confident a solution here too will be found.

There are a few CC-BY-SA imported datasets which will be renegotiated
along with LWG/OSMF support. The "By Attribution" and "Sharealike"
principles are in ODbL. OpenStreetMap is a well known international
GIS project, it is with this strength that we will be able to
(re)-negiotate imported data.

It can also to be said that wildly importing data is a direct
impediment to real mapping. Real mapping is what makes OSM unique.
See: http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community/
& http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community-ii/

2) Duplication of Software vs "forked" data duplication of work analogy:
The OSM editors software follows a very well defined specification. A)
API: Set of rules governing how data map be queried and uploaded. B)
DATA: OSM has a clearly defined XML data specification. C) Other:
Usability, coding style are defined by the projects but again narrowly
defined.
This is not true for OSM's GIS data which does not follow such a
strict set of rules and specifications. OSM's (and Wikipedia) strength
is the freeform nature in which people can organise and manipulate the
data. Creating strict rules to manage the formatting etc to allow
duplication/"cross database sharing" would impare the project.

I spend at least 3 hours a week going through keepright in Africa and
fixing problems with the map'ed and imported data, having to do this
in a ODbL, PD & a CC-BY-SA licensed databases would at best limit me
to around 1 hour on each database or at worst I'd only fix 1 dataset
which would diverge further from the other databases. Each database
may have completely different specifications. eg: OSM API 0.7 it has
been proposed to introduce a new datatype "polygon" made of a closed
series of nodes. Would the other databases also implement this feature
or would they diverge on the DATA specification too?

3) Fiefdom / Tribalism is the enemy.
Mark Shuttleworth says it better than I ever could:
http://www.markshuttleworth.com/archives/439

Regards
 Grant