Conference 7.286::digital

Nope, for me it prints "You may not copy, reproduce or transfer PAKs to any
entity outside or any organization inside of DIGITAL. If such copy,
reproduction or transfer occurs, it is a violation of Pat Sweeney's employee
agreement."

Ha-ha.

Actually, it prints for me:

"
                            U.S. INTERNAL USE ONLY


             INTERNAL PAKS ARE FOR DIGITAL INTERNAL SYSTEMS ONLY
    THEY SHOULD NOT BE GIVEN OUT TO CUSTOMERS OR USED ON CUSTOMER MACHINES
"

So if you can get to that server, I guess you can copy them internally to your
heart's content.
				/AHM

Alan, what you quoted is on the first page.  After you have entered the product
key name (in this example, VAX-VMS), you get the following at the top of the
screen:
  ___________________________________________________________________________
    NOTICE TO EMPLOYEES ORDERING PRODUCT AUTHORIZATION KEYS FOR INTERNAL USE
  ---------------------------------------------------------------------------
   You may not copy, reproduce or transfer   PAKs   to any entity outside or
   any organization inside of DIGITAL. If such copy, reproduction or transfer
   occurs, it is a violation of your employee agreement.
  ***************************************************************************

followed by instructions on how to proceed.

The internal transfer thing probably has something to do with export licensing.
It also keeps the responsibility right on YOU if an internal PAK is discovered
at a customer site.

On the other hand, it could be to guarantee that DIS could someday bill our
cost centers a monthly charge for each PAK we are using -- and if we start
transferring them around this would never be possible.

/john

>   any organization inside of DIGITAL. If such copy, reproduction or transfer
>   occurs, it is a violation of your employee agreement.

So, exactly, what part of the employee agreement does this violate?  And who
has so determined (DEC legal??)?

-Joe

I'm assuming, of course, that someone has sent the VTX PAK system
mail pointing out this possible error in wording and asking for
clairification?

Unless, of course, it's just more fun to debate it here first?

- greg

Oh well, a less acerbic answer:

We have a need to control software within Digital somewhat better.
There's a variety of reasons including export control, inappropriate
transfer to customers, taxes, version/field-test control, tracking,
etc.  Not to mention the rapidily blooming issue of license fees we
must pay to third party software vendors when we use their products.

The people we pay to build our administrative systems are not necessarily
experts in every detail of legalisms, and various other issues raised
in the preceeding paragraph so, like any other DEC employee, they can make
a mistake.  I'm not saying they have here, but a little slack might be cut.

The implementation of "internal PAKs" is imperfect; we can and should
have done better.  I won't go into the reasons we didn't here --- the
admin people aren't culpable for it anyway.  Just the opposite actually.

Re .2:

I followed Pat's instructions and *attempted* to access the system - that
was the strongest message I saw.
				/AHM

    re: .4 Mail to follow up .0 to the VTX PAK system is forthcoming.  I
    wanted to obtain some assurance that indeed all of us see the same
    screen.
    
    In the vein of .4: "We have a need to control" what arbitrary messages
    appear in a flash on my screen that refer to my employee agreement.
    Policies, export control, etc. are all valid _policy_ concerns but
    where's the tie to my employee agreement?  -- I know - it makes the
    message seem a bit more important, doesn't it?
    
    This is a company based on trust, or so I thought.  The "threats
    per day" regarding my conduct statistic is just another sign of the
    messages becoming "DON'T" as opposed to "DON'T...BECAUSE..."

    For whats its worth,
    
    I think the issue is making sure we do not continue to give free
    copies of software to the customer. I believe that if customers
    use our software for free, an argument can be made that all customers
    do not have to pay for the software, and there goes our revenue,
    profits, etc. 
    
    Johnse
    

    When I was in OTS (Officer Training School), we operated under an honor
    code with regard to lying, cheating and other useful activities.  A
    favorite technique used by cadet officers to discourage behavior they
    found objectionable was to loudly intone the opinion that this behavior
    constituted "AN HONOR CODE VIOLATION".  Methinks the employment
    agreement is being used here in a like manor.
    
    Or does the employment agreement explicitly require you to adhere to
    all company policies?  I haven't read mine since I signed it 4 years
    ago.
    
    -dave

"Violation of your employee agreement" may well be a poor choice.
It strikes me as heavy-handed as well.  However, the author may
have really meant "your general obligations as an employee" and
not necessarily the signed form.  Worth find out.

