Big Important Warning. This post argues that it is legal to trace from Google-provided satellite imagery and upload the results to OpenStreetMap. Do not do this. “Legal” is one thing; “accepted by the OSM community” another; and “liable to expose a not-for-profit Foundation to a lawsuit from one of the world’s biggest companies” something else entirely. Seriously, don’t. This post is here for interest and to start a discussion.

Since the year dot, it’s been accepted within OpenStreetMap that you don’t trace from anywhere without express permission (Yahoo!) or a really clear public domain waiver (US Government stuff). And you definitely, definitely don’t trace from Google satellite images.

That said, since about the year dot+1, we’ve had this little sentence which I put in the FAQ back on 6 December 2005:

“It’s not yet clear whether it’s ok to create a derived work from aerial photography: some readings of UK law suggest that you can do this without ‘inheriting’ the copyright in the photography. A definitive ruling on this could open up new avenues for Openstreetmap and similar projects, but in the absence of such a ruling, we’re continuing with the approach of sourcing our own, 100% independent data.”

So three and a half years on, let’s get a bit more definitive.

Bauman vs Fussell

I’m indebted to The Law of Photography and Digital Images by Christina Michalos for several crucial points, and to the Squire Law Library in Cambridge where I was able to consult it. Simon Stokes’ Digital Copyright has also proved a useful primer in related issues.

The question is: does tracing features from an aerial/satellite photograph (I’ll refer to them as aerial throughout) infringe any copyright in the aerial photograph?

The clearest case is Bauman v Fussell (UK, 1953). In this case, a painter created a painting of two cocks fighting, based on a photograph. The only element derived from the photograph was the position of the birds. Michalos summarises the judgement thus:

“1953: Bauman v Fussell (UK) held that the positions of birds not under the photographers control in a photograph not a substantial part of the photograph. A painting copying those positions was not infringing.”

Three judges ruled in this case: Lord Justice Somervell, Lord Justice Birkett, and Lord Justice Romer. The key issue, according to Michalos, was “whether the defendant’s painting reproduced a substantial part of the photograph”.

Somervell and Birkett believed it didn’t, thereby carrying the majority verdict. They concluded that the positions were not a “substantial” part of the artist’s copyrightable work (OSM legal eagles will recognise the word) and therefore could be copied. By analogy, the positions of roads, buildings and other features on an aerial photograph are not a substantial part of the copyright.

Romer, disagreeing with Somervell and Birkett, said the positions of the birds were indeed a substantial part:

“The appellant did not arrange the position of the birds, but no doubt he waited for the moment to take the photograph when the birds were in the position he wanted them to be and his photograph produces the position.”

But, in fact, even Romer’s viewpoint supports the theory that one can copy from aerial photography. Romer is saying here that the photographer’s skill in capturing the moment produced the original, copyrightable work which was infringed. This cannot apply to aerial photography. There is no originality in an orthophoto: by definition all orthophotos are essentially the same. As Michalos says:

“It is submitted that the decision in when to take the photograph and the angle to take it from, particularly in a fast moving event such as a cock fight, would require sufficient skill as to establish originality. This can be distinguished from a photograph where the relative positions of object do not form part of the protectable originality, such as buildings in relation to each other or the permanent setting of a monument.” (my emphasis)

So all three judges in Bauman v Fussell establish that there is no infringement in an activity such as tracing from aerial imagery.

Antiquesportfolio.com v Rodney Fitch & Company

Fast-forward to the 21st century and we have another very relevant case - and one which is reasonably well documented on the Internet. It’s a particularly interesting case.

Fitch had designed the branding and website for antiquesportfolio.com. For this he needed photographs of antiques; so he scanned them from Miller’s antiques encyclopaedia. At the same time, he also produced vectorised tracings of various of these antiques, for use in logos and business cards.

Antiquesportfolio.com claimed that Fitch’s work was an infringement of Miller’s copyright and therefore not usable, so sued for its money back.

The photographs themselves, of these 3D objects, were judged to be copyrightable and therefore Fitch had infringed. Michalos again:

“It was held in respect of photographs of antiques designed to bring out particular features of the objects, that the positioning of the object, the angle, the lighting, focus were all matters of aesthetic or commercial judgment sufficient for copyright to subsist.”

