[Strategic] Fwd: Subject: Forks and such

TimSC mappinglists at sheerman-chase.org.uk
Mon Aug 30 17:16:49 BST 2010


On 30/08/10 09:53, Jim Brown wrote:
> TimSC wrote:
>>> We have more map data than we have before. Of course, it is not in a
>>> single database or under a single license. Is this a bad thing?
> Actually, the amount of USABLE data can be defined as the amount in a 
> single database I think...
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.

Basically, a "one size fits" all approach doesn't reflect all 
contributors or users needs. If you think "one size does fit all", you 
need to argue that a fork would add no value to other users (not just 
yourself), and that might be difficult.

> This is because the data in these forked data sets cannot be combined 
> for use.  It is likely that they cannot even be rendered by OSM itself 
> on a map tile.  They are truly islands of data, with the only common 
> attributes being that OSMF hosts them and that the same editors and 
> tools can be pointed to the data set for editing (probably as long as 
> the editing apis and server logic stays the same over time).
For clarity, I generally agree with this.

> Hence, I would still strongly argue that having multiple datasets with 
> different licenses is very different from having multiple tools, and 
> does not add value to the goal of creating the most complete map of 
> the world.  And the reason for this is that having different licenses 
> has a permanent and downstream impact on the data and how it can be used.
Ah, it is interesting that you said the goal of the project is "the most 
complete map of the world", when OSM's goal is generally held to be that 
OSM "creates and provides free geographic data". Not all users want or 
need a global database. May specialist maps only cover a small area. 
Don't assume everybody has the same requirements. (Extreme example, 
people have discussed mapping fictional worlds and other planets.)

On my original point, different OSM tools are available under different 
licenses. The code from one can't be shared with another. This is again 
similar to the situation for map databases. Effectively, the software 
code was never unified and it is difficult to do an API upgrade on every 
tool, for example.

> Tools and other differences do not have the same impact.  They can 
> come and go, be revised and experimented with and the impact that they 
> have is limited to their users, not to their output.  The data they 
> generate can be used in the same fashion as that generated by other 
> tools.  Datasets with different licenses permanently affect the data 
> contributed to them.
I am still not seeing any fundamental differences between software and 
database licensing. Both determine how the tool or data may be used. So 
what? That difference doesn't change how they add value to the project.

TimSC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/strategic/attachments/20100830/42bf33e2/attachment.html>


More information about the Strategic mailing list