intellectual property laws

[David G. Hough on validgh]

It would kind of defeat the purpose of much of our work if it were
possible to patent the singular value decomposition or to copyright
the calling sequence of the BLAS (level 1,2, or 3).  Under traditional
intellectual property laws neither of these would be possible;
you could patent a piece of hardware that incorporated singular
value decomposition in its workings or you could copyright a particular
implementation of the BLAS conforming to the calling sequence.

There are some organizations that believe that the traditional laws
are inadequate and they have had some success in extending them
judicially.  I think this is a bad trend; fortunately the recent
patent victory obtained by one of the early semiconductor investigators
may force Congress to re-examine a number of aspects of our current
intellectual property laws and perhaps improve them.  Or make them
worse.

The League for Programming Freedom is trying to influence legislators
to return intellectual property laws to their traditional basis.
Richard Stallman has prepared the following summary of the issues
and the position of the League; if you have not thought about these
issues before, I would encourage you to do so.  
The time for influencing legislators may soon be very ripe.
However I don't intend to carry
on an extended discussion of intellectual property laws in this
mailing list.  

> From: uunet!ai.mit.edu!rms (Richard Stallman)
> Date: Mon, 24 Sep 90 18:53:02 -0400

> Here is some information about the League for Programming Freedom.
> 
> 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
> 		 (Version of August 7, 1990)
> 
> 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, such as
> Richard P. Gabriel.  Some of us are professors or researchers,
> including John McCarthy, Marvin Minsky, Guy L. Steele, Jr., Robert S.
> Boyer 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, and then again on August 2,
> 1990.  These marches stimulate 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
> dues.
> 
> If you have any questions, please write to the League or phone
> (617) 243-4091.  Or send Internet mail to leagueaprep.ai.mit.edu.
> 
> 		       Richard Stallman, President
> 		       Chris Hofstader, Secretary
> 		       Steve Sisak, 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
> 
> (Outside the US, please send a check in US dollars from a bank with
> connections to the US, to save us check cashing fees.)
> 
> 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
>     activities:
> 
>     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
> asetfilename look-and-feel
> 
> acenter atitlefont{Against User Interface Copyright}
> asp 1
> acenter (September 24, 1990)
> asp 1
> acenter The League for Programming Freedom
> 
> In June 1990, Lotus won a copyright infringement suit against Paperback
> Software, a small company that implemented a spreadsheet that obeys the
> same keystroke commands used in Lotus 1-2-3.  Paperback was not accused
> of copying code from 1-2-3---only of supporting compatible user
> commands.  Such imitation was common practice until unexpected court
> decisions in recent years extended the scope of copyright law.
> 
> Within a week, Lotus went on to sue Borland over Quattro, a spreadsheet
> whose usual interface has only a few similarities to 1-2-3.  Lotus
> claims that these similarities in keystroke sequences and/or the ability
> to customize the interface to emulate 1-2-3 are enough to infringe.
> 
> 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.  These suits try to broaden the Lotus
> decision and establish copyright on a large class of user interfaces.
> The Xerox lawsuit was dismissed because of a technicality; but if their
> planned appeal succeeds, a monopoly of unprecedented scope could still
> result.
> 
> And Ashton-Tate has sued Fox Software for implementing a database
> program that accepts the same programming language used in dBase.  This
> is a radical demand, but in the current judicial climate, the threat
> cannot be dismissed.
> 
> While this paper addresses primarily the issue of copyright on specific
> user interfaces, most of the arguments apply with added force to any
> broader monopoly.
> 
> aheading What Is a User Interface?
> 
> A user interface is what you have to learn to operate a machine.  The
> user interface of a typewriter is the layout of the keys.  The user
> interface of a car includes a steering wheel for turning, pedals to
> speed up and slow down, a lever to signal turns, etc.
> 
> When the machine is a computer program, the interface includes that of
> the computer---its keyboard, screen and mouse---plus those aspects
> specific to the program.  These typically include the commands, menus,
> programming languages, and the way data is presented on the screen.
> 
> A copyright on a user interface means a government-imposed monopoly on
> its use.  In the example of the typewriter, this would mean that each
> manufacturer would be forced to arrange the keys in a different layout.
> 
> aheading The Purpose of Copyright
> 
> 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
> acite{Fox Film vs.a: 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 the benefit to the public exceeds the cost
> to the public.  
> 
> The spirit of individual freedom must, if anything, incline us against
> monopoly.  Following either the Supreme Court or the principle of
> freedom, the fundamental question is: what value does user interface
> copyright offer the public---and what price would we have to pay for it?
> 
> aheading Reason #1: More Incentive Is Not 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 1986, user interface copyright was unheard of.  The computer
> industry developed under a system where imitating a user interface was
> both standard practice and lawful.  Under this system, today's
> plaintiffs made their decisions to develop their products.  When faced
> with the choice in actuality, they decided that they did, indeed, have
> ``enough incentive''.
> 
> Even though competitors were free to imitate these interfaces, this did
> not prevent most of the original products from being successful and
> producing a large return on the investment.  In fact, they were so
> successful that they became ai{de facto} standards.  (The Xerox Star was
> a failure due to poor marketing even though nothing similar existed.)
> 
> Even if interface copyright would increase the existing incentive,
> additional improvements in user interfaces would not necessarily result.
> Once you suck a bottle dry, more suction won't get more out of it.  The
> existing incentive is so great that it may well suffice to motivate
> everyone who has an idea worth developing.  Extra incentive, at the
> public's expense, will only increase the price of these developments.
> 
> aheading Reason #2: ``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.  Yet look
> around: today's interface copyright plaintiffs are large, established
> companies.  User interface copyright is crushing when the interface is
> an effective standard.  However, a small company is vulnerable when its
> product is little used, and its interface is little known.  In this
> situation, user interface copyright won't help the small company much.
> 
> Imagine a small company with 10,000 customers: a large company may
> believe there is a potential market of a million users, not reached by
> the small company, for a similar product.  The large company will try to
> use its marketing might to reach them before the small company can.
> 
> User interface copyright won't change this outcome.  Forcing the large
> company to develop an incompatible interface will have little effect on
> the majority of potential customers---those who have not learned the
> other interface.  They will buy from the large company anyway.
> 
> What's more, interface copyright will work against the small company if
> the large company's product becomes an effective standard.  Then new
> customers will have an additional reason to prefer the large company.
> To survive, the small company will need to offer compatibility with this
> standard---but, due to user interface copyright, it will not be allowed
> to do so.
> 
> Instead of relying upon monopolistic measures, small companies are
> most successful when they rely on their own inherent advantages:
> agility, low overhead, and willingness to take risks.
> 
> aheading Reason #3: Diversity in Interfaces is Not Desirable
> 
> The Copyright system was designed to encourage diversity; its details
> work toward this end.  Diversity is the primary goal when it comes to
> novels, songs, and the other traditional domains of copyright.  Readers
> want to read novels they have not yet read.
> 
> But diversity is not the goal of interface design.  Computer users want
> consistency in interfaces because this promotes ease of use.  Thus, by
> standardizing street signs and symbols on automobile dashboards, we have
> made it possible for any driver in the world to operate any car with
> virtually no instruction.  Incompatibility in interfaces is a price to
> be paid when worthwhile, not a benefit.
> 
> Significantly 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 this sort of ``interface
> development''.  The result will be gratuitous incompatibility.
> 
> aheading Reason #4: Meaningful Competition Will Be Reduced
> 
> Under the regime of interface copyright, there will be no compatible
> competition for established products.  For a user to switch to a
> different brand will require retraining.
> 
> But users don't like to retrain, not even for a significant improvement.
> For example, the Dvorak keyboard layout, invented several decades ago,
> enables a typist to type faster and more accurately than is possible
> with the standard ``QWERTY'' layout.  Nonetheless, few people use it.
> Even new typists don't learn Dvorak, because they want to learn the
> layout used on most typewriters.
> 
> Alternative products that require such an effort by the consumer are not
> effective competition.  The monopoly on the established interface will
> yield in practice a monopoly on the functionality accessed by it.  This
> will cause higher prices and less technological advancement---a windfall
> for lucky businesses, but bad for the public at large.
> 
> aheading Reason #5: 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 to switch
> to the best of the known interfaces.  But if Ford cars were steered with
> wheels and General Motors were steered with pedals, neither company
> could change interface without abandoning their old customers.  It would
> take decades to converge on a single interface.
> 
> aheading Reason #6: Users Have Invested More Money Than Developers
> 
> The plaintiffs like to claim that user interfaces represent large
> investments on their part.  
> 
> In fact, the effort spent designing the user interface of a computer
> program is usually small compared to the cost of developing the
> program itself.  The people who make a large investment in the user
> interface are the users who train to use it.  Users have spent much
> more time and money learning to use 1-2-3 than Lotus spent developing
> the entire program, let alone what Lotus spent develop the program's
> interface aemph{per se}.
> 
> Thus, if investment justifies ownership, it is the users who should be
> the owners.  The users should be allowed to decide---in the
> marketplace---who may use it.  According to acite{Infoworld} (mid
> January 1989), computer users in general expect user interface copyright
> to be harmful.
> 
> aheading Reason #7: Discrimination Against Software Sharing
> 
> User interface copyright discriminates against freely redistributable
> software, such as freeware, shareware and public domain software.
> 
> Although it aemph{may} be possible to license an interface for a
> proprietary program, if the owner is willing, these licenses require
> payment, usually per copy.  There is no way to collect this payment for
> a freely redistributable program.  The result will be a growing body of
> interfaces that are barred to non-proprietary software.
> 
> Authors of these programs donate to the public the right to share them,
> and sometimes also to study and change their workings.  This is a public
> service, and one less common than innovation.  It does not make sense to
> encourage innovation of one sort with means that bar donation of another
> sort.
> 
> aheading Reason #8: Copyright Will Be a Tool For Extortion
> 
> The scope of interface copyright is so vague and potentially wide 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 spirit of ``Millions for defense, but not a cent for tribute'' is
> little honored in business today.  Customers and investors often avoid
> companies that are targets of suits; an eventual victory may come years
> too late to prevent great loss or even bankruptcy.  Therefore, when
> offered a choice between paying royalties and being sued, most
> businesses pay, even if they would probably win.
> 
> Since this tendency is well known, companies often take advantage of it
> by filing or threatening suits they are unlikely to win.  As long as any
> interface copyright exists, this form of extortion will broaden its
> effective scope.
> 
> aheading Reason #9: Interface Copyright Inhibits Useful Innovation
> 
> Due to the evolutionary nature of interface development, interface
> copyright will actually retard progress.
> 
> Fully fleshed-out interfaces don't often arise as aemph{tours de force} from
> the minds of isolated masters.  They result from repeated
> implementations, by different groups, each learning from the results 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 advances that we
> ought to encourage are most often 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.
> 
> Users often appreciate small, incremental changes that make programs
> easier or faster to use.  This means changes that are upwards
> compatible, or affect only part of a well-known interface.  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.
> 
> However, such partial changes as this are not permitted by copyright
> law.  If any significant portion of the new interface is the same as a
> copyrighted interface, the new interface is illegal.
> 
> aheading Reason #10: Interface Developers Don't Want Copyright
> 
> At the 1989 ACM Conference on Computer-Human Interaction, Professor
> Samuelson of Emory School of Law presented a ``mock trial'' with 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 aspects of user interface
> copyright, by as much as 4 to 1 for some aspects.  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.afootnote{See the May 1990
> issue of the Communications of the ACM, for the full results.}
> 
> The advocates of user interface copyright say that it would provide
> better security and income for user interface designers.  However, the
> survey shows that these supposed beneficiaries would prefer to be let
> alone.
> 
> aheading Do You Really Want a User Interface Copyright, Anyway?
> 
> 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 resentment and eventually drives customers to try to
> escape.  In the long run, this leads to failure.
> 
> Therefore, by permitting user interface copyright, society encourages
> counterproductive thinking in its businesses.  Not all businesses can
> resist this temptation; let us not tempt them.
> 
> aheading Conclusion
> 
> Monopolies on user interfaces do not serve the users and do not
> ``promote the progress of science and the useful arts.''  User
> interfaces ought to be the common property of all, as they undisputedly
> were until a few years ago.
> 
> aheading What You Can Do
> 
> acomment Feel free to delete this section when sending a copy
> acomment to a politician
> 
> aitemize abullet
> aitem
> Don't do business as usual with the plaintiffs, Xerox, Lotus, Apple and
> Ashton-Tate.  Buy from their competitors instead; sell their stock;
> develop new software for other computer systems and port existing
> applications away from their systems.
> 
> aitem
> Above all, don't work for the ``look and feel'' plaintiffs, and don't
> accept contracts from them.
> 
> aitem
> Join the League for Programming Freedom---a grass-roots organization of
> programmers and users opposing software patents and interface
> copyrights.  (The League is not opposed to copyright on individual
> programs.)  Annual dues are $42 for employed professionals, $10.50 for
> students, and $21 for others.  We appreciate activists, but members who
> cannot contribute their time are also welcome.
> 
> Phone us at (617) 243-4091, send Internet mail to
> acode{leagueaaprep.ai.mit.edu}, or write to:
> 
> adisplay
> League for Programming Freedom
> 1 Kendall Square #143
> P.O. Box 9171
> Cambridge, MA 02139
> aend display
> 
> aitem
> Give copies of this paper to your friends, colleagues and customers.
> 
> aitem
> In the United States, write to your representatives and to these
> Congressional subcommittees:
> 
> adisplay
> House Subcommittee on Intellectual Property
> 2137 Rayburn Bldg
> Washington, DC 20515
> 
> Senate Subcommittee on Patents, Trademarks and Copyrights
> United States Senate
> Washington, DC 20510
> aend display
> 
> aitem
> In Europe, the European Commission is proposing to institute interface
> copyright.  Express your opposition by writing to:
> 
> adisplay
> Jean-Francois Verstrynge
> DG 3/D/4
> Commission of the European Communities
> 200 Rue de la Loi
> 1049 Bruxelles
> BELGIUM
> aend display
> 
> Also write to your own representative to the European Parliament.
> aend itemize
> 
> abye
> 
> \input texinfo    ac -*-texinfo-*-
> acomment %**start of header
> asetfilename patents.info
> acomment %**end of header 
> 
> asp 7
> acenter atitlefont{Against Software Patents}
> asp 1
> acenter (September 24, 1990)
> asp 1
> acenter 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 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.
> 
> aheading 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 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 give them the right to use it.
> 
> Patents do not cover specific programs: instead, they cover particular
> techniques that can be used to build programs, or particular features
> that programs can offer.  Once a technique or feature is patented, it
> may not be used in a 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 not used in 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.a: 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.
> 
> aheading 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.
> 
> aheading 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
> acite{Polaroid vs.a: 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.
> 
> aheading 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.''  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).
> 
> The technique of backing store was used in an earlier MIT project, the
> Lisp Machine System, before AT&T applied for the patent.  The Lisp
> Machine developers published nothing about this detail at the time,
> considering it too obvious.  It was mentioned years later when the
> programmers' reference manual explained how to turn it on and off.
> 
> The Lisp Machine was the first computer to use this technique only
> because it had a larger memory than earlier machines that had window
> systems.  Prior window system developers must have dismissed the idea
> because their machines had insufficient memory space to spare any for
> this purpose.  Improvements in memory chips made development of backing
> store inevitable.
> 
> 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 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.
> 
> aheading 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 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 follow 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.
> 
> aheading 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.
> 
> aheading 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.
> 
> aheading 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 acode{compress} followed an algorithm obtained from
> the journal acite{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.
> 
> 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.
> 
> aheading 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.
> 
> aheading 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.)
> 
> aheading 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.
> 
> aheading 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.
> 
> aheading 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.
> 
> aheading 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.
> 
> aheading 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.
> 
> aheading 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, acite{Diamond vs.a:
> Deihr}.afootnote{See ``Legally Speaking'' in acite{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.
> 
> acite{Diamond vs.a: 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.
> 
> aheading 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:
> 
> aitemize abullet
> aitem
> 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.  
> 
> aitem
> Software can be easily and cheaply copied.
> aend itemize
> 
> 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 end up being treated as hardware, as software,
> or as something in between.
> 
> aheading What You Can Do
> 
> One way to help eliminate software patents is to join the League for
> Programming Freedom.  The League is a grass-roots organization of
> programmers and users opposing software patents and interface
> copyrights.  (The League is not opposed to copyright on individual
> programs.)  Annual dues for individual members are $42 for employed
> professionals, $10.50 for students, and $21 for others.  We appreciate
> activists, but members who cannot contribute their time are also
> welcome.
> 
> To contact the League, phone (617) 243-4091, send Internet mail to
> acode{leagueaaprep.ai.mit.edu}, or write to:
> 
> agroup
> adisplay
> League for Programming Freedom
> 1 Kendall Square #143
> PO Box 9171
> Cambridge, MA 02139
> aend display
> aend group
> 
> 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:
> 
> adisplay
> House Subcommittee on Intellectual Property
> 2137 Rayburn Bldg
> Washington, DC 20515
> 
> agroup
> Senate Subcommittee on Patents, Trademarks and Copyrights
> United States Senate
> Washington, DC 20510
> aend group
> aend display
> 
> You can write to your own representatives using the following addresses:
> 
> adisplay
> Senator So and So
> United States Senate
> Washington, DC 20510
> 
> Representative Such and Such
> House of Representatives
> Washington, DC 20515
> aend display
> 
> You can phone senators and representatives at (202) 225-3121.
> 
> aheading 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.
> 
> aheading 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.
> 
> abye