So the photographs themselves are copyrighted. This is no great surprise. But the judgement goes on to say that tracing from these photographs, as Fitch did to create logos, does not infringe this copyright.

“I do not consider that it can seriously be contended that these logos represented an infringement of the copyright in the photographs in the Encyclopaedia. The simple photograph of an object, however carefully lit and angled or focused the photograph may be, and however skilful and careful the photographer may have been, is not really carried through, to any significant extent whatever, into these logos.”

Or as Michalos summarises it, “Where photographs of antiques were copied by tracing the outline of the object and simplifying the object to an outline, there was no infringement as what was original in the original photographs (such as lighting, angle and focussing) were not reproduced.”

So this second case backs up Bauman v Fussell: tracing from a photograph, where that photograph is a faithful reproduction of a 3D object, does not infringe the copyright in the photograph.

Ets-Hokin v Skyy Spirits

This concept is given a helpful name, “thin copyright”, in the US case of Ets-Hokin v Skyy Spirits.

Skyy commissioned photographer Joshua Ets-Hokin to photograph their vodka bottle. They then chose not to use his photos, but rather, went with similar images taken later by other photographers. There was no suggestion that Skyy had physically reproduced Ets-Hokin’s actual photographs. Nonetheless Ets-Hokin sued, claiming that the new photographs were so similar that they amounted to an infringement of copyright. The Court disagreed:

“Though the Ets-Hokin and Skyy photographs are indeed similar, their similarity is inevitable, given the shared concept, or idea, of photographing a Skyy bottle.  When we apply the limiting doctrines, subtracting the unoriginal elements, Ets-Hokin is left with only a “thin” copyright, which protects only against virtual identical copying.”

So let us apply this statement to tracing from aerial photography. If we subtract the unoriginal elements - i.e. the actual lie of the land which is being photographed - then the “thin copyright” applies solely to the image itself. This is protected against “virtual identical copying”, but there is no restriction on tracing the unoriginal elements.

Michalos summarises:

“It is submitted that for a non-original photograph of a mundane 3-D object taken “straight-on” which is intended to be an accurate copy of that object, any copyright that subsists is a “thin” copyright which is only infringed by actual reproduction of that image…

“It is the work labour and skill in creating that image which is protected… The ‘thin’ copyright conferred on photographs intended to reproduce 3-D objects should protect only the work labour and skill and not the photograph’s subject.”

Weetman v Baldwin

A fourth case, heard in British Columbia (Canada) in 2001, is not a direct analogy but is nonetheless relevant as the only one to deal explicitly with aerial photography.

Weetman produced a map principally from tracing over aerial photography, but also by adding his own knowledge and using his own specially-written software. Baldwin copied this map - but didn’t realise that Weetman had included an Easter egg (a misspelt lake name).

When Weetman sued, Baldwin claimed in defence that the information was factual and therefore not subject to copyright. Weetman won, with Judge Romilly specifically citing:

“trails, roads and other features detailed with a precision and an accuracy not previously attained by other mapmakers of the region in question, which was facilitated by a particular process pioneered by a mapmaker”

Weetman’s actual tracing work from the aerial photographs, which Michalos calls “interpretation of those sources”, is therefore deemed copyright-worthy  - i.e. the act of deciding “that’s a railway” and “that’s a tree”. (Comparable cases agree, such as Meshwerks v Toyota.) But there is, again, no suggestion that any copyright in the aerial photographs is involved.

(See also this overview.)

Case law - summary

Using two examples from Britain, one from Canada and one from the US, we can see clearly that there is no infringement of copyright in tracing features from a copyrighted aerial photograph. We can close our consideration of case law with this, from the oft-quoted House of Lords decision on Ladbroke v William Hill in 1964:

“Whether a part is substantial must be decided by its quality rather than its quantity. The reproduction of a part which by itself has no originality will not normally be a substantial part of the copyright and therefore will not be protected. For that which would not attract copyright except by reason of its collocation will, when robbed of that collocation, not be a substantial part of the copyright and therefore the courts will not hold its reproduction to be an infringement. It is this, I think, which is meant by one or two judicial observations that ‘there is no copyright’ in some unoriginal part of a whole that is copyright.”

