|
Items in cart [0] |
Questions? Call 888-624-8373 |
PAPERBACK PDF BOOK Free Resources |
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
| ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
| Copyright © 2009. National Academy of Sciences. All rights reserved. Terms of Use and Privacy Statement |
Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 43
Is Software a Special Case?
For the purposes of the law, the relevant question is not whether
software is different from other technologies and creative works that
now come under the protective umbrella-it clearly is. Rather, the
issue is whether software is so different that extensions or modifica-
tions of existing legal constructs are needed. Opinions abound on
this question. Said Stanford University law professor Paul Goldstein,
"Any time you are dealing with creative artists and that, to an ex-
tent, is what you are talking about here-you are talking about people
who genetically believe their work is different.... [T]he history of
copyright suggests that those differences will be taken account of."
Some experts in patent law echoed that reasoning.
Not all legal and technical experts attending the forum, however,
were as confident in the providence of the legal system. For ex-
ample, Mitchell Kapor, chairman of ON Technology, suggested that
software is so "fundamentally different" from works on paper, the
traditional realm of copyright law, that a "first-principle reconsidera-
tion" of the law may be more appropriate than determining "how to
stretch copyright." Added Pamela Samuelson, law professor at the
University of Pittsburgh, confusion about the expressive and functional
elements of software contributes to the blurring of boundaries between
copyright law and patent law.
THE PROCESS
Depending on whom you ask, software is either written, engineered,
built, or grown each term capturing some aspect of the process. Per
43
OCR for page 44
44
INTELLECTUAL PROPERTY ISSUES IN SOFTWARE
haps the most distinguishing feature of the process, however, is the
insignificance of manufacturing as a component, a factor that under-
lies software's inherent vulnerability to copying
"It is all design and no manufacture," explained Randall Davis,
associate director of the Massachusetts Institute of Technology's Artifi-
cial Intelligence Laboratory. "Reproducing it is trivial. Building it . . . is
the hard part. There is no significant added effort in building [a
multitude of identical products] once you have built the first one."
The process is so different from that in other fields of engineering,
Duncan M. Davidson has written, that it warrants revising Thomas
Edison's famous characterization of invention as "one percent inspi-
ration and ninety-nine percent perspiration." For software, accord-
ing to Davidson, the proper equation may be "fifty percent inspiration
and fifty percent perspiration" (Davidson, 1986, p. 10621.
While those in the field may quibble about the exact proportions
of the creativity and toil that go into a successful software product,
they do agree that both elements are essential. A "brilliant idea"
gives birth to a new product and, perhaps, even an entire industry,
Xerox's Robert Spinrad explained, but its potential cannot be realized
without the "pick-and-shovel engineering that turns the idea, the
prototype, into a reliable, distributable, maintainable, documented,
supportable product."
To Kapor, design is an underappreciated element of software de-
velopment, even though it is the primary determinant of a product's
value. "I believe more and more of the economic fortunes of com-
puter companies . . . [willl depend on how well designed the programs
are, not merely on how well they are implemented," he said. "EWle
had better worry seriously, if that is the crucial economic element,
about what we want to do about protecting the design of software,
independent of all the other factors."
Jerome Reichman agreed with Kapor and predicted that no long-
term solution to the legal problems associated with protecting software
will emerge until lessons drawn from the 200-year history of design
protection law are brought to bear on this new subject matter, which
he calls "industrial literature."
Yet, the importance of those other factors should not be diminished.
An idea, no matter how brilliant, will not reach commercial fruition,
Spinrad said, without the "detailed work" that goes into making a
practical marketable product. Design and implementation, however,
are not separate spheres of software development. The two activities
are interactive.
The path that leads from idea to product is usually circuitous, and
progress can be painstakingly slow, as evidenced by the field's ap
OCR for page 45
IS SOFTWARE A SPECIAL CASE?
45
parent resistance to major enhancements in productivity. In fact, soft-
ware development entails going down many paths simultaneously,
retracing one's steps, and starting out anew with a slightly revised
objective in mind. Dan Bricklin, co-developer of VisiCalc, the first
spreadsheet program for a personal computer, broke the process down
into eight stages, as described in Box 3.1. "This is a constant iterative
process," he said, and testing is nearly continuous. "Every time you
test, you end up changing your design, your constraints [such as the
amount of memory required or the speed of executing an operation],
or your statement of the problem." Each cycle results, Bricklin ex-
plained, in "greater understanding of what you are trying to do."
J V
"You can't just specify [a product), give it to a coder, and say it
will work," he added. "You will end up with lousy programs."
The seeming circularity of software development stems from a dif-
ficulty that exists from the outset the difficulty of clearly defining
the problem that the product is intended to solve. Studies of the
process suggest that at least 50 percent of the errors that arise during
development stem not from coding mistakes, according to MIT's
Davis, but rather from inadequate formulation of the problem and
incomplete understanding of human behavior.
"We try to build things," he said, "and we really don't know what
they are until we start to build them. So, one punch line here is, it
isn't the programming that is hard; it is figuring out what we're
trying to do that is hard." Consequently, the problem that motivated
the development effort may not be fully specified until the final code
is written. And even then, future changes are inevitable because
customers are bound to discover errors that were not exposed during
testing and debugging, no matter how rigorous the testing. "What
we can test," Davis said, "is the match between the program and the
specification, which is not at all the same thing as the specifications
and what the world is."
Software development is often likened to architecture, another de-
sign-intensive activity. Kapor noted that both activities are devoted
to accommodating human needs and motivations, as well as to satis-
fying aesthetic tastes. Davis pointed to a fundamental difference,
however. Software does not have a physical embodiment that can be
represented pictorially, as in blueprints or architectural diagrams.
Details often cannot be pinned down in advance. "There is almost
no way to visualize software," Davis explained. "Sure, we have flow
charts, we have data-flow diagrams, we have control-flow diagrams,
and everybody knows how basically useless those are. Flow charts
are documentation you write afterward because management re-
quires them, not because they are a useful tool."
OCR for page 46
46
INTELLECTUAL PROPERTY ISSUES IN SOFTWARE
BOX 3.1~0NSTANT ITERATION: STEPS IN
DEVELOPING SOFTWARE.
Specify the problem and define the constraints.
The process begins with a general description of the intended application,
which then must be evaluated and reevaluated in light of such constraints
as memory requirements, speed of execution, ease of use, and desired
completion date.
Design externals.
Determine how the program will interact with the outside world users,
input devices, other programs, output devices. Will the program inputs,
for example, be entered by keyboard or voice commands? How will data
on disk files be hand led?
Design internals.
Set up the data structure, organize movement and processing of the data,
and identify the critical points of data control, as well as the languages
and algorithms to be used.
Transform the design into code.
Use own existing code or license it from others, when feasible; write new
code. Assemble these elements into a prototype program for testing. Respecify
the problem on the basis of new understanding, and change the design
accord ingly.
Test, retest, and test again.
Evaluate the prototype's performance with real users and real data. Iden-
tify bugs and performance trade-offs. As needed, change the code, design,
constraints, and problem description.
Document for the user.
Explain how to use the program, how it works, and how to modify it.
Change the program to improve the documentation, if necessary.
Package and market.
Adapt the product, if necessary, to fit the distribution medium, such as a
floppy disk or compact disk. Prepare manuals. Advertise and position the
product in the market. Change the product to accommodate new hardware
or to adjust to new market conditions.
Support the product.
As appropriate, create user groups and provide on-site training, telephone
help lines, and informational publications. Track user feedback, correct
bugs, identify incompatibilities, and begin evaluating features to include
in the next product version.
*Abstracted from a talk given by Dan Bricklin, Software Garden, Inc., at CSTB's
December 1989 forum.
OCR for page 47
IS SOFTWARE A SPECIAL CASE?
47
Taken together, two attributes ascribed to software the unique-
ness of each product and the incremental, additive nature of the de-
velopment process appear to be contradictory. '~You use code that
worked before-bags of tricks," Bricklin explained. "You license code
from others or use stuff that is built into the operating system ....
You write new code. You tie it all together with all sorts of different
types of glue."
If the code underlying a specific function, such as methods for
searching databases, can be used in many applications, then where
does the uniqueness, or originality, in a product lie? Often, Bricklin
and others maintained, reusable components require very specific
tailoring to be incorporated into new applications. If cars were built
in the same manner, Davis explained, the size of each screw used in
their construction would be different.
More important, however, is the composite nature of the product.
"Most software is an accretion of pieces of software that have been
previously developed, used in ways the original innovator never
contemplated," explained Francis Fisher, adviser to the Educational
Technology Group at the Harvard Law School. "This reassembling of
bits and pieces is greatly in the public interest. That is how software
progresses."
Thus each new development project begins at a "higher jumping-
off point," Kapor added, "because there are more layers" to integrate.
"But once you actually sit down to write your piece, your program, it
is still grinding code, and testing and debugging."
This peculiarity of software poses a quandary for intellectual proper-
ty law. A large number of companies are in the business of produc-
ing reusable software components. This market illustrates the prob-
lem of balance: on the one hand, overly rigid protections could undermine
a slowly growing foundation of reusable components. On the other
hand, without intellectual property protections, these companies could
not exist. Although those in the field disagree on the depth and
breadth of the foundation, software developers would like to exploit
whatever experience is accumulating. "You have to be careful about
protecting [code] that can be used all over the place very careful,'
Bricklin warned. The law, he added, should encourage developers to
pursue successively higher levels of innovation, but without prevent-
ing them from exploring and implementing new iterations of existing
ideas and methods. If protection confers monopoly at too high a
level in Bricklin's tree-like scheme of software innovation, access to
branches leading to new designs and applications would be blocked,
he said.
OCR for page 48
48
INTELLECTUAL PROPERTY ISSUES IN SOFTWARE
SOFTWARE AS A CREATIVE MEDIUM
At its most abstract, software is "the ultimate creative medium,"
said MIT's Davis. It is, according to Davis, "a tangible form of dreams
and imagination."
Yet in software, abstraction and metaphor are embodied within
the product. The popularity of Apple's Macintosh computer, for ex-
ample, is attributed to a graphical user interface that mimics the desktop
work environment in visual imagery, in the behavior of the file folders,
trash cans, and other objects depicted on the screen, and in the inter-
action between the user and these objects. Indeed, a major aim of
software development is to create user interfaces in which "electronic
reality and actual reality completely overlap and reinforce each other,"
said Bruce Tognazzini, who started the human interface group at
Apple Computer. Thus software seeks to simulate reality and to
achieve cognitive compatibility with computer users, a combination
of features that, many software designers maintain, distinguishes it
from other technologies.
Reichman of Vanderbilt disagreed with this claim. Industrial de-
signers, he suggested during the forum, would argue that software
design is merely one application of advanced techniques that are
routinely applied to other innovative products.
Another hallmark of software is its malleability as a creative tool
and, consequently, its nearly unlimited utility. In a technical sense,
said MIT's Davis, "software is the universal machine.... We can
really do anything with the machine, and as a consequence, we, in
fact, try to do everything with it." The results are products that
enable a computer user to perform given tasks, not unlike, as Kapor
pointed out, conventional machines made of iron, steel, or plastic.
Yet, for the purposes of copyright law, software is treated as analo-
gous to a literary work.
Several software attributes, according to Kapor, strain the analogy
to literary works. Books and other works on paper, he said, are fixed
in form, sequential, noninteractive, uncoupled from the real world,
and nonfunctional in the sense of performing work. In contrast, software
is a dynamic composite an assembly of many different programs-
that, unlike pages in a book, can change its working order at the
beckoning of the user. Software, therefore, has a chameleon-like identity,
as "literary expression that does useful work," Kapor said. He added,
however, that identity cannot be ascribed on the basis of function,
because the tasks performed by a particular piece of software are
invoked at the direction of the user.
Because of software's underlying fluidity, however, definitional
OCR for page 49
IS SOFTWARE A SPECIAL CASE?
49
schemes can quickly become meaningless, Esther Dyson cautioned.
For example, she said, the popular spreadsheet program Lotus 1-2-3
was initially viewed as a user application for performing accounting
operations. But users have discovered the broader utility of the software.
"It isn't just interactive; it's a creative tool. If you perform a sequence
of actions in 1-2-3," she explained, "you may end up creating [a new]
application. You define the sequence of application actions, give it a
name-call it a macro and you are suddenly using an application as
a language, and you have created potentially-a new piece of intel-
lectual property within the old one.
"So, the stuff is very fluid. You can't say this is an application; this is
a language." Therefore, she said, "LYlou don't want to make rules that
apply to applications versus language versus interfaces without under-
standing that in the end these might be the very same things."
Similarly, particular functions can be embodied in either software
or hardware, and "in most cases the preferred embodiment will change
over time," said John Shoch, general partner at the Asset Manage-
ment Co. Still, each advance in hardware has the direct effect of ex-
panding the role of software.
Because of this continuing evolution, Harry Reinstein of Aion pre-
fers to conceptualize software as componentry incorporated into a
never-finished product. He suggested that very few software products,
even the largest ones, are fully independent entities. "We no longer
build complete systems. . .," Reinstein said. "We build components
that must, to be useful, work with other components, and that is why
the issue of interfaces is absolutely critical to this industry." Restrict-
ing access to software components, he maintained, would suppress
innovation, hamper the entry of new firms into the industry, and
limit the utility of software. Again, the issue is one of balance. Pro-
tections should prohibit copying of components, he said, but they
should not dampen competitive activity that builds on existing soft-
ware to develop new applications.
THE INFLUENCE OF THE MARKET
Although they confer ownership rights that vary in nature, copy-
rights, patents, and trade secrets are, in part, measures that help ensure
the lead-time advantage. Exclusivity, however, carries a risk, especially
if it results in a product whose functionality is isolated from that of
other offerings on the market. Interoperability, achieved by licensing
or by allowing the free use of program-to-program interfaces, proto-
cols, languages, and other types of interfaces, can enhance the value
of an individual software offering. It increases utility for computer
OCR for page 50
50
INTELLECTUAL PROPERTY ISSUES IN SOFTWARE
owners who may use the products of several vendors and who, for
example, may want one program to generate data that will be pro-
cessed by another application. In contrast, a product that is an entity
unto itself limits user choices and, consequently, restricts the size of
the product's potential market.
Therefore the marketplace sometimes provides incentives that
counterbalance inclinations to be overly protective and to regard all
"home-grown" innovations as proprietary. A firm that deems an interface
as proprietary to safeguard against the copying of the application
behind the interface may be making a tactical business error. Instead
of protecting the "corporate jewels," said Scott G. Davis, senior con-
sulting engineer at the Digital Equipment Corp., a proprietary stance
on interfaces may be "protecting the corporate fool's gold." Yet,
understandably, the more money, time, and personnel a firm has
devoted to developing an interface, or the more effectively it has
established a dominant market position, the stronger its urge to pro-
tect the interface for exclusive use.
In common with other industries, the software industry can find
especially precarious the footing on the tightrope between the need
to guard proprietary interests and the desire to cultivate a large pro-
duct market. In the software industry, however, the lack of common
understanding of what constitutes an interface can escalate "normal"
problems of contract interpretation when firms disagree on whether
an interface is open or on the nature of the rights of use accorded in
licensing contracts. In the view of some industry observers, firms
have promoted widespread use of particular innovations to cultivate
the market for their commercial implementations, but then have re-
versed themselves by declaring the innovations proprietary and de-
manding royalties for their use. These and other misunderstandings
arise, according to a position paper issued by the Association of Data
Processing Service Organizations (ADAPSO), because of "assump-
tions that are founded on differing views regarding the extent of
intellectual property claims."
SYMBIOSIS IN THE MARKET
In the personal computer side of the software industry, the compe-
titive environment has given rise to a new form of business behav-
ior that, according to Kapor of ON Technology, should not be jeopard-
ized by legal concerns. When Apple and then IBM disclosed the
architectures of their personal computers, they provided indepen-
dent software developers with the opportunity to write applications
for the machines without entering into a contractual relationship with
OCR for page 51
IS SOFTWARE A SPECIAL CASE?
51
the manufacturers. Thousands of software applications were written
by third-party developers, motivated by the prospect of market suc-
cess. In turn, those who succeeded by writing high-quality programs
benefited the hardware manufacturers by increasing the utility and
value of their computers.
"The economic cost of trying to achieve the same result if each
and every relationship between the software company and hardware
company had had to be negotiated- would have been so high that,
as a practical matter, it would have been completely impossible,"
Kapor said. All of this innovative, value-adding activity, he added, is
mediated through open interfaces, creating a "new industrial ecology."
This style of business relationship Kapor calls it a "nonrelationship
relationship" is a "very good way for pushing the whole system
forward."
This symbiosis is also reflected in the composition of personal-
computer software. "If you are running an application . . .," Kapor
explained, "you are actually using software that is made by about
four or five different companies, each of which is calling the other's
interface." But as in all segments of the industry, developers of applica-
tions for personal computers are becoming increasingly aware of the
risk of copyright and patent infringement, which could undermine
this form of business relationship and reduce the flow of benefits it
generates for users.
THE CASE OF INTERFACES
From single routines to large compilations of many programs, ele-
ments of software owe their value to their role in some larger system.
Within a single program, for example, individual routines are inter-
dependent, each one's task shaped by the functions performed by
others. In software systems, interdependency is magnified, as the
number of interacting entities multiplies to include many different
users, many different pieces of hardware, and many different programs,
remote and internal.
Interfaces account for much of the utility and behavior the value-
of software and hardware. Points of interaction between otherwise
independent components, interfaces link machine to machine, soft-
ware to machine, application to application, and user to computer.
As the complexity of hardware and software has grown and as the
push for interoperability has gained momentum, the number of inter-
faces of all types has multiplied, as have questions about the appro-
priateness of available intellectual property protections.
By design, external interfaces (as opposed to internal interfaces
OCR for page 52
52
INTELLECTUAL PROPERTY ISSUES IN SOFTWARE
that interconnect modules within a single software product) facilitate
cooperation with the outside world. From the perspective of users,
more cooperation, or compatibility, translates into greater value by
enhancing the capability of computers and by expanding access to
the software offerings of many different vendors. For vendors that
have invested in defining interfaces between proprietary applications,
evolving compatibility poses a quandary. Software interfaces are
often the product of significant investment, creative activity, and en-
gineering effort. To make an interface public is to share the fruits of
this work with the entire industry. And to the extent that functions are
bound up within an interface, they become vulnerable to copying.
However, companies that designate an interface as proprietary run
the risk of restricting the size of the market for their products.
The debate over proprietary interests in program code that ex-
presses external interfaces is intense and often divides the industry.
Those firms offering integrated systems solutions to computer com-
munications environments see component interfaces as crucial ele-
ments of proprietary value added. Those who produce software and
hardware components that must attach to and work with complex
information systems see proprietary interfaces as a barrier to market
entry. Thus, even if intellectual property law provides reasonable
protection for interfaces-the subject of a wide spectrum of opin-
ion business strategies dictate whether a firm will deem an inter-
face as open or proprietary.
Complicating the situation is the slippery identity of the various
classes of interfaces (see Box 3.21. Peter Schneider, IBM's vice presi-
dent for systems and programming, joked that interfaces are as diffi-
cult to define as pornography. '~We all know what an interface is,"
he said, "but none of us will have the same definition." What to the
original designer is a self-contained subroutine-and not an interface-
may be a convenient point of attachment to the designer of another
product, who may also want to exploit some of the functions performed
by the original.
The issue of whether a specific interface should be viewed as pro-
prietary or, because of its utility to users, as open and appropriate for
public use has many facets. For example, computer languages func-
tion as interfaces in that they are used to interpret electronic input
and to formulate messages that direct a computer to carry out a sequence
of actions. Obviously, languages have great utility, but opinion is
divided on whether they can be protected by copyright law. A related
issue concerns the protectability of specific language phrases, or sequen-
ces of keystrokes, that direct a computer to perform a specific func-
tion.~ For users, copyrighting of keystroke sequences might mean
OCR for page 53
IS SOFTWARE A SPECIAL CASE?
53
BOX 3.2 1 NTERFACES AN D SPECI FICATIONS
An interface is the boundary between two environments. An interface
specification describes what happens on the "other side" of the interface
when certain specified information is moved through the interface; the
specification also describes what the responses might be to the environ-
ment from which the stimu lus came.
The specification of a human interface might tell you what the mean-
ing is of what you see on a screen and what will happen when certain
actions are taken. The specification might also describe the kinds of
information that can be dispatched from the environment on the other
side of the interface. Similarly, the specification of a networking interface
might describe the format of messages required for sending and receiving
information through the interface.
The key is the specification of the form of information that crosses an
interface, plus a description of the meaning of the information crossing
the interface. The specification says nothing about implementation, only
information and behavior.
Scott G. Davis, Senior Consulting Engineer, Digital Equipment Corp.
that commands for the same function will vary from program to pro-
gram.
Issues such as these, said Ingari of Lotus, have made interfaces
"one of the nastiest and most difficult areas" for the software indus-
try to reckon with. And nowhere do the issues become more proble-
matic and more contentious than in the visual and behavioral domain
where machine and human interact, the user interface. Increasingly,
the "look and feel" of the user interface is becoming the definitive
attribute of software: the more intuitive an application's method of
operation and the more appealing and the more informative its graphi-
cal display, then the better the working relationship between user
and software and the more powerful a tool the computer becomes.
User interfaces are also emerging as the primary asset of firms that
specialize in software development and of those that offer entire in-
formation systems. "Increasingly, the economic value is absolutely
inseparable from that part of the program that the user directly inter-
acts with and experiences," Kapor said.
Debate over what is and what is not protectable in user interfaces
has spawned a rash of "look and feel" lawsuits. The central challenge
to judges in these cases (who will vary in their technical sophistica-
tion) is distinguishing the elements of interfaces that are protectable
OCR for page 54
54
INTELLECTUAL PROPERTY ISSUES IN SOFTWARE
expressions from their underlying ideas, which should reside in the
public domain. But some software designers doubt whether the dis-
tinction can be made.
"There is something funny about interfaces in which idea is bound
with expression," Aion's Reinstein said. Added Kapor, "The prob-
lem is that our traditional distinctions between idea and expression,
as far as I can tell, always wind up tripping all over themselves when
it comes to software." And in user interfaces all of the peculiarities
of software as a technological entity are magnified.
The sections that follow provide a brief overview of the evolution
of user interfaces and discuss some of the factors that underlie inno-
vation in this important area of software.
Evolution of User Interfaces
User interfaces have been called the last frontier in software de-
sign (Foley, 1987~. As they improve, so does our adroitness in wielding
the computer as a tool. Simply put, each generation of improve-
ments in the graphical display and the behavior of programs has
made computers easier to use.
These advances stem from the ability of designers, artists, and en-
gineers to encapsulate useful metaphors in electronic form. Perhaps
today's best known metaphor-based interface is the desktop, as em-
bodied in Apple's Macintosh computer and in several other systems.
Another successful interface is the electronic spreadsheet's two-
dimensional field of rows and columns and its internal logic that
meshes with the user's natural way of thinking and working.
Both examples demonstrate the benefits that result when appear-
ance and behavior are successfully mated in a well-designed interface.
The first electronic displays, in contrast, did not achieve this match.
According to Apple's Tognazzini, these early interfaces resembled
mechanical teletype machines, but with an important difference that
frustrated more than a few users. "Things came 'kerchunking' up from
the bottom of the display," he recalled, "and eventually kerchunked
off into infinity at the top of the display forever.... When somebody
wrote a routine that would allow you to scroll downwards, we were
all blown away. By slavishly adhering to a limited metaphor, the
original designers had lost a new power that an electronic display
could have provided- namely, downward review and scrolling."
Although today's interfaces mark a significant advance over the
"Stone Age" of interactive computing, they too will be deemed primi-
tive by the standards of the not-too-distant future. The most ambitious
developmental efforts seek to create artificial, or virtual) realities,
OCR for page 55
IS SOFTWARE A SPECIAL CASE?
55
three-dimensional renderings that simulate actual environments and
are responsive not only to keyboard commands, but also to speech,
touch, and even eye contact. Advanced flight simulators, which pro-
duce the imagery and "orchestrate the sound, force, and motion that
approximate the aerodynamic behavior of an airborne plane" (Foley,
1987, p. 127), serve as an example. Industry visionaries predict ad-
vances that will enable personal computer users to make their own
animated movies and, in essence, their own artificial realities. "So,
'you ain't seen nuthin' yet,"' said Tognazzini.
Where Does Innovation Lie?
While creativity, superior design, and sweat-of-the-brow program-
ming effort underlie all good software, high-quality user interfaces
may rank as the superlative example. An embodiment of art, human
intuition, and elements of various science and engineering disciplines,
interfaces are the products of a process that stands out because of the
intensiveness and complexity of the design effort required to produce
what some call "aesthetic functionality."
Compared with software applications alone, said Spinrad of Xerox,
"there is a different kind of invention and a different kind of creativ-
ity required" to develop a user interface that complements the way
people think. Interface designers, he continued, must have the skills
of cognitive scientists and a "gut understanding of what you can or
cannot achieve computationally."
Tognazzini characterized interface designers as illusionists who,
unconstrained by their medium, create their own natural laws. The
goal, he said, is to "create an illusion that doesn't break down." That
is, the behavior and the visual appearance of the objects in the illu-
sion created on a computer screen, be it a spreadsheet display or a
flight simulation, must mesh perceptually with all applications that
use the interface. "There is a paradox," Tognazzini said. "The simpler
the system that you sit down to use, probably the more complex the
design process that went into it. The more obvious the feature, the
more difficult or creative it was to generate that feature. For ex-
ample, pull-down menus and overlapping windows seem like obvi-
ous solutions, but they required years and years of careful experi-
mentation and playing before we hit upon them."
Iteration, experimentation, and research on user behavior and psy-
chology are involved in the selection of graphical symbols that best
represent functions, objects, or ideas on the screen, according to Ingari
of Lotus, who likened the process to the evolution of written language
from hieroglyphic figures. But efforts devoted to achieving a visual
OCR for page 56
56
INTELLECTUAL PROPER ISSUES IN SOFTWARE
connection with the user constitute only one element of the process.
In tandem, the design team must also work on the "back side" of the
interface, conceiving, structuring, and implementing the data struc-
tures and other software layers that underlie the behavior of the in-
terface and complete the cognitive link to the user. If successful, the
development effort results in an organic work, a merger of form and
function.
"The original version of [Lotus] 1-2-3 and its interface required a
great deal of hard work hundreds of hours, multiple iterations,"
explained Kapor, co-developer of the popular spreadsheet program.
"It was very nonobvious, and it was tested on users .... It would
certainly require a lot less effort to design a spreadsheet that used the
same menu tree because you wouldn't have to go through that."
Ingari maintained that understanding the complexity of the design
and development process will give a "very clear sense of the differ-
ence between the pieces of interfaces that should be and will be in
the public sphere and the pieces of the interface that must be protected
because they represent the essence of the work that is done to create
value." But others were less certain that the innovation within a user
interface can be dissected from the entirety of the work. "We have
this problem," said Davis of MIT, "that the innovation is the expres-
sion, is the value, and they become inseparable."
Under copyright law, however, some courts have split user inter-
faces into two components the screen display, which is viewed as a
pictorial or an audiovisual work, and the underlying program, which
is deemed a literary work. Even though they are embodied in a
single technical product, the two copyright categories are accorded
different rights under the law, explained Goldstein of the Stanford
Law School. The Copyright Office has taken the position that ". . . all
copyrightable expression owned by the same claimant and embodied
in a computer program, or first published as a unit with a computer
program, including computer screen displays, is considered a single
work and should be registered on a single application form."
To Kapor, this legal parsing ignores the "organicity" of the user
interface, akin to describing the human senses of touch, vision, and
speech without recognizing the role of the brain. The user interface-
both its appearance and its behavior "is not separable from the pro-
gram. It has roots potentially in every single line of code, in every
algorithm ...." Yet, said Reichman, "A merger of form and function
is precisely why copyright laws everywhere tend to reject industrial
designs. In the United States, this rejection is accomplished by a
doctrine of separability that was applied to industrial art, but not to
OCR for page 57
IS SOFTWARE A SPECIAL CASE?
57
industrial literature. This distinction is totally incoherent and ulti-
mately indefensible."
The unitary nature of user interfaces notwithstanding, the issues
at the heart of pending "look and feel" suits entail disentangling the
innovative elements of products from those elements that do not
merit protection because, for example, they are more appropriately
viewed as ideas or they do not reach the legal threshold for original-
ity. For now, these issues seem to lack conceptual clarity. Yet, as
Dyson explained, resolving the legal ferment that surrounds software
in general and user interfaces in particular requires assigning value
to the elements or combination of elements spawned by creativity
and superior engineering. "This," she said, "is what we want to
provide incentives for."
SUMMARY
Is software a special case, different from other technologies in the
ways it is designed, made, and used? Or, as Reichman contended, is
it another subset of advanced industrial design whose uncertain sta-
tus in systems of intellectual property law has never been effectively
addressed?
Software's characteristics- both positive and negative are relevant
to assessments of the adequacy of intellectual property protections
for the technology. Some familiarity with the distinguishing features
of software is essential for assessing how well law and technology
mesh. Likewise, appreciation for the process of creating software
from idea to marketable product-aids understanding of how the
law can foster or hinder innovation.
NOTE
1. lathe Lotus Development Corporation a. Paperback Software International and Stephen-
son Software, Limited (Civil Action No. 87-7~K, U.S. District Court for the District of
Massachusetts, 740 F. Supp. 37 Dune 28, 1990]) case addressed this issue at length.
OCR for page 58
-
Even the possibility that the legal basis for a stable, functional
marketplace for computer software might be threatened is enough
to create alarm in the industry, . . . one of the few high-tech
industries in which U.S. firms still enjoy a commanding position
in international trade.
Lewis Branscomb, Director, Science, Technology and Public Policy
Program, Harvard University
As an attorney, I want to make it possible for him [the business-
man] to be able to get back something on the R&D investment,
which today can run millions and millions of dollars.
I. lancin, Ir., Counsel, IBM Corp.
The purpose of the Constitution is to protect originality and
useful originality. So, if you spend $3 billion doing something
fundamentally useless, the Constitution doesn't really care.
Esther Dyson, Publisher, "Release 1.0"
[T]here is a stultifying, dulling effect in some cases subtle, [in
others] not so subtle- [resulting from] the confusion that has
arisen in this field, which is slowing down activity. It is slowing
down the small companies, . . . and it is slowing down the large
companies.
Robert Spinrad, Director, Corporate Technology, Xerox Corp.
Copyright is procompetitive. It allows the competitor to
enter a market by independently creating, via his own R&D,
a competing product.
Howard G. Figueroa, Vice President, Commercial and
Industry Relations, IBM Corp.
We can be hurt in our company by too much protection
or too little protection.
Frank Ingari, Vice President, Spreadsheet Division,
Lotus Development Corp.
Representative terms from entire chapter:
software development
