\documentstyle[]{article}
\author{David Golombek}
\title{Intellectual Property and Software Patents}
\date{\today}
\begin{document}
\maketitle

\newpage 
%\singlespace
\tableofcontents
%\doublespace
\newpage
\section{Introduction}

For the last twenty years, Richard Stallman has been fighting a battle
against proprietary software and software ownership.  Stallman firmly
believes in the freedom of software, where freedom is defined as ``the
users' freedom to run, copy, distribute, study, change and improve the
software.''\cite{free-sw} As anyone walking into a computer store can
clearly see, Stallman's fight has been a losing one, and proprietary
code still comprises most of the software running on computers today.
Modern capitalistic notions of consumerism mesh nicely with software
vendors' desires to make money, and most people are happy (besides
Stallman).  However, current software practices are actually slowing
software development and providing inferior programs to the public.
This paper will explain why current practices are indeed so bad for
the public, why the public don't realize this fact, and then attempt
to devise a model for software development and distribution that will
address some of the issues brought up by both sides.  It will end up
concluding that software patents should be abolished before they
become an even bigger problem than they are now, and that standardized
programming models should be promoted in order to facilitate code
sharing.  

\section{Existing Software Development Models}

Up to this point, software development has fallen under one of two
general categories, free software or proprietary software.  There are
minor variations, such as freeware programming, but these all
essentially involve some attempt by the author to make some money for
himself by restricting use of his program, and thus cannot be
classified as free software.

\subsection{The Free Software Model}

\begin{quotation}
``Free software'' is a matter of liberty, not price. To understand the
concept, you should think of ``free speech'', not ``free beer.''
\cite{free-sw}
\end{quotation}

The term ``free software'' has long been used by Richard Stallman and
others to describe the alternative to proprietary software.  As
indicated in the above quote from Stallman, it has nothing to do with
the price charged with the software, but rather what may be done with
it.  Free software is intended to give absolute power to the user of
that software, rather than reserving all rights for its creator.  That
is, with free software, the user has both the program to run, and
the source code to that program, which he may modify if he so desires
and distribute to anyone who wants a copy.  Furthermore, the user may
combine both actions, modifying the program to make improvements (or
merely stylistic changes), and then distribute this modified version.
All of this is in strict contrast to proprietary software, where the
original creator of the software retains near complete rights to that
program, and merely grants the user the right to run the program.

The idea of free software has been around since the beginning of
programming itself.  The companies that built the first computers
distributed the source code (initially in assembly language, later in
higher level languages) freely with the executable programs, in order
to demonstrate how to program their computers.  More noticeably in
support of free software were the universities who were the largest
initial purchasers of computers (aside from the military, which never
releases {\it anything}), which have always had a policy of sharing and
distributing all research results and techniques.  This policy
certainly helped form the attitudes of the first university computer
programmers.  

The first large computer culture outside of a computer company
developed at MIT at the Artificial Intelligence Laboratory and later
at the Tech Model Railroad Club (TMRC).  The growth of the computer
culture is detailed in Steven Levy's book {\underline
Hackers}\cite{hackers}, and covers the growth of the MIT hacker
community, which was the first group to formalize and
instituitionalize the practice of making the source code to all
programs avaliable.  The hackers at MIT wanted all information to be
free, especially that information that would help other people work on
projects.  Writing a tool that would help other hackers and
distributing the source code for that tool was considered a highly
moral and prestigious activity, one that all hackers should engage
in.  While these moral standards are certainly rather unique to the
group of hackers that developed them, the important lesson to be
learned from the early MIT hackers was how quickly they developed
software.  The cooperative community of hackers produced a tremendous
amount of software and advanced the state-of-the-art in software by
great leaps by virtue of many smart minds working in collaboration,
sharing work and ideas freely.

\subsection{The Proprietary Software Model}

The original MIT hacker community was splintered heavily when computer
companies hired many of the original hackers to work on
proprietary code, luring them away with large salaries.  Software
companies were able to make enormous profit margins, developing
software off the effort of a couple hackers and selling it for high
prices to large numbers of individuals.  Software companies had no
manufacturing costs, minimal distribution costs, and comparatively
small advertising needs, and thus were able to be among the most
profitable of companies, making their owners and employees very rich.  A
part of this profitability though was keeping company software private
to prevent other companies from copying it and redistributing it on
their own.  Thus each company kept their code under tight lock and
key.  Some went even further and began to patent their software and
ideas, trying to enforce their competitive advantage even further.
Both the ideas behind a piece of software and its interface were
considered proprietary to the company who created it, and the American
legal system backed up the companies in their claims.

