Re: Contract Wording, Again (terribly long and boring

Subject: Re: Contract Wording, Again (terribly long and boring
From: "Stephen D. Martin" <smartin -at- RC -dot- GC -dot- CA>
Date: Tue, 9 Sep 1997 11:43:37 -0400

Tim Altom wrote:

> In another message, Cindy Bailey is quoted as saying:
>
>> This means that you can bring your newly learned skills and
>> knowledge on documentation process with you, but you CANNOT share
>> with the client such information as: "Well, my last client decided
>> not to have a section on Blah-Blah because they did market research
>> that revealed it was counter-productive." That market research may
>> have given your last client an edge in the marketplace and this
>> information should absolutely not be shared with another client.
>
> The major point here, for me, is that her example is a terribly gray
> area. If a client has actually done such research (and none of ours
> do any such research, and won't let us do it, either) then the facts
> they've uncovered may have proprietary stamps on them both literally

I'm not sure what you find so "terribly gray" about Cindy's example. If
a client has done any research then they've made the effort, they've
paid the money for it therefor the results of that research are theirs
and not yours to disemminate unless you specifically get your former
employers permission to pass this data around. The only exception would
be in the case of common knowledge/obvious truth.

> and figuratively, but since the revelation is about the process of
> making manuals, it can't be forgotten and left behind no matter how

1) If you care to re-read Cindy's posting there was no mention made of
forgetting anything, simply the fact that one could not relay
proprietary information from a former client to your present client.

2) The revelation is not about the process of making manuals, it is
about the creation of specific manuals for a specific product from a
specific company.

Passing along such information has the potential to be dangerous to both
the contractor and the client. It is very easy for a contractor to earn
a bad reputation among past, present and potential clients since Company
A may not appreciate one passing along "their" data, Company B (to whom
the data has been passed), will begin to wonder what data of theirs will
be "given away", and Company C may want the inside scoop on Company B,
but not at the risk of Company D getting the scoop on them. If Company
A learns that you are passing around their data you may also find
yourself on the wrong end of a lawsuit.

As for the client, it is possible that Company A's findings will not
apply to Company B's product (i.e. Corel discovers x, y, and z about
users of WordPerfect, but the exact opposite could be true about users
of Microsoft Word). If Company B chooses to act now (a foolish move in
any case), they may end up shooting themselves in the foot when their
user base doesn't react as expected. If Company B chooses to verify the
information, they're wasting short-term time and money for a dubious
future gain.

> If a client finds out that Esperanto increases readership by forty
> percent, that fact can't be kept under wraps. Manuals, by their

Such findings are fairly obvious, but more likely misleading. Whether
the client printed in Esperanto, or Chinese, or Swahili, they will gain
in their *potential* readership, but how many unilingual Esperanto,
Chinese, or Swahili readers are actually going to buy the manuals? This
is the real question, and the answer would belong to whomever choose to
put forth the time and money to discover it.

> Other information, such as test data, service secrets, and microcode

I am curious as to why you think that market research results are any
different from test data or service secrets.

> Say that a client's high-power ad agency comes up with a killer
> layout. Your next client wants you to use the same layout. Layouts
> aren't copyrightable. They're free for the taking. But is it
> ethical? Is it unethical to just reuse an old template that you've
> developed? Is it even ethical for one of us to point out a
> mistake in a document if we're only able to spot it because we've
> worked with a prior client's data? Gray, gray, gray.

From my vantage point there's not a thing grey or unethical about
anything you've presented, could you perhaps exmplain how any of it
could be? The most basic layout is:

Title
Table of Contents
Body
Index

and it has become THE standard throughout the world, but before it
became the standard someone had to have created it. If it's unethical
to copy somebody's layout then everyone of us is guilty.

> Is there a way to draw a general line around the subject of proprietary knowledge at all?

non-proprietary knowledge:

I, as an individual or as a representative of Company A, can go to the
CIA World Fact Book, Encyclopedia Brittanica, etc., and discover how
many people speak a given language, which translates into potential
readership for manuals printed in that language. I can also arrive at a
(very) rough percentage estimate of that readership through simple
mathematics.

non-proprietary knowledge:

A third party such as PC Labs or the Association of Manual Writers
conducts a study to discover how many speakers/readers of Chinese would
buy MS-Word, how many would buy WordPerfect, and how many would buy
GeeWhiz WordPro; if the manuals were printed in Chinese.

proprietary knowledge:

Company A directs it's marketing department, or contracts out to Gallop
and Gallop, to discover how many of the billions of Chinese speakers in
the world would buy their specific product if the manuals were printed
in Chinese.

Of course now I'll be proven completely wrong.

TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html


Previous by Author: Re: documenting Unix command lines; more than one line
Next by Author: Re: Using technical information from another company
Previous by Thread: Re: Stealing Technical Writing (Was: Using...)
Next by Thread: Ballooning Help File Size


What this post helpful? Share it with friends and colleagues:


Sponsored Ads