Conference 7.286::digital

> 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.
> ----------------------------------------------------------------------------

  Maybe someone can point out where, in my employee agreement, it
  says *ANYTHING* about PAKs, let alone whether "copying" one
  (whatever *THAT* means in this electronic age!) is grounds
  for termination. Insubordination may be in there, but my
  supervisor hasn't mentioned copying PAKs either.

  Is anyone else getting as sick as I am about self-agrandizing
  groups making up rules about what causes they can fire us for?

  Is anyone else starting to see any need for a collective response,
  perhaps from an attorney, to management about these newly-invented
  "grounds for termination"?

                                   Atlant


P.S.: There's also the minor issue of "What an incredibly stupid waste
      of the company's valuable time and effort." But in my mind, that
      issue shrinks to insignificance compared to the "yet another group
      threatening to fire me" issue.

    Pretty soon we'll be evaluating whether it's more cost effective to use
    an outside product.  I guess we're already doing this.  One more PUSH
    NOT to use our own products.  I can expense a third-party product but
    management won't fund any cost center cross-charges.
    
    One of our Business Partner's just went to Microsoft.  Microsoft makes
    available via many servers ALL there products.  As an Employee or New
    Employee you're encouraged to use ANY and ALL of Microsoft's products
    and NOT someone elses.  Moreover, it's FREE no charge to the Business
    Units.
    
    	Regards,

$25 per PAK?  I doubt the product groups will see a a dime of that.

Does this means that if I get a paper PAK (because I got a new system)
that I can't share that PAK between multiple systems even though it
never came from VTX PAK.

    Maybe they're just preparing us for the day when none of the software
    is developed by Digital?
    
    So - is it a violation of the employee agreement to patch your system
    such that license lookup always results in success?
    
    Do the powers that be have any clue as to how much effort is wasted in
    maintenance of internal PAKs?  This is only going to make matters
    worse.

My opinion is that this latest threat has no basis in reality.  I've had
long talks with the manager of the group that runs VTX PAK.  The basic problem
is that Digital refuses to provide funding for this corporate resource - one
for which there is no alternative.  Thus the group has been forced to charge
its users.  All the income goes to support VTX PAK - none of it goes to the
product groups.

When this was put into place, I predicted that various groups would then
institute "PAK pools" so as to reduce their overall cost exposure.  This
indeed started happening, and I would guess that the VTX PAK group found
their income eroding (though their costs stayed the same) and added this
warning.

I don't blame the group maintaining VTX PAK.  This is another ludicrous example
of the failure of Digital upper management to maintain the corporate
infrastructure.

I have tried getting the Software Business Practices people involved - they
are sympathetic but don't have leverage to do anything about it.

				Steve

    I certainly don't have a problem if the VTX PAK group wants to levy a
    tax to various groups that they provide PAKs for.  They do perform
    a service.  However, doing it $25/PAK isn't the way to do it...
    
    Perhaps each product should modify its internal-use-only kit to
    not include an LMF check.  That would certainly circumvent the
    LMF PAK group...
    
    				-John

    If I were a customer, I'd only use S/W for my systems without anything
    like LMF/PAK's etc.. It's the customers money eaten for no added value! 
    Takes system-management time, adds burden and danger to my ops. I'm
    wondering why people accept this? 
    
    

Re: .6

I suggested not advancing the release dates in new versions, but Jon Maurer
of the Software Business Practices group begged me not to do that - he said
that some external license types DO depend on the release date.

The manager told me that the price would probably be adjusted downwards
after they had a better idea of how it worked.  Unfortunately, there is some
overhead in the cross-charge mechanism.

				Steve

Re: .7

The value added is that it satisfies our customers' auditors when they ask
how the customer knows they are properly licensed for all the software
they have.  It also allows Digital to offer flexible licensing schemes without
"giving away the bank".  PAKs are a relatively innocuous mechanism (compare
to methods keyed to system hardware IDs or a physical token).

				Steve

    I always use VTX PAK for all my licenses for royalty sw (e.g. UNIX,
    KAP).
    
    For Digital-supplied sw (e.g. the compiler group down the hall), any old
    existing PAK will do.  
    
    Right?
       /Wants_to_stay_honest

    Given the wording currently in VTX PAK, you can't copy/reuse PAKs
    even in the same group for anything, even plain 'ol Fortran.  
    
    It isn't clear about existing PAKs sitting on your system as to 
    whether they are grandfathered by this new "rule".
    
    				-John

I will choose to ignore the warning, and am following up through other
channels.

				Steve

    By what authority?  This is what I don't understand.
    
    So - we have what amounts to a new "policy" which comes about because
    an administrative/service group's management seems to think that it is not
    valuable enough to fund.
    
    BUT - they are willing to fund the policing efforts that will be
    required to enforce this new policy?  And a group not worth funding
    also gets added power to terminate employees who attempt to save some
    overhead time?
    
    Oh yes indeed, management is our core competency - no doubt about it.

    Hey - I just got a wonderful idea..
    
    I hereby offer Digital Equipment Corporation my resignation with the
    condition that Digital outsources it's internal PAK distribution business
    for its internal products to me.  I will offer this service at $12.50 per
    PAK per computer - at a considerable cost savings to the company.  Not only
    will the per PAK charge be half the price, but Digital would be able to 
    eliminate the PAK distribution group from its payroll.
    
    One caveat - the price for distribution of group PAKS may not be included
    in the $12.50 offer.  For example, if Digital was to create a PAK which
    enabled all company PAKs, then a somewhat higher charge may have to be
    negotiated.

    The original intent of LMF was to help the honest system manager stay
    honest, according to my immediate boss at the time it was invented (he
    was the Compilers & Development Tools member of the earliest task
    force).  Part of the theory is that plain theft is rare, but confusion
    is common.  An electronic record-keeping system makes it easy to be
    honest.
    
    So that's the spirit with which I approach VTX PAK.  If it's royalty
    sw, then I can stand the pain of pressing ESCAPE-O-P-ENTER (or else go
    find one of the increasingly rare systems that has a keyboard with a
    PF1 key on it).  Being honest is not that hard.
    
    But if it's Digital's own software, there is NO business reason and NO
    ethical reason to track the stuff.  As a software engineering manager
    I would never have expected any payment from other groups WITHIN
    Digital.  Nor would I have tolerated some third group demanding payment
    and appearing to threaten users' job security in order to use my
    groups' software.
    
    Steve, if this note stream has not already been forwarded to someone
    high up in personnel who could comment on the issues of appearing to
    threaten the livelihood of professionals who are honestly doing their
    jobs, please let me know and I will take the issue there.
    
    	/John Henning
         Onetime Software Engineering Manager for BASIC, COBOL, DATATRIEVE, 
         DECgraph, DECslide, MMS, RALLY, RPG II, SCAN, TEAMDATA

RE: Steve Lionel in an earlier reply:

  I had *NO DOUBT WHATSOEVER* that the implicit claim of termination
  was bogu. I do think it might be a nice gesture to find out who
  made that ridiculou claim, though, and see some corrective action
  taken against *THEM*. I'm quite tired of reading about all the
  ways someone speaking for Digital is claiming to to be ready to
  take punative action against the employees.


Re: <<< Note 4606.15 by PERFOM::HENNING >>>

