Find Command Cheat Sheet Free from Linux Training Academy Download Now!
Welcome Guest | Sign In

No Really, Lower the Volume Already

By Philip H. Albert
Mar 29, 2005 5:00 AM PT

Sometimes you can't win for trying. Like when you politely ask the kid sitting next to you on the subway who is playing his music a little loud to please turn it down. Just to be contrary, he responds by cranking it up even more.

No Really, Lower the Volume Already

In my March 15 column, Lowering the Volume in the Software Patent Debate, I suggested with the best of intentions that it might help everyone to lower the volume in the software patent debate.

Naturally, I received some very LOUD responses to that column. Some were coherent and some not even close. So let's try this again. Instead of YELLING at whomever you disagree with, take that energy and direct it in a more positive way -- GET OUT THERE AND DO SOMETHING.

Full Disclosure

Whenever someone posts a comment about my column, the post often includes a conjecture that I must be on the payroll of some group that wants me to write an advocacy piece favoring them. For the record, I shill for no one. I am not paid to take a particular position, nor have I ever been asked to promote a particular opinion. In any case, I hope that most readers consider the message rather than the messenger.

The Debate

The debate itself is not clear. Not all participants are advocating positions relative to the same set of issues. Some advocate that open-source licensing should dominate proprietary licensing. Others advocate for proprietary licensing over open-source licensing.

In what should be an entirely separate debate, there are those who argue against patents on software-based inventions and those that argue for patents on software-based inventions. That debate pits one side arguing for open-source development and against patents due to a belief that patents hinder open-source development, against the other side that argues for exactly the opposite.

Some even argue that the debate is not pro-patents versus anti-patents. For example, in Europe, the debate is about the methods of stopping patents on software-based inventions, denying any side that favors patents on software-based inventions.

Why Patents, Open-Source Software Intertwined

The two debates are often intertwined because of the belief that the existence of software patents might wipe out open-source software licensing.

The belief is not unreasonable and proceeds as follows: If an author of a software program releases his or her code under an open-source license and the software is good and useful, it will propagate indefinitely. This benefits the public (who can use this software without having to create it themselves) and the author (who will feel good, who was paid to create it anyway, will get a job because of it, etc.) -- until it hits a patent.

Once the patent holder is in the picture, a per-copy royalty might be required, and with many open-source licenses, there is no mechanism to collect royalties. This is fair. Most intellectual property rights only trigger when there is access to the rights owner's developments, so a software developer can avoid the rights of others by not accessing the protectable property of others.

Not so with patents. One can infringe a patent without ever seeing the patent, so open-source developers cannot ensure that their output is non-infringing.

Real Problem with Software Patents

The real problem is not patents per se, but bad patents. I assume that if someone figured out how to build an anti-gravity vehicle and wanted a royalty for each car developed according to his patent, we'd have no complaints. After all, we didn't have this before and there is little chance that anyone would have developed it without finding out how from the inventor's patent application.

Most of the arguments related to so-called "software patents" stem from the apparent ease of invention. I put software patents in quotes because there is no neat category of patents known as "software patents," just patents that might relate to inventions that could be implemented in software.

The real problem is not patents, but the apparent ease of invention in the software field. If something is easily invented, we seem to think that the inventor is not worthy of any rights to the invention. As far as I know, there are no patent laws anywhere in the world that specify difficulty as a measure of patentability. Instead, most countries look for novelty (you cannot patent something that already existed before you invented it) and inventiveness/nonobviousness (even if it did not already exist, but an obvious variation of it did, you still cannot patent it).

In addition to the notion that one should not reap large rewards for little effort, there is also the notion that patents on software-implemented inventions cause more problems than other patents. Previous programmers might have created the invention and not mentioned it because it was a trivial thing to do. If later programmers came up with the invention on their own, how inventive could it be?

Raise Bar, Lower Volume

There are many examples of patents on software-implemented inventions that should not have slipped past the patent office. This might be due to lack of knowledge of the prior art or too low a test for obviousness.

Software prior art is difficult to obtain relative to prior art for tractors. We know where to find old tractors, but old software can be hidden from view or lost more easily. Most patent offices have historical records of past patents organized by topic, so it is easy to find those that relate to tractors. Not so with software. Software can be harder to organize and there just isn't that much history yet.

It seems that much of the shouting about software-related patents is based on the perception that such patents are low quality and grant exclusionary rights without inspiring innovation. However, blanket opposition to patents will fail. It has to. There are too many vested interests, and many believe that patents are necessary and beneficial to society in general. They will not go away.

A more promising tack is to call for serious review of inventiveness for patents that do issue for software-implemented inventions. If a software construct is being independently created by thousands of programmers, it is a good indication that the construct is not all that inventive. It is more likely to lead to patent assertions against those with no prior knowledge of the patent, which is likely to lead to the typical anti-patent outrage. However, if some software construct is such that most uses of the construct derive from learning of its invention from an original inventor, less controversy can be expected.

Noninventive Concepts

Instead of opposing all patents on software-implemented inventions, how about opposing patents on noninventive concepts? One way to do this is to work on preserving historical records of software developments so that the prior art does not disappear.

Patents should not cover that which a person of ordinary skill in an art would stumble upon when writing code. It should be a little harder to end up with a patentable invention. While that means fewer patents for the less inspired, it also means fewer patent infringements by those that follow.

No matter how good at multi-tasking we are, it is never easy to concentrate with a lot of noise in the background. So let's all quiet down and get to work.

Phil Albert, a LinuxInsider columnist, is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.

How do you feel about government regulation of the U.S. tech industry?
Big tech companies are abusing their monopoly power and must be reined in.
Stronger regulations to protect consumer data definitely are needed.
Regulations stifle innovation and should be kept to the barest minimum.
Over-regulation could give China and other nations an unfair advantage.
Outdated antitrust laws should be updated prior to serious regulatory efforts.
Tech companies should regulate themselves to avoid government intervention.