So if an OpenStreetMap contributor were to purchase a printed aerial photograph, trace over it, and then upload the result to OSM as their copyrighted work (under the standard OSM licence), it would not be an infringement of copyright.

But what if, for example, the Google Maps API were used? Yahoo!, of course, has for a long time given permission for OSM users to trace over its imagery. Google’s imagery is better for large parts of the world, and there can be few OSM contributors who haven’t wished that it was available in a similar way.

It is clear from the four cases examined above that there would be no infringement of copyright. Copyright, though, is not everything. Use of Google’s aerial imagery is only by permission of their Terms of Service. Do these terms permit use?

The Google Maps API Terms of Service

The primary document is the Terms of Service for the Google Maps API, the service which would be used to provide the aerial imagery for tracing. (The Google Maps Terms also apply, but 1.4 in the API terms explains that “the Maps APIs Terms will take precedence”.)

In 7.1, Google provides two crucial definitions:

“(b) ‘Content’ means any content provided through the Service (whether created by Google or its third party licensors), including map and terrain data, photographic imagery, traffic data, or any other content.
“(d) ‘Your Content’ means any content that you provide in your Maps API Implementation, including data, images, video, or software. Your Content does not include the Content.”

We must read these definitions in the light of the case law above.

It tells us the ‘Content’ cannot include the lie of the land as depicted in the aerial photography. ‘Content’ is defined as “created by Google or its third party licensors” - i.e. the aerial photography providers. The four cases are unambiguous that the material which we are tracing is not created by Google or its third party licensors; otherwise a copyright would exist in it.

(Compare with the street name and geometry data in Google Maps’ own map tiles, created from TeleAtlas data. Mason v Montgomery Data explains that, even in the US, such data deserves copyright protection for the “mapmaker’s selection of sources, interpretation of those sources, discretion in reconciling inconsistencies among the sources”. Therefore this is indeed “Content… created by Google or its third party licensors”.)

Therefore a section like 7.3b, which explains that “Certain Content is provided under license from third parties… and is subject to copyright and other intellectual property rights”, does not apply to tracing from aerial photography, since this is not an act restricted by copyright.

Similarly, 10.2 forbids you to “copy, translate, modify, create a derivative work of, or publicly display any Content or any part thereof (for example, the following are prohibited: (a) creating server-side modification of map tiles; and (b) stitching multiple static map images together to display a map that is larger than permitted in the Maps APIs Documentation)”. Again, we are not creating a derivative work, modifying, translating or copying the Content by tracing features; we are creating an independent work. The two examples chosen by Google, however, are clearly copyrighted derivatives.

Nor does 10.6 apply. It says that you may not “use the Service in a manner that gives you or any other person access to mass downloads or bulk feeds of any Content, including but not limited to numerical latitude or longitude coordinates, imagery, and visible map data”. Again, this simply isn’t an issue, since tracings are not feeds or downloads of Google-licensed Content.

Other documents

The Terms & Conditions for Google Maps (i.e. not exclusively the API) define Content similarly (section 4): “a variety of content including but not limited to photographic imagery, map and terrain data, business listings, reviews, traffic, and other related information provided by Google, its licensors, and its users”.

The “provided by” here is slightly more all-encompassing than the “created by” in the API ToS. Nonetheless, the case law we have considered makes it clear that it still does not restrict tracing. We do, of course, also know that the API terms would take precedence in the case of a website using the API to help you trace over imagery.

Other restrictions, such as 2b (”you must not copy, translate, modify, or make derivative works of the Content or any part thereof”) and 2e (”mass downloads or bulk feeds of any Content “) are the same as what we have seen in the API terms with no significant changes of wording.

Google also provides a FAQ for the Google Maps API. In it they explain sites on which they don’t permit the API to be used:

“There are some uses of the Google Maps APIs that we just don’t want to see: maps that identify the places to buy illegal drugs in a city, for instance, or any other illegal activity. We also respect people’s privacy, so the Google Maps APIs shouldn’t be used to identify private information about individuals.”

Again, none of these examples could in any way be construed as forbidding tracing from the aerial photography or any similar activity.

Conclusion