> But if it's Digital's own software, there is NO business reason and NO
> ethical reason to track the stuff.  As a software engineering manager
> I would never have expected any payment from other groups WITHIN
> Digital.  Nor would I have tolerated some third group demanding payment
> and appearing to threaten users' job security in order to use my
> groups' software.
    
  Actually, there is at least one situation, and that's when our
  software uses someone else's licensed technology. Sometimes, it's
  just not possible to negotiate a flat-rate grant of license and we
  end up paying some sort of per-unit cost. Then even though the
  software is, ostensibly, "ours", we need to track it.

                                   Atlant

So what's new?  The wording that I find is the same as was printed on the
old "Internal Software Order Form" from years ago, before there was an LMF.
I believe that the intent was to prohibit people from obtaining software
under the guise of "internal use" and giving it to customers.

Would you agree that giving away software is bad?

Mark

Mark:

  Of course giving away software is bad, at least unless
  your name is "Netscape Communications". But offering to
  terminate employees who give away revenue software is a
  completely different kettle of fish than offering to
  terminate employees who share free-to-Digital software
  inside Digital.

  If no tracking of the software is required, then the group
  that's doing the tracking (and threatening termination to
  those who don't complain with their garndeous schemes) is
  wasting effort (and hurting morale). Can we afford them?

                                   Atlant

Ah but ... Somebody has to pay for the group running the internal
PAK system. Perhaps this is their way of making up a funding shortfall?

M

    Well actually, I can see _some_ point in this, as can anyone else who
    has been inconvenienced by the demise (due to lack of funding) of the
    automated MTBF-database system. But I don't like the proposed method.
    I'll make an alternative suggestion: an annual subscription to allow
    access to a PAK system. For that, I'd _require_ a decent UI. And I'd
    _require_ zero-cost access to non-royalty PAKs. I don't know what I'd
    consider a reasonable cost, or what my manager would consider
    reasonable. 
    
    But it all sounds rather as though no-one in HQ is willing to pick up
    the cost of something which is a basic requirement to running a
    hardware company. The proposed charge isn't going to help anybody be
    more productive or help Digital be more profitable.
    
    regards
    john

    
    
    
    Re: -.1, someone does pay - the vehicle is called contribution margin.
    
    As with many of the groups that provide useful, but not 100%
    "necessary" functions, these folks find themselves providing
    an unfunded service.  They want to continue a function that they
    perceive to have value to the corporation, a function that correctly
    records the corporations use of its software assets.  However, the
    corporation does not value this effort sufficiently to fund it
    directly.  So the supporting organization decides to revert to user 
    charges. 
    
    Only problem is , the users know that they really don't have to use the
    service.  So the supporting organization must also instill fear in the 
    user base sufficient to require them to continue using the service.  
    Someone forgot to factor in the questioning Digital employee and the
    penny wise manager.
    
    The problem with the approach taken is that the current $25 per pak fee
    will have to be rapidly increased as the user base declines, voting
    with their non-usage to ignore the rule that the system must be used.
    
    The corporation has declined to fund this activity, and I am sure that
    the field contribution margin was not changed to allow direct funding
    of the activity.  Perhaps the group should figure out how to either
    gracefully go out of business with minimal impact, or organize a
    campaign to convince senior management of the value of and need for 
    the VTX PAK function.   
    
    	Bill
    

    I'd hazard a guess that handling a $25 x-charge costs us >$25 in
    administrative costs...
    

    To add another 2 cents worth, here in the UK cost centre transfers
    for less than UK pounds 1000 may not be done.  So... if we save up
    all the $25 per PAK and we only need 5 a year then in (a long time
    away) we can pay off the PAK CC!
    
    Stupid, innit?
    
    Calvin
    

    As I remember things from about 12-14 mos ago, the full cost of a JV was
    about $125-150.  I doubt that things are much better now, with all the
    approvals that are required.  An automated cross-charge would not
    attract the same overheads as a JV, but the expense of a cross-charge
    for a single pak would undoubtedly exceed the the charge for the PAK. 
    But then, the group providing PAKS doesn't have to pay those "fees" -
    they are just part of the system.
    
    	Bill   

    Classic example of 'saving money' in one cost center by shifting the
    charge somewhere else. IN the end DEC pays more, but some group looks
    better on their paper.
    
    and we continue down the tubes.

Well not that I'm advocating doing this, but things could be a lot worse.

If memory serves, at IBM you have to pay for all internal software [this is
what I vaguely remember from a meeting at IBM about 10 years ago, so if
anyone has more recent information ...]

The argument is that if the Software is not worth full price to internal
customers then it probably isn't to paying customers either. Sort of an
instant feedback system to the originating group. 

Also, by not paying full price you can end up requiring your
customers to buy dependent software that you get for free. On the
other hand if you were required to pay full price you might ask
yourself whether that dependency was worth the additional cost.
I've just returned from a user group conference where I was
"reminded" to do something about a dependency we have gven them.

M

I called the "People Support Network" and asked to be faxed a copy of the
employee agreement I signed, as well as a copy of the agreement currently in
use.  They did this.  I have read them (there's surprisingly little
substantive difference in the 18 years!) and the only paragraph even remotely
of consideration is the following (this is the current wording):

  7.  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 of DIGITAL,
      such as experimentation, research and developments relating to existing
      and future products and services marketed or used by DIGITAL, and also
      any information which gives DIGITAL a competitive advantage including
      data relating to the general business operations of DIGITAL (e.g. sales,
      costs, profits, organizations, customer lists, pricing methods, etc.).
      I agree not to disclose any confidential information of DIGITAL, or of
      others which is entrusted in confidence to DIGITAL, to any non-DIGITAL
      person, corporation, or firm.  I further agree not to make use of
      such confidential information except on DIGITAL's behalf whether or not
      such information is produced by my own efforts.  I understand and agree
      that my confidentiality obligations under this Paragraph 7 shall
      continue both during employment and after termination of employment
      until such confidential information becomes generally available to the
      public through legitimate means.  It is understood and agreed that
      specific information which I may receive, observe, perceive, create,
      develop, or learn while an employee of DIGITAL shall not be deemed to
      be generally available to the public merely because such specific
      information is embraced by more general information which is generally
      available to the public.


There is *NOTHING* in this paragraph disallowing disclosure of information,
even "confidential" (PAKs are not classified as "confidential") to other
Digital employees. 

The threat is still present in the page displayed when you are about to save
the PAK.  I'll be following up with Personnel about this.

					Steve

    The business that I am in is related to setting up and reproducing
    customer critical escalations, aka CLDs.  For the last several weeks,
    several members of my team and myself have been forced to endure
    excruciating conditions, working weekends, etc. to setup and reproduce
    a seemingly phantom condition.
    
    After three weeks of miscommunication with our customer, we finally
    learned the precise environment in which we needed to test.  We had to
    get two systems in two different areas for testing.
    
    We get this rather large reproducer all set up only to find that we
    need license paks.  And the system administrators refuse to allow us to
    share paks because of this new policy.  I don't blame them.  I even
    sent them mail authorizing them to distribute paks and that I would
    take the blame and would accept termination doing "whatever it takes"
    to setup and reproduce this problem.
    
    This is a priority 1 case in IPMT.  We are working as close to 7x24 as
    possible on this.  Now I can't reproduce the problem.  I need license
    pak's for several products across several versions.  
    
    In normal cases, we require different licenses for different versions
    depending on how I tear down and re-build a system.  I find it hard to
    believe that I have to spend close to $1000 each time I have to setup a
    problem.
    
    Would whomever can change this please understand that there are groups
    that genuinely DO need shared paks.
    
    Grahame Plaisted

    Re: .28
    
    MCS groups usually have access to a so called Temporary Service PAK
    list, which is to be used in urgent customer situations to give out
    a PAK with a short lifespan (3 months, if my memory serves me right).
    
    You might want to contact the MCS group through which the IPMT was
    escalated, and request TSPs for the products you need.
    
    ...petri

    there are also things floating around called Seed Unit PAKs. Only for a
    subset of non-royalty layered products, and they expire each year, and
    I don't know where they come from. but they exist...
    
    good here, innit ?
    
    regards
    john

