Against Software Patents

 "Every silver lining has a cloud around it."

             PROTECT YOUR FREEDOM TO WRITE PROGRAMS
           * JOIN THE LEAGUE FOR PROGRAMMING FREEDOM *
               PART II - Against Software Patents

 Software  patents  threaten  to  devastate  America's   computer
industry.  Patents granted in the past decade are now being  used
to attack companies such as the Lotus Development Corporation for
selling  programs that they have independently  developed.   Soon
new companies will often be barred from the software arena - most
major programs will require licenses for dozens of  patents,  and
this  will  make  them infeasible.  This  problem  has  only  one
solution: software patents must be eliminated.

The patent system and computer programs

 The  framers of the United States Constitution  established  the
patent system so that inventors would have an incentive to  share
their  inventions  with  the general  public.   In  exchange  for
divulging an invention,  the patent grants the inventor a 17 year
monopoly on its use.  The patent holder can license others to use
the  invention,  but  may  also refuse  to  do  so.   Independent
reinvention  of the same technique by others does not  give  them
the right to use it.
 Patents  do  not cover specific  systems:  instead,  they  cover
particular  techniques  that can be used  to  build  systems,  or
particular features that systems can offer.   Once a technique or
feature is patented,  it may not be used in a system without  the
permission of the patent-holder  - even if it is implemented in a
different  way.   Since  a computer program typically  uses  many
techniques  and  provides many features,  it  can  infringe  many
patents at once.
 Until  recently,  patents were not used in the  software  field.
Software developers copyrighted individual programs or made  them
trade  secrets.  Copyright was traditionally understood to  cover
the  implementation details of a particular program;  it did  not
cover the features of the program,  or the general methods  used.
And  trade  secrecy,   by  definition,  could  not  prohibit  any
development work by someone who did not know the secret.
 On  this basis,  software development was extremely  profitable,
and received considerable investment,  without any prohibition on
independent software development.   But this scheme of things  is
no more.  A change in U.S.: government policy in the early 1980's
stimulated a flood of applications.  Now many have been approved,
and the rate is accelerating.
 Many programmers are unaware of the change and do not appreciate
the  magnitude  of  its effects.   Today the  lawsuits  are  just
beginning.

Absurd patents

 The Patent Office and the courts have had a difficult time  with
computer software.   The Patent Office refused until recently  to
hire  Computer Science graduates as examiners,  and in  any  case
does  not  offer  competitive salaries  for  the  field.   Patent
examiners  are  often ill-prepared to  evaluate  software  patent
applications  to determine if they represent techniques that  are
widely  known  or  obvious   - both  of  which  are  grounds  for
rejection.
 Their  task  is made more difficult because  many  commonly-used
software techniques do not appear in the scientific literature of
computer  science.   Some  seemed too obvious  to  publish  while
others seemed insufficiently general; some were open secrets.
 Computer scientists know many techniques that can be generalized
to widely varying circumstances.   But the Patent Office seems to
believe that each separate use of a technique is a candidate  for
a new patent.  For example,  Apple was sued because the Hypercard
program allegedly violates patent number 4,736,308, a patent that
covers displaying portions of two or more strings together on the
screen   -  effectively,   scrolling  with  multiple  subwindows.
Scrolling and subwindows are well-known techniques, but combining
them is now apparently illegal.
 The  granting  of  a  patent by  the  Patent  Office  carries  a
presumption in law that the patent is valid.   Patents for  well-
known  techniques that were in use many years before  the  patent
application have been upheld by federal courts.   It can be  hard
to prove a technique was well known at the time in question.
 For  example,  the  technique of using exclusive-or to  write  a
cursor  onto  a  screen is both well  known  and  obvious.   (Its
advantage is that another identical exclusive-or operation can be
used  to erase the cursor without damaging the other data on  the
screen.)   This technique can be implemented in a few lines of  a
program, and a clever high school student might well reinvent it.
But  it  is covered by patent number 4,197,590,  which  has  been
upheld twice in court even though the technique was used at least
five years before the patent application.  Cadtrak,  the  company
that  owns this patent,  collects millions of dollars from  large
computer manufacturers.
 English   patents   covering  customary   graphics   techniques,