There are at least four DECs/Digitals of major significance:

	Engineering
	Sales/service/field
	Administration/buracracy
	Manufacturing

You could write that list a hundred different ways and I don't mean
to lessen or raise the significance of any group by how I listed them.

I just wanted to note that my observation is that there is very significant
differences among them with respect to culture, "the Digital way", "do
the right thing", style, values, etc.

The effect of that is that the tone and style of messages varies a
great deal depending on the authoring group.  What might be offensive
in engineering might be run-of-the-mill in manufacturing, and vice-
versa.

Personally, I believe the above is responsible for many misunderstandings
a large number of which get discussed in Digital.note.  Folks sieze on
a single word or phrase in a memo, policy, note, whatever and get all
upset when the author never intended the message that got received.

Not that there aren't bad things, bad policies, wrong memos; just that
perhaps half of the time it is only a misunderstanding that is worth
resolving at the simmer rather than flame level.

This note isn't even a particularily good example (or maybe it is),
just the instance when I decided to enter comments that have been on
my mind for some time.

- greg

    Hmm, after reading all the replies here, I came to wonder about
    something... 
    
    In the past i've helped sales support folks out occasionally by getting
    them VTX PAK's for their workstations - to get 'em up and running
    (internal use only).  Of course I do so with the stipulation that this
    is _my_ PAK, and they are not to proprogate it to anyone else.  But,
    what are the limit's of my liability for the PAK if the system is 
    sold/loaned to a customer, with my PAK, without my knowledge?? 
    
    What about other instances where other employess have used keys
    under thier badge to help other internal sites (i.e., ACT) out
    but don't know the future for the systems they helped set up?
    
    Of course TSP's could have been used, but that's water under the
    bridge now...
    
    -Jp

    n
    I wonder if the PAK verbiage wasn't simply adapted from the existing
    verbiage on the ADS (Automatic Distribution System) order form.  The
    form is used to order software kit updates and documentation updates to
    be used internally.  The back of the form has a discussion of the
    importance of protecting DIGITAL's investment and of the copyright and
    trade secret laws and software licensing.  It says also,
    "All software is issued to you for internal use only.  Under Digital
    policies, you may not transfer software to any entity outside Digital. 
    If such transfer occurs, it is a violation of your employee
    agreeement."  The form has a place for the orderer's signature and
    the date, and badge number.
    
    Marge
    
    reference:  form EN-02286-10-00000(361) I believe the form has been
    around for some number of years...

    re: .10---It was exactly this concern (prompted by the requirement
    that getting a PAK from VTX requires one's badge number) that made me
    decide not to get any PAKs from VTX.  If I were to get a PAK, and it
    were to get "loose" into the user community somehow, my liability
    is effectively unlimited.  No thank you.
        John Sauter

>If I were to get a PAK, and it were to get "loose" into the user community
>somehow, my liability is effectively unlimited.  No thank you.  John Sauter

Isn't the whole idea of PAKs to have a way to point the finger at the person
to whome the PAK was originally issued?

Aren't all PAKs theoretically single use licenses?

Are the PAKs you're using on Sauter "stolen" from someone else?

/john

    re: .13
    
    I don't know about all PAKs being single-use licenses, or being
    identified with the person who signed them out.  Maybe there are ways
    to create PAKs that are not identified with an individual.  I do know
    that the PAKs I use on the workstation under my desk ("SAUTER") were
    provided with the software kits on the network.  If the person who
    provided them is making a mistake, it's that person's mistake, not
    mine.
    
    That may sound like I'm placing my head in the sand.  Considering that
    the alternative is to expose myself to what appears to be unlimited
    liability, I choose the sand.  I wonder how many other people have
    made the same choice.
        John Sauter

Time for me to jump in.....

As one of the group who worked on the PAK generation system, I can say that
it was the business' decision to place that warning on the VTX interface.
It was believed to be the same agreement that one signs when ordering software 
via a internal order. The reason we ask for Badge number should be obvious.
We dont want anyone but employees to be able to get PAKS.
How else to prove it, except by asking for some info that only the employee
would know?

Big Brother is NOT watching, so dont get paranoid! However, do keep in mind
that if an internal PAK should ever be found at a customer sight it could
theoritically could be traced back to the requestor. So what is my message?
Just use common sense and protect the information on the systems that you
are responsible for, if somebody else wants to get paks tell them that it is
easy enough to get their own via the VTX system.

RE. .12

I also am curious, if you didnt get your paks from VTX then you must have 
renegade copies and have asked others to do what you were not willing to do.
(-:

- George

    The warning on "Digital-to-Digital" transfers on the VTX PAK system is
    _not_ the same as that which appears on the printed form.

    "Use common sense" is _not_ the form of the reminder: "violation of your
    employee agreement" is the form of the reminder.

    This note is _not_ about the unauthorized loaning of software to
    customers.  It is formally conceded that it is a terrible thing for an
    employee to do.

    This note is about restrictions on Digital-to_Digital transfers of
    Digital assets (ie PAKs for Digital's software products) and
    gratuitous threats connected to one's employee agreement.

    Common sense will tell you that if you give a traceable PAK to another
    Digit, who then slips it to a customer, you will get the blame.
    I do not believe that simply giving a PAK to another Digital employee
    is a violation of the agreement that I signed (unless it is construed
    as insubordination), HOWEVER, if all the evidence points the finger
    at me, the end result is likely to be the same.
    
    Bottom line:  getting your own PAKs and letting others do the same
    		  is cheap insurance.
    
    Kevin

>    I do not believe that simply giving a PAK to another Digital employee
>    is a violation of the agreement that I signed (unless it is construed
>    as insubordination)

Although it *is* misconduct to violate export laws, I don't remember signing an
agreement that had anything to do with conduct.  It was 14 years ago, though,
and my memory may not be good.  Perhaps I should go to personnel and ask to
see my file.

/john

    An interesting addition to the PAK stuff...
    
    	One of the biggest problems (numbers of calls handled etc...)
    here in the CSC/CS is the PAK crap.  Legitimate customers are always
    calling in, they've purchased a new version or product and the PAK
    didn't come in time, so we read them, over the telephone, the PAK
    (and say things like, "Do you believe that you have a legal right
    to this information?") - don't go to legal with this, I'm paraphrasing.
    	Now we've put in an enhancement to DSIN (customer dial in - also
    called digital software information network), so that the customer
    (if he's a VMS customer), gets an option TSP - Temporary Service PAK.
    The software (and this has been through legal, so don't get excited),
    prompts the user with the same question, "do you feel that you have
    a right to have this information?" (paraphrased).  If the answer is
    yes, he gets whatever PAK he needs.
    	
    
    

    Funny you should mention it, but I don't recall any reference to PAK's
    in my employee agreement at all.
    
    I must have missed it.  Of course, in 1979, I wouldn't have known what
    a PAK was anyway.
    
    The warning does seem a bit authoritarian.  Frankly, I ignored it.
    

    re: .15
    
    ``...if you didnt get your paks from VTX then you must have 
    renegade copies and have asked others to do what you were not willing
    to do.  (-:''
    
    Not so.  I don't know if the PAKs I have are renegade or not, but I did
    not _ask_ others to provide them, they were provided with the network
    kits without my asking.
    
    re: .17---even better insurance would be to not create PAKs of your
    own.  That shifts the risk to someone else.  Of course, if nobody else
    is willing to take the risk for you, then this isn't an option.
        John Sauter

What do you do when you have multiple operators/system managers?  One person
gets the pak and another one (of many) distributes it.  So much for 
traceability.

Internal PAKs do not represent single-use licenses.
They don't represent licenses at all.

We don't need licenses to use the software we own --- excluding
international transfer laws/rules/taxes that I don't understand.

They do represent authorizations.

John, your liability is exactly the same as it was before PAKs
were created and it is most certainly not "unlimited".

- greg

Like .15 was involved, I was one of a group of system managers who were part
of the "Software Keys Distribution Task Force" that set up the basic rules for
Internal U.S. Key Distribution.

We (the system managers) didn't want any tracability on getting a PAK, for
just the same reasons that everyone here is worried about. What if someone else
gives your PAK out to a customer? There is no way that you can protect yourself
against it... heck, if they don't have a copy of the actual PAK, you can always
pull out the information from the license database on your system.

When the 3rd meeting came up, we were forced (by upper management, we were
told) into the issue that they HAD to have tracability of some kind. We were
told that this was more for FYI for the groups that develop the different
products, that they wanted to use this to track site usage of a certain product
on the network, that current methods weren't good enough.

Though we kept trying to push, we got nowhere. However, we were assured that
the only information that was being recorded was the SITE that the paks were
given to. We were also told that the mechanism that asks for your badge number,
etc. is not being recorded, but is being used vs. the employee master file to
validate that you are a DEC employee. Since I wasn't in on writing the VTX
application, nor seen what the code actually does, I can't guarantee that upper
management didn't change this, and there's not a database storing each VTX PAK
transaction, but if you look at the authorization number, you'll notice that
only your site code is present.

We were also told unofficially that if a PAK was ever found at a customer
site, that that would not mean immediate termination, especially since we
made sure that they knew how concerned we were that a PAK could be stolen
from you without your knowledge. That an investigation would be launched into
the issue. And I'll tell you quite honestly from seeing an employee "almost"
terminated (being a system manager, I had to get system info on him and
participate in meetings with security), that if they can't tell certainly 100%
that you're to blame, I don't think they'd terminate you. It's my opinion that
the notice "breach of employee contract" was added so that you're aware of the
serious nature of the PAKs. Whether or not they can actually do that for an
internal transfer, I don't know, though for obvious reasons they don't want
people transferring it. I know we were told that it is an asset and should be
protected by the employee as any DEC asset he has under his control.

Now, the disclaimer. This was the procedure that we the system managers
ended up deciding on realizing that if we were too demanding, that management
would make their own decision. We were added to the loop give our recommenda-
tions to insure that it wouldn't cripple system management. This was also at
least 6-12 months before the VTX PAK distribution became available. After our
meetings, it was supposed to go before upper management, development groups,
and the LMF people. After we gave them these guidelines, we were out of the
loop. So, whether anything changed, I can't tell you.

But beware! We were told that after the VTX PAK distribution was enabled
for some time, they might change the mechanism more "to get more information for
development". I don't know what that means. Regardless, as someone said
earlier, just use common sense in using PAKs, and make sure you make other
people get their own! :-)

John

    re .19: (giving version limited PAK's out nearly autmatically)
    
    Makes me shudder - this is not the way to solve the perceived PAK
    problem!
    
    re most previous:
    
    To ask internal users to get PAK's for the SW they are using also
    has the flavour of "using what we sell" (in this case force the
    customers to use). Customer:"We got a lot of problems with PAK's,
    for instance entering them is a real pain". DEC employee:"I would
    not know about that - we are not using any".
    
    							    Heinrich 

    re: .23---Greg, I can't agree that my liability is exactly the same
    as it was before PAKs were created.  Before PAKs, I could get into
    trouble for giving a tape containing a software product to a customer,
    for example, and after PAKs this is still true.  However, before PAKs
    I could not get into trouble for giving a PAK to a customer (because
    they didn't exist) and now I can.  Furthermore, the risk that I will
    be blamed unfairly is greater, since if I create a PAK it has my
    "fingerprints" on it, and if some other employee should steal it from
    me and give it to a customer, I could be blamed.
    
    re: .24---I am glad to hear that I am not the only employee who is
    concerned because of the language of the PAK procedures.  I agree that
    the termination procedures require a large burden of proof of
    misconduct, so perhaps I am over-reacting, but I'd rather be safe than
    sorry.
    
    As a result of the reassurances in .23 and .24, if the situation arises
    where some software is available over the net that I want to run, but
    the provider of the software does not make a PAK available, I will
    consider using VTX to create myself a PAK.  I will, of course, be very
    careful that the PAK does not leave my machine.  Is it possible to get
    limited-time PAKs through VTX?  If it were that would reduce my risk.
        John Sauter

John, I'm glad you've switched from "now my liability is unlimited" to
a more realisitic statement that there is a slightly increased chance
thatyou might be asked if you transferred a PAK to a customer.

Your _liability_ however remains exactly the same.

... oh, I'm getting kicked off the system ... have to enter more later

- greg

    Of course, if we use the field test PAKS that come with products
    over the net and give them to our customers then one might presume
    the engineering people will disappear one-by-one.
    
    As to increased fear because when there were no PAKs we couldn't
    get in trouble for distributing them - give me a break!  I couldn't
    get fired for losing VAXstation 3100's before Jan. 11th, etc. etc.
    
    
    Don
     

				DIGITAL

			  EMPLOYEE AGREEMENT

In consideration of my employment by Digital Equipment Corporation (DIGITAL),
its successors and assigns, a Massachusetts corporation, I hereby agree as
follows:

1. I will make full and prompt disclosure to DIGITAL of all inventions,
improvements, modifications, discoveries, methods and developments (all of
which are collectively termed "developments" hereinafter), whether patentable
or not, made or conceived by me or under my direction during my employment,
whether or not made or conceived during normal working hours or on the premises
of DIGITAL.

2. Upon request by DIGITAL, I agree to assign to DIGITAL all developments
covered by Paragraph 1 and any patents or patent applications covering such
developments and to execute and deliver such assignments, patents and
applications, and other documents as DIGITAL may direct and to fully
cooperate with DIGITAL to enable DIGITAL to secure and patent or otherwise
protect such developments in any and all countries.  However, this Paragraph
2 shall not apply to developments which do not relate to the actual or
anticipated business or research and development of DIGITAL or its subsidiary
or affiliated corporations, provided that such developments are made or
conceived by me entirely during other than DIGITAL working hours, and not on
DIGITAL's premises and not with the use of DIGITAL's equipment, supplies,
facilities, tools, devices, or trade secret information.

3. I hereby represent that, to the best of my knowledge, I have no present
obligation to assign to any former employer or any other person, corporation
or firm, any developments covered by Paragraph 2.  I also represent that, to
the best of my knowledge, there is no legal prohibition including but not
limited to an agreement with any former employer that might prevent me from
performing my duties of employment with DIGITAL.

4. I will also assign to DIGITAL any and all copyrights and reproduction rights
to any material prepared by me in connection with my employment.

5. I will not disclose to DIGITAL, or induce DIGITAL to use, any confidential
information of other persons, corporations or firms, including my former
employers (if any).

6. During the course of employment by DIGITAL, I may learn of DIGITAL's
confidential information or confidential information entrusted to DIGITAL by
other persons, corporations or firms.  DIGITAL's confidential information
includes matters not generally known outside DIGITAL, such as developments
relating to existing and future products and services marketed or used by
DIGITAL and also data relating to the general business operations of DIGITAL
(e.g., concerning sales, costs, profits, organizations, customer lists, pricing
methods, etc.).  I agree not to disclose any confidential information of
DIGITAL or of such other persons, corporations or firms to others or to make
use of it, except on DIGITAL's behalf, whether or not such information is
produced by my own efforts.  Also, I may learn of developments, ways of
business, etc., which in themselves are generally known but whose use by
DIGITAL is not generally known, and I agree not to disclose to others such
use, whether or not such use is due to my own efforts.

7. At the time I begin my employment and during the term of my employment by
DIGITAL, I will not engage in or become employed by or act on behalf of any
other person, corporation or firm which is engaged in any business or activity
similar to or competitive with that of DIGITAL, unless such employment has
been approved by DIGITAL in writing and signed by an appropriate personnel
manager of DIGITAL.

8. In the event that my employment is transferred by DIGITAL to a subsidiary
or affiliated company (as the case may be), my employment by such company will,
for the purposes of this agreement, be considered as continued employment by
DIGITAL, unless and until I execute an agreement, substantially similar in
substance to this agreement, then in force in any such company for which I
become employed.

9. I hereby give DIGITAL permission to use photographs of me, either during or
after my employment, with or without using my name, for whatever purposes it
deems necessary.

10. Upon termination of my employment, unless my employment is transferred to
a subsidiary or affiliated company of DIGITAL, I agree to leave with DIGITAL
all records, drawings, notebooks and other documents pertaining to DIGITAL's
confidential information, whether prepared by me or others, and also any
equipment, tools or other devices in my possession which are owned by DIGITAL.

11. My obligations under this agreement shall survive the termination of my
employment regardless of the manner of such termination, and shall be binding
upon my heirs, executors and administrators.

							WITNESS MY HAND AND SEAL

			Signature_________________________________________(Seal)

			Date___________________________


WITNESS____________________________

EN-01078-06-REVB(646) (machine copy transcribed by JRC)

    re: .29---My memory is not as sharp as John Covert's, but 871.29 looks
    familiar to me; I suspect it is also what I signed, nearly 14 years
    ago.
    
    I don't see anything in 871.29 restricting the transfer of information,
    software or anything else from one part of Digital to another.
        John Sauter