.28, if I understand correctly, only needs internal PAKS.  The systems
he is working on are _internal_ systems being used to reproduce a problem.

Internal $25 cross-charges should not be discouraging him from obtaining
internal PAKS to use on internal machines.  Get them from VTX.

The VTX PAKS were _never_ intended to be used at customer sites, no matter
how short the need.  But that's not the issue in .28, as I understand it.

/john

    
    Would it not be easier to allow each internal group that has
    need for PAKs, to generate their own?  Guidelines could be 
    issued.  If Corporate doesn't value the function enough to 
    fund it, then each business unit should have the option of
    funding that function within (IMHO).
    
    Dennis
     

This is just another example of "us working against each other", "cutting our
own throats", etc. A group that provides a much needed service for the rest of
the company "being forced" to charge a "service" fee, because someone "higher
up" doesn't understand that in order to sell "software", people/consultants/SI
folks need access to it, and PAKS provide for that "free access". Now with the
$$$ freeze on in the ABU, I'm not going to dare pull that "DECMESSAGQ" kit, to
get myself familiar with the product, I'll rely on the documentation as much as
I can. But my past experience tells me that it would be much better to install
the package and "really learn the product". I don't blame the group that issues
these PAKS, somewhere I keep wishing, that someone "high enough" in the company,
will have the "vision" to pull everything together. This just adds to my list of
frustrations, you would not believe the problems we're having here in the field
with "field service issues" and "new product failures". I'm really surprised
that my customer hasn't kicked us out "completely", I think the only thing
holding us in there right now, is their large installed base of our systems and
the relationship they have with us (the sales team) ---- but if all these issues
keep happening in the field, even they will kick us out completely. 

Charging for internal PAKS, just another "handcuff", another knot, another 
noose around our necks. I can't wait to see what happens next week.


Sorry --- it's been a bad week (and its only Weds.)




Rick C.
Title: Tired, Frustrated and Worn out

    re: .30
    
    The Alpha Seed Unit PAKs are sent to business partners that have been
    loaned systems for demo/development purposes.  The systems are not
    meant for production purposes and it's a violation of the terms of the
    loan if they are.
    
    In addition, the ASAP SDKs (for business partners that own their Alpha
    gear) include terminating license PAKS.  The T's and C's govern their
    use: demo/development purposes only.
    
    Mark
    SPE MRO

    Yesterday we got the riot act read to us about reducing all
    expenses for rest of the year. Such efforts have been going on since Nov.
    
    Walk in the office today and get called into the boss's office for an
    explaination of why I spent $1500 on licences after being told not to
    order anything just yesterday.  
    
    "What????"
    
    This stuff is already hit the cc billing. Pak charges for new versions 
    of vms on some machines I had to update to v6.2 cause I need to use them 
    for testing.

    I needed to do this cause the group responsible for testing got desolved
    to save money. So it was either play Mr Mom (aka system manager) in 
    my spare time, on 3 vms machines, or sling trash on the field. I took 
    the later approach.
     
    The boss asks "why didn't you forcast these charges then ? "
    
    "Because there never were charges for non-royality PAKS before, so I had
    no reason to forecast this stuff before"
    
    So I look like a heel to the boss for trashing our budget on unplanned
    expenses when the huma-humas are checking every dime. At least the low 
    lifes give you a break if you order a full set of non-royality licences. 
    ONLY $500, such a deal to save you from spending 45 minutes trying to make
    sure you have grabbed every jerkwater pak needed to make VMS and the
    layered products install without having to rerun VMSINSTALL 5-6 times .
    Anyways fun when the install manual is 4 inches thick.
    
    The heck with this, time to go back to VMS 2.0 and not have to deal 
    with these clowns....

    Better forewarn the boss if you have been using VTX PAK in the past month
    or so.                               
    

    Yep.  Our CC just got hit with over $1000 for PAKs.  Turns out that one
    of our guys extracted all non-royalty PAKs and when the one he wanted
    didn't install, extracted them all a second time thinking something was
    wrong with the first one (it didn't help).

    If they are really going to do this (charge for internal PAKs), then
    there needs to be some serious upgrades to the service, such as more
    detailed descriptions of the PAKs.  Very often there are several PAKs
    available for a given product and you wind up having to get more than
    one before you get the one you need.  Also, there should be a provision
    for getting "credit" for unused or unusable PAKs.  And what about
    "trial" PAKs for free so you can try out a product before deciding to
    "buy"?

    I plan to work this issue strenuously with my CC manager and finance
    person.  Maybe if enough of us bitch loudly enough, it will reach the
    ears of someone who can do something about this.  Oh boy, just what we
    need - another time consuming hassle eating into getting real work
    done!

    Bruce

	I smell a Dilbert cartoon coming on...

							mike

    re: -1
    
    Perhaps Sunday. 8-)
    
    What a crock of cow dung this is. Especially with no prior
    notification. 
    
    "Breath deep the gathering gloom, watch lights fade in every room"
    
    Jim C.
    
    

> If they are really going to do this (charge for internal PAKs), then
> there needs to be some serious upgrades to the service, such as more
> detailed descriptions of the PAKs.  Very often there are several PAKs
> available for a given product and you wind up having to get more than
> one before you get the one you need.  Also, there should be a provision
> for getting "credit" for unused or unusable PAKs.  And what about
> "trial" PAKs for free so you can try out a product before deciding to
> "buy"?

  There shouldn't be any damn PAKs at all, especially for internal
  users.                                   ==========

  Perhaps they serve the bean-counter's needs, but the customer
  technical folks have hated these for years, and they create
  a distinct competitive *DISADVANTAGE* for us. Ask yourself:
  Have you installed any PAKs on PCs or Macintoshes?

                                   Atlant

    re .37:
    
    See http://www.unitedmedia.com/comics/dilbert/archive/dilbert960512.jpeg

    So eliminate the PAK people/organization.  Last time I strolled through
    VTX PAK, you could get software and a PAK for PAK generation software.
    Have a local node in the cost centers run the software and you don't
    need anyone else once you  have paid your $25 dollars for the PAK
    generator PAK.  Done one time.  Brings up a thought, just what kind of
    support structure needs to be in place to support the generation and
    distribution of PAK's if it is all done by computer?  A system manager
    who would certainly not be dedicated to that system.  What else?  In my
    view, nothing.  Networks are supported(?) by another organisation
    already.
    
    JMHO, Bryan

