Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
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
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
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."
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.
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.
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
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
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
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
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
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
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,
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
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
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.
- 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.