including airbrushing,  stenciling, and combination of two images
under  control  of a third one,  were recently upheld  in  court,
despite the testimony of the pioneers of the field that they  had
developed  these  techniques years  before.   (The  corresponding
United States patents,  including 4,633,416 and  4,602,286,  have
not yet been tested in court, but they probably will be soon.)
 All  the  major  developers of spreadsheet  programs  have  been
threatened  on the basis of patent 4,398,249,  covering  "natural
order recalc"  - the recalculation of all the spreadsheet entries
that  are  affected by the changes the user  makes,  rather  than
recalculation  in a fixed order.  Currently Lotus alone is  being
sued,  but  a victory for the plaintiff in this case would  leave
the other developers little hope.  The League has found prior art
that may defeat this patent, but this is not assured.
 Nothing protects programmers from accidentally using a technique
that is patented, and then being sued for it.  Taking an existing
program and making it run faster may also make it violate half  a
dozen patents that have been granted, or are about to be granted.
 Even if the Patent Office learns to understand software  better,
the  mistakes  it  is making now will follow  us  into  the  next
century,  unless  Congress  or the Supreme  Court  intervenes  to
declare these patents void.
 However,  this  is  not  the whole  of  the  problem.   Computer
programming is fundamentally different from the other fields that
the patent system previously covered.   Even if the patent system
were  to  operate  "as intended" for  software,  it  would  still
obstruct the industry it is supposed to promote.

What is "Obvious"?

 The  patent  system will not grant or uphold  patents  that  are
judged to be obvious.   However,  the system interprets the  word
"obvious" in a way that might surprise computer programmers.  The
standard   of   obviousness   developed  in   other   fields   is
inappropriate for software.
 Patent  examiners and judges are accustomed to considering  even
small,   incremental  changes  as  deserving  new  patents.   For
example,   the  famous  "Polaroid  vs.   Kodak"  case  hinged  on
differences  in the number and order of layers of chemicals in  a
film   -  differences between the technique Kodak was  using  and
those described by previous,  expired patents.   The court  ruled
that these differences were unobvious.
 Computer scientists solve problems quickly because the medium of
programming  is  tractable.    They  are  trained  to  generalize
solution  principles  from  one problem  to  another.   One  such
generalization is that a procedure can be repeated or subdivided.
Programmers  consider this obvious  - but the Patent  Office  did
not  think  that  it was obvious when it granted  the  patent  on
scrolling multiple strings, described above.
 Cases  such  as this cannot be considered  errors.   The  patent
system  is  functioning  as it was designed to  do   -  but  with
software, it produces outrageous results.

Patenting what is too obvious to publish

 Sometimes  it is possible to patent a technique that is not  new
precisely  because it is obvious  - so obvious that no one  would
have published a paper about it.
 For example,  computer companies distributing the free X  Window
System developed by MIT are now being threatened with lawsuits by
AT&T over patent number 4,555,775,  covering the use of  "backing
store"  in  a  window system that  lets  multiple  programs  have
windows.   Backing store means that the contents of a window that
is temporarily partly hidden are saved in off-screen  memory,  so
they can be restored quickly if the obscuring window disappears.
 Early window systems were developed on computers that could  not
run two programs at once.  These computers had small memories, so
saving  window  contents was obviously a waste of  scarce  memory
space.  Later, larger multiprocessing computers led to the use of
backing  store,  and to permitting each program to have  its  own
windows.  The combination was inevitable.
 The  technique  of  backing store was used at MIT  in  the  Lisp
Machine   System  before  AT&T  applied  for   a   patent.    (By
coincidence,  the  Lisp Machine also supported  multiprocessing.)
The Lisp Machine developers published nothing about backing store
at the time, considering it too obvious.  It was mentioned when a
programmers' manual explained how to turn it on and off.
 But  this  manual was published one week after the  AT&T  patent
application   -  too  late to count as prior art  to  defeat  the
patent.   So the AT&T patent may stand,  and MIT may be forbidden
to continue using a method that MIT used before AT&T.
 The  result  is  that the dozens of companies  and  hundreds  of