Which of these models is more correct is a philosophical judgement and
not one that has been definitively answered by any existing doctrine.
The next section will examine what current United States law dictates
with regards to software patents.

\section{What United States Law Says}

The founding fathers of the United States included the basis of our
current patent and copyright system in the Article 1, Section 8 of the
Constitution when they wrote:

\begin{quotation}
The Congress shall have Power [...]

	To promote the Progress of Science and useful Arts by securing for
	limited Times to Authors and Inventors the exclusive Right to their
	respective Writings and Discoveries;
\end{quotation}

The US Patent and Trademark Office (PTO) was founded to help enforce
these ideals and to create a process for the assignment of patents.
It is in charge of deciding which claims are original pieces of work
and granting patents and trademarks to those claims they find meet the
standards set up in 15 U.S.C 1051-1127, 1511, 35 U.S.C, and 44 U.S.C
1337-1338, which form the principal statuatory authorities of the PTO.
The PTO's self-stated interpretation of these laws is to ``promote
industrial and technological progress in the United States and
strenghen the national economy.''\cite{PTO}

While the basic principle remains of the patent system remains as
strong and popular as ever, the exact interpretation of these patent
laws has changed over time.  The application of patent law to software
is particularly volatile and the subject of much controversy.
Existing patent and copyright law was initially assumed not to cover
software, considering them akin to algorithms, which are not
patentable.  In a series of patent grants and court cases, including 
{\it Diamond vs. Deihr}, interpretation of patent law was taken to
mean that software was patentable, and the rush to patent all new
software ideas was on.

\section{Why Proprietary Software is Bad}

The United States has used the principles set out in the Constitution
to govern the administration of patents in the software industry.  And
up to this point, this policy has worked reasonably well.  Many
companies have made a lot of money, and advances in computer
technology and application have continued to advance, helping the
public good.  This situation is unlikely to continue much longer.
While our current system has worked well up to now, the buildup of
software patents and changes in the nature of software engineering are
likely to create a future where the public good is no longer served by
software patents.

\subsection{Problems with Software Patents}
Patents and copyrights are the primary means companies use to keep
their programs proprietary.  They use patents to protect the ideas and
processes of their programs, and copyrights to prevent users from
reverse engineering the program to determine how it was accomplished.
Several ways in which software patents are directly harmful to the
advancement of the state-of-the-art in software engineering will be
shown below.

\subsubsection{Many software patents are for Obvious Work}
Many of the software patents granted by the PTO are for ideas and
pieces of code that seem obvious to the common member of the computer
science community.  For example, Cadtrak has patent \#4,197,590, which
is for the use of exclusive-or (xor) in computer graphics.  The use of
the xor operation has long been known, and it is the most intuitive
way to perform many graphics operations, such as a display of a mouse
cursor, image masks, and several forms of shading.  Unfortunately, the
software patent reviewers at the PTO are not always dedicated computer
scientists, and many obvious concepts like the xor patent are let
though.  This is as much a problem with the administration of the
patent system as it is with the patent system in general.  The sheer
number of software patents being submitted makes it likely that some
number of obvious patents will always make it through, no matter how
well the PTO is administered.  

\subsubsection{Problems with Patent Searches}
The normal way of avoiding overstepping someone else's patent is to do
a search of all existing patents for any prior work.  Unfortunately,
as the list of existing patents grows larger, this becomes a more
difficult task.  Patents are written in a very specific language, one
that only trained professionals (read lawyers) can be trusted to fully
understand.  Thus, to do a patent search effectively, a company needs
to hire a specialized patent lawyer to do the search for them, who are
extremely expensive.  Even these patent lawyers make mistakes, because
some patents are so vague as to possibly encompass extremely large
areas of software, leaving a company continually uncertain if it is
about to be sued for patent infringement.

These patent searches must be performed constantly, because new
software patents come out daily (up to one hundred a week in recent
years), and because a typical software project will cover an extremely
wide range of subjects.  A company must continually ensure that every
part of every product, both existing and under development, complies
with all patents, or face lawsuit from the patent holder, back-dated
to the date of the other companies' patent application.  The only ways
to escape these lawsuits are to license the patent or to remove the
patented material from the program, and even these drastic measures
may not satisfy the courts, which can still apply fines for profits
made on patented material.