RE: .29

	Petri,

	Unfortunately, the "case" is an after-the-fact, that is, after the
	fact that sales VPs keep calling my VPs every hour on this.  In such
	situations, you don't worry about the trivialities, you just get it
	done.

	I am only interested in solving a problem.  The PAKs that I need
	change every time I set up a problem.

	I do not think it wise to say something like, "I'm sorry, you have
	to get me the PAKs to setup the problem."  Then the MCS cost center
	has to pick up the tab.  I can hear the prolonged squawk now.

RE: .30

	John,

	Our system managers have said that they don't want to touch this.
	They don't want to get fired for spreading around internal use paks.
	As another noter indicated, my cost center will not tolerate high
	PAK costs.  Hypothetical example:

	$1000 per setup
	30 or so per week (for a large OS group)

	$30K per week in pak costs.  This is NOT acceptable.

	I believe .35 describes this in a tone with which I also epathasize.



Grahame

    I would suggest that people upset by the situation raise the issue
    through their management chain.  Keep pushing until it gets high
    enough.  Maybe something will happen.
    
    				Steve

    
    	I can see the need for keeping track of how many times X product
    has been installed internally. The big problem is LACK OF COMMUNICATION
    from the VTX PAK people. They should have notified every single CC
    manager inside digital of this pending change before implementation.
    	Every CC is running off of a budget which was planned a year ago
    and has been in effect for 9 months now. So they implement the change
    and hose everybody elses budget. Instead of saying we are going to
    implement this as of Q1 FY97, so plan for it.
    	Here in HLO the support group does 90% of the software installs.
    Which means VTX PAK will cross charge our CC, then we have to
    turnaround and cross charge the actual CC we are doing the software
    install for.
    
    Ron

    Naive question ...
    
    How does the VTX PAK service check that the Cost Centre that you enter
    is actually the one that you are in? What if i just enter ABC, or
    better still, whatever CC that VTX PAK sits in???
    
    mb

    re .40's " -< Do we have a VP for cost containment? >-"
    
    I suppose you thought you were joking?
    
    The fact is, we do, recently announced, and one of his very first 
    actions was remarkably similar to the one enacted in the excellent
    URL comic strip reference you provided.
    
    Funny old world.
    
    /Chris.
    
    

    re .46: I was afraid it wouldn't be a joke... you just confirmed it...

    Re: .44
    
    VTX PAK does not provide the service of keeping track of how many
    times a product was installed internally.  Its only purpose is to
    provide PAKs for internal use.
    
    The big problem is that Digital as a corporation isn't willing to fund
    its own infrastructure.

    re .48
    
      Steve
    
       Please stop sticking up for them. 
    
       4 years ago I tried to get these folks (I believe this are the same
    folks that handle external pak generation systems) to build a feed so
    when we (MCS) renew a customer's contract, we could automatically build
    the paks with new end dates, transfer the file electronically to the 
    customer through a secure proprietary transport, and mail a letter
    telling the customer's system manager where the command stream was to
    run to update their keys and how to execute it. It would save millions
    a year in Admin costs and reduce the hassle on customers for this
    unique "Digital advantage". I never got past 2nd base. They were busy
    rebuilding their systems and said come back in a couple of years (OK,
    they said 18 months). Now nobody sees their real advantage, so they
    decide to whack us internal types.
    
        What's next ?   Charges for ELF even though there is no phone
    book?   Usage charges on notes files?  VTX Orange book policy
    extractions to a mail file?   There is used to be something called
    being a good Corporate citizen. Some of us try really hard to help out
    the other D**cies in this place. I have enough problems to deal with
    without surprise charges so someone can track an asset that is
    free to begin with. This is worse than a $40 solution for a $5 problem.
    
         And yes, this really pushed my button today. Sorry....
    
      

	Maybe it's time someone published the licensing check patch again?

	(I remember seeing one on a T-shirt at DECUS many years ago. :))

							mike

This has an interesting side effect.  I have in one hand the Lotus Business 
Partner Program case.  It has something like 20 CD-ROMs full of Lotus 
products (Notes, cc:Mail, WordPro, 1-2-3, etc.)  In my other hand I have 
Microsoft Developer's Library, Enterprise Edition.  It has all the Back 
Office products (Exchange, SQL Server, etc).

Now, this new policy means that if I get any exposure to DEC products 
(MAILworks, Office Server, MAILbus 400, X.500), I'm going to need to pay 
for them, get the approvals, etc. 

So, I can learn about Lotus messaging products with no extra charge, 
Microsoft messaging products at no extra charge, or I can wait two months 
for the approvals to get the Digital products, and then have some retentive 
finance person give me grief about spending _his_ money.

(By the way, it took my six months to get a $300 software product earlier 
this year).

If I follow the course of least resistance, the next time I do a messaging 
architectural review for a customer, I'll tell them to throw out all the 
Digital messaging products and replace them with either Lotus or Microsoft. 
 My personal reason is that when there is a question from the customer I 
can test the Lotus and Microsoft products, but not the Digital products.

If this is what the corporation wants, then that's fine.  However, I hope 
someone points this out to the powers that be.  I can push any of the three 
products sets, so it's no skin off my nose.

(Just to keep the flames down, I managed to download all the PAKs I needed 
in April, so I won't in fact be telling customers to dump DEC's products.  
Nevertheless, if I didn't have the PAKs in hand today, I would probably not 
be pushing DEC's messaging software.)

john

    re: .45
    
    So what's Bob Palmer's cost center? If we knew that, we would ensure
    that this ridiculous problem is brought to the attention of the highest
    level of the company in the shortest time, by charging all our PAKs to
    his cost center rather than ours.
    
    Then maybe the bean counters who allow this sort of thing to go on
    (cross charging cost centers without prior warning or notice) will
    learn that they should not work that way.

re .52
    
>    So what's Bob Palmer's cost center? If we knew that, we would ensure
>    that this ridiculous problem is brought to the attention of the highest
>    level of the company in the shortest time, by charging all our PAKs to
>    his cost center rather than ours.

You asked for it - you got it. And while you're add it, mention to him that his 
location's wrong in the corporate directory ;^)


                          Index of Corporate Directory 
 (Selections: 0  )                                          (New messages: 0  )
--------------------------------------------------------------------------------
   No.           Employee Name              Phone No.   Badge   Loc  CC
--------------------------------------------------------------------------------
 > 1     PALMER, ROBERT B                 DTN 223-6600  188314  MLO  C60


tim m.

    
    
 > 1     PALMER, ROBERT B                 DTN 223-6600  188314  MLO  C60
    
    Wow, I'm in cost center C60. Hopefully a goal for next year will be to
    even out the salary structure in this cost center :^).
    
    Actually I'd guess that was his CC when he was the honcho of Corporate
    Manufacturing & Distribution and not yet CEO.
    
    Greg
                                            

    Can someone tell me if it is against Corporate Rules to generate your
    own PAKs (assuming you have worked out how to do it yourself;
    hypothetically of course).                                   

    The latest that I can see is Bob being in CC 644.
    
    Speaking of Bob, he used to chime in now and then. That has got to be
    close to a year ago now. Too bad his entry into notes was so brief.
    
    Jim C.
    

    RE: .55
    
    While I can't comment on the "legality", I do know the PAK generator
    software is hard to get.  It isn't on the network anywhere.  Customers
    (actually ISVs) can get the software to generate their own PAKs, but
    the price is pretty high (if I remember correctly).
    
    Even with reverse engineering the code, I doubt most people would
    ever figure out the checksum algorithm.
    
    I certainly would be illegal for customers to figure out the PAK
    checksum scheme.
    
    				-John

    "Do the right thing".  But cya.
    
    If it's royalty software, get a pak.
    
    If it's non-royalty software that you need to do your job, then take
    your pick:
       - Recycle paks.  Tell your boss.  In writing.  Keep a copy.
       - Generate paks.  Tell your boss.  In writing.  Keep a copy.
    
    If it's software that you do NOT need in order to do your job, but you
    just want it for the general educational interest (e.g. because you
    might need to know about it later), then spend those well-intentioned
    neurons on software that does not give you hassles. 
    
    	/John