thousands  of  users who accepted the software from  MIT  on  the
understanding  that  it  was free are  now  faced  with  possible
lawsuits.    (They  are  also  being  threatened  with  Cadtrak's
exclusive-or  patent.)  The X Window System project was  intended
to develop a window system that all developers could use  freely.
This public service goal seems to have been thwarted by patents.

Why software is different

 Software systems are much easier to design than hardware systems
of  the same number of components.   For example,  a  program  of
100,000  components  might  be 50,000 lines  long  and  could  be
written by two good programmers in a year.   The equipment needed
for  this costs less than $10,000;  the only other cost would  be
the  programmers' own living expenses while doing the  job.   The
total  investment  would  be  less  than  a  $100,000.   If  done
commercially in a large company,  it might cost twice  that.   By
contrast,   an   automobile  typically  contains  under   100,000
components;  it requires a large team and costs tens of  millions
of dollars to design.
 And software is also much cheaper to manufacture:  copies can be
made easily on an ordinary workstation costing under ten thousand
dollars.  To  produce a complex hardware system often requires  a
factory costing tens of millions of dollars.
 Why  is this?   A hardware system has to be designed using  real
components.   They  have  varying  costs;  they  have  limits  of
operation;  they  may be sensitive to temperature,  vibration  or
humidity;  they may generate noise;  they drain power;  they  may
fail either momentarily or permanently.   They must be physically
assembled in their proper places, and they must be accessible for
replacement in case they fail.
 Moreover,  each of the components in a hardware design is likely
to affect the behavior of many others.   This greatly complicates
the  task  of  determining  what  a  hardware  design  will   do:
mathematical modeling may prove wrong when the design is built.
 By  contrast,   a  computer  program  is  built  out  of   ideal
mathematical  objects  whose behavior  is  defined,  not  modeled
approximately, by abstract rules.  When an if-statement follows a
while-statement,  there  is  no  need to study  whether  the  if-
statement  will draw power from the while-statement  and  thereby
distort  its output,  nor whether it could overstress the  while-
statement and make it fail.
 Despite  being built from simple parts,  computer  programs  are
incredibly complex.  The program with 100,000 parts is as complex
as an automobile, though far easier to design.
 While programs cost substantially less to write, market and sell
than automobiles, the cost of dealing with the patent system will
not be less.  The same number of components will, on the average,
involve the same number techniques that might be patented.

The danger of a lawsuit

 Under the current patent system, a software developer who wishes
to follow the law must determine which patents a program violates
and  negotiate  with  each patent holder a license  to  use  that
patent.   Licensing  may  be  prohibitively  expensive,  or  even
unavailable  if  the  patent  is  held  by  a  competitor.   Even
"reasonable" license fees for several patents can add up to  make
a project infeasible.   Alternatively,  the developer may wish to
avoid using the patent altogether; but there may be no way around
it.
 The worst danger of the patent system is that a developer  might
find,  after releasing a product,  that it infringes one or  many
patents.  The resulting lawsuit and legal fees could force even a
medium-size company out of business.
 Worst of all, there is no practical way for a software developer
to  avoid  this danger  - there is no effective way to  find  out
what  patents a system will infringe.   There is a way to try  to
find out  - a patent search  - but searches are unreliable and in
any case too expensive to use for software projects.

Patent searches are prohibitively expensive

 A system with a hundred thousand components can use hundreds  of
techniques  that might already be patented.   Since  each  patent
search costs thousands of dollars, searching for all the possible
points of danger could easily cost over a million.   This is  far
more than the cost of writing the program.
 The costs don't stop there.   Patent applications are written by
lawyers  for  lawyers.   A programmer reading a  patent  may  not
believe that his program violates the patent, but a federal court
may rule otherwise.   It is thus now necessary to involve  patent
attorneys at every phase of program development.
 Yet  this only reduces the risk of being sued later  -  it  does
not eliminate the risk.   So it is necessary to have a reserve of
cash for the eventuality of a lawsuit.
 When a company spends millions to design a hardware system,  and
