Mile
Zero

Patents are important. They create an incentive for inventors to release their inventions into the public domain in return for a temporary monopoly on those inventions. Everybody loves patents. Software patents, on the other hand, must die.

Lately there has been a lot of news about patents, as almost every mobile company in existence is suing every other company for infringement. That many happy lawyers should have been a warning sign that something fishy was going on. And this being the Internet, everyone online wants to leap to the defense of their favorite. But ultimately, there are no winners in this game, because software patents have done nothing but harm innovation. They're counter-productive, anti-competitive, and insulting.

The most well-written defense of software patents that I've seen comes from Nilay Patel, who is a former lawyer, and focuses mainly on why patents in general are beneficial to society. I don't have any issues with that. But let's examine his claims on software patents in particular, as a way of getting at why they're broken. He writes:

Patents publicly disclose some of the most advanced work ever done by some of the most creative and resourceful people in history, and it'll all be free for the taking in several years. Stop offering patent protection and there's no more required disclosure -- all this stuff stays locked up as trade secrets as long as it offers a competitive advantage, after which point it may well be forgotten.

...

What might surprise you is that the USPTO has historically resisted efforts to patent software, only to have the courts chart a different course. The conflict itself is a simple one: software is ultimately just the automated expression of various algorithms and math, and you can't patent math. To many, it then seems like a forgone conclusion that software patents shouldn't exist -- preventing other people from using math is solidly outside the boundaries of the patent system. The problem isn't software patents -- the problem is that software patents don't actually exist.

But look a little closer and it's easy to see that the boundaries between "just math" and "patentable invention" are pretty fuzzy. Every invention is "just math" when it comes right down to it -- traditional mechanical inventions are really just the physical embodiments of specific algorithms.