Oh yeah, one more thing with respect to the last problem we had to set up.

There were tons of third party libraries.  In each case, we either were given
the pak up-front or were told not to worry about licenses.  They understood.

Moral of the story:  It's easier to work with the third parties than it is with
		     our own internal policies.

Grahame

Re: .49

The group handling VTX PAK today is not the group that had it a year ago.
That latter group dropped it, and VTX PAK went unmaintained for over a year.
The current group was pressured to take it on, but was not provided funding.

I don't blame them for trying to recover their costs somehow.  I don't
think the current threat regarding sharing PAKs is justifiable, and am
persuing that.  But I think people's venom is misdirected.

					Steve

    re: .60
    
    It doesn't matter who is running the service now. The lack of
    communication from them is what upsets alot of people. Not to
    mention the inanity of internal paks to begin with.
    
    It's interesting that we haven't heard from anyone responsible for
    this debacle.
    
    Jim C.
    
    

    Re .57:
    
    >     I certainly would be illegal for customers to figure out the PAK
    > checksum scheme.
    
    It is not illegal to figure anything out.
    
    
    				-- edp
    
    
Public key fingerprint:  8e ad 63 61 ba 0c 26 86  32 0a 7d 28 db e7 6f 75
To find PGP, read note 2688.4 in Humane::IBMPC_Shareware.

    re .60
    
      Steve   
    
       You just aren't getting it.
    
    1.    We run this application because someone a long time ago
          said we had to.  There is no monitary reason for non-royality paks.
          The decision to write a vtx application to reduce calls the the
          Licence Mgt group was made years ago and programming paid for 
          years ago.  That application has not changed in at least 3 years. 
          Ok, so we need to pay to update the product tables and relink for
          a new version of OpenVMS. How much money 
          is going to start flowing to this group for a product in 
          maintence mode? And I don't need a GUI now or in the future....
          I'd rather put the money in revenue generating or customer
          satisfaction applications than this system.
    
    2.    Someone decides they are going to bill everyone, just to put heat
          in the system. Like there are not REALLY important screwups to
          deal with in this company.
    
    3.    These folks decide to jv the cost centers for the $25 a pac. Heck the 
          financial systems are free to use right? [About as much as that
          Pak system is free]. How long till the machines that are
          maintained by CCS start JV'ing those charges on to the users on 
          nodes they maintain(they too didn't forecast these charges)?
          For the $25, how much will it cost in charge accounting both in 
          financial systems and cc manager's reconcilation time?
          
    
    We played this same game 3-4 years ago when MIS wanted be a "profit
    center" internally. Don't we ever learn?  Wait till you or one of your
    buddies gets the boot in order to keep extra accounting types on
    the payroll cause everyone is JV'ing everyone else for petty charges.
    
    So I have calmed down a bit today, but the  issues are still there, at
    least until I scrap the VAXes for more WinTel stuff. Then I can use
    Microsoft Select or Lotus Passport to get this job done. A least I 
    will not get double billed for a second extract when the file mailed to
    me was corrupt (I got burned the same as a previous noter for $500).
    This half-baked application is not thought out.
    
    A lot of us take the hit for the team, esspecially with half our
    co-workers gone. In some cases you consolidate until you have enough
    size to handle this as "monkey dust". If this was the only piece of
    code I was maintaining and had to start cc'ing folks, I think I'd be
    really nervious about my slot.
    
    I don't ussually say much in this file, but sometimes there is a need
    to let folks know they are impacting others in their short sighted
    views. 
    
        Sorry we disagree . I've got to get back to work on a solution for
    $13,000,000 in contracts. Real applications for REAL money (aka
    customers).
    

    RE: .62
    
    I was thinking about customers figuring it out by reverse engineering
    the code.  I should have been more clear.
    
    If the customer can figure out the scheme without violating the
    terms and conditions of their licenses, lets say with the help
    of a crystal ball, then great.  They still may be unable to use
    that knowledge however if there are patents involved, right?
    
    				-John

    Re .64:
    
    a) Isn't VMS source code available for a fee?  Hardly necessary to
    reverse engineer the code then.
    
    b) The machine code may be viewable by user of systems -- users who
    have not agreed to licenses prohibiting reverse engineering.
    
    c) If Digital has ever sold VMS without getting agreement to the
    license first (such as by putting the license in shrink-wrapped
    packages or sending it after an order is made), then the license is not
    legally binding.
    
    d) A patent would prevent somebody from marketing a competing product,
    but I don't think it prevents people from using the patented method
    themselves.
    
    
    				-- edp
    
    
Public key fingerprint:  8e ad 63 61 ba 0c 26 86  32 0a 7d 28 db e7 6f 75
To find PGP, read note 2688.4 in Humane::IBMPC_Shareware.

>    a) Isn't VMS source code available for a fee?  Hardly necessary to
>    reverse engineer the code then.
    
    Not all of it. Certain critical areas of VMS source code are omitted
    from the distribution, fee or no. I suspect (without remembering for
    sure) that this includes the license testing code, as it does other
    security-sensitive areas.

    So is there anything wrong with someone that already was bitten by the
    $500 scam putting the megafile up on a web server so we all can use the
    same licenses?
    
    bill

    Re: .63
    
    I do get it.  All I'm saying is that the group who maintains VTX PAK
    tried to get corporate funding but failed, and went to the charge as a
    last resort.  The manager of the project told me that he'd love to find
    a way to stop charging for individual PAKs - as long as someone would
    cover his group's expenses for the system.
    
    Getting angry at the VTX PAK people for charging the fee is
    misdirected.  
    
    				Steve

I agree that getting angry at the PAK group for corporate not
supporting them is misdirected, but what I they have done which
is out of line is:

* $25/PAK and $500 for all PAKs is way out of line.  We're talking about
	supporting one (1) head here (yes, I did ask the manager of the
	group!)  I have a hard time believing that there are that few
	hits on the PAK generator that this much is required.

* This was done without prior warning and communication.  Any change
	that directly affects the budgets of nearly ALL groups in the
	corporation should have been WIDELY communicated WELL in ADVANCE
	of its imposition.

* The draconian warning message is improper, unnecessary, and unenforceable.

The other reason you see heat directed at that group is that it's really
difficult to direct heat at an amorphous "corporate" which declined to
fund this one head.  If I could find out who it is that decided that their
individual bottom line was more important than the thousands of groups that
are now being impacted, you can bet that I'll direct heat appropriately.

