TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Copyrighted material in manuals? From:"Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA> Date:Wed, 24 Feb 1999 11:10:01 -0700
Eric L. Dunn wondered <<If you are going to produce a software
help/instruction manual/book, how much information can you 'lift'
from the instruction manuals that come with the software. In most
cases all the information already exists in the documentation that
came with the software. What is usually lacking is either the
organisation or a few how-to, task oriented instructions.>>
The short legal answer is that you can't lift any of it without the
permission of the copyright holder (usually the publisher, but not
always); this isn't a literary situation, or academic research, for
which there are some helpful rules of thumb concerning "fair use for
the purposes of scholarly review". In your case, I suspect a court
would judge this as simple theft for the purposes of avoiding doing
the work yourself.
The longer answer has two components. First, facts per se are not
copyrighted, only the manner in which they're expressed (i.e., the
wording). What this means is that you can use the existing documents
as the basis for your own writing, thereby eliminating much of your
research, provided that you test the results; given the errors that
creep into documentation, you don't want to be in the situation of
preserving someone else's errors in your own documentation. Second,
simply cutting and pasting text is probably doing your audience a
disservice. It's possible (perhaps even likely) that the
characteristics of your audience differ enough from those of the
original documentation's audience that simply copying the text will
fail to communicate; even if the text is adequate, it may not be as
well written as text you can create yourself, and won't apply as well
to the specific context of your product's users. There are very few
helpful shortcuts in technical communication, and blindly copying
someone else's documentation isn't one of them.