That last bit, the part about how everything is "just math" (Patel uses the example of a special beer bottle shape), is where this argument runs into trouble (well, that and the point where he admits that he's neither a patent lawyer nor a developer, meaning that he brings almost no actual expertise to a highly-technical table). As Patel is not a developer, it's not immediately apparent to him the difference between pages of source code and a physical mechanism. But they are, in fact, very different: computer programs are, at heart, a series of instructions that the device follows. They're more like a recipe than a machine. Can you imagine patenting a recipe--claiming to have "invented" a type of bread, or a flavor of pie, and insisting that anyone else making an apple pie must pay your licensing fees? It's ridiculous.

To add insult to injury, what most programmers will tell you is that the majority of software is not "some of the most advanced work ever done," but a series of obvious steps connected together. Take, for example, Patel's own example, drawn from Apple's multitouch patent.

You may think that looks really complicated--Patel clearly does--but it's really not. That chunk of text, once you pull it apart and turn the math into actual working code, reduces to three steps:

1. Use the Pythagorean theorum to determine the distance between two arbitrary points.
2. Repeat step one.
3. Divide the difference between the distances found in steps 1 and 2 by the elapsed time between them, thus determining the speed at which your arbitrary points are moving closer or farther away.

That's not "some of the most advanced work ever done" in computer science. It's not even particularly complicated. Geometry students across the United States do that on a daily basis. I write code to do something similar several times a day, as does any graphics programmer. It's just the most obvious way to solve a common problem--like most programming.

Now, Patel is careful to say that this is not the complete patent. But I've looked over the complete patent text, and frankly there's little I see there that goes beyond this level of complexity. It describes the kind of common-sense steps that anyone would take if they were implementing a multitouch UI (as well as a number of steps that, as far as I can tell, no-one--including the patent-holder--has actually implemented, such as distinguishing between a palm or elbow and a stylus). There's nothing novel or non-obvious about it--it's just written in so much legalese that it looks extremely complicated.

Such obfuscation overturns the entire argument for patents in the first place. After all, if I were trying to code something, there's no way I'd turn to a software patent like this to figure out how to implement it--it leaves out too many steps, overcomplicates those that it does describe, adds a bunch of extraneous notes that I have to discard, and includes no source code at all. It'd be easier for me to figure it out myself, or learn from an open-source implementation.

Moreover, if I worked for a big company, like Apple or Microsoft, I'd be forbidden from reading patents in the first place, because the penalties for "knowing" infringement are much higher than "unknowing" infringement (a particularly ironic term, given that someone can "unknowingly" infringe by inventing the process independently). Meanwhile, as Lukas Mathis points out, we don't actually need the patent for an actually innovative piece of programming (Google's original PageRank) because it was published openly, as an academic paper.

I'm not saying, by the way, that multitouch hardware can't--or shouldn't--be patented. By all means, the inventor of the capacitative screen--a non-obvious, physical work of engineering--should be rewarded for their creativity. But that's not what Patel is defending, and it's not what the patent in question actually covers.

So software patents don't cover brilliant work, and they're not encouraging innovation. In fact, they discourage it: thanks to patent trolls who sue small companies over broad software patents, indie developers may not be able to afford the cost of business at all. If this seems difficult to reconcile with the arguments for the existence of software patents, that's because it undermines their entire case. Software patents are just broken: that's all there is to it.

What bothers me about this is not so much the ongoing lawsuit frenzy--I could really care less when large companies sue each other as a proxy for their market competition--but that there's this idea floating around that some software patent lawsuits are worthwhile, based on who's doing the suing. Everyone agrees that trolls like Lodsys (a shell company suing small developers over a purported patent on "in-app purchases") are a drain on the system. Whereas if Apple, or Microsoft, or Nokia files a patent suit, their fans charge to their defense against "copycats," as if their patents are the only really innovative ones in existence. Even this week, pro-Apple pundit John Gruber cheered Google's action against Lodsys while simultaneously insisting that Android and Linux should be sued out of existence for patent theft.

But there are no justified software patent lawsuits, because there are no justified software patents. You don't get to say that patent trolls are despicable, while defending your favorite company's legal action as a valid claim--it's the same faulty protection racket at work. Software patents are a plague on all our houses, and tribalism is no excuse for preserving them.

I'm not a fan of centralized software distribution in general, but I have to admit that I've grown to enjoy checking on the most recent additions to the Android Market. I'm probably not going to install anything I find there, but it's neat to see what people are working on. Too many days, however, browsing through the "just in" section requires scrolling past screen upon screen of cookie-cutter entries churned out by application mills somewhere: a thousand local TV station website wrappers, ringtones and contact images, individual calculators for obscure engineering functions, keyboard skins, and vast other numbers of useless pseudo-programs.

Indeed, most of these aren't even really "applications" as you'd normally think of them. They're content, or content wrappers. But thanks to the new "mobile app" model, the confusion between program and data is growing. It's hard to imagine that this is a good thing.

But first, some context: sometime between the first and second World Wars, a mathematician named Alan Turing came up with a fairly interesting idea: if you had a machine that read in a string of inputs from a tape, and acted on them in series, you could perform complex mathematical operations mechanically. More importantly, you could build a machine that (if it were first given a set of action codes) would emulate other computing machines. He called this the Universal Turing Machine, and it was kind of a big deal. In gratitude, the British government had him chemically castrated to "treat" his homosexuality, and eventually drove him to suicide. It's not one of the proudest moments in history for Britain, computer science, or humanity in general.

To this day, when discussing programming languages, we say that they are "Turing-complete"--that they're capable of simulating a Universal Turing Machine, and in turn, any other Turing-complete language. Which is pretty cool: if you've ever used an emulator, you've seen a demonstration of a UTM at work. Effectively, it turns a computer from something like a calculator, where its functions are essentially mechanical operations, into something more like a box of Legos: an infinitely-adaptable, reconfigurable toolkit for doing mental work.

Which brings us back to the mobile app store model. In this case, the platform is still a UTM--you can still write emulators and multi-purpose programs for Android--but it's being presented to the user as single-purpose. Applications work in their own little silos, and content is distributed as if it were code, even if there's no technical reason why it has to work this way.

Take, for example, Snaptic's AK Notepad, one of the most popular notepad applications on Android. Desktop users could be forgiven for thinking that a "notepad" is an editor for text files, but AK Notepad is not (it does support a clumsy import-export process, but I can't imagine using it regularly). Instead, it keeps its notes in a proprietary database that no other application can access. Want to switch to another, better tool for jotting down your grocery list (or another, more involved project)? Good luck with that.

And then there are, of course, the multitude of web-site wrappers, like those local news "applications" that have flooded the market. They're nothing but a WebView with a preset URL. They're bookmarks. And in doing so, they've taken a real UTM-type application (the browser) and turned it into a single-purpose tool. It's the equivalent of asking you to download a complete version of Firefox just for a single website. The same logic is at work for the e-book applications, which pack their own reader software for each title--here, at least, the existence of prior standards and alternate distribution portals means that standalone reader software has a chance.

I bring this up not just because it's kind of a shame from a net-neutrality, open-platform, generative-computing standpoint, but also because I feel like it robs people of one of the joys of computing: the feeling that the software is a toolkit, to be applied to any given wad of data depending on the task at hand. One program may be better at text display, another better at formatting, and yet another may provide a no-distraction writing environment. With code and content separate, you can use whichever is best for the current task, and you're not locked into a single tool. The new mobile paradigm fuses the two into a single conceptual blob, and any task becomes limited by a single piece of software. It seems like a tremendous step back for computing.

Or maybe I'm just cranky from the flu, and annoyed to find myself staring at a spammy directory of Fox affiliate stations across the entire midwest where I expected some kind of software. It's hard to say.

Android's swelling collection of "augmented reality" applications got a boost the other day when Layar hit 2.0. Layar's probably the most advanced example of its type, combining live video from the phone's camera with data overlays for local points of interest. Part of what makes Layar so interesting compared to its competitors is that it has an open API for developers to create their own overlays. I'm sure you're as excited as I am for the eventual branded or ad-driven layers.

This kind of thing is a deeply attractive technology just because it's so visceral--people love to consider the implications of digitally remixing (or obscuring) their surroundings. But the current fashion of doing so in a literal sense is probably a dead end. At the very least, it prompts a vision of annoying tourist hordes wandering around the city holding cell phones in front of their faces, like superstitious villagers waving the cross at their surroundings to keep the evil eye at bay ("evil eye" is actually not a bad term for the abuse of AR tech). Worse, to restrict the term "augmented reality" to that kind of hallucinogenic literalism misses the point, and squanders the potential of AR as a sixth sense by cramming it on top of our visual range. I'd argue that we've had augmented reality for a while now--and that it comes wrapped in a more appropriate level of abstraction.

Take Astrid for example. Astrid's another Android program--in this case, it's a to-do list/reminder system. On its own, Astrid lets you set timed tasks, tag events, and synchronize your reminders with Remember the Milk. But if you combine it with Locale, Android's location-sensitive alert system, now you can have reminders triggered by physical proximity, like entering the grocery store or coming home from work. Although there's no camera involved, and no sexy floating map, this is also augmented reality. Indeed, if you look through Locale's plugin selection in the marketplace, there's a wide range of intriguing possibilities: from waking your computer when you walk through the door, sending an HTTP request at certain locations, or keeping people posted of your location via Twitter or SMS.

Not to mention the concept of networked notation: really, I should be able to "tag" my current location and read tags posted by other people (see also: GeoBuzz or, to some extent, Ushahidi). This includes recommendations/warnings for nearby businesses, event recordings, historical information, and helpful hints ("Don't try the brown acid!"). It's the virtual equivalent of a message board, wherever you go, but sortable, searchable, and omnipresent. And that's the kind of sixth sense that's actually useful, because it gives you a local's situated knowledge no matter where you go.

If this still sounds kind of boring compared to the Virtual Light fantasy that Layar and other visual AR programs are pitching, that's because it is. But it's undeniably more effective than waving a phone around and hoping to spot a clue. Likewise, if I'm in Paris and looking for a good bakery, being able to see the relative position of my destination doesn't help me when the AR overlay neglects to mention that it's across the Seine. What I need in that situation is a good digital map--a less futuristic, but undoubtably more versatile form of augmented reality (and one that's available to anyone with a smartphone right now).

A while back, BMEzine ran a story (subsequently picked up all around the Web) on living with magnetic implants (note: link contains disturbing images). In this scenario, crazy people have neodymium magnets embedded in their fingers, giving them the ability to "feel" electromagnetic fields from computers, security sensors, and power cables. The author describes it as a relatively subtle perception, but one that gives access to a rich array of new information. To me, that's the model we should be using when building augmented reality applications. It's not about giving you a window into a garish world of digital overlays, but about simply providing context and knowledge in a given area.

Sometimes the best technologies are a lot less flashy. The cyberspaces of Gibson and Stephenson are a lot cooler than the textual Internet, but in a pinch I'm pretty sure which one would be more adaptable and innovative. So it goes with the augmented reality craze: when the dust settles, I think we'll find that we've been doing this in better, less literal ways all along. We're symbol-using creatures--abstractions are our friends. Let's use them.