[DMCA-Activists] IEEE Spectrum: A Lucid Reading of Software Patentability (Should be Required Reading)

[Seth Johnson]

> http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i080205
> http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i070305

(Text for both articles pasted below)


I have said that two things would happen, now that a definitive
historical register has been established in Europe, in which the
EU Parliament has refused to ratify a law that would have
legitimized the European Patent Office's illegitimate practice of
granting software patents despite of the explicit exclusion of
computer programs from patentability under the European Patent
Convention of 1973: 1) Many voices who had reserved judgement or
held ambivalent or noncommittal positions on the issue, would now
start to come out of the wings and take a clear position against
software patents based on basic principle; and 2) the pure
position, the position that says it's in the nature of pure
abstraction that we find the real reason for not allowing
software to be patented, would be increasingly recognized (as
opposed to other kinds of analysis, such as legal or economic --
just as valid to be sure -- which have been emphasized
heretofore).

The following two articles constitute the single most lucid,
brief and precise treatment of the issue of software
patentability I have seen yet.  The author, Ben Klemens, presents
an enormously clear exposition of the nature of the issue,
covering the essential nature of the problem and explaining what
the broad community of programmers have known as an almost
intuitive matter all along, but what has been largely disregarded
and discredited by many in the legal, legislative and government
functionary exclusive rights communities.

Klemens reaches the same position I have propounded: that
innovative devices may encompass media that expresses code, but
the pure abstract logical functions expressed in such media (of
any sort), are inherently no more appropriate for patentability
than pure abstraction represented in written expression would be
-- indeed, software, no matter how "hard" it is, is simply a form
of written expression representing pure abstraction.


Seth


---

> http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i080205


New legal code

Copyrights should replace software patents

Second in a two-part series

By Ben Klemens


Last month I discussed the fundamental impossibility of
distinguishing between software and pure mathematics and argued
that software patents should be abolished as a result. If
software is math and pure mathematics is supposed to be
unpatentable, then every software patent issued exposes a legal
contradiction.

This month I explore the current economic consequences of having
that contradiction enshrined in U.S. intellectual property law
and propose that instead of software patents, we rely on another,
already existing, method that can protect innovators from
exploitation: copyright.

One of the most common arguments from those who advocate software
patents is that software is just like any other technology.
Patents work great for pharmaceutical companies and integrated
circuits, so why shouldn't they work for software as well?

But there is a key difference between software, on the one hand,
and physical technologies such as drugs and integrated circuits,
on the other: the software industry is not only massive but
massively decentralized. Every company with a Web page or an
accounting database has people on staff writing software to
support those systems--from the simplest script for automating
backups to complex, custom-built systems.

Only a relatively small number of firms make drugs or ICs, but
the software industry, with no equipment costs to speak of, as
well as the ubiquitous demand for software to oil the gears of
our lives, is unlike any other business. It not only includes the
usual full-time producers, such as Novell Inc. and Microsoft
Corp., but also a team of people in the basement of every company
in America. A study by the U.S. Department of Commerce's Bureau
of Economic Advisors found that in 2002 nearly as much money was
spent in the United States on software written in-house as on
prepackaged software--US $72 billion and $76 billion,
respectively.

But what does the ubiquity of software creation have to do with
patentability? The answer lies in the fact that because
programmers use similar, if not identical, software and hardware
tools to tackle common needs, certain ideas are independently
conceived over and over again. But independent invention is not a
defense against claims of patent infringement.

Patents are public records, and in a centralized industry with
relatively few players--such as pharmaceuticals--the assumption
that all patents are common knowledge is not unreasonable. The
relative handful of drug companies can each support a legal
department that is abreast of drug patents.

Now let's take a look at an example from the decentralized
software industry. U.S. telecommunications giant SBC
Communications Inc., in San Antonio, holds U.S. patents that are
allegedly infringed on by a broad range of Web pages--including
the Web site I threw together for the California Institute of
Technology's undergraduate intellectual property class. Some
businesses, such as Museum Tour, a company in Milwaukie, Ore.,
that sells educational toys, received letters demanding royalties
for patent infringement from SBC. Applying the logic of the
centralized industries, SBC's patents are public record, so the
toy company could have avoided its dispute with SBC by hiring a
patent attorney to do a full search of the software patent
database before putting up its Web site.

