I have, for some truly inexplicable reason, spent a lot of time in the company of IP lawyers in the past month. This includes software industry folks, professors, and even a general counsel for the MPAA. I am not a lawyer, I don’t often wear suits, and I was thrown out of a few colleges in my time, so you can understand, perhaps, why it is unusual for me to be in the company of such affluent and well-educated folks.

If there is one thing that has completely perturbed me through all these meetings, however, it is the observation that these lawyers, who work full time in IP litigation and regulation, universally agree that patent law is perfectly suited to software, provided the software patents are well written.

(Related: Trying to make sense of muddy patent waters)

That “well written” is a change I’ve seen in this community over the past decade—the only change to their positions. Just like the description of Earth in “The Hitchhiker’s Guide to the Galaxy” went from “Harmless” to “Mostly Harmless,” it seems that the legal world considers the problem with software patents, historically, to be that they were not worded correctly. The problem was that they were too broad.

These lawyers with whom I’ve been associating all have the same thought process: Copyright is not for protecting software, but patents are. And this is why everyone has to spend all their time cranking out useless patents like sandbags in a flood.

Now I will fully admit that software patents are getting more restrictive, and the patent office, working with members of the community, has offered up a few ideas to make software patents less offensive and broad. This is a good thing, as in the past we’ve had some truly horrendous software patents issued for utterly mundane things that every developer uses every day.

This is not to say, however, that software patents are restrictive at all. They are now “more restrictive” than before. They are now greater than zero. Just barely. Stupid things are still getting patented in software. Things like hyperlinking a timecode in a video, previewing two Web pages at once, or just making a plain old bookmark.

Patents are completely wrong for protecting software. In our current system, there is only one aspect of patents that I feel is valid for software protections: their length. Ten to 20 years is about right for protecting a piece of software, and copyright law would extend that to something like less than 70 years. But that’s an issue with copyright law and is outside the scope of this rant.

The misunderstanding
I understand why no one within this patent system (lawyers, judges, patent clerks, patentees) wants anything to really change. It’s not that no one understands software, because there are definitely people within this process that are software experts.

For those in the process that don’t understand software, it’s reasonable for them to want to see patents as the correct form of legal protections. From the outside, software serves a function. It looks like a machine, and machines are patentable. Looking at the process by which software is made, it looks like just that: a process.

This is not the way we should be thinking about software, however. To put it in software terms, it is harmful. To understand why this is not the way to regulate software, we will need a few metaphors, and we’ll need to change copyright law a little bit. These are not impossible things, however, as the U.S. Copyright Office often takes public comment on copyright issues.

I’ve briefed them before. You can, too. Check out their site and see when they’re looking for comments.

First, however, we must understand why patents exist.

The patent system
The patent system exists for one reason: to save technology from the dustbin of history. Back in the 1600s, if someone invented a new method of making horseshoes, it was in their own best interest to keep that method secret. If someone else discovered the secret method, the originator could be ruined and had no recourse to prove he had thought of it first.

The patent office was created to preserve that information. In exchange for a temporary monopoly on the invention, society is availed of the secret behind what makes that invention work. Thus, inventions that move humanity forward are not lost to history when their creators die. In terms of the game Civilization, you could call the patent the time period between when you start researching a technology, and the time when it becomes a national asset: the alphabet, gunpowder, or the steam engine.

Without a patent system, if someone discovers how to make gunpowder and takes that secret to their grave, your society is going to be overrun with foreign invaders using muskets.

Thus, Eli Whitney did not go to his grave holding the secret of the cotton gin in his cold dead fingers. Society was able to continue to benefit from his invention after he had passed away because he was not hiding the technology from history to save his advantage in the marketplace.

This sounds perfect for software, except our patent system does nothing to save software for society. All it does is capture some vague descriptions, some diagrams and flow charts, and some pictures.

