[Strategic] Fwd: Subject: Forks and such

[andrzej zaborowski]

Hi,

On 31 August 2010 02:36, Grant Slater <openstreetmap at firefishy.com> wrote:
> 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.

Last I heard, NearMap, like many individual mappers (me included)
support the ODbL, but don't support giving the OSMF the possibility to
change to another license without knowing what that license will be.
Once a specific license is proposed it will be a good time to decide.

>
> 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.

Which is meaningless because the OSMF wants much broader rights than
to release the database under this license.  Effectively only
public-domain-like licenses are compatible (I don't see how CC-By can
possibly be compatible with the current CT).  So the text of the ODbL
should not be a factor in the negotiations, it can only be used as a
sort of bait.

Just today I have started a discussion on the mailing list of another
CC-By-SA mapping project who's data is being used in OSM to sense how
much data we will be able to keep.  So far just two people out of
about 10 who contributed to the discussion openly disagreed, both
based on the upgrade clause in CT, not the ODbL.  OSMF is an alien
body to them.

> It can also to be said that wildly importing data is a direct
> impediment to real mapping.

This has been discussed so many times on the talk list, with so many
arguments on one side and on the other one, and so many intelligent
blog posts, that claiming that imports are bad or good for mapping is
always subjective.  There is a vocal minority against imports and it
has become the most vocal during the license change.

> 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.

That's the same problem you get with forked software.  Also I'm quite
happy with the level of coherence in tagging between geographic areas
in OSM.  Since the forks are proposed by the same community who has
been taking part in the old OSM, I don't see them diverging so much
that the software built for OSM would become unusable with any of
them, I'm sure any actions in such directions would be discouraged.

Cheers