Part of the problem is that infringing a software patent is so
easy, because so many patents have been issued in even the most
basic fields of computing. For example, just record a macro to
automate a repetitive task in writing an online document. Suppose
your word processor saves the macro as part of the document (many
do by default), and your macro bears a sufficient resemblance to
one of the more than 170 000 software patents registered with the
U.S. Patent and Trademark Office. Congratulations! You've just
engaged in worldwide distribution of an infringing technology. If
you are truly committed to avoiding liability and following the
law, then you will need to hire a lawyer to do a full patent
search before you click the Record Macro button, design a
database form, program a function to calculate a piece of
textbook math, or draw up a Web page.

Does this sound absurd yet? Patents, designed for centralized
industries, have been applied to the most decentralized industry
imaginable, and the result is that patent law is taken only
partly seriously. Ronald Mann, a scholar at the University of
Texas, in Austin, interviewed venture capitalists and programmers
and found them resigned about software patents. Programmers don't
do patent searches on every line of code. Instead, they simply
expect that a patent attorney will demand royalties if the need
arises. Testimony to the U.S. Federal Trade Commission by
businessmen and programmers said the same thing: to stay within
the law requires such an absurd, paralyzing amount of work that
nobody bothers. Conversely, one would be hard-pressed to find a
pharmaceutical company that does not bother with regular patent
searches.

Patents offer the benefit of fostering certain types of
innovation, but the law also imposes economic costs. Most
notably, everyone in the industry must spend money on remaining
abreast of every relevant patent. When "industry" means everyone
with a computer, that's an astronomical sum.

If a person or company does not spend the money to clear its
macros, functions, and data structures, then it exposes itself to
liability. Defending oneself against a claim of patent
infringement can cost millions; it is easier to just pay a
royalty so that the claimant will go away. Filing (or buying) a
vaguely worded patent and sending out royalty demands has thus
become a sure-fire business model. Some companies have no
business other than seeking patent royalties and infringement
damages. To give one example from a long list, Acacia
Technologies Group, in Newport Beach, Calif., is suing nine U.S.
cable TV providers, claiming a patent on the software written by
these cable companies [see "The Patent Profiteers," IEEE
Spectrum, June 2004].

There is no sensible means of reconciling an industry that has
massive independent invention with a law that makes independent
invention a liability. So what's the solution? How can we protect
programmers and companies that invest in developing innovative
new software from being ripped off--without tying the entire
software industry up in red tape? The answer is copyright.

Copyrighting is very different from patenting. First, there is no
paperwork. If you write an equation on the back of an envelope,
then you hold the copyright to it, and there is no need for
lengthy negotiations with the Library of Congress, as well as no
need to put your work in the public record. But if somebody finds
your envelope and plagiarizes the equation, then they are guilty
of infringement, and you may attempt to prosecute them
accordingly.

But as opposed to the case with patenting, independent invention
is a valid defense against claims of copyright infringement. That
is, if someone on the other side of the country should write down
the same equation independently, then that person has done
nothing wrong legally. Under a copyright regime, where
independent invention is a valid defense, provided you have not
reviewed and copied code from a copyright holder, you are free to
write all the code you can dream up independently.

Because it doesn't offer a patent's monopoly protection, a
copyright is, in some ways, weaker protection than a patent, but
is there any evidence that innovation would be harmed without
patent protection? Before the In re Alappat ruling by the U.S.
Court of Appeals Federal Circuit in July 1994, software was
effectively protected only by copyright; yet it would be
difficult to claim that before 1994 the IT industry was short on
innovation.

Copyright still provides protection from the sort of shady
dealings that fair laws should prevent. If competitors find a way
to copy code out of one program and paste it into one of their
own, or if pirates mass-produce copies of an installation CD, or
if a disgruntled employee take the company's code base to a
competitor, then those people could still be prosecuted under a
copyright regime.

There are many considerations to molding copyright laws to fit
software best, but in an industry with literally millions of
independent inventors, a copyright is much less likely to stifle
innovation than a patent or to impose the cost of hiring a
standing army of lawyers.


ABOUT THE AUTHOR

