On 01/12/11 00:33, James Livingston wrote:
On 1 December 2011 00:18, Jonathan Harley <j...@spiffymap.net
<mailto:j...@spiffymap.net>> wrote:
By way of analogy: suppose I sent you a private email which
included a license saying if you publicly use my email, you must
share with me any other emails you combine it with. My email sits
in your inbox together with other emails, and you can do searches
across all of them. If it's a unix system, they're probably all in
one single file. But have you really "combined" my email with your
other private emails? My email is sitting there unmodified and
completely independent of all your other private emails; it is not
itself combined with them. So no, "storing next to" is not
"combining". You can safely share a screenshot of your mail
program without having to send me all your other private emails.
The problem with analogies is that they are analogies and aren't the
same as the original thing. As a similar one, what if instead you sent
me your mailbox rather than a single email, and I imported all your
mail into mine (so are probably stored in the same file). Although
none of the actual data (emails) have changes, they are stored
together (possible even in a SQL database rather than flat files).
I don't know if that would count as two collective databases or a
single derived database.
As long as you can still tell which emails came from my mailbox, then
definitely collective. Being stored together does not form a derivative
database.
(I think we may have some terminology confusion here: in IT we tend to
think of a database as "all the data that can be accessed through this
software" - but when lawyers say database they really mean dataset, and
how it is stored and retrieved isn't relevant.)
If your mail software threw away some of the header information in my
emails (specifically the envelope-to field) so that you could no longer
separately search my emails and your emails if you wanted to, that would
probably be a derivative database.
If the rendering of the second output depends on the first
dataset, the Produced Work created from the second dataset is not
independent of of the first dataset.
No, the produced work isn't independent of it, but the datasets
are still independent of each other, that's my point.
My point is that to actually do the rendering, you will have created a
single database containing both datasets in the process (albeit
possible as transient in-memory data structures). I don't think we're
really disagreeing, just both unsure as to where the line is and
guessing on different sides :)
I think we may be just making different assumptions about what rendering
involves? I was thinking of a simplistic renderer that would simply
examine each map feature independently and decide whether/how to render
it based on what had already been rendered (for example onto a tile),
but you're right, another way would be to build an in-memory structure
representing parts of both and then do something with the combination.
I don't really think that in-memory data structures count as databases,
though. The ODbL says "using this Database... to create a Produced Work
does not create a Derivative Database". I would have thought that the
software doing its work would count as "use" for this purpose.
It seems to me that this would be something a future version of ODbL
could be clearer on, though.
Jonathan.
--
Jonathan Harley : Managing Director : SpiffyMap Ltd
Email: m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com
Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ
_______________________________________________
legal-talk mailing list
legal-t...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