We can conclude:

- Case law firmly establishes that tracing from aerial photography is not an infringement of any copyright in that imagery.
- Read in this context, the Terms of Service for the most popular aerial photography API, that provided by Google, do not prohibit such tracing.

With this in mind, we can see why Google appears happy for the high-profile Wikimapia to continue to exist - even though Google is hardly shy in sending take-down notices to sites that they believe contravene their terms of service.

So, should you start tracing from Google aerial imagery, and upload the results to OpenStreetMap? You could - but you shouldn’t. OSM is by its nature very cautious about sources: the point of the whole project is to provide a “clean room” map of the world unencumbered by traditional copyright. You should not endanger such a terrific project just on the say-so of one chap with a blog.

You should, however, take this say-so, and investigate further. Are there other sites or publications, like Wikimapia, which encourage tracing or other means of obtaining factual information from imagery, and which have also been left alone? (I can think of one superb printed map, for example, which acknowledges that “Google Earth and Panoramio are not only invaluable sources, they have practically revolutionised the work of map publishers”.) And can Google or other aerial imagery providers confirm this reading - or otherwise?

It matters. The ability to trace from high-quality satellite imagery will not hurt the providers of this imagery. But it will greatly aid many, many mapping projects, and the applications - from hobbyist to humanitarian - that benefit from the data they create.

I’ve wondered about setting up a crazyguyonabike journal to record our cycling trips, but since I don’t post enough here anyway…

Yesterday we put the bikes in the back of the car, drove to Lechlade, and cycled from there to Oxford. (We’re doing a Changing Places in WW on the Upper Thames and I needed to take the modern pics.) Our route, in brief, was: Lechlade->Mill Lane->old B4449 past Kelmscott->Clanfield (”mentioned in the Domesday Book” - er, like everywhere)->Bampton->Shifford Lock->Hinton Waldrist->detour to Newbridge->Appleton->Bablock Hythe (south bank)->rather muddy bridleway->Farmoor->Eynsham->via A40 to Godstow and Oxford->Royal Oak->cheeseburger.

Generally a lovely ride: pretty flat, at least until you get nearer Oxford and the valley narrows; some quiet roads; and bakingly hot. After our previous ride on proto-NCN45 via Upton-on-Severn, where we encountered a downpour of morris dancers, I was rather expecting to find the same in Bampton but sadly not.

There was one utterly wonderful highlight on such a hot day, which was this:

Duxford Ford is the one forded crossing of the River Thames (clearly not the navigation channel), on a bridleway from Chimney to Hinton Waldrist. You wouldn’t try it in the winter; the current was still pretty considerable even this weekend. But wading across, pushing the bike, it was a real delight on such a hot day.

What wasn’t so great? The traffic in some places was lousy, particularly the A415 at Newbridge, which was bad beyond belief. We witnessed two near-accidents and at least one “what the hell are these cyclists doing on my personal racetrack” wanker who was, inevitably, driving an expensive German automobile. The pubs are all Greene King. Really. At Newbridge there are two pubs, one on each side of the river: both are run by Greede Kerching. It must be the first Strongbow I’ve had in at least a year.

And: there really needs to be a bridge at Bablock Hythe. It would have made our route so much easier, safer, and more pleasant. The arguments for the bridge (the single break in the Thames Path, Oxford-Witney cycle route, etc. etc.) have been rehearsed so many zillion times before that I won’t bore you with them.

But really - it’s just like the Oxford-Cambridge railway; one of those staggeringly obvious schemes that never gets done because highway engineers are still the sort of people against whom Robert Aickman used to rage furiously in early IWA Bulletins. (”Motor Moloch”, the column was called.) At one point we passed a lonely “Oxfordshire Cycleway” sign, a disconnected remnant of a now-abandoned route, closed by Oxfordshire County Council because of rising traffic levels. Heaven forfend that they actually do something to make the roads bearable for those not in BMWs, of course.

So next time, I think we’d divert onto the back roads and head back to Charlbury via Witney, or maybe Minster Lovell, rather than hacking into Oxford. Still, a great ride.

CPAN has some really good e-mail modules - including one written by the BBC. How cool is that? But the documentation isn’t entirely transparent unless you’re a MIME wizard… which I’m certainly not.