BEN KLEMENS has a Ph.D. in social sciences from California
Institute of Technology, in Pasadena. He is currently a guest
scholar at The Brookings Institution, Washington, D.C. His book
Math You Can't Use: Patents, Copyright, and Software is to be
published by the Brookings Institution Press.

---

> http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i070305


Software Patents Don't Compute

No clear boundary between math and software exists

First of two articles on software patents

By Ben Klemens


In 1997 the U.S. Patent and Trademark Office granted Amazon.com a
patent for "one-click shopping"—a system that lets customers make
purchases without having to go through an online checkout. The
patent started a fierce debate in both the business and the
technical press. Critics felt the Amazon.com patent was the
poster child for everything that was wrong with software patents,
charging that such patents allowed obvious applications of
existing technology to be wrapped up in intellectual property
monopolies.

The Amazon.com patent is no fluke. Consider the following
recently issued patents:

    * Method and system for solving linear systems (U.S. Patent
No. 6078938). 

    * Cosine algorithm for relatively small angles (No. 6434582). 

    * Method of efficient gradient computation (No. 5886908). 

    * Methods and systems for computing singular value
decompositions of matrices and low rank approximations of
matrices (No. 6807536). 

The arcane details of these patents are not relevant. What is
relevant is that these patents are for purely mathematical
algorithms, and for centuries prior to the 1990s, mathematics was
not patentable. So how did these patents come to be granted?

By U.S. law, scientific principles may not be patented.
Electromagnetism, the theory of relativity, and a menagerie of
quantum particles were all discovered after the inception of the
U.S. Patent and Trademark Office, now based in Alexandria, Va.
Yet none of these discoveries could have received patents,
because until the early 1990s it was universally agreed that
mathematical algorithms were in the category of scientific
principles that could not be owned by an individual.

What has changed is that mathematics has become increasingly
reliant on machines. Abstract algorithms that involve inverting
large matrices or calculating hundreds of coefficients in a
sequence are routine today and of only limited use without
physical computers to execute them.

Conversely, devices such as video drivers, network interface
cards, and robot arms depend on algorithms for their operation.
Because of the machine-intensiveness of modern mathematics and
the math-intensiveness of modern machines, the line between
mathematical algorithms and machinery is increasingly blurred.
This blurring is a problem, because without a clear line
delimiting what is patentable and what is not, creative
entrepreneurs will eventually be able to claim sole ownership of
abstract mathematical discoveries. But how do we draw a line that
would ensure that mathematical algorithms are not patentable
while innovative machines are?


THE EASIEST LINE TO DRAW would be simply to say that if an
invention is physical, then it should be patentable, and if it is
abstract, then it should not be. But what do we do with
inventions that involve both the physical and the abstract? For
example, the case of Diamond v. Diehr involved a rubber-curing
machine that relied on a significant amount of software to
control the machine's timing. The U.S. Supreme Court ruled in
1981 that the patent was for industrial equipment, not an
abstract algorithm, and thus the overall patent—software plus
machine—was valid. But the court left a key question hanging: how
much physical invention is necessary before the overall device is
patentable? If all of the inventiveness is in the algorithm,
which is then applied in a trivial manner to a simple machine, is
the overall patent okay?

In a long series of rulings, culminating in 1994 with In re
Alappat and In re Lowry, the U.S. Court of Appeals for the
Federal Circuit ruled that an uninventive physical component
added to an inventive abstract component makes the whole
patentable. In other words, "a new algorithm to calculate Fourier
transforms" is not patentable, but "a stock PC on which is
programmed a new algorithm to calculate Fourier transforms" has
enough of a physical component to be patentable.

Further, the court ruled that since a computer is so integral to
a computational algorithm, patent examiners are obliged to assume
that one exists. If an application is for "a pure computational
algorithm," then the examiner must read it as if the words "a
computer on which is programmed" had been prepended to the
description of the algorithm.

This is the bottom of the slippery slope: there is no longer any
meaningful barrier to the patenting of abstract algorithms. The
use of any inventive mathematical algorithm that requires more
calculation than can be reasonably done by hand is now
patentable.


ANOTHER APPROACH MIGHT BE to distinguish between the pure
mathematical algorithm, which should not be patentable, and its
application to real-world problems, which should be.

