[Osmf-talk] Contributor Agreement is Dual Licensing
matt at asklater.com
Sun Dec 13 14:14:55 UTC 2009
> On Sun, Dec 13, 2009 at 10:01 AM, Frederik Ramm <frederik at remote.org
> <mailto:frederik at remote.org>> wrote:
> Gervase Markham wrote:
> > On 12/12/09 15:16, Frederik Ramm wrote:
> >> The main reason, I think, is that what you (the individual
> >> have is not necessarily a database (think of someone just making
> a few
> >> fixes to road names or so).
> > That may be true. But that doesn't require the OSMF to have special
> > rights. Why not write the licence so whatever rights downstream users
> > need are granted to them directly by the original submitter of
> the data?
> > There should be no need for the involvement of a third party.
> ODbL is a license that can be used for people who already have a
> database that they want to license.
> That OSM is a project where a database comes into existence by having
> lots of people contribute to a common pool is outside the scope of ODbL.
> Making a license that covers the crowd-sourced creation *and* the
> downstream licensing of a database would surely be possible but that
> would be an entirely different beast I believe, and also one that would
> in all likelyhood be a special OSM license used by nobody else than OSM.
> Isn't that what ODbL plus Contributor Terms is? Something different
> from ODbL, incompatible with other ODbL data and unique to OSM.
incompatible on import, compatible on export. if you have some ODbL data
then there's nothing in the contributor terms or ODbL which would
prevent you from combining the two and redistributing it. but it
wouldn't be possible to add it to OSM.
> It seems to me that the Contributor Terms are the source of many of the
> problems identified with the proposed license scheme. They hinder the
> ability for other ODbL datasets to be added to OSM, they prevent
> attribution-only datasets from being added to OSM.
they prevent other ODbL datasets from being added to OSM. i, personally,
don't think this is a bad thing. instead of hunting for datasets to
import, maybe it would be better to go out mapping?
> Additionally, they load a lot of responsibility onto OSMF and take away
> the ability for contributors to protect their own data.
this is incorrect. all contributors still retain their rights to their
data, these aren't taken by OSMF and contributors still have full
ability to protect their data.
> OSMF becomes a single point of failure. This is not a good thing.
according to our own counsel, OSMF already was a de-facto single point
of failure as the licensor. in that regard, very little is changing.
More information about the osmf-talk