Here’s what I’ve found works to send an HTML format e-mail with attachments. (For these purposes I was never sending more than five attachments, but it’d be trivial to change.) Working out that the outer part needed to be multipart/mixed was the bit that took me the time - simply attaching files to an Email::MIME::CreateHTML message puts them as extra alternative parts in a multipart/alternative message, so a mailer might just display one of the attachments as the message body.

use Email::MIME;
use Email::MIME::CreateHTML;
use MIME::Types;
use Email::Send;
use Email::Abstract;

# ———————————————————–
# You’ll need to define:
#
# $html - the HTML for the e-mail
# $plain - plain-text version
# $sender_name - name of sender
# $sender_email - address of sender
# $name - name of recipient
# $address - address of recipient
# $subject - subject line
# @body - attachments (slurped into $body[1] etc.)
# @fn - filenames for attachments

# —– Create HTML

my $htmlmail = Email::MIME->create_html(
    header => [],
    body => $html,
    body_attributes => {
        disposition => ‘inline’ },
    text_body => $plain);

# —– Create base message

my $email = Email::MIME->create(
    header => [
        From => "$sender_name <$sender_email>",
        To => "$name <$address>",
        Subject => $subject ],
    attributes => { content_type => “multipart/mixed” },
    parts => [$htmlmail]
);

# —– Add attachments

for ($i=1; $i<=5; $i++) {
    next unless $attach[$i];
    ($mimetype,$encoding) = MIME::Types::by_suffix($fn[$i]);
    $att = Email::MIME->create(
        attributes => {
            content_type => $mimetype,
            filename => $fn[$i],
            encoding => $encoding,
            name => $fn[$i],
            disposition => “attachment” },
        header => [ 'Content-ID' => "$year$mon${mday}_${contentid}_$i" ],
        body => $body[$i]);
    $att->header_set(’MIME-Version’);
    $att->header_set(’Date’);
    $email->parts_add([$att]);
}

# —– Send mail

$Email::Send::Sendmail::SENDMAIL = ‘/usr/sbin/sendmail’;
my $sender=Email::Send->new({mailer => ‘Sendmail’});
my $response=$sender->send($email);
return $response;

Answer: a spraymailing PR bunny who knows how to use PHP.

Hello,
The following press releases were sent to you recently. We should be very grateful if you would tell us whether or not you intend to make use of them.

Not a good start.

TECHNIFOR - #1174 - 2009-03-10
XF530p: the portable deep marking solution | Capable of attaining a depth of 0.4mm, the XF530p is the world’s first portable deep marking by micro-percussion machine – which stands out for its versatility and ease of use. Whether it is used on tubes or smooth surfaces, it is simply applied to the part, with no need for other pre-tension equipment or supplementary positioning. It can mark pipelines (oil, mining, gas), lifting/hoisting equipment (pallet trucks, forklift trucks), “off the road” vehicles and even naval constructions and metallic structures.
http://ns204460.ovh.net/press/pressdoc_files/1174/CUK_TECHNIFOR-XF530P.pdf 

Ok. And that has precisely what to do with the inland waterways of Britain, pray?

But hey. We get plenty of irrelevant press releases, mostly about the America’s Cup or other saltwatery things. I can live with that. The really offensive bit is in the headers.

Subject: MEPAX Monthly Reminder
X-Mailer: Mepax/Php 

So. You add us to your initial mailing list, without permission, because you found Waterways World on Mediadisk - or some such grot - filed under “boating”… and this press release talks about “naval constructions”.

You then, astonishingly, write a nag mailer to follow up every single such misdirected release with a “monthly reminder”. And you expect us to write a personalised reply (”we should be very grateful if you would tell us”) to your automated mailer.

After recovering the power of speech, I have written a personalised reply to info@mepax.com, and it does involve the words “get” and “lost”.

(Clare’s list of Top 10 PR mistakes should be compulsory reading for bunnies everywhere.)