\subsubsection{Problems with Patent Licensing}
If all patent licenses were cheap and easy to obtain, most of the
initial problems with patents could be avoided.  A company could
simply pay out royalties to whoever had the patents they needed and
continue on developing their software if they felt the price was
right.  This still wouldn't solve all the problems that we are likely
to encounter in the future, but would significantly simplify things.
Unfortunately, most companies are eager to make as much money as
possible, and thus charge very high fees for patent licensing, knowing
the law will tend to support them in court.  Some companies will not
license their patents at all, trying to maintain exclusivity on their
work to guarantee greater sales.  Since the company knows their patent
is exclusive, they can charge exorbitant amounts, and frequently do.

\subsubsection{Software Patents last too Long}
In the world of physical devices and mechanical construction, creation
of a new process for peforming some task can be an expensive endeavor,
and can be expected to be useful for a reasonably long time.  The
seventeen year length of patents is reasonable, allowing the inventing
company to reap full rewards from the invention before other companies
are allowed to start utilizing the process.  The software industry
moves so quickly that seventeen years is an infinity --- roughly one
third the entire history of computer software.  By the time a patent
expires, only the most enduring of software will be at all relevant,
such as the RSA patent.  Rather than a patent still being useful at
the end of its stay, most software patents are useless to anyone, and
thus their conversion to the Public Domain is meaningless.  Instead of
merely allowing the inventing company time to recoup its design costs,
software patents lock the patented idea up until it is ready to die.