plans  to  invest tens of millions to manufacture  it,  an  extra
million or two to pay for dealing with the patent system might be
bearable.   However, for the inexpensive programming project, the
same extra cost is prohibitive.  Individuals and small  companies
especially cannot afford these costs.  Software patents will  put
an end to software entrepreneurs.

Patent searches are unreliable

 Even if developers could afford patent searches, these are not a
reliable method of avoiding the use of patented techniques.  This
is   because  patent  searches  do  not  reveal  pending   patent
applications (which are kept confidential by the Patent  Office).
Since it takes several years on the average for a software patent
to be granted, this is a serious problem: a developer could begin
designing  a large program after a patent has been  applied  for,
and  release  the program before the patent  is  approved.   Only
later  will the developer learn that distribution of the  program
is prohibited.
 For example,  the implementors of the widely-used public  domain
data   compression  program  "compress"  followed  an   algorithm
obtained  from the journal "IEEE Computer".   (This algorithm  is
also  used  in  several  popular  programs  for   microcomputers,
including "PKZIP".) They and the user community were surprised to
learn  later that patent number 4,558,302 had been issued to  one
of the authors of the article.  Now Unisys is demanding royalties
for  using this algorithm.   Although the program  "compress"  is
still in the public domain, using it means risking a lawsuit.
 The   Patent  Office  does  not  have  a  workable  scheme   for
classifying  software  patents.    Patents  are  most  frequently
classified  by end results,  such as "converting iron to  steel;"
but  many  patents  cover algorithms whose use in  a  program  is
entirely independent of the purpose of the program.  For example,
a program to analyze human speech might infringe the patent on  a
speedup  in  the Fast Fourier Transform;  so might a  program  to
perform symbolic algebra (in multiplying large numbers);  but the
category to search for such a patent would be hard to predict.
 You might think it would be easy to keep a list of the  patented
software  techniques,  or even simply  remember  them.   However,
managing  such a list is nearly impossible.   A list compiled  in
1989  by  lawyers specializing in the field omitted some  of  the
patents mentioned in this paper.

Obscure Patents

 When you imagine an invention,  you probably think of  something
that could be described in a few words, such as "a flying machine
with fixed,  curved wings" or "an electrical communicator with  a
microphone  and  a  speaker".   But most  patents  cover  complex
detailed processes that have no simple descriptions  - often they
are  speedups  or  variants  of  well-known  processes  that  are
themselves complex.
 Most  of these patents are neither obvious nor  brilliant;  they
are obscure.   A capable software designer will "invent"  several
such improvements in the course of a project.  However, there are
many avenues for improving a technique,  so no single project  is
likely to find any given one.
 For  example,  IBM has several patents (including patent  number
4,656,583)  on workmanlike,  albeit complex,  speedups for  well-
known  computations performed by optimizing  compilers,  such  as
register coloring and computing the available expressions.
 Patents are also granted on combinations of techniques that  are
already widely used.   One example is IBM patent 4,742,450, which
covers  "shared copy-on-write segments."  This  technique  allows
several  programs  to  share  the  same  piece  of  memory   that
represents information in a file; if any program writes a page in
the file, that page is replaced by a copy in all of the programs,
which  continue to share that page with each other but no  longer
share with the file.
 Shared  segments  and  copy-on-write have been  used  since  the
1960's;  this  particular  combination may be new as  a  specific
feature,  but is hardly an invention.   Nevertheless,  the Patent
Office thought that it merited a patent,  which must now be taken
into account by the developer of any new operating system.
 Obscure patents are like land mines:  other developers are  more
likely  to reinvent these techniques than to find out  about  the
patents,  and then they will be sued.  The chance of running into
any one of these patents is small,  but they are so numerous that
you cannot go far without hitting one.  Every basic technique has
many  variations,  and  a small set of basic  techniques  can  be
combined  in  many ways.   The patent office has now  granted  at
least  2000 software patents  - no less than 700 in  1989  alone,
according to a list compiled by EDS.   We can expect the pace  to
accelerate.  In ten years, programmers will have no choice but to
march on blindly and hope they are lucky.

Patent licensing has problems, too

 Most large software companies are trying to solve the problem of
patents  by  getting patents of their own.   Then  they  hope  to
cross-license with the other large companies that own most of the
patents, so they will be free to go on as before.
 While this approach will allow companies like  Microsoft,  Apple
