RICHARD STALLMAN

FREE SOFTWARE FOUNDATION

MR. STALLMAN:  I guess I'm just speaking for myself because, yes, I am
involved in software development with the foundation, and I guess this is
probably the opinion of the foundation too since I'm its president.

(laughter)

COMMISSIONER LEHMAN:  Great.  Well, welcome, and why don't you proceed.

MR. STALLMAN:  Okay.  Each year the government creates new bureaucratic
programs.  Each is created for a purpose.  That doesn't mean it serves that
purpose or that it is worth the cost.

It's hard the close down unnecessary bureaucracies because people presume
they must do some good.  It's easy to admit a government program has
drawbacks, but many won't seriously consider whether it does its job at all.

Thus we see, in the announcement of these hearings, the supposition that
software patents are helpful.  We are asked whether they protect software
developers enough.  Patent lawyers chose the word "protection" to imply that
patents are beneficial.

I'm not a lawyer.  I'm a programmer, considered a good one.  I am here to
explain why software patents impede software development and retard software
progress.  Software is like other fields of engineering in many ways, but
there is a fundamental difference: Computer programs are built out of ideal
mathematical objects.  A program always does exactly what it says.  You can
build a castle in the air supported by a line of zero mathematical
thickness, and it will stay up.

Physical machinery isn't so predictable, because physical objects are
quirky.  If a program says to count the numbers from one to a thousand, you
can be sure it will do that. If you build a counter out of machinery, a belt
might slip and count the number 58 twice, or a truck might go by outside and
you'll skip 572.  These problems make designing reliable physical machinery
very hard.

The result is that software is far easier to design per component than
hardware.  This is why designers today use software rather than hardware
whenever they can.  This is also why teams of a few people often develop
computer programs of tremendous complexity.

People naively say to me, "If your program is innovative, then won't you get
the patent?" This question assumes that one product goes with one patent.

In some fields, such as pharmaceuticals, patents often work that way. 
Software is at the opposite extreme: A typical patent covers many dissimilar
programs and even an innovative program is likely to infringe many patents. 
That's because a substantial program must combine a large number of
different techniques and implement many features.  Even if a few are new
inventions, that still leaves plenty that are not.  Each technique or
feature less than two decades old is likely to be patented already by
somebody else.  Whether it is actually patented is a matter of luck.

The only way a programmer can avoid this mess is by sticking to things that
are obsolete.  You may not recall the state of the computer field 17 years
ago since most people didn't pay attention back then, there were no personal
computers.  If you were a hobbyist you might get a computer with a few
thousand bytes of memory.  If you were lucky it might run basic.

This shows another way that software is different, it progresses very
quickly.  A program three years old is becoming obsolete, and one that's six
years old looks Stone Age.  A 20_year monopoly for anything in computers is
absurd.

In other fields a new technique may require development, building one device
after another until you understand how to make the technique work.  If a
steel part functions badly and you think copper might be better, you can't
type "replace steel with copper" and try the new device a minute later.  The
need to recoup the cost of this development is part of the usual argument
for patents.

In software, an individual technique usually doesn't need much development. 
What we do develop are products that combine a new technique with dozens of
other techniques.  When a second programmer decides to use the same
technique, he will have to do just as much development as the first
programmer.  Firstly, because he's probably using a different combination of
techniques with that new one, and secondly, because the first programmer
probably kept the results of development a trade secret.

The patent system is supposed to help by discouraging trade secrecy.  In
software, patents don't do this.  Today, just as in 1980, most developers
publish general ideas and keep the source code secret.  Here is a copy of a
compiler that I wrote with a few friends.  It's printed four pages per sheet
to make it manageable.  This program is mainly the work of four people,
another dozen helped substantially, and others occasionally.  The two
principal developers were not working on this full_time.

This compiler and its output are probably being used on more than a million
computers today.  Major companies such as Intel and Motorola have adopted it
and now add to it.  The U.S. Air Force is funding extensions to it.  Many
widely used systems are compiled with it.  Just a few lines of code can be
enough to infringe a patent.  This compiler has 10,000 pages __ how many
patents does it infringe?  I don't know, nobody does.

Perhaps you can read the code and tell me?

(laughter)

I know of one patent it infringes, I found it along with some near misses in
a list I saw by luck.  I believe I have prior art for that patent, but I
can't be sure what a court would say.  I don't dare tell you the patent
number, because if I were sued, I couldn't pay for the defense.  I would
lose by default.

An invalid patent is a dangerous weapon.  Defending a patent suit typically
costs a million dollars and the outcome depends mostly on legal
technicalities.

I've had at least one patentable idea in my career, I know this because
someone else patented it years later.  It's a feature for using
abbreviations in a word processor.  A couple of years ago, the users of the
word processor XyWrite received a downgrade in the mail.  XyWrite had an
abbreviation feature, the developer removed it when threatened by the patent
holder.

They knew about my earlier published work; why didn't they fight the patent?
Sometimes a business can't afford to have a lawsuit that will drag on for
years.  At those times, even if the patent is invalid, you lose.

These patents are invalid because of luck.  It was pure luck that these
ideas were published by one person before they were patented by another. 
And it was luck that the ones who published didn't patent instead.

This is an important point:  What is patented and what is not is mainly a
matter of luck.  When you develop a large system and you need to combine a
large number of techniques and features, whether or not you can use each
given one is a matter of luck.

The carelessness of the Patent Office in dealing with software is well
known.  So some people assume that if the PTO only did a better job,
everything would be okay.  They say we that we should wait while the invalid
patents spew out, and eventually the PTO will understand software and do the
job right.

There are two flaws in that suggestion:  The PTO will not do a better job,
and that would not solve the problem if they did.