…for they shatter the illusions of faithful happy Mac users like me that you “can just plug it in” and “boom, it works” and stuff like that. Well, it might be true that if you try to get two Genuine Apple AirPorts to talk to each other via WDS they work happily - though given that AirPort Utility frequently can’t even find the Express within 50cm of it, I doubt it. (Computers really need a “IT’S JUST THERE YOU BLASTED THING” button, to go with the “OH JUST RUDDY DO IT” one for every dialogue box.)

Getting an AirPort Express to talk to a Belkin router is, however, decidely not fun. And that’s a great shame given that the Express costs £70, but the Belkin is just £30 from Argos.

So after n hours of swearing, Googling, and therapeutic pints of perry in the Rose & Crown (now only 30 seconds from our new house - which I should blog some time, it’s much more exciting than this), we now, finally, have wifi in the barn (where the computers are) as well as the house (where the phone line is).

As ever, for the sake of any other poor unfortunates trying to do the same, here’s what finally worked. Our setup is a cheapy unbranded Chinese ADSL modem; an AirPort Express connected to it; and a Belkin G+ (aka F5D7231-4) in the next room, which provides enough of a boost for the signal to make its way to the barn via several very chunky 18th century stone walls.

To summarise, the changes that made the difference (as far as I can tell) were: giving absolutely everything an IP address in the same range; making sure that range was 192.168.2.x, which seems to be where the Belkin is happiest; preventing anything apart from the modem/router itself from distributing IP addresses via DHCP; and using wireless channel 1.

ADSL modem/router
IP address 192.168.2.1. DHCP pool 192.168.2.2 to 192.168.2.15. (I figured it was easier just to have one box distributing IP addresses.)

AirPort Express (connected to router via Ethernet cable)
Basic settings:
- Wireless tab set to ‘Participate in a WDS network’.
- Network name set to ‘My luvverly wireless network’ (well, not really, but you get the point).
- Channel 1. I initially tried it on 12. It didn’t work.
WDS settings:
- WDS main.
- MAC address of the Belkin added as a WDS remote.
Internet tab:
- Configure IPv4 manually.
- IP address 192.168.2.2.
- Subnet mask 255.255.255.0.
- Router address 192.168.2.1.
- DNS server 192.168.2.1.
- Connection sharing Off (Bridge Mode).

Belkin (in the next room, not connected to anything)
Use as access point: enabled, with IP address 192.168.2.254 (the default) and subnet mask 255.255.255.0. After a reboot, this disables half the functionality (a Good Thing), and you can log in at 192.168.2.254.
Channel 1 (as per above).
SSID ‘My luvverly wireless network’ (again, same as above).
Wireless bridging enabled.
Enable only specific access points: ticked, and the MAC address of the AirPort Express entered.

Security (update)
Oh, I was hoping you weren’t going to mention that. The AirPort and the Belkin won’t talk WPA to each other, sadly. They will, however, talk WEP 128-bit, with the usual caveat that the Belkin’s ASCII-to-WEP key algorithm is different from Apple’s. I took a 13-character Apple-style password, set it on the AirPort, then passed it through this WEP key generator and fed the resulting hex bytes into the Belkin.

Finally, kick each item several times, and have a large drink. Or two.

After all that, the client computers (I’ve tested three) should just work happily and get their settings via DHCP.

Matt Amos (who should blog more) has done a really cool visualisation of the editors used by OpenStreetMappers. Blue is Potlatch, red is JOSM, green is Merkaartor, and grey is everything else.

Really big disclaimer: this is based on the created_by tag, and JOSM and Potlatch treat this differently. JOSM sets the tag whenever it adds a new object: Potlatch sets it whenever it adds a new one or modifies an existing one. So there’ll be an inevitable bias towards Potlatch. (Potlatch’s behaviour is arguably more sensible but I’ll leave that for another time!) But despite all that - isn’t the big mass of blue pleasing to the eye? Well, I thought so.

See the full image here.

There has been some debate in the OpenStreetMap community about the exact provisions of the Open Database Licence.

Richard Weait has done a very good job explaining it in diagram form, but the exact nuances of the licence may still remain unclear to some. Therefore I hope the following illustrations will aptly yet concisely show the intricacies of licensing geodata, and the respective virtues of CC-BY-SA and the ODbL.

Thank you for your time.

Back in the early days of amateur webmapping, many of us got regularly, righteously exercised about the “Multimap patent”.

