An interesting blogpost by cloudsourced about “Why OpenSpaces and GeoVation Vexes Me So“, talking about the key question – generally – about trying to build stuff using the Ordnance Survey’s OpenSpace API: why does OS want to demand that what you build with it becomes OS’s property?

Derived Data. The single most stifling element of the Ordnance Survey’s licensing regime is the practice of claiming copyright over any data derived from an OS base map. This has massive implications to anyone in a public sector body, or anyone who wishes to use their data. Any geographical data created by a public sector body (who almost exclusively use OS data) is not their’s to do what they like with, it is claimed by the Ordnance Survey under their copyright. Local authorities cannot share the location of its rubbish bins with the public, does this sound absurd to anybody else? Derived Data stops dead any effective sharing of public geographic data, and any innovation that would come from it.

This is a topic we’ve gone over and over. Interestingly, cloudsourced links to the terms & conditions of the OpenSpace API, which goes like this in section 5.4 on Derived Data:

5.4.1 You may create Derived Data, and You may permit End User’s to create Derived Data, in connection with Your Web Application. In the event that You or any End User creates Derived Data, such Derived Data shall be owned by Us

Flipping heck! Same old rubbish. But hang on, what’s this?

save that if any Derived Data is created which is a severable improvement (as defined by Commission Regulation (EC) No 772/2004, known as the Technology Transfer Block Exemption) of the Ordnance Survey Data then such Derived Data shall be owned by the person or entity creating the same.

Now the “severable improvement” bit caught my attention suddenly. Never noticed that before. But what is a “severable improvement”? It’s explained a little by crschmidt, who links to a discussion on the OpenStreetMap mailing list, where Richard Fairhurst describes it as

In practice, then, I read that to mean that if you use the Sustrans webmapping to find out where the routes go, this information is solely copyright Sustrans (who might be more willing to give permission) and not OS, even though it’s delivered through the medium of a derived work. So, if you had the wiggly lines already (whether mapped by GPS or NPE), you could tag them as NCN routes if Sustrans were ok with that.

My reading: if you’ve got something that didn’t come from OS, and which you can stick onto one of its maps wholesale, and remove wholesale, then it’s not – and cannot be – claimed as derived data by OS. But that doesn’t help if you don’t have it in some separate form; if you use OS as a base, then it’s derived data.

As Ed Parsons (formerly OS, now Google) points out in the comments

There is a relatively simple way to define derived information, and that is to ask what is not… If i create a new feature that is not represented as a feature on the original map/dataset it cannot be derived from it. If the OS would just agree with this it world more things forward.. but then we have been asking for this for years… At some point you have to move beyond cock-up territory to conspiracy…

We like Ed’s definition. It makes sense. I wonder quite what the effect on OS would be of adopting that definition. How sizeable a reduction in licence fees?

The following posts may be related...(the database guesses):
• 
  Fatal error: Uncaught Error: Call to undefined function related_posts() in /home/customer/www/freeourdata.org.uk/public_html/blog/wp-content/themes/fod/single.php:20 Stack trace: #0 /home/customer/www/freeourdata.org.uk/public_html/blog/wp-includes/template-loader.php(106): include() #1 /home/customer/www/freeourdata.org.uk/public_html/blog/wp-blog-header.php(19): require_once('/home/customer/...') #2 /home/customer/www/freeourdata.org.uk/public_html/blog/index.php(17): require('/home/customer/...') #3 {main} thrown in /home/customer/www/freeourdata.org.uk/public_html/blog/wp-content/themes/fod/single.php on line 20