*************************************************************
* *
* 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]------------------------------