The patent is described thus:

“A map of the area of a client computer (10) is requested from a map server (11). Information relating to a place of interest is requested from an information server (12) by the client computer (10). The information is superimposed or overlaid on a map image at a position on the map image corresponding to the location of the place of interest on the map. The information (or “overlay”) server (12) may contain details of, for example, hotels, restaurants, shops or the like, associated with the geographical coordinates of each location. The map server (11) contains map data, including coordinate data representing the spatial coordinates of at least one point on the area represented by the map.”

The patent, filed in 1996, was granted several years later in Europe, the States and Australia. (Read the full US patent, or search for EP0845124B at the European Patent Office.)

 

It’s clearly pretty wide-ranging; the “map server” and “information (or ‘overlay’) server” describes every mashup since the days when the cynics were calling it ‘Red Dot Fever’ (popularly attributed to Schuyler Erle, though I had it in mind that it was Saul Albert) - never mind ‘Google Maps Fatigue’, or, ahem, ‘Why Mashups Suck‘. Almost every webmap could be subject to this patent.

But, fortunately, Multimap never really showed any signs of exercising the patent. Sure, a reference number sat at the bottom of every Multimap page, but that always seemed not so much “we intend our lawyers to get medieval on your ass”, rather “hey, we were here before these Google upstarts, you know”. Indeed, as far back as 2002, Edward MacGillavry - who has a much longer webmapping CV than most of us - could write that Multimap has never “taken any steps to enforce their patents… I am wondering what the actual benefit is of patenting technologies like this”.

Well, today we know.

Coals to Newcastle / patents to Seattle

Multimap was bought by Microsoft in December 2007. At the time, received opinion was pretty much “well done to the plucky little British guys for getting bought”, at a time when Google’s march seemed unstoppable.

We worried that some of Multimap’s bright sparks would be assimilated, of course - but hey, this is the land of Maps 2.0, they won’t find it hard to get jobs. (Visit mapme.at, it’s great.) We fretted that the sole existing OS Landranger slippy map would be taken down, to be replaced by some crap Virtual Earth cartography. That sort of level of furrowed-brow, slightly-bad-things-might-happen concern.

We had forgotten about the Multimap patent.

I am not kidding. I really don’t remember anyone even mentioning it. Searching today, I can see that Rob Dunfey at gisconsultancy.com had been smart enough to spot this angle. Directions Magazine remembered, too, and asked Multimap founder Sean Phelan - grandfather of webmapping, and holder of first the patent, then a very large cheque - about it in passing. He was non-committal. (Probably thinking about his yacht, rather marvellously named Nerdvana.)

Flossie!

Fast-forward to the present.

Earlier today, I idly looked at the latest Google News results for ‘openstreetmap’. I noticed a new site: www.flosm.de, built by an outfit called 123map.

As the name suggests, it’s done in Flash - and as the author of Potlatch, the Flash OpenStreetMap editor, that interested me straight away. It’s a slightly bizarre concept: it superimposes TeleAtlas vector data on OpenStreetMap tiles, so you can compare the two. (There are potential bandwidth-leeching and licensing implications in that, but that’s by the by.) I haven’t seen a great clamour for this, but never mind. Any road up, it’s not going to change the world.

But the story I’d found in Google News was… more interesting. You can read it here (softpedia.com), but here are some of the choice quotes.

“123map revealed that, in order to build Flosm and additional services that it is yet to deliver, it licensed technology from Microsoft, taking advantage of the company’s intellectual property licensing program…

“‘[123map] recognizes, like so many technology companies across Europe, that a way to spur growth in our industry is to license patented technology for mutual benefit,’ explained David Kaefer, general manager of Intellectual Property Licensing at Microsoft…

“It is the specific Microsoft technology that enables this comparison, by making it possible to overlay information on a map image.”