Kevin Farlee

    I have an idea. Put internal non-royalty PAKs in the Integrated
    Repository. It has a search mechanism, and if required a chargeback
    mechanism (as is reportedly used for sending faxes). It wouldn't be so
    easy to generate "traceable" PAKs with nodenames and things in but the
    hoops the present system goes thru to embed a nodename in a non-royalty
    PAK seem to add little value. 
    
    Why there ? Basically because it's an "infrastructure" facility which
    the guys at HQ would have to be seriously deranged to "unfund" (talk
    about tempting fate...).
    
    regards
    john

One of the "features" of VTX PAK is that each PAK has a unique and traceable
authorization ID, the theory being that if it ends up at a customer site,
we'll know who to fire...  

				Steve

    Maybe one reason "management" keeps ducking the infrastructure issue is
    because someone always steps into the most gaping holes and tries to
    fix it themselves.  What that works, fine.  When that fails, we see the
    PAKs debacle.
    
    If they can't do it without financing, and they can't get financing,
    maybe they should let it drop -- and force central management to take
    the heat and see the problem.  Maybe, just maybe, they're acting as
    enablers to allow management's continued arrogance & narrow-mindedness.
    Maybe, just maybe, this is one issued where we should *let* the
    corporation grind to a halt, if that's what it would do, to show
    management the effects of their policies.
    
    -Mark

    That sounds lovely, doesn't it. But I can't see a way of doing that
    without hurting our customers (ie our wages) more than we hurt our
    intermediary managers.
    
    Steve, I guessed what the justification was likely to be. I would ask,
    simply, how many disciplinary cases has the uniqueness of internal PAKs
    contributed to, and what is the likely business impact (positive or
    negative) of having readily-available internal PAKs which are
    untraceable. Untraceable PAKs exist already - e.g. the seed unit PAKs I
    mentioned earlier. Passing these on is already a violation of some
    agreement or other.
    
    regards
    john

I was simply offering an observation of the "value added" of VTX PAK.  
I have
no idea if the traceability has ever been of use.

A long term technical solution would be to have all products check for a
DIGITAL-INTERNAL-USE-ONLY PAK product name, and then we would need only one
PAK for non-royalty products.  Royalty products still need a mechanism to
ensure proper tracking, but the current fee often inflates the royalty by
200% or more.

				Steve

    As one of the principals in trying to keep VTX PAK alive for the the
    past 2 years, I'd like to comment of the various issues brought up.
    
    Eight years ago we (Digital) decided to prevent access to our software
    w/o a "key" or a PAK. This was seen at the time as a significant
    revenue protection plan, particularly in the high unit cost, low volume
    market of VMS software. Having done this, we needed a way for our
    employees, system managers, to get keys for SW internally operated
    systems. At the time, being a highly decentralized company, we built a
    fairly open access method, "VTX PAK". Employees could get "internal"
    PAKs for internal use via this mechanism.
    
    A couple of years ago, in the U.S., we tied in an ancillary application
    "VTX SalesPAK" which produced temporary keys (timed-out) for use by
    field people for demos & consulting work.
    
    During recent IS cutbacks, the IS department decided to no longer "own"
    VTX PAK, even tho they were the originators of it. Many cards and
    letters from myself and others to no avail, they ceased support of the
    application. The application requires updating because it is not
    synchronous to the SSB license key generator database. In an effort to
    keep this alive, we searched around and found a group willing to take
    on the responsibility of maintaining the application (whew!), but could
    not afford to do it for free. I could get no money to fund it. They
    agreed to do it on a fee per PAK basis. This was the only way we could
    keep this functionality alive. The price was set as a trial, and will
    change as volume predictions can be made.
    
    This is not smart and not efficient, and it works. We wish we could
    have convinced senior mgt to spend 30k a eyar and keep the application
    in place and free. We were not successful.
    
    Admittedly, there was not a widespread announcement of this move. I
    will take some of the heat for this, sorry we didn't do a good job
    there.
    
    As far as the "losing your job if you....", if you provide an internal
    PAK to a customer you are providing access to a product for which they
    have not paid. You, or I, are not allowed to give the company's
    products away, that's effectively stealing from the company. Adjusting
    the price of a product to $0 can be done through normal allowance
    mechanisms which would provide a real PAK to the customer. If there's a
    temporary need, temp PAKs are always avaliable, either from VTX
    SalesPAK or the CSLA group, in the U./S.
    
    As far as giving an internal PAK to the guy in the next cube...I
    believe this is an attempt to manage the control and wherabouts of
    internal PAKs, so that, if someone is abusing them (giving them away
    externally) it can be tracked back to them. As you notice, your badge
    number is in the PAK ID of an internal PAK you request. If your not
    allowed to give it to anyone, and it shows up externally, most likely
    you put it there. I'm not supporting this ystem, I'm just telling you
    the why's and wherefores...
    
    Pressure on senior IS to put this application back in mainstream IS
    functions would be helpful. I certainly wasn't successful.
    

>                                                          We wish we could
>    have convinced senior mgt to spend 30k a eyar and keep the application
>    in place and free. We were not successful.
    
    You mean that we are all arguing over an issue that costs ONLY $30k
    per year? Like HALF A DOLLAR PER EMPLOYEE????
    
    Sheesh!
    
    And as for the 25$ price-tag per PAK, are you saying that only 1200 new
    PAKs are issued internally per year? Like only one in fifty employees
    need a new PAK each year - seems a tad low?
    
    Please don't take this personally, but if Senior Management can't suss
    this situation out themselves, then what hope is there for issues
    that involve _real_ money and _real_ customers?
    
    mb (who sadly won't be upgrading his VMS software in the near future,
    even though it is needed for his job!)

    re: ... it works
    
    It works to distribute data and produce chargebacks, perhaps.  But I
    was suckered into ordering the "non-royalty" omnibus PAK with no notion
    that I was committing my cost center to a 500 buck charge -- and then
    the PAKage didn't run on my workstation.  I ultimately followed other
    group procedures to get my system going, so I have an unused, unusable,
    $500 garbage file.
    
    How am I supposed to get the charges reversed on that?  How did the
    system "work" for me?
    
    -Mark

    A few observations:
    
    1.) WHAT infrastructure?  A large problem with many aspects of
        Digital is that folks don't realize the path/food-chain
        as to how doing their job maps to others. (It's a systems
        analysis sort of thing - NOT an engineering sort of thing
        so the company has never been good at it.)
    
    2.) Who cares about the charge?  Simply zero out the bits in the
        LMF check in your favorite product (it's easy to do in OpenVMS
        and you can ask CXO for it) and you should be able to run
        merrily on.  (i.e. return SS_SUCCESS instead of SS_FAILURE or
        somesuch.)
    
    3.) They can charge my cost center anything. That all rolls up to
        ONE cost center anyway.  As long as I'm doing my job, earning
        money for the company they can charge $1million internal for it.
        My financial anlayst can most likely find some other silly and
        stupid expense to cross charge THEIR cost center with and they
        can fight it out with paperclips and postits.
    
    Until it impacts a customer, who cares?
    j

    Obviously the originator of a cross charge should pay for the
    processing/handling costs of doing the cross charge.

    re: .78: the digital internal economy is measured in the same unit as
    the economy BETWEEN digital and other companies.
    
    That is, when your cost center manager is told that she needs to lay
    off 4 people, it will do her no good whatsoever if she tries to argue that
    her cost center is only spending money internally whilst the next cost
    center over spends money externally.
    
    It matters.
    
       /john

    re:.78, continuing on from .80:
    
    > Who cares about the charge?
    
    Somebody.  Honest.  It may not be you, but it's somebody.
    
    -Mark

    Any update on this?  We're in a new fiscal year now.  Am I still going
    to be charged for non-royalty PAKs?  Need to get some but don't want to
    spend $500!
    
    	Thanks!
    		David

    As far as I can tell, its still $25 each or $500 for everything...
    
    It wouldn't be so bad if the PAKs were like the ones we sell to
    customers (ie, no release date on the PAK).  However, the ones from
    VTX PAK have release dates set one year in advance.  This means that
    just to upgrade to newer versions we have to pay each year, whereas,
    we don't make the customers pay each year.  What is wrong with
    this picture...  Imagine Microsoft making its employees pay for
    Windowss 95, but giving it away for free to existing Windows 3.1
    customers...
    
    				-John

