On 22/10/12 16:35, Martin Koppenhoefer wrote:
2012/10/22 Jonathan Harley <j...@spiffymap.net>:

You have an obligation to make your derivative database available, if you
made one.

or describe the details and release the code, how you did it, in this
case you don't have to release the data.

Oops, yes, I over-simplified. But you don't have to describe the details AND release the code, you can do either/or.

Unless, and I'm assuming you don't intend this, it was accurate enough to be
used as data - for example, if you labelled the lat/long of the bounding box
accurately and included high enough resolution vector data.

I think you won't have to judge on how high the resolution would have
to be, neither must the image be georeferenced: with any
translation/modification/alteration a database would still remain a
derivative database under the ODbL. Frederik wrote some time ago he
believes it might depend on the intent with which you use the work.
According to this you might probably use the same work as work and as
database, and according to your use, different terms would apply. What
is important here is that the recipient of the work gets notice of the
obligations in case he would reuse the work as a database. So actually
the license with which you release your produced work is not
comparable to having the full copyright.

I'm not quite sure what you mean by "full copyright", copyright is a right which you get from creating something (at least in English law) and it definitely applies to maps. I suppose you mean the case where you're the sole original author and aren't bound by the license conditions of some database you used.

Anyway, the ODbL is explicit that an image is an example of a produced work, so for anyone creating them, their responsibility is clear: include the notice required for produced works.

It's also explicit that a produced work is not a derivative database (4.5b), so it follows that a map image does not have to be licensed using ODbL. So, the hypothetical person wishing to publish on a stock art website only has to decide whether they wish to impose ODbL or some other restriction on their work, or not. Not imposing any restrictions on an image is clearly allowed. (In which case a database derived from the image would not be bound by ODbL.)

What's muddy is whether a vector image is, or might in some circumstances be, a database. In the absence of a clear definition, my guess is that it depends how much usable geodata is in there. That's surely more measurable than intent. So my answer to the question about "can I publish an OSM-derived map as SVG" is "yes, but make sure no OSM XML tags get carried over into the SVG XML, then there will be no doubt that it's a produced work not a derivative database".



At least this is what I hope ;-) . I am not sure if legally there is
maybe the requirement for an explicit restriction to not re-engineer /
re-construct the database from produced works in order to prohibit it,
in this case this would be a loophole.


I think it's clear that creating a new database from a produced work (that isn't a database) is not prohibited by ODbL. But I don't think it's really worth worrying about; reverse engineering an image, or an SVG file that doesn't include the original lat/lons would result in such an inaccurate database that I can't imagine anyone would want it. You only have to look at what trouble Apple have been getting into with their various not-quite-matching datasets.

(Aside: I went to SotM Scotland this weekend, and Apple Maps advised me to abandon my car on Waverley Bridge and continue by foot into Princes St Gardens, as that is where Apple believes Edinburgh is located for the purposes of driving directions!)

J.

--
Dr Jonathan Harley   :    Managing Director    :   SpiffyMap Ltd

m...@spiffymap.com      Phone: 0845 313 8457     www.spiffymap.com
The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK


_______________________________________________
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Reply via email to