Specific Microsoft technology? flosm.de is built with Flash and appears to call serverside Perl (e.g. http://www.flosm.de/tools/geo03/geocoder_flash.pl?thm=98). I don’t see any Silverlight or .net. I don’t see any Microsoft technology.

Then one of the denizens of the #osm IRC channel pointed me towards the German-language OSM mailing list. Detlev Reiners of 123map has posted there several times, and most recently, has explained a bit more about the Microsoft connection. I don’t speak German, but fortunately Google Translate does. Besides, “Sean Phelan” is the same in any language.

“The patent describes the overlay geographic data, which from different servers on which the data is subject to the client delivered. They are then included on the basis of their geographical Coordinates superimposed. Inventor Sean Phelan.”

In other words, the same Multimap patent we were so worried about seven years ago.

So there you have it. Microsoft is actively claiming a patent for putting stuff on webmaps.

Where now?

Think how, if applied, this changes the webmapping landscape. Every Google Maps view: a penny to Microsoft. Google Earth? Several pennies, I reckon. Yahoo? OpenStreetMap? Anything using OpenLayers? A new startup, like CloudMade or Geofabrik?  Start saving. You owe Microsoft. 

And at a tidy royalty for pretty much every map on the web today, the $50m price for Multimap looks good value. Seen the other way round, the patent looks like a very, very canny investment by Sean Phelan.

Of course, it’s not quite that simple.

Back in 2002/2003, when we were all getting worked up about the patent, Proper GIS Types looked into it and concluded that it was so much baloney. Carl Reed, an OGC chap, found several examples of prior art (1 , 2). A presenter at an Ordnance Survey-sponsored conference in Cambridge the same year concluded both that prior art existed, and that the patent was merely “the automation of a manual process” anyway.

But Microsoft must know this. They’re big enough and - surely? - not so stupid that they wouldn’t try to enforce a patent with enormous negative PR potential… unless they thought it might stand up. And it’s a fairly familiar patent strategy: pick on the little guys first, get a steady income stream. Once the precedent is established, go for the medium-ranking sites. Then, eventually, go to Google and say “I think we should talk”.

I hope Google’s lawyers have their answer ready. I hope it’s not too far removed from Arkell vs Pressdram.

Future Publishing has a spiffy subscription management website, myfavouritemagazines.co.uk (cf this, but clearly not as horribly naff as this).

It does everything you could possibly want, online, which is clearly both convenient for the customer and efficient for the company. And they’re quite proud of it: ”The links below are designed to give you complete control over your subscription.” “This area is designed to answer your every need.” All of that. You can order back issues, get a replacement for an issue that hasn’t arrived, change your delivery address, and so on. It makes me quite ashamed of our simple little online order system at WW.

Except the one thing you can’t do is cancel a subscription. “Please write to us at any time during the initial 60 day period [sorry, the what?] supplying your full name, address, subscription number (if possible) and magazine name. Write to: Future Publishing, Unit 4, Lathkill Street, Market Harborough, Leicestershire, LE16 9EF.”

Free clue: making it difficult doesn’t stop people cancelling their subscription. It just makes them pissed off with you and less likely to buy one of your other magazines.

“Museum of Zoology: The most startling thing about this museum is its levitating Finback Whale, which looms over the surrounding buildings in a strangely out-of-place way.”

I’ve just not renewed the hosting for geowiki.co.uk (well, strictly speaking I’ve not renewed the hosting for geowiki.co.uk every day for the past couple of years, but you know what I mean). So there endeth possibly the first GPS mapping site, sadly neglected since 2004ish, with comedy flat-file storage but a background in a lovely shade of blue. (I’m keeping the domains, of course. ‘geowiki’ is too cool a name to let go.)

“this is an idea that is similar to one i have beenworking on in my mind”

I still sometimes wonder about a site that would document “what’s it like?” rather than “what’s there?”. Probably, in fact, not a classical wiki: every time you replace others’ content with your own, the view becomes a little narrower. (Must. Not. Mention. Wikipedia.) But, you know, hours in the day and all that.

As a general rule, every time I read some Debord I get seized with the urge to do something psychogeographical on the web.

“I just noticed Geowiki, which is about the only way I’d like interactive maps to work on Wikitravel.”

Curiously my GPS tracks are still saved in ~/Geowiki/Tracks/GPX/ . Intermittently I paste them onto a big Illustrator file called GMoE - Geowiki Map of Everywhere. Where “everywhere” means “the UK”. National Grid references are so much easier to work with.

Now, if you’ll excuse me, I’m off to find that Levitating Finback Whale.