[Local-chapters] Editable Servers

[Serge Wroclawski]

We had a productive meeting today but one issue wasn't able to be
resolved, so we discussed bringing it up on the list.

The crux of the matter is the wording in the Chapter Agreement that says:

"The chapter may however operate a clone of the database for running
its own tile-server or any other service that makes use of the data
(and is not editing the data)."

The general consensus of the meeting was that this wording is to
ensure that there is a single unified dataset. I agree that having a
single dataset that's "OpenStreetMap" is a good thing.

The problem the wording imposes, though, is multifaceted, so I'm going
to break down the objections raised by the US group:

* Changeset-capable servers allow us to make updates to OSM

One of the things that makes the US somewhat lucky is that we've been
approached by government agencies who are genuinely interested in OSM.
They really want to make it easy to get their data in OSM.

To that end, we've been working on a variety of approaches to allow
that to happen, from improved shapefile conversion tools, to
discussions on ways to break up import reviews, to discussions of
fully automated mechanisms to create diffs between versions when
governments provide us new datasets.

With such a tool, when the municipality gives us a new dataset, we
could potentially create an changeset automatically, then push that
back upstream.

This provision would prohibit that, and that's bad for OSM.

* Editable servers open doors

One of the other potential avenues of work in the US is the desire by
some groups (including governments) to run their own crowdsourced
dataset. They can't use OSM itself because they often want to provide
the data under a different license- either public domain or something
very permissive.

Of course they can do this themselves. The town of Springfield could
stand up their own custom instance of OSM and then provide editing. Of
course it would be "closed loop", but if the data were public domain,
we could feel legally free to slurp it into OSM. But for that, again,
we need something that can generate changesets and push them upstream.

* Architectures Change

OSM evolves. With each iteration of the API, the system becomes more
complete and more capable. And there's been a general abstraction in
the API. The API does not map directly to the underlying data store.
This is a very good thing, as it allows changes in the implementation
without effecting the API. We may find that in time a new architecture
could be created which would allow multiple clusters to coexist where
all of them are writable and all of them share the same unified data
set. This chapter agreement would cut that option off for local
chapters.

* Additional License-like requirements

If you read the chapter agreement as it pertains to the data, it, in
effect, creates a new license. Let me explain it more:   If I'm an
independent third party, I can fork OSM at any time so long as I abide
by the terms of the license. I could take a planet.osm, load it up on
my own server, begin offering an editor, and go to town. This chapter
requirement explicitly says that a local chapter is prohibited from
running a server that has the capacity to create changsets (ie to
edit). That's acting as a de-facto new license requirement.  Not only
do I think this is a very bad idea, but it's prohibited from the
license in section 8e to bound the licensee by any additional terms
other than those explicitly specified in the license.

* Exiting mechanisms exist to handle this situation

Since we can all agree that the data itself is protected by the
license, what's controlled by the Foundation is the term (and possibly
trademark) "OpenStreetMap". I'm free to take a fork and call it
"Serge's Map" but I can't call it OpenStreetMap without permission
from the Foundation, which is the exact reason for Chapters.

Since that's established, if any Chapter should fork the dataset, the
existing rules for handling disputes between the Chapter and the
Foundation would be in place to prevent the Chapter from continuing
this activity. The Chapter which did this would be disbanded, and then
they'd not be allowed to call it OpenStreetMap anymore.


To summarize: I think we want to have a unified dataset, but that
restricting servers capable of making changesets isn't the way.

- Serge