For example, the case of Gottschalk v. Benson concerned the
patentability of a program to convert between binary-coded
decimal and plain old binary. Evidently, this was too close to
unapplied pure math; the Supreme Court struck down the patent in
1972, because "the patent would wholly pre-empt the mathematical
formula and in practical effect would be a patent on the
algorithm itself."

In contrast, State Street Bank and Trust Co. v. Signature
Financial Group Inc. was a suit over alleged infringement of
State Street's patented system for doing the bookkeeping for a
suite of mutual funds. The system did not push around physical
objects, but the Court of Appeals for the Federal Circuit ruled
that the share prices and other numbers it derived still have a
real, tangible effect and may therefore be considered to be a
valid subject for a patent. So this attempt to distinguish the
patentable from the unpatentable is too unreliable.


TO FIND OUT WHY all these distinctions fail, we turn to one of
the founders of computer science, Alan Turing. In 1936, Turing
described a theoretical computer that is effectively equivalent
to every computer in existence today. His design included an
infinitely long tape and read/write head, which did different
things depending on the data on the tape and the machine's state.
Because different states cause the machine to do different
things, his contraption is often called a state machine.

A modern PC is equivalent to Turing's tape and head—a physical
device that can store data and execute various operations. The
programs that instruct the computer's operation generate the
states that dictate how it will operate: they make up the
impermanent information that guides the computer, but they do not
change its fundamental design or composition.

Because almost all modern programming languages encompass the
ability to turn a computer into a state machine, they are all, at
a deep level, equivalent—a program written in one such language
can be directly translated to any other language, such as from
Perl to C++ or from Microsoft Visual Basic to Lisp. So all
software is essentially made of the same stuff.

In 1936, Alonzo Church proved that that stuff is mathematics.
Church created lambda calculus, a formal means of writing
mathematical expressions and also a tool that can be used to
program a state machine. That is, any program written in a
language such as C is a trivial translation of a set of purely
mathematical lambda-calculus expressions.

So where is the line drawn between software and mathematical
expression? Based on Church's and Turing's work, there is none.
Any legal attempt to force a wedge between pure math and software
will fail because the two are one and the same. A patent on a
program is a patent on a mathematical expression, regardless of
whether it is expressed in C, Lisp, or lambda calculus.


BUT WHILE DEMOLISHING the distinction between software and math,
Turing and Church's work offers a natural division between
patentable machinery and unpatentable mathematics—exactly what we
have been looking for. Let the devices that implement state
machines—physical objects such as computers—be patentable, and
the states to which they are set—information such as programs and
data—remain unpatentable. The distinction meets the goal of
ensuring that pure mathematics is not patentable while letting
those who design faster and better computing devices patent their
inventions.

The distinction is clear, and it offers no slippery slope down
which the courts could slide. An innovative field-programmable
gate array (FPGA) is a state machine and so would fall on the
patentable side of this fence, while code loaded onto the FPGA
would be an unpatentable state to which the state machine has
been set.

A Java machine constructed on an application-specific integrated
circuit (ASIC) would be a state machine, but a Java machine
existing only in software running on a general-purpose central
processing unit would be a state. A robot arm would be a state
machine, but its device driver would be a state.

The courts failed to review the mathematics literature and as a
result made several vain attempts to reinvent the wheel. Software
and lambda calculus are in the same equivalence class, which
means any law that allows software to be patentable allows the
patenting of the evaluation of certain mathematical expressions.

But, fundamentally, if we are to disallow the patenting of pure
scientific and mathematical discoveries to foster basic research
and innovation, the only way to do so is to disallow the
patenting of the states to which state machines may be set—that
is, to abolish software patents.

Editor's Note: This is the first of two articles on software
patents. This article focuses on how the U.S. patent system
attempts to draw a dividing line between patentable machines and
unpatentable mathematics—and why the system is failing. Next
month's article will discuss the economic and legal impact of
software patents and a proposed solution.


ABOUT THE AUTHOR

Ben Klemens has a Ph.D. in social sciences from California State
Polytechnic University, in San Luis Obispo. He is currently a
guest scholar at The Brookings Institution, Washington, D.C. His
book Math You Can't Use: Patents, Copyright, and Software is to
be published by the Brookings Institution Press.


-- 

RIAA is the RISK!  Our NET is P2P!
http://www.nyfairuse.org/action/ftc

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://realmeasures.dyndns.org/cc

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.