and IBM to continue in business,  it will shut new companies  out
of  the field.   A future start-up,  with no patents of its  own,
will be forced to pay whatever price the giants choose to impose.
That price might be high:  established companies have an interest
in  excluding  future  competitors.  The  recent  Lotus  lawsuits
against Borland and the Santa Cruz Operation (although  involving
an extended idea of copyright rather than patents) show how  this
can work.
 Even  the giants cannot protect themselves with  cross-licensing
from companies whose only business is to obtain exclusive  rights
to patents and then threaten to sue.   For example,  consider the
New   York-based   Refac  Technology   Development   Corporation,
representing  the  owner of the "natural  order  recalc"  patent.
Contrary  to  its name,  Refac does not develop  anything  except
lawsuits   - it has no business reason to join a  cross-licensing
compact.   Cadtrak, the owner of the exclusive-or patent, is also
a litigation company.
 Refac  is demanding five percent of sales of all  major  spread-
sheet  programs.   If a future program infringes on  twenty  such
patents   -  and this is not unlikely,  given the  complexity  of
computer programs and the broad applicability of many patents   -
the combined royalties could exceed 100% of the sales price.  (In
practice, just a few patents can make a program unprofitable.)

The fundamental question

 According to the Constitution of the United States,  the purpose
of patents is to "promote the progress of science and the  useful
arts."  Thus,  the  basic question at issue is  whether  software
patents,  supposedly  a method of encouraging software  progress,
will truly do so, or will retard progress instead.
 So  far  we have explained the ways in which patents  will  make
ordinary  software  development  difficult.    But  what  of  the
intended  benefits of patents:  more invention,  and more  public
disclosure  of inventions?   To what extent will  these  actually
occur in the field of software?
 There  will be little benefit to society from  software  patents
because  invention  in software was  already  flourishing  before
software  patents,  and  inventions were  normally  published  in
journals for everyone to use.  Invention flourished so  strongly,
in  fact,  that  the same inventions were often found  again  and
again.

In software, independent reinvention is commonplace

 A patent is an absolute monopoly;  everyone is forbidden to  use
the patented process,  even those who reinvent it  independently.
This  policy  implicitly  assumes that inventions  are  rare  and
precious, since only in those circumstances is it beneficial.
 The  field of software is one of constant reinvention;  as  some
people  say,  programmers throw away more "inventions" each  week
than other people develop in a year.  And the comparative ease of
designing large software systems makes it easy for many people to
do  work  in  the field.  A programmer solves  many  problems  in
developing  each  program.   These  solutions are  likely  to  be
reinvented   frequently  as  other  programmers  tackle   similar
problems.
 The  prevalence  of independent reinvention  negates  the  usual
purpose of patents.  Patents are intended to encourage inventions
and,  above all,  the disclosure of inventions.   If a  technique
will be reinvented frequently, there is no need to encourage more
people to invent it;  since some of the developers will choose to
publish  it  (if publication is merited),  there is no  point  in
encouraging  a  particular inventor to publish it  - not  at  the
cost of inhibiting use of the technique.

Overemphasis of inventions

 Many analysts of American and Japanese industry have  attributed
Japanese  success at producing quality products to the fact  that
they emphasize incremental improvements,  convenient features and
quality rather than noteworthy inventions.
 It is especially true in software that success depends primarily
on  getting the details right.   And that is most of the work  in
developing  any  useful  software  system.    Inventions  are   a
comparatively unimportant part of the job.
 The idea of software patents is thus an example of the  mistaken
American preoccupation with inventions rather than products.  And
patents will encourage this mistaken focus,  even as they  impede
the development work that actually produces better software.

Impeding innovation

 By  reducing  the  number of  programmers  engaged  in  software
development,  software  patents will actually impede  innovation.
Much software innovation comes from programmers solving  problems
while  developing  software,  not from  projects  whose  specific
purpose is to make inventions and obtain patents. In other words,
these innovations are byproducts of software development.
 When  patents make development more difficult,  and cut down  on
development projects,  they will also cut down on the  byproducts
of development - new techniques.

