[dryfoo@athena.mit.edu: Drink Beer* with a Rich Genius, and Save the World, Too!]

Rick Lathrop RickL at samson.cadr.amis.com
Tue Aug 7 12:47:00 EST 1990

    Date: Fri, 3 Aug 90 00:45:52 EDT
    From: rms at ai.mit.edu

[The US Mail address of the League for Programming Freedom is:]

    1 Kendall Sq #143
    PO Box 9171
    Cambridge MA 02139

    But even better is to pass out League literature to the people you are
    working with--as many of them as possible.

OK, good idea.  I am forwarding your reply around several places.

For the record, The League for Programming Freedom was founded by
Richard Stallman (Emacs inventor and McArthur "Genius" Grant winner),
and includes as board, officers or members: John McCarthy (Lisp inventor
and co-founder of AI); Marvin Minsky (frames inventor and co-founder of
AI);  Patrick Winston (director of the MIT AI Lab); Guy L. Steele, Jr.
(Common Lisp); a list of distinguished individuals too numerous to
mention; and in their footsteps myself (your humble scribe).  We share a
common concern with the legal precedents our profession in this decade
will endow to the next millenium.

			-=*=- Rick Lathrop

p.s. Standard disclaimer:  As always, I speak only for myself, and not
for any of the institutions with which I may be affiliated.

