[BBLISA] How would you address this?

[Michael Tiernan]

I'm sorry for the length of this but I figured I'd recap where I stand
on it all and typing with one hand is really really slow and
monotonous.

This whole thing started with:
   My vendor says "For security reasons, the license file must be in
/opt/FOOFOO_license unless /opt is not on local disk. In that case,
the license file will be placed in /var/adm/FOOFOO_license. This is
not a bug."

Some of the responses we've already discussed but here are the ones
that I'm willing to bring in to work on Monday:

Don Harris suggested:
   "Use their argument against them.", 'You can tell them that "for
security reasons" you don't keep license information in obvious locals
like /opt or /var/adm. You keep license information in a secure area
determined by your security/license policy. :)'

I like it, it mentions our corporate policies which can trump most
arguments the vendor can muster.

Stephen Wadlow made some very good points with an uncharacteristically
(for a sysadmin type) diplomatic precision and asked some spot-on
questions:
   "I'd love to know why they think that this is more secure (or why
alternatives are less secure) and why it's not a bug."
One of the best questions was:
   "Does the program have to run as root?"
This was going to be one of my first things I'd been planning on
checking on. I actually don't think they provide instructions for
autostarting the license server at boot time. So while the don't say
it shouldn't run as root, they don't seem to say that it should be.
(I'll review the docs Monday.) I'm also going to ask them for
clarification/citation on what security issue this fixed license
location addresses.

He further honed the "policy" statement to read:
   'My response would be: "My company does not allow outside
organizations to dictate our systems administration standards and
security policies without justification.  We are the customer in this
situation.  What is your explanation for needing to change the way we
do things?"'

This is a nice sharp statement that makes the vendor have to respond
in kind. I'm in an area where security concerns are more sensitive
than the ordinary so this one has good potential.

He further discussed more of the "business" side concerns:

   'And to support it from your side:  If all of the other licensed
software that you use has the ability to let you choose to centrally
manage where and how you store your licenses, then you've got the
power of a standardized system working for you.  If this one package
has inflexible requirements, then it will be the albatross in your
environment, and will likely suffer for it.  Their inflexibility
results in higher sysadmin costs on your end, and the increased
likelihood of downtime, or generally being unavailable due to not
fitting nicely into your system.  So, it's a bad match for you, and
bad PR for them.  That might be enough reason to investigate
alternatives.'

Business, as many others have pointed out, is what this is all about
and Stephen provided me with fodder to provide to the boss who's going
to ask "Why do we care?"

Then Adam applied logic to the problem and brought out these points:
   'First off, ignore their claim of "for security reasons"; it's just
not worth your time to argue with them.'
Adam's right in 99.99% of cases (see email discussing wrestling with a
pig). In this one, sadly, the vendor is the one falling back onto this
claim. While I agree with Adam in principle, in this case, I think the
problem and claim has to be addressed head on.

Y'know, this is the first time anyone (including myself) asked this
question. I suppose I should have asked it myself but I never
verbalized it.
   "[...] you should also ask yourself why it matters so much to you
where the files are stored. Is it really because it conflicts with
other stuff? Does it actually cause you problems during upgrades or
migrations? Or do you just find it esthetically unappealing?"
The fact is that we do use a centralized location for our licenses and
license servers (40+/-) and this requirement the vendor wishes to
foist on us gives us one aberration which will isolate this specific
tool and backup copies of it from the main location where these sorts
of things belong.

Mark Lamourine made a quiet point, obviously in jest, which might be
seen by some more junior people who would act on it without
considering the ramifications and I wanted to address it publicly.
(How do I know someone more junior might consider it? 'cause I'd
already considered it, pondered how easily I could do it, then
discarded it.)
   "Think you [could] use strings(1) on the binary to find the
location of the file name and emacs to edit the binary (Of course, the
new name has to be no longer than the old one)."
No, really, I considered it. The reality is, that when other people
have to depend on our work, doing something like this taints all the
results generated by the software in addition to voiding any warranty
that might have existed. (As a side note, it probably breaks two or
three laws AND puts you dead center in the liability issue.) Remember
the Mars Lander? It only had to descend a few meters before firing the
retros but someone calculated in feet, not meters. How do you think he
spun THAT ONE on his resume?

My sincere thanks to everyone for their feedback (both the humorous
and serious) on this and the valuable advice offered.
I also thank you all for giving me a place to commiserate about stupid
things like this.

I'm going to take this message to work with me and prepare an email
response to them and hope for the best.

Thank you all! Now play nice! I'll let y'all know what happens.
--
    << MCT >>   Michael C Tiernan.
    http://home.comcast.net/~Michael.Tiernan/
    Is God a performance artist?
    EGO hack vivo quod ago accido.