Could patents ever be beneficial?

 Although software patents in general are harmful to society as a
whole,  we  do  not claim that every single  software  patent  is
necessarily harmful.  Careful study might show that under certain
specific  and narrow conditions (necessarily excluding  the  vast
majority of cases) it is beneficial to grant software patents.
 Nonetheless,  the  right  thing to do now is  to  eliminate  all
software patents as soon as possible, before more damage is done.
The careful study can come afterward.
 Clearly  software  patents  are not urgently  needed  by  anyone
except patent lawyers.   The pre-patent software industry had  no
problem  that  was solved by patents;  there was no  shortage  of
invention, and no shortage of investment.
 Complete  elimination of software patents may not be  the  ideal
solution,  but it is close, and is a great improvement.  Its very
simplicity  helps  avoid a long delay while  people  argue  about
details.
 If  it  is ever shown that software patents  are  beneficial  in
certain exceptional cases,  the law can be changed again at  that
time   -  if  it is important enough.   There  is  no  reason  to
continue the present catastrophic situation until that day.

Software patents are legally questionable

 It  may come as a surprise that the extension of patent  law  to
software is still legally questionable.   It rests on an  extreme
interpretation  of  a  particular 1981  Supreme  Court  decision,
"Diamond vs.  Deihr".  (See "Legally Speaking" in "Communications
of the ACM", August 1990.)
 Traditionally,  the  only  kinds  of  processes  that  could  be
patented  were  those  for  transforming  matter  (such  as,  for
transforming  iron into steel).   Many other activities which  we
would  consider  processes were entirely excluded  from  patents,
including business methods,  data analysis,  and "mental  steps."
This was called the "subject matter" doctrine.
 "Diamond vs. Deihr" has been interpreted by the Patent Office as
a  reversal of this doctrine,  but the court did  not  explicitly
reject  it.  The case concerned a process for curing rubber  -  a
transformation of matter.   The issue at hand was whether the use
of  a  computer program in the process was enough  to  render  it
unpatentable,  and the court ruled that it was not.   The  Patent
Office  took this narrow decision as a green light for  unlimited
patenting  of  software  techniques,  and even  for  the  use  of
software to perform specific well-known and customary activities.
 Most  patent lawyers have embraced the change,  saying that  the
new  boundaries  of patents should be defined over decades  by  a
series  of expensive court cases.   Such a course of action  will
certainly  be good for patent lawyers,  but it is unlikely to  be
good for software developers and users.

One way to eliminate software patents

 We  recommend the passage of a law to exclude software from  the
domain of patents.   That is to say that,  no matter what patents
might  exist,  they would not cover implementations in  software;
only implementations in the form of hard-to-design hardware would
be covered.   An advantage of this method is that it would not be
necessary  to  classify  patent applications  into  hardware  and
software when examining them.
 Many have asked how to define software for this purpose  - where
the line should be drawn.   For the purpose of this  legislation,
software  should  be  defined by the  characteristics  that  make
software patents especially harmful:

o    Software   is  built  from  ideal  infallible   mathematical
     components, whose outputs are not affected by the components
     they feed into.
     Ideal mathematical components are defined by abstract rules,
     so that failure of a component is by definition  impossible.
     The  behavior  of any system built of  these  components  is
     likewise  defined by the consequences of applying the  rules
     step by step to the components.

o    Software can be easily and cheaply copied.
     Following this criterion, a program to compute prime numbers
     is  a  piece  of software.   A  mechanical  device  designed
     specifically   to  perform  the  same  computation  is   not
     software,  since  mechanical components have  friction,  can
     interfere with each other's motion,  can fail,  and must  be
     assembled physically to form a working machine.
     Any piece of software needs a hardware platform in order  to
     run.   The software operates the features of the hardware in
     some  combination,  under  a plan.   Our  proposal  is  that
     combining  the  features  in  this  way  can  never   create
     infringement.   If  the hardware alone does not  infringe  a
     patent,  then using it in a particular fashion under control
     of  a  program should not infringe  either.   In  effect,  a
     program is an extension of the programmer's mind,  acting as
     a proxy for the programmer to control the hardware.
     Usually  the hardware is a general purpose  computer,  which
     implies  no particular application.   Such  hardware  cannot
     infringe any patents except those covering the  construction
     of  computers.   Our proposal means that,  when a user  runs
     such  a program on a general purpose  computer,  no  patents
     other than those should apply.
     The  traditional distinction between hardware  and  software
     involves  a complex of characteristics that used to go  hand
     in hand.   Some newer technologies,  such as gate arrays and
     silicon compilers, blur the distinction because they combine
     characteristics   associated  with  hardware   with   others
     associated   with  software.    However,   most   of   these
     technologies  can  be classified  unambiguously  for  patent
     purposes,  either  as  software or as  hardware,  using  the
     criteria above.   A few gray areas may remain, but these are
     comparatively small,  and need not be an obstacle to solving
     the problems patents pose for ordinary software development.
     They will eventually be treated as hardware, as software, or
     as something in between.

Fighting patents one by one

 Until  we succeed in eliminating all patenting of  software,  we
must try to overturn individual software patents.   This is  very
expensive  and can solve only a small part of  the  problem,  but
that is better than nothing.
 Overturning patents in court requires prior art,  which may  not
be easy to find.   The League for Programming Freedom will try to
serve  as a clearing house for this information,  to  assist  the
defendants in software patent suits.   This depends on your help.
If you know about prior art for any software patent,  please send
the information to the League at the address given above.
 If  you  work  on software,  you  can  personally  help  prevent
software  patents by refusing to cooperate in applying for  them.
The details of this may depend on the situation.

Conclusion

 Exempting  software  from  the scope  of  patents  will  protect
software  developers  from  the  insupportable  cost  of   patent
searches,  the  wasteful  struggle to find a way clear  of  known
patents, and the unavoidable danger of lawsuits.
 If  nothing  is  changed,  what is  now  an  efficient  creative
activity  will become prohibitively expensive.   To  picture  the
effects,  imagine if each square of pavement on the sidewalk  had
an  owner,  and  pedestrians required a license to  step  on  it.
Imagine the negotiations necessary to walk an entire block  under
this  system.   That  is what writing a program will be  like  if
software  patents  continue.    The  sparks  of  creativity   and
individualism  that have driven the computer revolution  will  be
snuffed out.

The LPF

 The League for Programming Freedom is a grass-roots organization
of  professors,  students,  businessmen,  programmers  and  users
dedicated  to bringing back the freedom to write  programs.   The
League is not opposed to the legal system that Congress  intended
-  copyright on individual programs.   Our aim is to reverse  the
recent  changes made by judges in response to special  interests,
often explicitly rejecting the public interest principles of  the
Constitution.
 The  League  works to abolish the new monopolies  by  publishing
articles,  talking  with public officials,  boycotting  egregious
offenders,  and in the future may intervene in court  cases.   On
May 24,  1989,  the League picketed Lotus headquarters on account
of  their lawsuits,  and then again on  August  2,  1990.   These
marches stimulated widespread media coverage for the  issue.   We
welcome  suggestions  for other activities,  as well as  help  in
carrying them out.
 Membership dues in the League are $42 per year for  programmers,
managers and professionals;  $10.50 for students; $21 for others.
Please give more if you can.  The League's funds will be used for
filing briefs; for printing handouts, buttons and signs; whatever
will persuade the courts,  the legislators,  and the people.  You
may  not get anything personally for your dues - except  for  the
freedom   to  write  programs.    The  League  is  a   non-profit
corporation,  but not considered a tax-exempt charity.   However,
for those self-employed in software,  the dues can be a  business
expense.
 The League needs both activist members and members who only  pay
their dues.   We also greatly need additional corporate  members;
contact us for information.
 If you have any questions,  please write to the League, phone +1
617 621-7084, or send Internet mail to lpf@uunet.uu.net.

         Jack Larsen, President
         Dean Anderson, Secretary
         Steve Sisak, Treasurer

 Jack Larsen can be contacted at (708) 698-1160;  Fax (708)  698-
6221. The adress is:

    League for Programming Freedom
    1 Kendall Square #143
    P.O.Box 9171
    Cambridge, Massachusetts 02139