Imagine a software patent. Let’s take this one from Samsung, approved in 2012. This is a patent for making a bookmark. The patent includes a half-dozen diagrams, and a mock-up of a screen UI.

There is no source code included in this patent. It’s just diagrams and a drawing of a UI. This is preserving nothing for the future of society. It’s the difference between shooting a bullet and throwing it.

We could fix this in one of two ways, legally. One, we could start adding source code to patent applications. Or two, we could stop this silliness and just set up some sort of subset of copyright rules for software.

Copyright is about protecting the implementation. Patents are about protecting the functionality. A novel is an implementation of a plot. You can copyright the novel but not the plot. You can copyright a movie, but you can’t copyright a single line of dialog, such as “Yes” or “Get to the chopper!”

So it should be with software. You should be able to copyright the combined works that you are building into a piece of software. If you suspect someone has literally stolen your code, compiled it and is selling it, the courts shouldn’t have to do much more than diff the two sources in question.

Instead of debating whether one can patent this or that, we should be arguing about where, exactly, the line is between code plagiarism and commonly used things such as headers. That’s a significant grey area that can be thoroughly explored by people in the legal profession, and can likely be handled by an arbitrary percentage number. A perfect place for the legal folks to help us out.

Protections
For Eli Whitney, the cotton gin was something physical a competitor could have purchased, taken apart and rebuilt themselves. Such an endeavor would take time, but could be done, had been done, and is still done to this day.

For software, however, even having the binary to copy isn’t a big help when you’re expected to re-implement an entire system. While a year spent copying a cotton gin would yield a competing product in a decent time frame, a year spent copying a piece of software doesn’t really guarantee anything. It all comes down to implementation.

And implementation is where there is differentiation. Just as Disney’s “The Wild,” a film about a Central Park Zoo lion accidently shipped off to Africa, was in production for years before DreamWorks’ “Madagascar,” teams are what make the difference, not necessarily what they’re making.

DreamWorks crunched and built their own movie about a Central Park Zoo lion accidently shipped off to Africa in a timeframe that was shorter than Disney’s. They got to market first with a different script, different characters, different art style and actors. They basically just made the other guy’s movie faster. And they won: Madagascar spawned sequels and penguin junk everywhere.

And so it is with software. DreamWorks had every right to act on its knowledge of Disney’s pipeline, and to work harder to get their own project done faster. Sound like any software projects you’ve worked on in your career?

This tells us that, in the digital economy, where digital assets and revenue sources are created by teams working to create what are, essentially in the end, large pools of 1’s and 0’s, implementation is the differentiator, not functionality.

If your competitor has built and patented the only functionality anyone actually wants in your market, everyone loses if they implement it poorly. But if they copyright their poor implementation instead of patent it, then anyone can build a better version and compete on quality instead of functionality.

There was a time when functionality was the differentiator for software. In the days when it was a major breakthrough to plug an Atari ST into a lathe, functionality was the biggest part of software. Today, however, mobile devices have imposed UI expectations on developers. Poorly designed interfaces can tank functionally solid applications. A better movie is a better movie, even if it’s basically the same movie you’ve seen 100 times before.

And a better app is a better app, even if it’s just getting you a pizza or finding you an apartment.

Software needs copyright protections on the actual code, not patent protections on the functionality. Copyright ensures someone cannot simply take your application and sell it as their own work.

Patent law, on the other hand, attempts to give developers a monopoly on meta-concepts that often restrict the freedom of other developers to build as they please.

Sadly, software patents do seem to be here to stay, but it would certainly save everyone time and effort if they’d just go away. We could handle this mess with a big private Git repository hosted at the copyright office, where source code could be checked in privately for copyright registration, and with the addition of some law laying down a line on where plagiarism can exist therein. Obviously, boilerplate code and headers would need to be exempted from copyright restrictions, and 70+ years seems a bit long for software to remain in private hands, but frankly, those restrictions sound preferable to not being able to make bookmarks without being exposed to legal risks.