\section{Why Proprietary Software Hasn't Hurt Us Yet}

The problems described above with the patent system may not seem too
bad, since software has been progressing at a rapid rate despite these
problems.  Sure, the problems may cause hassles for a lot of software
companies, but are they really hurting the software industry?  The
answer to this question is currently under debate, with the League for
Programming Freedom (LPF) taking the side that patents are harmful,
and many large software companies claiming that patents are useful and
neccessary.

\subsection{The LPF's View}

In ``Against Software Patents''\cite{LPF} the LPF states ``Software
patents threaten to devestate America's computer industry. ... The
problem has only one solution: software patents must be eliminated.''
This unequivocal position has won few friends among the big-business
friendly American government, but the LPF has has many strong points
for its argument.  In the above mentioned article and many others,
they cover several of the problems with patents mentioned above, as
well as others.  They additionally argue that programmer efficiency is
being stifled by the neccessity of performing constant patent searches
and that innovation is being stifled by concerns of overstepping
broadly worded patents.  They even argue that software patent law
extensions may be illegal, that the interpretation of the Supreme
Courts 1981 decision in {\it Diamond vs. Deihr} used by the PTO is
faulty, that the decision supporting a patent on a computer program as
part of the rubber curing process was for a specific case and not a
general ruling on software patents.

The LPF is specifically interested in abolishing software patents,
suggesting a law be passed excluding software from the domain of
patents, as was considered to be the case until the 1980's.  They
admit there might theoretically be some limitted set of software that
might deserver patent protection, but have never seen the existance of
such programs, and were they to exist, would need to be handled as a
special case.  The LPF is not opposed to copyrights on individual
programs, but rather these large patents on software ideas and on
user-interface protectionism through copyright or patents.  To fight
for theses views, they write papers explaining their position,
petition Congressmen and especially members of relevant committees,
give speaches, and run protests.

\subsection{Large Software Companies' View}

Many large software companies have taken stands in favor of the
existing software patent system.  They like the status quo most of the
time, finding they can use it to their advantage.  Large software
companies (IBM is the canonical example) build up large collections of
patents and use these to force other companies to pay them royalties
on their products.  IBM takes its portfolio of over 9000 patents and
approaches smaller companies, claiming violation of one or more
patents, then asking for a 1\% royalty for licensing one patent, or a
5\% royalty for licensing the entire portfolio.  If the company
refuses to license the patents, IBM can threaten to take them to
court, a process more lengthy, painful, and expensive than the
licensing would ever be.  IBM can protect itself from similar
extortion schemes by finding a patent that the extorting company has
violated and forcing them into a cross-licensing scheme, which costs
IBM nothing.  Other companies that have similar patent portfolios
include Microsoft, AT\&T, and DEC.

There are a few large software companies which do not follow this
viewpoint, notably Adobe, Oracle, Autodesk, Synopsis, and Wind River
Systems.  Unfortunately these make up the have-nots, the companies
that didn't have large patent portfolios, and have been on the losing
side of software patent battles in the past.  Even these companies are
forced to patent their software to protect against having someone else
claim the patent and force them to pay royalties on their own idea.  

The big losers in the software patent model are small companies and
individual programmers.  These groups are typically unable to afford
constant patent searches to determine the legality of their programs
and don't have the deep pockets needed to fight any sort of a patent
battle, even when they are right.  Thus even when a small company or
individual obtains a software patent, they frequently fall victim to
the extortion used by larger software companies or are unable to
pursue all companies that infringe on their patents.  
 
\subsection{Why Proprietary Software Will Begin to Hurt More}

\subsubsection{The Patent Flood is Increasing}

The problems with the current patent system presented by the LPF are
not going to get better on their own.  In fact, they are going to get
much worse.  There are currently tens of thousands of software patents
in existance, so many that no one can even be certain, because some
patents are so vague on the limits of what they claim (example, a
claim to all automated Bingo games, which was deemed to include
computer bingo games).  Tens to hundreds more software patents are
granted weekly, in an ever increasing flood, with every company eager
to patent every little idea they can.  At the same time the number of
PTO patent examiners remains roughly constant, and so each patent will
receive less attention, letting more trivial or non-original patents
fall through the cracks.  

\subsubsection{The Stakes are Increasing}

As the database of existing patents grows larger, patent searches
become more difficult and it becomes harder write any software that
entirely avoids all patents.  If more companies become monopolistic
and refuse to license their software, trying to force everyone else to
use their program, we could eventually reach a point where making any
progress in software engineering became a prohibitively difficult
task.  Many signs are beginning to point towards the fact that this
point is much closer than a lot of programmers, managers, and
businessmen want to admit.  The number of software patent lawsuits has
been rising dramatically, as well as the size of many of these
lawsuits.  Even industry giants such as Microsoft, Novell, and Oracle
have been embroiled is high-stakes lawsuits, such as the Stac
Electronics vs Microsoft suit which eventually forced Microsoft to
remove part of MS-DOS 6.0.  

\subsubsection{The Litigation is Increasing}

The software industry used to be run by programmers who were forced
into management, people who studied computer science in school, not
business.  These days, most computer companies have CEO's brought in
from big business schools, people with lots of experience, and most
importantly for this discussion, are knowledgeable about the law.  In
particular, they know how to manipulate the law to work for them, and
know the right lawyers to talk to in order to twist the law even
further.  Like the rest of society, the computer industry has become
more litigious, prompting the LPF slogan ``Innovate, don't litigate!''
This hasn't helped the software patent problem, and this trend of
bringing every issue to court seems to continue to grow.  

\subsubsection{The Scope of Software is Increasing}

Perhaps the most important reason that we need to do something about
proprietary software now is that it will be technically necessary for
software companies to share more code and advances in the coming
years.  The scope of software projects has been growing rapidly over
the last few decades, as the complexity of what software vendors
attempt to do increases.  Early software projects were simple affairs
usually, involving fairly few programmers, most of whom were doing
original work, because there was little prior art to reproduce.
Modern software projects involve large groups of programmers, many of
whom are reproducing work done by other programmers at other
companies.  Libraries are being developed and shipped (sometimes free,
sometimes not), allowing programmers to avoid rewriting everything
from scratch, but due to interface copyrights, these libraries are not
interchangeable, and thus many programmers choose to reproduce
everything on their own, rather than be trapped into a proprietary
solution.

\section{The Mixed Software Model}

Up to this point, the paper has been pointing out the problems with
the existing situation with software.  And as important as it is to
reiterate the problems to make sure people agree that they do exist
(at least to some degree), suggesting solutions to problems is even
more important.  Thus, the paper turns to finding a new model for
software, one that doesn't rely on patents, but that still allows
software companies to profit from their efforts.  

The basis for this new model is some technology called Object
Brokerages or Object Warehouses.  This technology has existed for the
last three years, and has been developed in several systems, including
CORBA, the Common Object Request Broker Architecture, headed by IBM,
what is now called DCOM, the Distributed Common Object Model, headed
by Microsoft, and finally OpenDoc, Apple's now mostly defunct entry
into the running.  These technologies are all based around the same
idea, that there exist ``objects'', or blocks of code and data
representing something, be it a file on a disk, or a network, or any
other computational entity.  The Object Brokerages allow for the
universal naming and communications between these objects, allowing
for a large system of these objects to work together to create a
larger program.

But a technology does not a policy make, as we have discussed in
class.  How does this techology translate into a new model for
software?  It leads to a model called the mixed programming model, in
which companies do not have patents on their code, but still have
copyright to protect them, but a programming scheme that encourages
effective code sharing is adopted, to gain the benefits of code reuse.
Now that the final model has been layed out, lets build up to it in
pieces to explain where it came from.

First, software patents need to be eliminated.  The LPF has a strong
case that software patents are currently hurting the software
industry, and this is only going to get worse over time.  Even by
drastically reducing the time that software patents held to three or
fewer years, patents will still dramatically slow down the pace of
progress in computer science.  Therefore, they must be removed
entirely.  Software companies will be forced to innovate even faster
to distinguish themselves from their competitors.  

Second, large software companies, particularly Microsoft, need to be
broken up.  This is a contentious point, and unfortunately beyond the
true scope of this essay.  It is not strictly neccessary for the model
presented here to work, but makes the explanation of it much easier.
The problem with large companies like Microsoft is that they
monopolize a realm of applications, such as word processing, and
present a single program that everyone uses, and that becomes such a
standard that it becomes impossible for other competitors to enter the
market.  Proving that a company has become a monopoly is difficult
however, and it is difficult to gain popular support for breaking up a
company in our big-business friendly government.  However, positing a
breakup of large software companies will make the examples to come
easier, and so will be left in.

Third, the government needs to lead a push towards standardizing on
one of the object brokerages mentioned above.  Each of the contending
models has its strengths and weaknesses, but all are workable enough
to serve as a good foundation for large software projects.  DCOM and
CORBA are the two primary proposals, and large projects have in fact
already be completed based on both of them.  The government needs to
force one of these to become a truly open standard, taking it out of
the hands of its creator and into the realm of an ANSI (American
National Standards Institute) or ISO (International Standards
Organization), preventing the creator from continually changing it
from preventing ``unwanted'' others from using the model.  Microsoft
and other vendors have been guilty of this, publishing a standard,
then modifying it too fast for other vendors to use, allowing only
internal developers to use the ``standard''.  Equally importantly, the
government cannot allow the object model to stay in standards
committees forever, becoming more complex as everyone adds on their
favorite features, as has happened with many designs worked on by
committee.

Fourth, and finally, there needs to be a strong push towards using
this object brokerage very widely in user applications.  This is
perhaps the hardest step, because it is nearly impossible to
legislate, and will not necessarily be of interest to large software
companies.  Large software firms like Microsoft have been developing
these object brokerages, but when it comes to letting other firms
create plugins for core parts of their applications, Microsoft
suddenly backs off becomes proprietary again.  The goal of all of this
again is to allow different vendors to create objects that will
interoperate cleanly, allowing the user (or a packager) to pick which
modules to use in assembling the final application.  For example, a
user could put together his own document package, picking an editor, a
spell-checker, a graphics module, a table manager, and font package,
all from different suppliers.  Or if the end user didn't want to do
this, a packager could pick these components by default, still
allowing the user to replace individual components if he so wished.

This mixed code model contains a bit of the best of both the free and
proprietary software worlds.  It contains some of the code sharing
evolution from the free software model, because companies can use
objects from other companies rather than having to reimplement them on
their own, if that company is selling the module for a reasonable
price.  If the price isn't reasonable, they can create their own
replacement, or find one from another vendor.  The mixed model also
contains much of the proprietary model, in that companies can still
profit from their work, and are safe from having people copy their
code directly due to copyright law.  The public wins most though,
because software companies are forced to compete more, but are
competing in an advancing manner, rather than fighting to reinvent the
wheel over and over again.

\section{Conclusion}

Intellectual Property laws are currently very strong, protecting the
creator of software near complete rights to his code, in the form of
software patents and interface copyrights.  Unfortunately this
protection is beginning to disrupt future software development because
of the poor handling of software patents, the sheer number of patents,
and problems with patent licensing.  Future software development will
be greatly hindered by these patents, and thus something drastic needs
to be done.  By eliminating software patents and and promoting
technologies that support code sharing via object brokerages, software
development will become unhindered once again, with software companies
able to make quick progress once again.

\newpage
%\singlespace
{\raggedright
\bibliography{iprop}}
\bibliographystyle{plain}

\end{document}