Re: .83

According to the Ts and Cs, customers are SUPPOSED to pay to upgrade to new
versions, if they don't have a "right to new versions" support contract.
Release dates were the mechanism intended for enforcing this.  But the
corporation decided to inflict the pain on its own employees only, and to
throw away revenue by allowing customers to run any new version at no charge.
The major reason for this is that our internal data systems are so screwed
up that we don't know who is and who is not eligible to use the products.

					Steve

    re .83
    A friend on mine just went to work at Microsoft from one of our
    Business Partners.  Upon arrival they provided her with a PC and a
    number of Server locations AND said have at it.  Every piece of
    Microsoft product is available for her to try at her leisure.  Use it
    and abuse it.  Let us know if there are any issues.  They don't have to
    pay a penny e.g., no cost centers or organizations charges.
    
    We have an organization to administrator the PAKs for customers.  Do we 
    have additional people to manage this internally?
    
    	Regards,

We, as a corporation, refused to pay the minimal cost for people to manage PAKs 
internally, which is why the group which took on the task has been forced to 
charge internal users.

				Steve

> We, as a corporation, refused to pay the minimal cost for people to
> manage PAKs internally, which is why the group which took on the task
> has been forced to charge internal users.

  Microsoft, of course, also refuses to pay the minimal cost
  to manage PAKs internally, so they don't have any.

                                   Atlant

It seems particularly ironic that a company that is now so hardware focused
is so "concerned" about software internally - especially for software that
it isn't making investments in to stay competitive in a number of cases.

PAKS are another good example of a "tax" that was imposed that should be
undone.  It was an extremely doubious (IMO) thing when it first came
about, and is inexcusible if we claim that, e.g. Compaq, is a competitor.
(There is no excuse as far as I'm concerned for laying off 10%
of the workforce, but still not issuing unlimited duration PAKS internally
to reduce overhead.  The latter, and other reduction of administrivia
is exactly the type of thing that should get cut *first*.)

