************************************************************* * * * TASK-CENTERED USER INTERFACE DESIGN * * A Practical Introduction * * * * by Clayton Lewis and John Rieman * * * * Copyright 1993, 1994: Please see the * * "shareware notice" at the front of the book. * * * ************************************************************* * * * * * * * * * * * * * * * v.1 * * Appendix L * * What Can You Borrow? A Quick Introduction to Copyrights * and Related Legal Stuff, as of 1994 * * If you read computer magazines or the business press, you know that many of the big software companies have recently been embroiled in legal battles with each other over claims of copyright violation. That fact reflects the current state of the copyright law: it's very confused. Copyright law was developed primarily to protect printed matter, and courts are still struggling to decide how to apply that law to the computer software, especially user interfaces. Because the law is unclear and rapidly changing, we can't give you firm advice on exactly what you can borrow from other interfaces. But we can give you some background that will help illuminate the issues the courts are struggling with. And, although we aren't patent or copyright attorneys, we can define what we perceive as fairly clear boundary markers: things you certainly can borrow and things you certainly cannot. Our practical, procedural advice is that you should build your interface with those boundary markers in mind, then work with your company legal staff to check out the gray areas. --------------- L.1 Background --------------- We'll start with the background. In the United States there are four main legal techniques for protecting "intellectual property," which is what the law calls novel ideas that people invent or create. The four techniques are trade secrets, trademarks, patents, and copyrights. All are intended to encourage creativity and commerce by giving people some kind of ownership in the fruits of their intellectual labor and by making their creations available to the public. TRADE SECRETS are simply things that a company doesn't reveal about its product. Most software code is protected this way. The source code -- the human-readable Fortran or C or Pascal -- doesn't come with the package when you buy a program for your personal computer, so you can't copy parts of it and use them to build a different program. Various laws allow the company to prohibit employees and former employees from passing secrets on to other companies. Obviously, trade secrets don't protect the parts of the interface that users can see, but the underlying implementation is usually secret. TRADEMARKS don't protect software itself. Instead, they protect the graphics or words that a company uses to identify its products, so other companies can't confuse customers by using similar identifiers for their products. It takes time and effort to acquire rights to a new trademark, and protection can be lost if the public starts to think of the trademark as a generic term. This happened to both "aspirin" and "nylon," for example. To prevent this, major companies will aggressively encourage you to identify ownership of their trademarks if you use them in your documentation. This is the reason for notices of the form "BigGraph is a trademark of BigCompany, Inc." that you often see in computer publications. Trademarks sometimes appear as a part of an interface, such as the stylized apple in the Macintosh menu bar, which is a trademark of Apple Computer. PATENTS give inventors exclusive rights to machines or processes they've invented, for a period of 17 years. Patents are relatively difficult and expensive to obtain, and before 1981 the patentability of software was uncertain. Today software patents are fairly common, including some covering interface features. For example, features of a program called "Zoomracks" were patented, and that patent had to be licensed by Apple Computer when it produced HyperCard. Patents protect an inventor's ideas from more than copying: they also protect the ideas from being used by someone who reinvents them. This means you can infringe a patent without ever having seen the inventor's work! Some of the requirements for a patent are that the idea be substantially innovative and original, that the inventor disclose the idea in sufficient detail that other people can apply it when the patent protection expires, and that the exact boundaries of the new idea -- the "claims" of the patent -- be spelled out. COPYRIGHTS are currently the most important form of intellectual property protection that you'll deal with as an interface designer. Copyrights were originally developed to prevent unauthorized copying of printed text, graphics, and audio-visual recordings. Their protection has been extended to computer software, in part because the physical process of copying software is similar to copying text or recordings, and in part because the availability of patents for software was uncertain. A copyright is easy to acquire. As soon as you create something, you (or your employer) own copyright to it. If you publish what you've created, then you should register it with the US Copyright Office and put a notice on copies that you distribute: "Copyright 1995 by Joe Programmer." Failure to do those things doesn't completely destroy your rights, however. A copyright gives protection for the life of the author plus 50 years, or for 75 years if it's owned by a company. -------------------------------- L.2 What's Covered by Copyright -------------------------------- You should assume that all commercial software is protected by copyright, unless it comes with a specific statement giving you rights to copy it. But exactly what protection does that copyright provide? Copyrights protect the "form" of an idea's expression, but not the idea itself. For example, we, the authors, hold the copyright to this book. If you want to copy the chapter describing task-centered design, you need our permission (which we give, with restrictions, in the shareware notice). But if you want to use the task-centered design process, our copyright doesn't stop you. In fact, you could write your own description of task-centered design and publish it, even copyright it. You could do those things because the copyright on this book only protects the way we've described the process: the words, the graphics, the overall structure of the presentation. Unlike a patent, it doesn't give us any rights to the idea. The distinction between what's the "idea" and what's the "expression" is one of the important questions that hasn't been clearly answered for copyright protection of interfaces. The copyright statute provides very little guidance, so the courts have to decide each individual case by analogy to previous court decisions, most of which don't deal with software. One principle the courts rely on is that functional parts of the design qualify as ideas, not as expressions. So, for example, selecting from a menu is functional. That's an idea. Maybe it could be patented, but it can't be copyrighted. On the other hand, the graphical details and perhaps the order of items in the menu could be copyrighted -- unless they were specifically designed to improve the menu's usability (that makes them ideas), or unless they are the only way of making this menu work (that makes the idea "merge" with the expression). You can see that this is a slippery issue. There's a second important question about which the law is still unclear. If we go back to the printed-text foundations of copyright, we find that our copyright on this book prevents other authors from copying an entire section, or translating part of the book into another language, or outlining it, or producing a very close paraphrase. But it's obvious that the copyright doesn't stop anyone from using the same individual words and phrases we've used in some completely different order. If you want to publish a sentence with "task" or "design" or "it's obvious that" in it, you can. Individual words, common phrases, and even longer, anonymous texts that everyone knows (such as, "Why does the chicken cross the road..."), are in the public domain. Similar principles apply to interface copyrights, but it isn't yet clear what's a word-sized or phrase-sized chunk of an interface, or what's in the public domain, or what's a translation or a paraphrase. The courts have made some rulings, but the answer will change as technology and the law evolve. Both of these issues -- ideas versus expressions, and public domain elements -- are critical to the "look and feel" lawsuits that have seen so much coverage in the recent press. Is the desktop metaphor a functional idea, or is it one expression of an idea? And even if it is an idea, is it in the public domain? Some courts have recently taken the approach of breaking down an interface into its component elements and analyzing those separately for copyright violation, which may spell the death of the overall "look and feel" protection. But the issue is still undecided. ------------------------------- L.3 Practical Boundary Markers ------------------------------- With that as background, here are some of the boundary markers we promised. They define the current state of interface law as we see it, from a practitioner's point of view, not from an attorney's. They should help you decide what can or can't be copied as you design an interface. 1. Things you certainly can copy (unless the rights have been sold). - Anything produced by your company. - Things you've written earlier for your current company. - Things recommended in the style guide for the system you're developing under. - Things supplied as examples/prototypes in a commercial toolkit, programming language, or user-interface management system (often these require you to give notice, such as "parts of this interface are copyrighted by WallyWindows UIMS"). 2. Things you can probably copy -- but watch the news and check with your attorney. - "Common" ideas, such as windows as the boundaries of concurrent work sessions, menus for selecting commands, an arrow-shaped pointer controlled by a mouse, graphical icons to represent software objects. The problem here is making sure it's a common ("public domain") idea, not one developed by some company and stolen by a few others. - Sequences or arrangements of menu items, commands, screens, etc., IF the original program clearly orders the sequence to improve usability (i.e., if it's alphabetical, or most-common-item first), or IF there is only one or a very few other ways that it could be arranged (i.e., if there are only two items in a menu, then there are only two ways they can be arranged). - Icons ideas, commands, menu items, or other words that are obvious choices for the function they represent, so usability might be reduced if other words or graphics were used. An example might be the word "print" to stand for printing, or a computer-mouse icon to select mouse options (but don't copy the mouse graphic itself -- draw your own). 3. Things you can probably not copy -- again, watch the news and check with your attorney. - Sequences or arrangements of menu items, commands, screens, etc., if you're only copying the sequence order because it will make it easier for users of someone else's existing program to use your new program. - Icons, commands, menu items, or other words that are not an obvious choice to describe their function, even if they would make your program more usable for users of the original program. An example might be a database print command labelled "DataDump," or a mouse-options icon showing a cute little mouse with a checklist. 4. Things you can certainly not copy (unless you get permission). - Things you've written earlier for a different company. - An entire interface from another company's program, even if you implement it with all new code. - An entire detailed screen from another company's program. - Source code or object code from another company's program, even if you translate it into a different language. - Trademarks from other companies. If you need to use someone else's trademark, such as "Unixª" in documentation, be sure you credit the owner: "Unix is a trademark of Unix Systems Laboratories, Inc." - Patented features. Unfortunately, there's no easy way to discover what's patented. - Exact bitmaps of icons, words, or fonts. - Graphic details that define an interface's aesthetic look. ------------- L.4 Strategy ------------- As we noted earlier, the development process we recommend is to keep these boundary markers in mind, develop your interface, and then talk over your decisions briefly with your company's legal staff. If there's a central feature of the interface you're worried about, such as picking up an entire interface metaphor, you may want to get legal advice a little earlier. If you're an individual developer or a small start-up company, the same strategy should work, with a couple of modifications. First, attorneys are expensive. You should have one, but make sure you have a client-attorney relationship in which the attorney provides guidance and you do the legwork of checking out other programs, negotiating for license agreements, etc. Second, when you're making decisions such as whether to incorporate your business, how much of a contingency fund to maintain, and how much to charge for your product, you should consider the possibility that your system might unknowingly violate a patent or a copyright. ------------------------------------ L.5 Some Philosophical Observations ------------------------------------ The current state of the law makes the design of good interfaces unnecessarily difficult. This is largely because of recent court cases that extend copyright protection to functional interfaces. Historically, the court cases and the statutory law that defined copyright were developed largely for the protection of published text and entertainment (novels, music, films) that are typically used ONCE by each user. This law is fundamentally inappropriate for protecting functional interfaces, although perhaps not for computer games, for several specific reasons: 1. Copyright is explicitly prohibited from protecting ideas. But new ideas -- functionality -- is exactly what the law should be protecting and encouraging. Such ideas are the express domain of patent protection. 2. The effect of current copyright law is to give companies a monopoly on functionality that was created, not by them, but by the users of their products. It is users' efforts in learning a random arrangement of controls that makes the arrangement valuable when it is later incorporated into another program. Once again, patent succeeds where copyright fails: a patent can only protect useful novelty created by the inventor, not random elements that other people's acceptance might someday render useful. 3. The burden of determining which parts of a copyrighted interface are protected is placed entirely on the designer of a new program. This, too, differs notably from patent, where the inventor's claims list identifies specific issues of concern. 4. The copyright protection period of 75 years for a corporate author is unreasonably long. In the fast-changing world of software, it effectively gives the creator an absolute monopoly, as compared to the limited monopoly that both patents and copyrights are intended to confer. On the balance, then, patent appears to be more appropriate than copyright for the protection of functional interfaces. This is not surprising, since patent law was developed to support the innovation and distribution of functional ideas. However, patents also have their problems, including difficulty and expense of acquisition, difficulty of discovery, and a 17-year protection period that may be too long for the pace of software development. These issues would benefit from thoughtful legislative attention, since their continuing evolution in the courts is discouraging software development. We urge designers to investigate the issues on their own and to support efforts for rational legislation. ============================================================ Credits and Pointers ------------------------------------------------------------ The Communications of the ACM is a good journal to watch for recent news and practitioner-oriented discussions of intellectual property issues related to interfaces. Three recent articles of interest are by Paul Heckel, supporting patents for software; the League of Programming Freedom, arguing against patent restrictions on software; and Pamela Samuelson, reviewing recent copyright decisions: - Heckel, Paul. "Debunking the Software Patent Myths." Commun. ACM 35:6, (June 1992), pp. 121-140. - The League for Programming Freedom. "Against software patents." Commun. ACM 35:1, (Jan. 1992), pp. 17-22, 121. - Samuelson, Pamela. "Updating the copyright look and feel lawsuits." Commun. ACM 35:9, (Sept. 1992), pp. 25-31. An in-depth discussion of copyright issues, concluding that copyright can evolve into an effective protection for computer software, is presented in: - Clapes, A.L. "Software, Copyright, and Competition." Quorum Books, New York, 1989. For a layman's overview of general copyright and trademark law (not as applied to software), see: - Andorka, Frank H. "A Practical Guide to Copyrights and Trademarks." Pharos Books, New York, 1989. For those interested in a lawyer's point of view, one place to look is the Software Law Journal. An article summarizing the issues we discuss, current as of the end of 1992, is: - Gollhofer, R.A. "Copyright protection of computer software: what is it and how did we get it." Software Law Journal 5 (Dec. 1992), pp. 695-713. [end credits and pointers]