Some years ago a professor I know patented Kirchoff's current law, which
says that the electric currents flowing into a junction equal the currents
flowing out.  He did this to confirm, privately, his suspicion that the PTO
could not handle the field of electronics.  He never tried to enforce the
patent which has since expired.  I will disclose his name if you give
assurances that he and his lawyer will not get in trouble for this.

Kirchoff's laws were formulated in 1845.  If the PTO couldn't understand
electricity after a century, how can we expect it to understand software in
another decade or two.

(applause)

Computer scientists look at many software patents and say, "This is absurdly
obvious".  Defenders of a patent system reject our opinion.  "You're using
hindsight," they say.  "You're more skilled than a typical practitioner."
What we consider obvious patents are not errors, they reflect a different
definition of "obvious".  It's not going to change.

What if the PTO stopped making mistakes and issued no more invalid patents?
That would not solve the problem because all new techniques and features,
those not known today, would be patented just the same.

Suppose the PTO were perfect, suppose that it is the year 2010 and you're a
software developer.  You want to write a program combining 200 patentable
techniques.  Suppose 15 of them are new, you might patent those.  Suppose
120 of them were known before 1990, those would not be patented any longer. 
That leaves 65 techniques probably patented by others, more than enough to
make the project infeasible.  This is the gridlock we are headed for.

Today's PTO mistakes are bringing us to gridlock sooner, but the ultimate
result is gridlock even with a perfect PTO.

I have explained how patents impede progress; do they also encourage it?
Patents may encourage a few people to look for new ideas to patent.  This
isn't a big help, because we had plenty of innovation without patents.  Look
at the journals and the advertisements of 1980 and you'll see.  New ideas
are not the limiting factor for progress in our field.  The hard job in
software is developing large systems.

People developing systems have new ideas from time to time, naturally they
use these ideas.  Before patents they published the ideas too for kudos.  As
long as we have a lot of software development, we will have a steady flow of
new published ideas.

The patent system impedes development.  It makes us ask for each design
decision, "Will we get sued?" And the answer is a matter of luck.  This
leads to more expensive development and less of it.  With less development,
programmers will have fewer ideas along the way.  Thus, patents can actually
reduce the number of patentable ideas that are published.

A decade ago the field of software functioned without patents, it produced
innovations such as windows, virtual reality, spreadsheets and networks. 
And because of the absence of patents, programmers could develop software
using these innovations.

We did not ask for the change that was imposed on us. There is no doubt that
software patents tie us in knots.  If there's no clear and vital public need
to tie us up in bureaucracy, untie us and let us get back to work.

I'm finished.  I hope I didn't exceed my time.

COMMISSIONER LEHMAN:  No, you didn't.  Thank you very much.

Does anybody else have any questions of Mr. Stallman?

Thank you very much.

(applause)

COMMISSIONER LEHMAN:  Did you write this entire 10,000 pages worth of code?

MR. STALLMAN:  No.  As I said, about four people did most of the work.  In
what's here, I and one other person did most of the bulk of the work.  And
then there were like two or three others who did substantial pieces, and a
dozen who did significant pieces.

By the way, with this goes another stack __ this tall __ of machine
descriptions for particular target machines, but I didn't include them
because they have a lot more different contributors.

COMMISSIONER LEHMAN:  And what do you do with this? How do you make this
available to the public?

MR. STALLMAN:  It's on the Internet.  You can FTP it and run it.  Many
organizations distribute it.  We also supply it on compact disks.

COMMISSIONER LEHMAN:  So that's how you make most of your work which is
dedicated to public domain as I understand it, pretty much.

MR. STALLMAN:  It's not public domain, but that's getting into a digression,
it's free software.

UNMIKED VOICE:  Can you go back to the microphone?

COMMISSIONER LEHMAN:  I apologize, I should have asked that.

MR. STALLMAN:  I don't want to get into free software because it's a
digression I think for the most part, and it leads into an area where I have
views that are definitely a small minority's views.  What I've said I think
most programmers would agree with.  I've stayed away from my controversial
beliefs.

But, yes, I distribute free software, and because of that I generally can't
licence even one patent.  Other software developers can muddle through if
they have to license a few patents, gets to be enough and they get crushed.

But I can't __ I get stopped dead by even one.

COMMISSIONER LEHMAN:  Have you been sued yet?

MR. STALLMAN:  No, but I've had to stop distributing software because I've
seen other people being threatened for the same patents.  I didn't wait till
I got sued.  People often wouldn't actually sue a charity.  After all, I am
the president of a charity, and they might feel it would look bad to be
suing us, so instead they would just sue our users.  Right?  And how would I
feel if I were trying to help the public, giving them something that's a
trap, a trap for getting sued.

COMMISSIONER LEHMAN:  Have any of your users been sued, of your work?

MR. STALLMAN:  They haven't been sued for the programs that we write, but
for other free software we use they have been threatened. They received
letters from AT&T, everyone using XWindows got threatened by AT&T and by
Cadtrack.  So even though we didn't write that software, it's an essential
part of the system we're trying to build.

COMMISSIONER LEHMAN:  Thank you very much.

Our next witness is Timothy Casey, Senior Patent Counsel with Silicon
Graphics.

MR. STALLMAN:  Would you like to keep this?  It's an exhibit, we'll offer it
to you, but we'll throw it away if you don't want it.

COMMISSIONER LEHMAN:  It seems like a shame to throw it away, but I think
that it's going to be hard for us to take it back to Washington.

MR. CASEY:  I'd be happy to recycle it for you.

(laughter)

COMMISSIONER LEHMAN:  But we can put it in a museum here in San Jose.  Well,
since it's available actually on the Internet, we can just call it up there,
if we need it.

Please go ahead.


Back to The San Jose Index

Forward to Timothy Casey