p.p.s. Some of the biologists on some of the forwarded networks may
wonder how issues of software legalism relate to them.  The answer is
that it will have a substantial impact on the programs they will be able
to run, throughout their entire professional careers.

    The first two pages are the invitation to join and membership form.
    We usually print them back-to-back.

    The following two pages are the two position papers, in Texinfo
    format.  To format these for printing, you need TeX plus the Texinfo
    macro package that comes with GNU Emacs.  If you just want to read them,
    you'll find it easy enough to read them without formatting them.

		   Fight "Look and Feel" Lawsuits
	       Join the League for Programming Freedom

    The League for Programming Freedom is an organization of people who
    oppose the attempt to monopolize common user interfaces through "look
    and feel" copyright lawsuits.  Some of us are programmers, who worry
    that such monopolies will obstruct our work.  Some of us are users,
    who want new computer systems to be compatible with the interfaces we
    know.  Some are founders of hardware or software companies.  Some of
    us are professors or researchers, including John McCarthy, Marvin
    Minsky, Guy L. Steele, Jr., and Patrick Winston.

    "Look and feel" lawsuits aim to create a new class of
    government-enforced monopolies broader in scope than ever before.
    Such a system of user-interface copyright would impose gratuitous
    incompatibility, reduce competition, and stifle innovation.

    We in the League hope to prevent these problems by preventing
    user-interface copyright.  The League is not opposed to copyright
    law as it was understood until 1986--copyright on particular
    programs.  Our aim is to stop changes in the copyright system which
    would take away programmers' traditional freedom to write new
    programs compatible with existing programs and practices.

    The League for Programming Freedom will act against the doctrine
    behind look-and-feel suits by any means consistent with the law and
    intellectual liberty.  We will write editorials, talk with public
    officials, file amicus curiae briefs with the courts, and boycott
    egregious offenders.  On May 24th, 1989, we picketed Lotus
    headquarters on account of their lawsuits against competitors,
    stimulating widespread media coverage for the issue.  If you have
    other ideas, please suggest them.

    The League is also opposed to software patents, potentially even more
    dangerous than look-and-feel copyright.  Patents threaten to make
    every design decision in software development a chance for a lawsuit.
    However, there is no way we can get rid of them except by organizing
    to make Congress hear our voice.

    Unless new forms of monopolistic practices arise, these are the only
    issues that the League plans to act on.

    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
    influence the courts, the legislators, and the people.  You won't get
    anything personally for your dues--except for the freedom to write
    programs.  The League is a non-profit corporation, but because it is a
    lobbying organization, your contributions may not be tax-deductible.

    We also accept corporate (nonvoting) members; please phone or write
    for more information.

    The League needs both activist members and members who only pay their

    If you have any questions, please write to the League or phone
    (617) 243-4091.  Or send email to league at prep.ai.mit.edu.

			   Richard Stallman, President
			   Chris Hofstader, Secretary
			   Denis Filipetti, Treasurer
    To join, please send a check and the following information to:

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

    (Overseas, calculate the equivalent in your currency rather than
    writing a check in US dollars.)

    Your name:

    Your address, where we should write to you for elections and such:

    The company you work for, and your position:

    Your phone numbers (home, work or both) and email address, so we can
    contact you for demonstrations or for writing letters.  (If you don't
    want us to contact you for these things, please say so; your support
    as a member is helpful nonetheless.)

    Is there anything about you which would enable your endorsement of the
    LPF to impress the public?  For example, if you are or have been a
    professor or an executive, or have written software that has a good
    reputation, please tell us.

    Would you like to help with LPF activities?

    The corporate charter of the League for Programming Freedom states:

	The purpose of the corporation is to engage in the following

	1. To determine the existence of, and warn the public about
	restrictions and monopolies on classes of computer programs where such
	monopolies prevent or restrict the right to develop certain types of
	computer programs.

	2. To develop countermeasures and initiatives, in the public interest,
	effective to block or otherwise prevent or restrain such monopolistic
	activities including education, research, publications, public
	assembly, legislative testimony, and intervention in court proceedings
	involving public interest issues (as a friend of the court).

	3. To engage in any business or other activity in service of and
	related to the foregoing paragraphs that lawfully may be carried on
	by a corporation organized under Chapter 180 of the Massachusetts
	General Laws.

    The officers and directors of the League will be elected annually by
    the members.
    \input texinfo
    @setfilename look-and-feel

    @center @titlefont{Against User Interface Copyright}
    @sp 1
    @center The League for Programming Freedom

    In the past few years, a few companies have begun to sue others
    for following what used to be standard practice in the computer
    field: implementing programs that are compatible with the competition.
    These plaintiffs claim to have a copyright on the user interface
    of a program---something unheard of before 1986.

    In June 1990, Lotus won a suit against Paperback Software, a small
    company that implemented a spreadsheet that talks to the user in the
    same terms used by 1-2-3; they immediately went on to sue Borland about
    Quattro, a spreadsheet whose usual interface has only a few similarities
    to 1-2-3, claiming that these similarities in keystroke sequences and/or
    the ability to customize the interface to emulate 1-2-3 are enough to

    Even more ominously, Apple Computer has sued Microsoft and Hewlett
    Packard for implementing a window system whose displays partially
    resemble those of the Macintosh system.  Subsequently Xerox sued Apple
    for implementing the Macintosh system, which derives some general
    concepts from the earlier Xerox Star system.  The Xerox lawsuit was
    dismissed because of the length of time that had elapsed since the
    release of the Macintosh system, but a monopoly of unprecedented scope
    could still result from this suit if the Xerox appeal is successful.

    @heading What Is a User Interface?

    The user interface of a program is the way in which you communicate
    with it.  Other machines also have user interfaces.  For example, the user
    interface of a typewriter is a collection of keys corresponding to
    letters, digits, and punctuation, and arranged in a well-known order. 
    The user interface of a car includes a steering wheel for turning and
    pedals to speed up and slow down, plus a lever to signal turns, etc. 

    In the case of a machine which is a computer program, the interface
    includes that of the computer---its keyboard, screen and mouse---plus
    those aspects specific to the program.  Those typically include the
    choice of commands, menus and programming language, and the way your
    data is presented on the screen.  

    User interface copyright would mean a monopoly on a user interface. 
    In the example of the typewriter, this would mean that each
    manufacturer would have to arrange the keys in a different order.  

    @heading The Purpose of Copyright

    In any discussion of what copyright law ought to mean, we must start
    by noting its purpose.

    In the United States, the Constitution says that the purpose is to
    ``promote the progress of science and the useful arts.''  Conspicuously
    absent is any hint of intention to enrich copyright holders to the
    detriment of the users of copyrighted works.

    The Supreme Court made the reason for this absence explicit, stating in
    @cite{Fox Film vs. Doyal} that ``The sole interest of the United States
    and the primary object in conferring the [copyright] monopoly lie in the
    general benefits derived by the public from the labors of authors.''  

    In other words, since copyright is a government-imposed monopoly,
    which interferes with the freedom of the public in a significant way,
    it is justified only if it helps the public more than it costs the

    The spirit of individual freedom must, if anything, incline us even
    less to accept such a monopoly.  So if either the Supreme Court or the
    principle of freedom is our guide, we have to ask: what value does
    user interface copyright offer the public---and what price would we
    have to pay for it?

    According to Infoworld magazine (mid January 1989), computer users in
    general have considered this question and reached a consensus: they
    expect user interface copyright to be harmful for them.  If we believe
    that the users should determine how their interests are to be served,
    the issue is already settled.  But so as not to take their word for it,
    let's now investigate how much good and harm user interface copyright
    would do in various ways.

    @heading Is More Incentive Needed?

    The developers of the Star, the Macintosh system, 1-2-3 and dBase claim
    that without interface copyright there would be insufficient incentive
    to develop such products.  This is disproved by their own actions.

    Until a few years ago, user interface copyright was unheard of.  The
    entire development of the computer industry took place under a system
    where imitating a user interface was standard practice, and lawful.  And
    it was under this system that today's plaintiffs made their decisions to
    develop their products.  When faced with the choice in actuality, these
    developers decided that they did, indeed, have ``enough incentive''.

    Everyone was free to imitate these interfaces, but this did not prevent
    most of them from being successful and producing a large return on the
    investment.  In fact, they were so successful that they became de-facto
    standards.  (The Xerox Star was not successful, but was not imitated;
    users simply did not like it.)

    Even supposing that interface copyright would increase the existing
    incentive, this does not mean that it will lead to much additional
    improvement in user interfaces.  The existing incentive is so great that
    it may well suffice to motivate everyone who has an idea worth
    developing.  Then the change would only increase the price of these
    improvements.  Once you suck a bottle dry, more suction won't get more
    out of it.

    @heading ``Look and Feel'' Will Not Protect Small Companies

    The proponents of user interface copyright claim that it would protect
    small companies from being wiped out by large competitors.

    One problem with this idea is that it won't work.  It is no coincidence
    that today's interface copyright plaintiffs are large, established
    companies.  The effect of user interface copyright is crushing when the
    interface is widely known---an effective standard.  However, a small
    company is vulnerable when their product is little used, and its
    interface is little known.  In this situation, user interface copyright
    won't make much difference.

    Thus, imagine that a small company with 10,000 customers is afraid that
    a large company will produce a compatible product and use their other
    advantages to take over the market.  The large company may believe there
    is a potential market of a million users that the small company has not
    reached.  Suppose that the small company tries to stop this with
    user interface copyright, forcing the large company to make the new
    product incompatible.  What effect will this have?

    Not much.  Probably only 20,000 potential customers already know the
    interface used by the small company.  The other 970,000 potential
    customers will see no disadvantage in the incompatibility with a product
    they have never learned to use.  So they will buy from the large company

    What's more, the interface copyright tactic will begin to backfire for
    the small company once the large company's product becomes an effective
    standard.  Then even people who know about the small company and have
    some reason to prefer them will be likely to choose the standard
    interface instead.  Now the small company will need to offer a
    compatibility mode---but, due to user interface copyright, this will not
    be allowed.

    Instead of supporting monopolistic measures, small companies would be
    wiser to rely on their own inherent advantages: large companies have
    high inertia, high overhead, and are more cautious.

    @heading What Will Interface Copyright Cost the Public?

    So much for the value of interface copyright; what about the cost? 
    Computer user interfaces will be less convenient and more incompatible.

    One cost we can be sure of is that future user interfaces will be less
    widely used by developers, because most developers will not be allowed
    to use them.  We will also lose much of the usefulness of the
    important interface concepts of the past decade.  The few systems
    permitted to use them will be more expensive due to the lack of
    competition---a windfall for a few manufacturers, but bad for the
    public at large.  

    But this is not the only cost.  Better interfaces may be hard to think
    of, but it is easy to invent interfaces which are merely different. 
    Interface copyright will surely succeed in encouraging more of this
    sort of ``interface development''.  The result will be greater
    incompatibility between computer systems---exactly what the user does
    not want.

    These ``improved'' interfaces may be slightly better or slightly worse
    if considered abstractly; but for the users who have already learned
    to use one well-known interface, they are inevitably worse, because
    they require retraining.

    Even an intrinsically superior interface may be unacceptable for the
    users due to incompatibility.  For example, the Dvorak keyboard,
    invented several decades ago, enables a typist to type much faster and
    more accurately than is possible with the standard ``qwerty'' keyboard.
    Nonetheless, few people use it.  Already-trained typists don't know how.
    New typists don't learn how, because they want to learn the standard
    layout they can expect to find on most keyboards.

    @heading Diversity in Interfaces is Not Desirable

    Here we can see one of the implicit assumptions behind the system of
    copyright, and why it does not apply to user interfaces.  Copyright
    was designed to encourage diversity; its details work toward this end.
    Diversity is exactly what benefits the public when it comes to novels
    and songs, and the other traditional domains of copyright.  Readers
    want new, different novels to be written so that there are more
    different things to read.  This is indeed a way to promote the art of
    creative writing.  

    But this is not the way to promote the art of programming user
    interfaces.  Computer users regard diversity in interfaces as a price to
    be paid, not as a measure of progress.

    Thus, when proponents of interface copyright say that this will force
    developers to find ways to vary the accepted interfaces, they are saying
    that the users will suffer.

    But that is not the whole of the problem.  A technology cannot fully
    mature without standardization of the modes of use, so that one can
    confidently expect to operate any piece of equipment almost in one's
    sleep.  It is not for nothing that so much effort is devoted to the
    development of industrial standards, including international symbols for
    information that guides users of various systems including automobile
    control panels.  Anything which impedes standardization impedes the
    social penetration of technology.  User interface copyright operates
    directly against the proliferation of computer use.

    @heading Incompatibility Does Not Go Away

    If there had been a 50-year interface copyright for the steering
    wheel, it would have expired not long ago.  During the span of the
    copyright, we would have got cars steered with joysticks, cars steered
    with levers, and cars steered with pedals.  Each car user would have
    had to choose a brand of car to learn to drive, and it would not be
    easy to switch.  

    The expiration of the copyright would have freed manufacturers
    ostensibly to switch to the best of the known interfaces.  In practice
    they would still be unable to do so without forcing all their old
    customers to learn to drive all over again.  It would take decades for
    the country to converge on a single interface, perhaps into the 21st

    @heading Who Invests in the User Interface?

    The plaintiffs like to claim that user interfaces represent large
    investments on their part.  

    In fact, designing the user interface of a computer program is usually a
    small part of the investment in developing the program itself.  The ones
    who do make a large investment in the user interface are the users who
    train to use it.  Users have spent many times more on learning to use
    1-2-3 than Lotus spent to develop the entire program, let alone what
    Lotus spent develop the program's interface per se.

    Therefore, if investment justifies owning the interface, it is the
    users who should be the owners.  And they should be able to permit
    everyone to clone it, as they would prefer to do.  

    @heading Discrimination Against Sharing of Software

    User interface copyright discriminates against freely redistributable
    software, such as freeware, shareware and public domain software.

    For a proprietary program it @emph{may} be possible to license the
    interface, if the owner is willing.  But there is no way to do this for
    programs that are freely redistributable---any means for collecting
    royalties from the users for use of the interface is incompatible with
    redistribution by them.  Thus, in practice, licenses will not be
    available for freely-redistributable software.  The result will be a
    growing body of interface techniques that are allowed in proprietary
    software but forbidden in non-proprietary software.

    This discrimination is harmful because non-proprietary software provides
    several advantages to the public: users can customize it, improve it,
    and study it to learn programming; they can also develop habits of good
    citizenship by lawfully passing on copies to their friends.

    Software developers who choose to encourage redistribution are choosing
    to serve the public fully rather than only themselves.  Today such
    public spirit is scarcer than innovation.  It does not make sense to
    encourage innovation by thwarting public spirit.

    @heading The Fear Factor

    The scope of interface copyright is so wide and vague that it will be
    difficult for any programmer to be sure of being safe from lawsuits. 
    Most programs need an interface, and there is usually no way to design
    an interface except based on the ideas you have seen used elsewhere. 
    Only a great genius would be likely to envision a usable interface
    without a deep resemblance to current practice.  It follows that most
    programming projects will risk an interface infringement suit.  

    The danger will be increased because the actual, de facto scope of
    interface copyright will be wider than supposedly intended.  This is
    due to the practice of intimidation.  

    When offered a choice between paying royalties and being sued, most
    businessmen choose to pay, even if they would probably win the case. 
    They know that customers and investors may avoid them because of the
    suit, so that an eventual victory will come years too late to save
    them from great loss or even bankruptcy.  They speak of suits ``putting
    their money in jail.''  They prefer the certainty of a payment they can
    bear, even if it is unjust.  

    This phenomenon is well known, and some companies take advantage of it
    by threatening to sue when they know they don't have a real case.

    If patents are any guide, intimidation will be widespread in the area of
    interface copyright.  @w{G. Gervaise} Davis (an attorney specializing in the
    field) estimates that 90% of all recent software patents would be
    overturned in court, if anyone dared to challenge them.  These patents
    are part of a strategy of intimidation; they were filed in order to gain
    a position for intimidation.

    @heading Barrier to Evolution

    Despite the high and many-fold social cost of user interface
    copyright, the reader may still feel that it must have some beneficial
    effect on progress in user interfaces, however minuscule.  However,
    interface copyright may actually retard progress, because of the
    evolutionary nature of interface development.  

    Fully fleshed-out user interfaces schemes don't often arise as tours de
    force from the minds of isolated masters.  They result from repeated
    implementations, by different groups, each learning from the successes
    and failures of previous attempts.  For example, the Macintosh interface
    was based on ideas tried previously by Xerox and SRI, and before that by
    the Stanford Artificial Intelligence Laboratory.  The Xerox Star also
    drew on the interface ideas that came from SRI and SAIL.  1-2-3 adapted
    the interface ideas of Visicalc and other spreadsheets.  dBase drew on a
    program developed at the Jet Propulsion Laboratory.

    This evolutionary process resembles the creation of folk art rather
    than the way symphonies, novels or films are made.  The ideas that we
    ought to encourage are most often ideas for small, localized changes
    to what someone else has done.  If each interface has an owner, it
    will be difficult to implement such ideas.  Even assuming the owner
    will license the interface that is to be improved, the inconvenience
    and expense would discourage all but the most determined.  

    @heading Evolution vs. Compatibility

    The careful reader will now notice an apparent contradiction between
    the usefulness of evolutionary growth and the undesirability of
    incompatible changes.  Why aren't the evolutionary changes rejected
    by users who do not want any change?

    To some extent, they are rejected.  For this reason, developers often
    try to satisfy both goals.  They make changes that are
    upward-compatible, or change only a small portion of the well-known

    Thus, on computer keyboards, we now have function keys, arrow keys, a
    delete key and a control key, which typewriters did not have.  But the
    layout of the letters is unchanged.  This is an upward-compatible change.

    When complete upward-compatibility is impossible, developers still strive
    for as much compatibility as is possible given the improvement to be
    made.  This reduces the retraining cost for the given amount of benefit.

    However, such partial changes as this would not be permitted by copyright
    law.  If any significant portion of the new interface were the same as a
    copyrighted interface, the new interface would be illegal.

    @heading What Do Interface Designers Think?

    At the 1989 ACM Conference on Computer-Human Interaction, Professor
    Samuelson of Emory School of Law presented a debate on the legal
    arguments for and against user interface copyright, and then asked the
    attendees---researchers and developers of user interfaces---to fill out
    a survey of their opinion on the subject.

    The respondents overwhelmingly opposed all forms of user interface
    copyright, in most cases by 4 to 1.  When they were asked whether user
    interface copyright would harm or help the field, on a scale from 1 to
    5, the average answer was 1.6.  For the full results, see the May 1990
    issue of the Communications of the ACM.

    The advocates of user interface copyright have a habit of trying to sell
    their scheme as a method of providing better security and income for
    user interface designers.  However, the survey shows that these supposed
    beneficiaries would prefer to be let alone.

    @heading Do You Really Want a User Interface Copyright, Anyway?

    Many organizations talk about aiming to have a major influence in
    shaping the world.  The way to have this influence is to encourage
    others to imitate what you do: if your way of doing things is appealing
    enough to draw the world after you, then you can shape it.

    If, on the contrary, you create obstacles to drive others away from your
    path, eventually they will succeed, leaving you in irrelevant isolation,
    no matter how inspiring your way might otherwise have been.

    For a business, ``locking in'' customers may be profitable for a time.
    But, as the vendors of proprietary operating systems have found out,
    this generates public resentment, and eventually drives customers to try
    to escape.  In the long run, this is not the way to succeed.

    @heading Conclusion

    We have seen that monopolies on user interfaces do not serve the users
    and do not ``promote the progress of science and the useful arts.''  It
    follows that user interfaces ought to be the common property of all, as
    they undisputedly were until a few years ago.

    @heading What We Can Do

    @comment Feel free to delete this section when sending a copy
    @comment to a politician

    @itemize @bullet
    Don't buy from Xerox, Lotus, Apple or Ashton-Tate.  Buy from their
    competitors or especially from the defendants they are suing.

    Don't own stock in these companies.

    Don't develop software to work with the systems made by these companies.

    Port your existing software to competing systems, so that you encourage
    users to switch.

    Above all, don't work for the ``look and feel'' plaintiffs, and don't
    accept contracts from them.

    Join the League for Programming Freedom and participate in further
    activities.  You can phone the League at (617) 243-4091, or send
    electronic mail to @code{league@@prep.ai.mit.edu}, or write to:

    League for Programming Freedom
    1 Kendall Square #143
    P.O. Box 9171
    Cambridge, MA 02139
    @end display

    The League is a grass-roots organization of programmers and users
    dedicated to preserving the freedom to develop software that does what
    users want.  The League opposes software patents and user interface
    copyrights, and advocates a return to the legal system for software that
    existed a decade ago.

    Annual dues for individual members are $42 for employed professionals,
    $10.50 for students, and $21 for others.  We appreciate activists, but
    members who have no free time to contribute are also welcome.

    Tell your friends and colleagues about this issue and how it threatens
    to ruin the computer industry.  Ask them to join the League.

    In the United States, write to Congress.  You can write to your own
    representatives, but it may be even more effective to write to the
    subcommittees that consider such issues:

    House Subcommittee on Intellectual Property
    2137 Rayburn Bldg
    Washington, DC 20515

    Senate Subcommittee on Patents, Trademarks and Copyrights
    United States Senate
    Washington, DC 20510
    @end display

    You can write to your own representatives using the following addresses:

    Senator So and So
    United States Senate
    Washington, DC 20510

    Representative Such and Such
    House of Representatives
    Washington, DC 20515
    @end display

    You can phone senators and representatives at (202) 225-3121.

    In Europe, there is no user interface copyright as of now, but the
    European Commission is proposing to institute it.  Express your
    opposition by writing to:

    Jean-Francois Verstrynge
    DG 3/D/4
    Commission of the European Communities
    200 Rue de la Loi
    1049 Bruxelles
    @end display

    Also write to your own representative to the European Parliament.
    @end itemize

    \input texinfo    @c -*-texinfo-*-
    @comment %**start of header
    @setfilename patents.info
    @settitle Patents draft: @today{}
    @comment %**end of header 

    @sp 7
    @center @titlefont{Against Software Patents}
    @center (draft)
    @sp 2
    @center The League for Programming Freedom

    Software patents threaten to devastate America's computer industry.
    Newly-granted software patents are being used to attack companies such
    as the Lotus Development Corporation and Microsoft for selling programs
    that they have independently developed.  Soon new companies may be
    barred from entering the software arena, because the cost of licensing
    the dozens of patents necessary for a major program will make such a
    project economically impossible.

    As programmers, we believe that if the United States Patent and
    Trademark Office continues to grant software patents, we will soon be
    effectively forbidden from writing programs that are useful.

    @heading The Patent System and Computer Programs

    The framers of the 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 the use of the invention.  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 let them use it.

    Patents do not cover specific programs: instead, they cover particular
    techniques that are used to build programs, or particular features that
    programs offer.  Once a technique or feature is patented, it may not be
    used in another program without the permission of the
    patent-holder---even if it is implemented in a different way.  Since a
    program typically uses many techniques and provides many features, it
    can infringe many patents at once.

    Until recently, patents were simply not used in the field of software.
    Software developers would copyright individual programs, or make them
    trade secrets.

    Copyright was traditionally understood to cover the particular 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

    On this basis, software development was extremely profitable, and
    received considerable investment, without prohibiting the development of
    new programs by others.

    But this scheme of things is no more.  Software patents became legal in
    the U.S. in 1981, and now enough time has elapsed for numerous patents
    to be approved.

    Many programmers are unaware of the change and do not appreciate the
    magnitude of its effects.  Today the lawsuits are just beginning.

    @heading Absurd Patents

    The Patent Office and the courts have had a very difficult time with
    computer software.  The Patent Office refuses 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
    which have been previously used or are 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, others seemed
    insufficiently general.  Complicated assemblages of techniques have
    often been kept secret.

    And what is obvious to a programmer is frequently not obvious to a
    patent examiner, many of whom view innovations in computer science the
    same way as they see innovations in chemistry or biology.  Computer
    scientists know many techniques that can be generalized to widely
    varying circumstances.  Based on patents that have been awarded, the
    Patent Office seems to believe that each separate use of a technique is
    a candidate for a patent.

    For example, Apple has been sued because the Hypercard program violates
    patent number 4,736,308, a patent that describes nested scrollable
    objects: windows that can scroll, containing tables that can
    individually scroll, containing items that can individually scroll.
    These three types of scrolling were all in use at the time that patent
    number 4,736,308 was applied for, but combining them is now illegal.

    Many well-known and widely used techniques have been patented.
    Unfortunately, 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 for more than 10 years before the patent was
    granted have been upheld by federal courts.

    For example, the technique of using exclusive-or to write a cursor onto
    a screen is well known, and has been used for decades.  (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 used in just a few lines of program, and a clever high
    school student might well reinvent it.  But this, as well as other
    important graphics techniques, is covered by patent number 4,197,590,
    which has been upheld twice in court.

    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.)

    Currently all companies who have developed spreadsheet programs are
    being sued because of a 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.  This technique is very similar to the old artificial
    intelligence techniques of antecedent reasoning and constraint
    propagation, but we cannot rely on the courts to overturn the patent on
    these grounds.

    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 them void.

    However, this is not the extent of the problem.  Computer programming is
    fundamentally different from the other fields that the patent system
    previously covered.  As a result, even if the patent system were fixed
    to operate ``as intended'' for software, it would still largely wipe out
    the industry it is ostensibly designed to encourage.

    @heading 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 a hundred thousand
    components might be fifty thousand lines long and could be written by
    two good programmers in a year.  The equipment needed for this costs
    less than ten thousand dollars; the only other cost would be the
    programmers' own living expenses while doing the job.  The total
    investment would be less than a hundred thousand dollars.  If done
    commercially in a large company, it might cost twice that.  By contrast,
    an automobile typically contains under a hundred thousand 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 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 inserted in their place in the
    machinery, and it must be possible to gain access to them to test or
    replace them.

    Moreover, each of the components in a hardware design is likely to
    affect the behavior of many others.  Therefore, is it very hard to
    figure out 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 merely modeled approximately, by
    abstract rules.  When you write an if-statement after a while-statement,
    you don't have to worry that the if-statement will draw power from the
    while-statement and thereby distort its output, nor that it will
    overstress the while-statement and make it fail.

    Despite the fact that they are built from simple parts, computer
    programs are incredibly complex.  The program with fifty thousand lines
    probably has a hundred thousand parts, making it 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 is not less.
    The same number of components will, in general, be likely to involve the
    same number of possibly-patented techniques.

    @heading What Is ``Obvious''?

    The patent system will not grant or uphold patents that are judged to be
    ``obvious.''  However, the standard of obviousness that the patent
    system has developed in other fields is inappropriate to the software

    Patent examiners are accustomed to considering even small, incremental
    changes as deserving new patents.  For example, the famous
    @cite{Polaroid vs.@: Kodak} case turned 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 far faster than people in other
    disciplines, because the medium of programming is more tractable.  So
    they are trained to generalize solution principles from one problem to
    another.  One such generalization is that a procedure can be repeated
    within itself, a process known as nesting.  Nesting in software is
    obvious to computer programmers---but the Patent Office did not think
    that it was obvious when it granted the patent on nested scrolling, for
    which Apple was sued.

    Cases such as this cannot be considered errors.  The patent system is
    functioning in software just as it does in other fields---but with
    software, the result is outrageous.

    @heading 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 saw a point in writing
    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''.  This
    technique is used when there are overlapping windows; the contents of a
    window that is partly hidden are saved in off-screen memory, so they can
    be put back quickly on the screen if the obscuring window disappears (as
    often happens).

    In fact, the technique of backing store was used in an earlier MIT
    project, the Lisp Machine System, before AT&T applied for the patent.
    But the Lisp Machine developers did not publish anything mentioning the
    use of backing store
    until the
    programmers' reference manual was written some years later.
    They expected that any window system developer would have the same idea,
    given that the memory of the computer was large enough to make the idea
    practical.  (Earlier window systems, such as those at Xerox, did not use
    backing store because the computers in use had insufficient memory space
    to spare any for this purpose.)

    Without a publication, the use of backing store in the Lisp Machine
    System may not count as prior art to defeat the patent.  So the AT&T
    patent may be enforceable, 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. at footnote{They are being
    threatened by Cadtrak as well.}  The X Windows Project was intended to
    develop a window system that all developers could use freely.  Because
    of software patents, this public service goal seems to have been

    @heading The Danger of a Lawsuit

    Under the current patent system, a software developer who wishes to
    follow the law must determine which patents his program violates and
    negotiate with each patent holder a license to use that patent.
    Licensing may be prohibitively expensive, as in the case when the patent
    is held by a competitor.  Even ``reasonable'' license fees for several
    patents can add up to make a project unfeasible.  Alternatively, the
    developer may wish to avoid using the patent altogether; unfortunately,
    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 such searches are unreliable and in any case too expensive to
    use for software projects.

    @heading Patent Searches Are Prohibitively Expensive

    In a system with a hundred thousand components, there can easily be
    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.

    But 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 such involvement 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.

    In particular, individuals and small companies cannot afford these
    costs.  Software patents will put an end to software entrepreneurs.

    @heading Patent Searches Are Unreliable

    Even if companies could afford the heavy cost of patent searches, they
    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 patent to be
    granted, this is a serious problem: a company 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 that company
    find out whether its profits will be confiscated.

    For example, the implementors of the widely-used public domain program
    @code{compress} followed an algorithm obtained from the journal,
    @cite{IEEE Computer}.  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 is still in the public domain,
    using it means risking a lawsuit.  And implementing the algorithms
    found in the journals is no longer safe.

    In addition, the Patent Office does not have a workable scheme for
    classifying software patents.  Patents are most frequently classified by
    the activity they are used in, 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 in practice.  The patent office has now granted
    more than 2000 software patents.  In 1989 alone, 700 patents were
    issued.  We can expect the pace to accelerate.

    When you think of inventions, you probably call to mind revolutionary
    inventions such as the telephone or magnetic core memory.  This is not
    the standard that the patent system uses, however.  What we would
    consider a minor cleverness or variation or combination of existing
    techniques, they consider patentable.  This leads to a profusion of
    obscure patents.

    Any capable software designer will ``invent'' several such
    improvements in the course of a project, and will say that they are
    straightforward---hardly inventions at all.  However, the number of
    avenues for such improvement is very large, so no single project is
    likely to find any given one.  Therefore, the Patent Office is not
    likely to classify them as obvious.  As a result, IBM has several
    patents (including 4,656,583) on certain fairly straightforward,
    albeit complex, speedups for well-known computations performed by
    optimizing compilers, such as computing the available expressions and
    register coloring.

    Patents are also granted on combinations of techniques that are
    already well known and in use.  One example is IBM patent 4,742,450,
    which covers ``shared copy-on-write segments.''  This is a technique
    that 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 are very old techniques; this
    particular combination may be new as an advertised 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.

    These sorts of patents are like land mines: your chances of running into
    any one of them are small, but soon there will be thousands of them.
    Even today it is hard to keep track of them, and a recent list published
    by lawyers specializing in the field omitted some of these IBM patents.
    In ten years, programmers will have no choice but to march on blindly
    and hope they are lucky.

    @heading 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
    all the other companies and be free to go on as before.

    While this approach will allow companies like Microsoft, Apple and IBM
    to continue business, it will shut future companies out of the
    marketplace.  A future start-up, with no patents of its own, will have
    no choice but to meet whatever conditions the giants choose to impose.
    And that price might be extremely high: companies currently in the
    market have an incentive to keep out 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 a system of industry-wide cross-licensing will not protect the
    software industry from companies whose only business is to buy patents
    and then sue people for license fees.  For example, the New York-based
    REFAC Technology Development Corporation recently bought the rights to
    the ``natural order recalc'' patent, solely so that REFAC could sue
    Lotus, Microsoft and other companies selling spread-sheet programs.
    Contrary to its name, REFAC does not develop anything except lawsuits.
    It has no financial incentive to join a cross-licensing compact.  The
    exclusive-or patent is owned by another such litigation company,
    Cadtrak, which is now suing Western Digital.

    REFAC is demanding five percent of sales of all major spread-sheet
    programs.  If some future program infringes on twenty such patents---and
    this is not at all unlikely, given the complexity of a computer program
    and the specificity of patents that have been recently issued---that
    program will never be used.

    To get a picture of the effects for yourself, imagine if each square of
    pavement on the sidewalk had its owner, and you had to negotiate a
    license to step on it.  Imagine trying to walk the entire length of a
    block under this system.  That is what writing a program will be like if
    software patents are allowed to proliferate.

    @heading 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 whether they will instead hold progress back.

    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.

    @heading In Software, Independent Reinvention Is Commonplace

    A patent is an absolute monopoly; anyone who uses the patented
    technique can be stopped, even if it was independently reinvented.

    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.

    As programmers, we solve many problems each time we develop a program.
    In the past, we would publish the important solutions in journals, and
    forget the rest.  All of these solutions are likely to be reinvented
    frequently as additional people tackle similar problems and try to do a
    good job.

    Today, however, many of these specialized solutions are being patented.
    If you then rediscover it in the course of your work, you are headed for
    a lawsuit that you cannot anticipate.

    Meanwhile, the prevalence of independent reinvention negates the usual
    justification for patents.  Patents are intended to encourage the
    development of 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 it merits publication), there is no point in
    encouraging a particular inventor to do so---and certainly not at such
    a high price.

    @heading Could Patents Ever Be Beneficial?

    Although software patents are in general are harmful to society as a
    whole, we do not claim that every single software patent is necessarily
    harmful.  It is possible, though not certain, that careful study would
    show that under certain specific and narrow conditions (necessarily
    excluding the vast majority of cases) it would be 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.

    This 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.

    Clearly software patents are not urgently needed by anyone except
    patent lawyers.  The pre-patent software industry had no problem that
    patents solved; there was no shortage of invention, and no shortage of

    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.

    @heading Inventions Are Not the Important Thing

    Many observers of US and Japanese industry have noted that one of the
    reasons Japanese are better at producing quality products is that they
    assign greater importance to incremental improvements, convenient
    features and quality rather than to 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 small part
    of the process.

    The idea of software patents is thus an example of the mistaken American
    preoccupation with the big invention rather than the desirable product.
    Patents will reinforce this misdirection of American attention.
    Meanwhile, by presenting obstacles to competition in the important part
    of software development, they will interfere with development of quality

    @heading 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, @cite{Diamond vs.@:
    Deihr}. at footnote{This information comes from a paper being written by
    Professor Samuelson of the Emory School of Law.}

    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.

    @cite{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 did 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 what can be patented should be defined over decades by a
    series of expensive court cases.  Such a course of action will certainly
    be good for the patent lawyers, but it is unlikely to be good for
    software developers and users.

    @heading One Way to Eliminate Software Patents

    We recommend that Congress pass a law that excludes software from the
    domain of patents.  That is to say that, no matter what might be
    patented, the patent 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 judging

    People often ask how it would be possible to define software for this
    purpose---where the line would be drawn.

    For the purpose of this legislation, software should be defined by
    precisely the characteristics that make software patents harmful:

    @itemize @bullet
    Software is built from ideal mathematical components, whose inputs are
    clearly distinguished from their outputs.

    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 to its components.  

    Software can be easily and cheaply copied.
    @end itemize

    Thus, a program which computes prime numbers is a piece of software.  A
    mechanical device designed specifically to perform the same computation
    would not be software, since the mechanical device might fail if it were
    not properly oiled, and would have to be constructed out of physical

    There are areas of design which are between hardware and software in
    some ways: for example, gate arrays and silicon compilers.  These will
    fall on one side or the other of the line that is drawn.  If the line is
    drawn as proposed here, based on the needs of the field, there is reason
    to hope that these will fall on the side that is best.  However, these
    in-between areas are comparatively small, and what really matters is to
    solve the problem for the larger area of ordinary software as surely and
    expeditiously as possible.

    @heading What You Can Do

    One way to help oppose software patents is to join the League for
    Programming Freedom.  The League is a grass-roots organization of
    programmers and users dedicated to preserving the freedom to develop
    software that does what users want.  The League opposes software patents
    and user interface copyrights, and advocates a return to the legal
    system for software that existed a decade ago.

    Annual dues for individual members are $42 for employed professionals,
    $10.50 for students, and $21 for others.  We appreciate activists, but
    members who have no free time to contribute are also welcome.

    You can phone the League at (617) 243-4091, send electronic mail to
    @code{league@@prep.ai.mit.edu}, or write to:

    League for Programming Freedom
    1 Kendall Square #143
    PO Box 9171
    Cambridge, MA 02139
    @end display

    In the United States, another way to help is to write to Congress.  You
    can write to your own representatives, but it may be even more effective
    to write to the subcommittees that consider such issues:

    House Subcommittee on Intellectual Property
    2137 Rayburn Bldg
    Washington, DC 20515

    Senate Subcommittee on Patents, Trademarks and Copyrights
    United States Senate
    Washington, DC 20510
    @end display

    You can write to your own representatives using the following addresses:

    Senator So and So
    United States Senate
    Washington, DC 20510

    Representative Such and Such
    House of Representatives
    Washington, DC 20515
    @end display

    You can phone senators and representatives at (202) 225-3121.

    @heading Conclusion

    Exempting software from the scope of patents will prevent the patent
    system from turning an efficient creative activity into something that
    is prohibitively expensive.  Individual practitioners will be able to
    continue work in their fields without expensive patent searches, the
    struggle to find a way clear of patents, and the unavoidable danger of

    If this change is not made, it is quite possible that the sparks of
    creativity and individualism that have driven the computer revolution
    will be snuffed out.


More information about the Biomatrx mailing list