this space intentionally left blank

November 5, 2013

Filed under: tech»innovation

Patently Nonsense

Now that Apple and Microsoft (with a few others) have formed a shell company in order to sue Google over a bunch of old Nortel patents, and IBM has accused Twitter of infringing on a similar set of bogus "inventions," it's probably time again to talk about software patents in general.

Software Patents: Frequently Asked Questions

Q. When it comes to software patents...

A. No.

Q. Hang on. Are they a valid thing? Are any of these suits valid?

A. See above: no, and no.

Q. Why not?

A. Because software patents, as a description of software, are roughly like saying that I could get a patent for the automobile by writing "four tires and an engine" on a piece of paper. They're vague to the point of uselessness, and generally obvious to anyone who thinks about a problem for more than thirty seconds.

Q. Yeah, but so what? Isn't the point of patents to create innovation? Haven't we had lots of innovation in software thanks to their protection?

A. True, the point of patents is to make sure that people let other people use their inventions in exchange for licensing fees, which is supposed to incentivize innovation. In patents for physical inventions, that makes sense: I need to know how to build something if I want to use it as a part of my product, and the patent application will tell me how to do that. But software patents are not descriptive in this way: nobody could write software based on their claims, because they're written in dense legal jargon, not in code.

Let's take one of the patents in question, IBM's "Programmatic discovery of common contacts." This patent covers the case where you have two contact lists for separate people, and you'd like to find out which contacts they have in common. It describes:

  1. Having one local list of contacts,
  2. getting a second from the server,
  3. comparing them, and
  4. presenting a list of hyperlinks to the user.
That is literally the extent of detail present in this patent. Now, do you think you can build a contact matching system by licensing that patent? Or will you do what every other software company on earth has done, and invent the stupid thing yourself (a task that would take a decent coder a couple of days)?

As for the innovation argument, it's impossible to prove a negative: I can't show you that it wasn't increased by patents. But consider this: most of the companies that we think of as Internet innovators are strikingly low on patent holdings. Reportedly, Twitter owns nine, and has pledged not to sue anyone over them. Google's only applied for a few, although they have purchased many as a defensive tactic. Facebook is not known for licensing them or taking them to court (indeed, just the opposite: enter the Winklevii). For the most part, patent litigation is limited to companies who are either no longer trailblazers (Microsoft), are trying to suppress market competition (Apple), or don't invent anything at all (Intellectual Ventures). Where's the innovation here?

This American Life actually did a pair of shows on patents, strongly arguing that they've been harmful: companies have been driven out of business by patent trolls. Podcasters have been sued for the undeniably disruptive act of "putting sound files on the Internet." The costs to the industry are in the billions of dollars, and it disproportionately affects new players — exactly the kind of people that patents are meant to protect.

Q. So there's no such thing as a valid software patent?

A. That's actually a really interesting question. For example, last week I was reading The Code Book, by Simon Singh. Much of the book is taken up by the story of public key encryption, which underlies huge swathes of information technology. The standard algorithm was invented by a trio of researchers: Ron Rivest, Adi Shamir, and Len Adleman. As RSA, the three patented their invention and successfully licensed it to software firms all over the world.

The thing about the RSA patent is that, unlike most software patents, it is non-obvious. It's extremely non-obvious, in fact, to the degree that Rivest, Shamir, and Adleman literally spent years thinking about the problem before they invented their solution, based on even more years of thinking on key exchange solutions by Whitfield Diffie, Martin Hellman, and Ralph Merkle. RSA is genuinely innovative work.

It is also work that was independently invented by the espionage community several years before (although obviously they weren't allowed to apply for patents). Moreover, a lot of the interesting parts of RSA are in the math, and math is not generally considered patentable. Nevertheless, if there's anything that would be a worthy software patent, RSA should qualify.

It goes without saying that matching contacts, or showing search ads, or scrolling a list based on touch, are not quite in the same league. And it's clear that patents are not creators of value in software. People aren't buying Windows computers or iPhones because they're patented. They're buying them because they run the software people want, or run on good-looking hardware, or any number of other reasons. In other words: software is valuable because of what it does, not because of how.

Q. So software shouldn't have any protection?

A. Sure, software should be protected. In fact, it already is. Code can be copyrighted, and you can sue people who take it and use it without your permission. But that's a different matter. Copyright says you can sue people who publish your romance novel. Software patents would be like suing anyone who writes about boy-meets-girl.

Q. Okay, fine. What's the answer?

A. Ultimately, we need patent reform. The steps for this are the same as any other reform, unfortunately: writing letters, asking your political candidates, and putting pressure on the government. It's not a sexy recommendation, but it's effective. If we could frame these as another type of frivolous lawsuit, the issue may even get some traction.

Personally, though, I'm trying to vote with my wallet. I'd like to not give money to companies that use patents offensively. Incidentally, this is why I'm cautiously optimistic for Valve's Steam Machines: it's much harder for me to not give money to Microsoft, since I play a lot of games on Windows (and XBox). A Linux box with a good game library and a not-terrible window manager would make my day.

Finally, there's a community site that can help. Ask Patents is a forum set up by the people who run the Stack Overflow help group for programmers. It takes advantage of a law that says regular people can submit "prior art" — previously-existing examples of the patented invention — that invalidate patents. Ask Patents has successfully blocked bad software patents from being granted in the first place, which means that they can't be used for infringement claims. Over time, success from finding prior art makes patents more expensive to file (because they're not automatically granted), which means fewer stupid ones will be filed and companies will need to compete in the market, not the courtroom.

August 23, 2011

Filed under: tech»innovation

Software Patents Must Die

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.

November 2, 2009

Filed under: tech»innovation

Winter of our Discontent

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.

August 20, 2009

Filed under: tech»innovation

Not So Literal

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.

Future - Present - Past