Soon enough, the cost of buying the individual PAKs for all Digital software
products will be less than the cost of buying the all-inclusive PAK.  :-(

						Brian

    Keep in mind that it was customers trying to keep track of what
    licenses they legally had that asked for something like LMF and PAKs.
    Granted that the emergence of CDROM as a distribution media also
    was able to take advantage of LMF, but we certainly didn't shove it
    down user's throats (well, most users anyway).
    
    				-John

John:

  While I'll grant you that customers *DID* ask for a mechanism
  to keep track of Digital's licensed software, I *DON'T* think
  they wanted something like PAKs, and the response to PAKs at
  DECUS was negative, loud, and continuous. They would have
  been much happier if we'd simply been able to keep records
  or help them keep records of what software was licensed on
  which machines.

  (They want a way to keep track of Digital hardware maintenance
  contracts too, but thankfully we haven't proposed a mechanism
  that shuts their system down if some database somewhere thinks
  that the contract isn't up-to-date.)

  Our tiered software licensing strategy of licensing software
  based on processor capacity didn't help either. As machines
  naturally grew more and more powerful through the years and
  customers upgraded to these newer machines, they were con-
  tinually in the bind of not knowing whether, say, "DECthis"
  or "DECthat", licensed at tier <mumble>, was now legal to
  run on their new machine that ran 5x faster at half the price
  of the old machine.

  PAKs continue to be (let's be frank) a pain in everyone's butt,
  and one more reason why doing business with Digital is, generally
  spreaking, a pain in the butt. The PC software industry (much
  bigger than Digital's software industry) seems to get along fine
  without such a mechanism everywhere except the Far East. If we
  wanted to delight the customers and enable our own internal
  businesses, we'd eliminate PAKs.

                                   Atlant

Without PAKs, or some similar mechanism, we would not have been able to
offer low-cost personal use and concurrent use licenses, nor would we be able
to have the widespread "loan of products" service.  We moan a lot about PAKs
because our own internal policies make them much more painful to us than they
are to customers.

					Steve

    
    Re: .93
    
    >We moan a lot about PAKs because our own internal policies make
    >them much more painful to us than they are to customers.
    
    Are you sure about that?  From reading this notesfile, I would
    gather that the PAK system is just as painful to the customers,
    if not more so.

Steve:

> Without PAKs, or some similar mechanism, we would not have been able to
> offer low-cost personal use and concurrent use licenses, nor would we be
> able to have the widespread "loan of products" service.

  C'mon Steve, you're a more-imaginative software engineer than *THAT*,
  aren't you? You've seen demo software with built-in time-bombs or
  other restrictions. Surely for as much pain as the PAK system has
  caused everyone, we could have designed a standard, re-usable
  piece of code that securely implements "demo mode". (One quick
  idea, not original to me: include a properly-checksummed resource
  in the image that allows the image to be run, or to be run only
  under certain circumstances such as a range of dates. Remove or
  doctor the resource and the image won't run, period, or runs in
  some very basic demo mode.)

  And PC servers are an existence proof that "personal use" or
  "concurrent use" licensing can exist without PAKs.

  Then, the normal distribution software would never have had to deal
  with PAKs, but if the system were really well-designed, any Digit
  would have been able to set the "demo flag" in a product and then
  hand it over to a customer. One might even envision doing this
  automatically on the Internet.

                                   Atlant

Re: .94

I've talked to a lot of customer system managers, and all of them agree
that PAKs are a minimum of hassle for the benefits.

Re: .95

C'mon, Atlant - you're a more realistic person than *THAT*, aren't you?  You
want us to devote engineering resources to create a "demo" version of every
single layered product?   The advantage of PAKs is that most customers 
ALREADY HAVE the product and its documentation on the SPL CD-ROM.  Engineering
doesn't have to care about various promotion and loan schemes - it's all
handled with PAKs.  For most customers, PAKs are a one-time thing - set and
forget, even across version updates.

				Steve

    	I know we're supposed to be more *customer oriented*, but the
    last few replies don't seem to touch much on the waste of money for
    the current *internal* PAK system usage.
    
    	Is there some reason that internal non-royalty PAKs need to have a 
    release date ? Other than planned obsolesence as a means of providing 
    funds to the maintainers of the PAK system, I can't think of any other 
    reason off-hand.
    
    	We're trying to cut costs, but we have some obvious money being
    wasted here. Aside from having to pull new PAKs yearly, remove old ones,
    reinstall new ones, we also engage financial people to charge and pay
    for the system. For someone doing a lot of testing in a large lab,
    the costs (as minimal as they may seem) now have to be an additional
    item that needs to be planned and budgeted for (read: more wasted
    time).
    
    	So instead of just providing central funding for "whatever it
    takes" to maintain the PAK system, we invoke a much more internally 
    expensive and wastefull process.
    
    	Two simple items, central funding and elimination of release dates
    on *FOR_DIGITAL_INTERNAL_USE_ONLY* PAKs, would make things much simpler
    for everyone having to deal with this. It might even save enough money to 
    resume funding the DECturkey program again ;-)
    
    	Ray

Re: .97

No, there's really no good reason for the release date.  It serves only to
limit the damage should an internal PAK get outside the company.

I agree with your proposal to eliminate release dates from internal PAKs.

				Steve

    I will assure you that customers find PAKs as big a pain, or more, than
    we do. I am convinced we have spent more money solving PAK problems-
    missing, short shipped, lost, expired, etc etc- than the value of all
    the software that might have been mis-used.
    
    I have never meet a customer that was trying to 'steal' software. PAKs
    simply get in the way of people with a job to do.
    
    It is really one of the many ways that makes it hard to do business
    with DIGITAL.

Steve:

  You must have attended different DECUS sessions than I did.


> C'mon, Atlant - you're a more realistic person than *THAT*, aren't you?  You
> want us to devote engineering resources to create a "demo" version of every
> single layered product?

  The scheme I just defined would allow *ANYONE* (who has access
  to the "resource generator" gizmo) to turn the full working version
  of a product into a limited demo. It could be time-limited with no
  effort at all by the original software engineers or feature-limited
  if they chose to define some subset of features (by using some
  standardized call like CheckDemo() ).

                                   Atlant

    Hey, what about this ISSUER=DEC PRODUCER=DEC stuff!  What are we gonna
    do if the branding police find out?!  :-)
    
    Do the Software Business Practices folks have any comment on changing
    the LMF?
    
    And where is Greg Robert, now?  I kinda consider this to be his legacy.
    
    Mark

Release dates make sense from another perspective.  As software products
get sold to companies like Computer Associates, Digital can control
prolonged use of these once royalty-free but now royalty paks.

Given our decreasing software emphasis, this is valuable for Digital.

Ram
(who personally detests PAKs; whose customers constantly remind him
that SUN and HP are much more license-friendly than Digital).

    	A release date on a PAK doesn't prevent prolonged use of a product.
    It only prohibits one from *upgrading* a product once the release date
    on the PAK is older than the layered products release date.
    
    	Besides, a much easier method of control would be to simply change
    the name of the PAK that the sold product looks for. Many product's PAK 
    names do not nessecarily map well to the product name anyway, so this
    shouldn't be a big deal for the amount of times it happens.
    
    	Ray
    

Changing the product name invalidates all existing PAKs.  Digital doesn't
know who is entitled to a new PAK, so we'd get into big trouble doing that.

				Steve

    	I'm not sure I follow. For example -
    
    		- Oracle buys Rdb
    		- Oracle recodes Rdb installation to look for PAK named 
    		  ORARdb0xx instead of Rdb0xx *for next release of the product*
    		
    	If you want the new release, you need to get a new PAK. If you 
    already have the product and a PAK, you continue to run that until
    you decide to upgrade. What am I missing ?
    
    	Ray
    

    Re .96
    
    It's not necessary to create a "demo" version.  All that's necessary is
    to design a mechanism similar to the one used by the makers of PC and
    Macintosh shareware.
    
    When a program is run, it displays a dialog asking the user to enter
    the shareware registration number.  It does this every time it's run
    until the number is entered.  Some of these probrams also disable
    certain very nice features until the number is entered, at which time
    the program stores the registration in a preferences file somewhere. 
    The software thus creates its own demo version, a version that can be
    handed out to other users so that they can see whether they want to buy
    it or not.
    
    It's possible to tie the registration to a specific box simply by
    linking it, in some encoded fashion, to the box's hardware ID (maybe
    the Ethernet address).  Then, if the software is copied to another
    machine, it will know that it's not a registered copy.  Similarly, a
    fresh "pirated" install requires at least the registration number.
    
    Another thing that is done, by commercial programs such as QuarkXpress,
    is that a program checks the network when it's started.  If there's
    another copy running elsewhere (such as a fresh "pirated" installation
    instead of a copy) that has the same registration number, the copy that
    is just starting decides that it's not installed legally and refuses to
    work.
    
    These are off-the-cuff ideas, sure, but it's obvious to me that
    something better than the PAK system could be implemented.

Sounds a lot like a PAK to me...

	Steve

    
    If I recall, in order for Digital to defend it's intellectual property
    rights, it had to show that it had done 'something' to protect them.
    Which led to PAKs.
    

    O.K., so if I follow the rules.... 

    I can now upgrade the PC on my desk to Windows95 or NT for "free",
    since Digital now has a global license for these products from
    Microsoft.

    but...

    to upgrade the OpenVMS workstation with a product that I personally
    develop and support, our CC must pay $25.00 to some internal group.

    Correct?


    							-Paul

>    Correct?

Just showing the relative efficiencies of the market vs Digital
internal processes, right?

    Have you visited VTX PCSOFTWARE?  Where did you get the notion it was
    free?
    
    Frank
    

    Re: .112
    
    Frank,
    
    We do have a corporate Microsoft Select agreement that includes
    WfWg 3.11/DOS 6.22, Windows 95 and Windows NT Workstation 3.51.
    
    All you need to do is to get a kit of any of the above operating
    systems from someone/somewhere and install away.
    
    ...petri

    
    Re: .113
    
    I revisited PCSOFTWARE.  You are right, we don't seem to need to buy
    licenses for Win, Win F WG or W95.
    
    I hadn't studied the list carefully enough.
    
    There is no mention of Windows NT Workstation but I'll take your word
    for it.
    
    FJP

    CONCLUSION:

    Microsoft can effectively manage software licensing of their products
    to Digital with the Select program.

    Digital cannot even manage software licenses of it's own software
    product within the company.

    Hello?  Is anybody listening?

    Mr. Palmer, I anxiously await further "selective changes in management".


    							-Paul

Any piece of software that ties itself to an Ethernet (or similar) device 
earns my eternal hatred.

PJDM

    .107, .116:
    
    In a past position I had the dubious pleasure of wrestling with third-
    party software which bonded with the host's Ethernet address.  It
    worked passably well... as long as the host's managers were careful to
    move the address chip when replacing hardware, whether the replacement
    was a repair or a hardware upgrade.
    
    Of course, my services were solicited only because no care was taken.
    By the time I got involved, people had long since escalated past the
    usual unflattering comparisons to raw sewage.
    
    Dick

    Re .117
    
    I've just come across a worse method at my customer.  The key is
    dependent upon upon the VMS version.That sounds OK initially but as I
    just found out while helping them do their upgrade, this isn't a one off
    thing.  Each time you upgrade OpenVMS (I don't know what effect patches
    have) you need a new key - problem is you need to provide some
    information by running a program in the upgraded environment that
    generates a 'VECTOR'.  This 'VECTOR' is needed to generate the new key.
    To compound the problem, the original S/W vendor is now out of business
    and a special arrangement is in place for the keys.
    
    Fortuneately my customer is in the process of stopping use of this
    product but in the meantime they are stuck at their old version of
    OpenVMS.
    
    	Owen.