Hi, SteveC wrote: > And we'd like help similarly with building a practical definition of > Produced Work. Here's how the license RC1 defines it:
Obviously this goes hand in hand with the definition of a (derivative) database; everything you make from our data which is not a produced work will be a derivative database and vice versa. > "Produced Work" – a work (such as an image, audiovisual material, > text, or sounds) resulting from using the whole or a Substantial part of the > Contents (via a > search or other query) from this Database, a Derivative Database, or this > Database as part of a > Collective Database. > > Thoughts on more practical definitions? My first impulse has always been to think a produced work (as compared to a database) must be like a program binary compared to source code: A highly lossy transformation. That would then lead to a definition along the lines of "if the data is sufficiently disfigured it is a produced work". But one would always have to tiptoe the line (what about an SVG file? and what if the SVG file contains, in comments, every OSM object it refers to?) But someone (forgot who - stand up and claim credit if you read this!) has brought up a *very* practical definition during the discussion: "A produced work is whatever you declare to be one." It sounds crazy at first, but read on! This would effectively mean that anyone who makes anything from our data has a choice: * Either declare it to be a derivative database. This means he has to put it under ODbL (or a compatible license). * Or declare it to be a produced work. This means he has a wide range of licensing models available, all bound by the reverse engineering clause, *and* he has to make the derivative database from which he created the work available under ODbL. In an extreme example, this would mean that someone could take the planet file and say: "Here, that's my produced work, and it comes under the all-rights-reserved-whatever license." Fine - as soon as someone tries to use that planet file by e.g. loading it into a DBMS, the reverse engineering clause would kick in: "Creating a Produced Work, and then re-creating [...] this Database from the Produced Work, is still subject to this Licence." On the other end of the scale, someone who published PNG tiles on their web server could say: "No, this isn't a produced work, we consider these PNG files to be databases." - which would be in line with the EU definition of what is a database. The free choice between produced work and derivative database would probably end where the produced work cannot, by any twist of definition, be called a database; I guess that would be anything that is neither electronic nor arranged systematically in any way, e.g. some work of art made from clay or so. Such a freedom of choice would remove form us the burden to create a definition and to watch out for violations. It would of course also be attractive for certain use cases; say I created a system that renders tiles in real-time and I have applied clever simplification algorithms to the data which I would like to keep to myself. It would actually be quite attractive for me to say that my published tiles are a database and licensed under ODbL, because then that's all I have to release, whereas if I declare them to be a produced work, then the license would force me to release my cleverly simplified database. If people are uncomfortable with the full freedom of choice, then we could at least create a definition that contains a wide "choice band", i.e. the universe of derived works would be divided into (a) some that are clearly databases, (b) some that are clearly produced works, and (c) a large middle band where people have free choice. I'm still unsure if this would work, discussion much anticipated, but nothing would beat this in terms of practicality! (Except PD of course.) Bye Frederik _______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
