Ian Beatty

Group 3

Synopsis – Week of Sep 14-18

The two readings for this week both argue against the power that patent law holds over

the development of new software. As opposed to copyrights, which protect the original work of

authors and artists, patents are meant to protect the money-making ideas, products and

techniques of companies or individuals. Patents must be applied for, and after approval is granted

they provide exclusive rights to make use of the protected technique or idea for a certain period

of time. When patents were originally instituted, lawmakers had no idea of the possibility of the

existence of software, which is unique in that it is non-physical but still able to perform valuable

tasks. These two readings see many of the same problems with the application of patent

software, but propose somewhat different solutions.

In “A New Paradigm for Intellectual Property Rights in Software,” Mark Webbink argues

against the bloated use of patent protection in the software industry. Taking issue with a previous

article which asserted that patent protection was responsible for the growth of the software

industry to begin with, Webbink asserts that other factors, such as the growth of the personal

computer, had far more to do with the success of software, and that patents may have actually

grown to be a hindrance to the industry. To Webbink, the main problem is the sheer amount of

patents being applied for. Every program may be split into tiny bits of patentable intellectual

property, and when each small part receives protection, a tangled morass of patents is quickly

created. Companies are able to own thousands of small patents, many of which are spurious but

are nevertheless accepted by the Patent and Trademark Office. Because patents are such a

powerful way of claiming intellectual territory, Webbink argues that the generation of patents
has become too much of the focus of today’s software companies, to the detriment of their real

research and development. In addition, these huge patent libraries can be used to discourage

competition, especially when large companies cross-license their patents, creating a combination

of wide rights and deep resources that small companies cannot hope to match or even challenge

in court because of the expense of copyright litigation. Thus, the growing number of applications

for patents misdirects the energy of large corporations and strangles small ones, depriving the

software industry of many opportunities for advancement.

As a solution, Webbink argues that the patent system needs to be overhauled, making it

harder for spurious and narrow patents to be accepted, while making it easier to challenge patents

upon acceptance. He appreciate patents as a source of profit for innovators, but thinks that the

system can be truly beneficial only if it is jerked hard and brought under control.

Richard Stallman’s 2002 speech, entitled “Software Patents – Obstacles to Software

Development,” takes a similar approach in attacking patents. As a coder, he is better acquainted

with the unique problems engendered by software patenting, and gives a good idea of how

difficult coding becomes when patents are protected vigorously. In particular, patents discourage

the development of new programs because of the secrecy of pending applications and because of

the opacity of their language. At times, he says, even the patent-holders are unable to decipher

their own patents, meaning that prospective coders can be turned off by the possibility of

litigation based on obscure interpretations of the numerous and confusing patents. And even

when confronted with a patent that is well-understood, the options of an innovator are few.

Licenses to use patents are expensive or impossible to maintain, and even when a patent may be

avoided, its non-use will likely lead to the creation of slower, inferior programs. Because of the
sheer number of patents and the expense of litigating them, fighting against patent protection is

often infeasible, even in the case of clearly spurious patents.

If he had his way, Stallman would like to make all software unpatentable, as he argues for

in Europe. Still, he recognizes the entrenched nature of the American patent system, and supports

a system that would eliminate or reduce the spurious software patents which choke innovation.

Any detailed proposal for this initiative was not forthcoming. While he may have a better grasp

of the real technical problems of software patenting, Stallman also seems to have an idealistic

hope that patenting might become a thing of the past. This will not happen.

In most ways, I agree with Stallman and Webbink’s criticism of the process of patenting

software. While patenting can lead to innovation through proving rewards to innovators, its

misuse in the software industry is hurting innovation and probably reducing profits. Webbink’s

proposal to limit patents to whole systems (rather than small elements therof) seems a good place

to start. Coders should be free to use the elements of other programs to create new and better

software for profit, because this availability of code is the most powerful driving force for more

innovation. In the end, Stallman’s argument against patents altogether is unconvincing, because

he gives no real way that companies may make money without exclusive rights to, at the very

least, the aggregates of their many unique ideas. So, while patents are indubitably harmful to the

world of software, the system must be reformed and not abolished. Relying on organizations of

volunteers coding in their free time is at least as dangerous as relying on monolithic corporations

that attempt to choke off competition through litigation. The real solution is somewhere in

between these extremes, and so I concur with Webbink: only a more stringent and conscientious

patent system has the potential to achieve the greatest good for the future development of

software.