Re: Software vendor trying to force MSU based contract

[Zahir Hemini]

Yes but how easy is that to do? I am fairly sure that there is a limit to what 
vendors like Rocket or Serena would want to be supporting.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Tom Brennan]

Yep!  I always tried to be somewhat neat with my projects, but you never 
know until someone else takes it over and says, "Hey, where's the macro 
library?" or similar.  Oops... that was under my personal 
high-level-index, you know, the datasets you deleted 4 years ago :)


Phil Smith wrote:

Of course, as others have noted, escrow doesn't mean anyone alive can use it to 
build/support an actual product. How many of us have encountered products as a 
vendor whose source was incomplete or didn't match what was shipping?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Steve Beaver]

Tom

The guy that started Jolly Green in Canada sold the company to a guy that 
supports QWS3270Secure, QFTP, etc.  The only problem I had, and it wasn't 
because of the actual product, was when W10 came out and it took him about 30 
minutes to send me a new object.  

Ran it around the block, and that was my 1 and only maintenance issue

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Monday, March 6, 2017 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

Same here.  Instead of escrow or source code supplied to an end user, I think 
it would be far better for folks to consider someone else to take over should a 
product be left behind (for whatever reason).  For example, the code could be 
given or sold to Rocket/Dino/Serena/etc. and hopefully get some long-term 
support.

Charles Mills wrote:
> I am very negative on the benefits of escrow. 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Charles Mills]

An interesting "reverse" variant of this. A long time ago I had a customer 
negotiate a contract that said that if we went out of business that they would 
get first refusal rights on hiring one particular developer of ours. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Monday, March 6, 2017 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

Same here.  Instead of escrow or source code supplied to an end user, I think 
it would be far better for folks to consider someone else to take over should a 
product be left behind (for whatever reason).  For example, the code could be 
given or sold to Rocket/Dino/Serena/etc. and hopefully get some long-term 
support.

Charles Mills wrote:
> I am very negative on the benefits of escrow. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Phil Smith]

Tom Brennan wrote:
>Same here.  Instead of escrow or source code supplied to an end user, I think 
>it would be far better for folks to consider someone else to take over should 
>a product be left behind (for whatever reason).  For example, the code could 
>be given or sold to Rocket/Dino/Serena/etc. and hopefully get some long-term 
>support.

Sure, that would be better. Not always an option; I can think of at least one 
case where a large vendor decided to kill an entire product line that had a 
moderate number (more than 50, maybe less than 100, not sure) live customers. A 
smaller vendor offered to take over the maintenance and split it with the large 
vendor; the discussions never even got to the point of "Split how?" - the large 
vendor said "Naw, not interested", and that was it, they screwed the customers. 
I was astonished-seemed like a win-win-win: customers not irritated, large 
vendor gets SOME money instead of NO money, small vendor gets some money. And 
the big vendor wasn't likely to have to invest a lot in it legally-their 
lawyers could definitely beat up the smaller vendor's lawyers. Nor was there IP 
involved: the products had been acquired less than two years earlier from yet 
another vendor, and the technology was specific to that product line.

Of course, as others have noted, escrow doesn't mean anyone alive can use it to 
build/support an actual product. How many of us have encountered products as a 
vendor whose source was incomplete or didn't match what was shipping?


--
...phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Tom Brennan]

Same here.  Instead of escrow or source code supplied to an end user, I 
think it would be far better for folks to consider someone else to take 
over should a product be left behind (for whatever reason).  For 
example, the code could be given or sold to Rocket/Dino/Serena/etc. and 
hopefully get some long-term support.


Charles Mills wrote:
I am very negative on the benefits of escrow. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Charles Mills]

Am I being consistent?



Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Monday, March 6, 2017 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

On 6 March 2017 at 11:36, Charles Mills <charl...@mcn.org> wrote:
> I am very negative on the benefits of escrow. Here's a mental exercise.

Some readers will remember a several days long discussion fest right here on 
this very list in May 2014 under the subject "

Vendor Source Code". We covered most of the above, and a bunch more.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Charles Mills]

I don't believe the issues of IP rights in escrow have been fully litigated.

Escrow is an executory contract (in bankruptcy law terms). The whole point
of bankruptcy is to let you tear up past "mistakes" and start over. If I
were a creditor of a bankrupt software company I would argue that the IP
value should be used to pay creditors, not given away based on a
pre-bankruptcy executory contract. 

Don't shoot the messenger here, please. Charles Mills is not planning to do
any such thing. He is just saying what a hypothetical creditor might well
do.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Monday, March 6, 2017 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

On 2017-03-05, at 17:38, Knutson, Samuel wrote:

> Most vendor products that provide meaningful value also are internally
quite large and complex.  Very few if any sites that inherited a source
escrow from a vendor which goes out of business or sunsets a technology can
support those products.  Sometimes the products themselves include
technology built using protected IP from IBM, or other vendors that is
protected by non-disclosure arrangements.
>  
Shouldn't a realistic DR test exercise recovery from escrow?

> Consider that source escrow does not automatically imply the ability for a
company that received an escrow to further disclose or share that IP with
others (the community).  You mostly likely cannot just take an escrow tape
and upload it to GitHub.
>  
Does the escrow agent retain the IP rights?  If not, then who?
Could multiple end customers get exclusive rights to the IP?
That's an oxymoron.

>The product might today be something you like but the firm is mostly
likely going to be better served by locating a replacement than by trying to
nurse along Abandonware.  Source escrow just isn't worth the trouble for
most systems infrastructure products.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Tony Harminc]

On 6 March 2017 at 11:36, Charles Mills  wrote:
> I am very negative on the benefits of escrow. Here's a mental exercise.

Some readers will remember a several days long discussion fest right
here on this very list in May 2014 under the subject "

Vendor Source Code". We covered most of the above, and a bunch more.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Paul Gilmartin]

On 2017-03-05, at 17:38, Knutson, Samuel wrote:

> Most vendor products that provide meaningful value also are internally quite 
> large and complex.  Very few if any sites that inherited a source escrow from 
> a vendor which goes out of business or sunsets a technology can support those 
> products.  Sometimes the products themselves include technology built using 
> protected IP from IBM, or other vendors that is protected by non-disclosure 
> arrangements.
>  
Shouldn't a realistic DR test exercise recovery from escrow?

> Consider that source escrow does not automatically imply the ability for a 
> company that received an escrow to further disclose or share that IP with 
> others (the community).  You mostly likely cannot just take an escrow tape 
> and upload it to GitHub.
>  
Does the escrow agent retain the IP rights?  If not, then who?
Could multiple end customers get exclusive rights to the IP?
That's an oxymoron.

>The product might today be something you like but the firm is mostly 
> likely going to be better served by locating a replacement than by trying to 
> nurse along Abandonware.  Source escrow just isn't worth the trouble for most 
> systems infrastructure products.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Charles Mills]

I am very negative on the benefits of escrow. Here's a mental exercise.

Scenario (1). You hire a new developer. You sit him or her down next to the 
existing developers. You share all of the little tips and tricks with the new 
person. You share source code libraries, JCL libraries, etc. How long before 
that person is able to do things more or less on his or her own? Two months? 
Three months? Six months?

Scenario (2). You are using some vendor product. It blows up in production. You 
call the vendor and no one answers the phone. You Google and find they have 
gone out of business. You get your lawyers to contact the escrow agent. After 
some amount of process you obtain the source code, which may or may not be 
current and complete and may or may not include internals documentation and 
little things like JCL libraries. You put a programmer to work on it loading 
the source code, learning to build it, and finding and fixing the bug and 
testing the fix. And all this is going to happen in time to save your 
production? Really?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Knutson, Samuel
Sent: Sunday, March 5, 2017 4:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

Most vendor products that provide meaningful value also are internally quite 
large and complex.  Very few if any sites that inherited a source escrow from a 
vendor which goes out of business or sunsets a technology can support those 
products.  Sometimes the products themselves include technology built using 
protected IP from IBM, or other vendors that is protected by non-disclosure 
arrangements.
Consider that source escrow does not automatically imply the ability for a 
company that received an escrow to further disclose or share that IP with 
others (the community).  You mostly likely cannot just take an escrow tape and 
upload it to GitHub.The product might today be something you like but the 
firm is mostly likely going to be better served by locating a replacement than 
by trying to nurse along Abandonware.  Source escrow just isn't worth the 
trouble for most systems infrastructure products.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Knutson, Samuel]

Most vendor products that provide meaningful value also are internally quite 
large and complex.  Very few if any sites that inherited a source escrow from a 
vendor which goes out of business or sunsets a technology can support those 
products.  Sometimes the products themselves include technology built using 
protected IP from IBM, or other vendors that is protected by non-disclosure 
arrangements.
Consider that source escrow does not automatically imply the ability for a 
company that received an escrow to further disclose or share that IP with 
others (the community).  You mostly likely cannot just take an escrow tape and 
upload it to GitHub.The product might today be something you like but the 
firm is mostly likely going to be better served by locating a replacement than 
by trying to nurse along Abandonware.  Source escrow just isn't worth the 
trouble for most systems infrastructure products.

Just my .02 speaking only for myself.

Best Regards,
Sam Knutson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, March 02, 2017 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

On Thu, Mar 2, 2017 at 3:00 AM, Dave Wade <dave.g4...@gmail.com> wrote:

> I am going to say something you gentlemen may not like...
>
> 1) Do you need the product?
> 2) Do you need continued support, e.g. for legal and compliance reasons?
> 3) is the company in financial difficulties?
>
> If the answer to all these is "yes" then paying the increased charges
> may be your best option. If the company folds or files for protection
> it matters not how many bits of paper you have, if there is no
> business to honor the contracts you have then replacing the product
> may be much more expensive. In my humble IBM is the biggest player of
> these sorts of games and is doing an excellent job of squeezing the
> last drop of blood from its traditional mainframe customers..
>
> .. and throwing lawyers at a problem usually drives the costs up even
> more...
>

​I think you have some very valid points. I don't think that _any_ software 
company offers the following "option", but it is one that I'd like. What I 
_wish_ every company would "require" from a vendor is that should the vendor 
either "go out of business" or "sunset a product", that the customer would get 
a copy of the current source for the product, along with all internal 
documentation. No, I have not been taking any "funny pills". I do realize that 
perhaps all of the current z/OS vendors would like like hyenas if anyone asked 
this of them. Which is yet another reason that I am a FOSS advocate. An 
individual company might not be able to support "some product", but the 
"community" could possibly do so.
--
"Irrigation of the land with seawater desalinated by fusion power is ancient. 
It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Charles Mills]

This kind of extortion is not limited to the mainframe world. I have a
purchased "perpetual" license for a popular graphical FTP client. I now have
a new PC. The "perpetual" license is not good for the current version of the
program (12.4), only the exact version for which it was purchased (12.3) and
the 12.3 version is no longer available for download. So it's a perpetual
license for something that is not available. Grr.

Thank you for listening.

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Edward Gould]

> On Mar 2, 2017, at 3:00 AM, Dave Wade  wrote:
> 
> I am going to say something you gentlemen may not like...
> 
> 1) Do you need the product?
 In general there are plug compatible products out there that are *CHEAP*

> 2) Do you need continued support, e.g. for legal and compliance reasons?
Excellent question which leaves quite a few products wanting. 
example: We had a multiple CPU upgrade going on and one product would not run 
because of an issue with a license. This had been addressed 2 weeks before 
hand. When we called at 02:00  all we got was an answering machine. We had to 
back out the upgrade. 

> 3) is the company in financial difficulties?

That is hard to tell, IMO. Numbers given to the public are not necessarily 
valid. I would guess that I would call the local BBB and see if there are any 
complaints (current). Also a call to other people that may have their product 
and get a feeling about support etc is easier.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Rugen, Len]

We had a vendor of a product to lookup error message codes try to jump our 
price years ago.  Internet search engines were just becoming useful and IBM was 
putting manuals online, so we told the vendor we would renew for a reasonable 
increase, or cancel if they wouldn't accept that.  They didn't, we cancelled 
and removed the product before its expiration date.

When we reached the expiration date, the salesman called back asking why we 
didn't renew.  I reminded him of what we said, he then offered to renew at the 
same price as before.  I explained that we had taken the effort to find another 
way and no longer needed his product, even if it was free.  

I hope his boat payment wasn't hurt :-)

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Thursday, March 02, 2017 7:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

As Dennis said, have the lawyers read your currently contract.

Hopefully, your product keys will not expire or lock you out if you change 
boxes.  The OS-Level will not usually hurt you unless the new version is using 
some features that they never used before.  But the type and serial number will 
hurt you if they are used to control the ACTIVATION of the product.

Let us all know how it works out

Steve   


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longnecker, Dennis
Sent: Thursday, March 2, 2017 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

I would think that if you had a contract in place and were not requesting any 
changes to the contract, the T's would stay the same.   If the contract was 
based on machine serial number, address, OS, etc. and you were requesting a 
change, then they could do this to you.   Sometimes they try to change the name 
of the product with a new version, but my contracts usually have language to 
include new versions, etc.

It's pretty hard to amend a contract unless both sides sign on the dotted line.

Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of JT
Sent: Tuesday, February 28, 2017 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Software vendor trying to force MSU based contract

Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.


JT

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Steve Beaver]

As Dennis said, have the lawyers read your currently contract.

Hopefully, your product keys will not expire or lock you out if you change 
boxes.  The OS-Level will not usually hurt you unless the new version is using 
some features that they never used before.  But the type and serial number will 
hurt you if they are used to control the ACTIVATION of the product.

Let us all know how it works out

Steve   


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longnecker, Dennis
Sent: Thursday, March 2, 2017 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

I would think that if you had a contract in place and were not requesting any 
changes to the contract, the T's would stay the same.   If the contract was 
based on machine serial number, address, OS, etc. and you were requesting a 
change, then they could do this to you.   Sometimes they try to change the name 
of the product with a new version, but my contracts usually have language to 
include new versions, etc.

It's pretty hard to amend a contract unless both sides sign on the dotted line.

Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of JT
Sent: Tuesday, February 28, 2017 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Software vendor trying to force MSU based contract

Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.


JT

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Longnecker, Dennis]

I would think that if you had a contract in place and were not requesting any 
changes to the contract, the T's would stay the same.   If the contract was 
based on machine serial number, address, OS, etc. and you were requesting a 
change, then they could do this to you.   Sometimes they try to change the name 
of the product with a new version, but my contracts usually have language to 
include new versions, etc.

It's pretty hard to amend a contract unless both sides sign on the dotted line.

Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of JT
Sent: Tuesday, February 28, 2017 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Software vendor trying to force MSU based contract

Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.


JT

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Paul Gilmartin]

On 2017-03-02, at 07:34, Peter Vander Woude wrote:
> 
> I pushed them that our contract for the 2 products from vendor A had totally 
> different terms, that basically gave us flat charges and/or very minimal 
> annual increases.  It took a bit, but they finally admitted, that they had 
> not even pulled the contract language from Vendor A, and had to finally give 
> in and lower the maintenance cost.
>  
"Due diligence" isn't always diligent.  There are legends that circa 2010
IBM was interested in acquiring the floundering Sun, but found Sun's
existing contract entanglements unacceptable.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Paul Gilmartin]

On 2017-03-02, at 07:16, Pommier, Rex wrote:
> 
> The company will remain nameless, but several years ago I was dealing with a 
> vendor (who will remain nameless) who had pretty much the same thing.  They 
> already had their software in escrow and were willing to provide source if 
> they went out of business.  We asked them, and they responded affirmatively - 
> and put it in the contract - that if their company was sold to a large 
> software vendor in New York that we would get their source code.  Fortunately 
> that never happened but some vendors are willing to go that step.
>  
The city of Denver had such a contract with a local TV cable franchise
which was acquired ... and acquired by Warner, so Denver could have,
if it chose, blocked the Time-Warner merger.  If the lawyers were good
enough.

You could imagine a contract for perpetual maintenance at a fixed
price (CoLA adjustment?), but hardly a contract guaranteeing continued
upgrades.  And if a vendor chooses to sunset a product, then offers
a competing similar product with enhancements ("Change the name and
raise the price!") ... how good are your lawyers?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Peter Vander Woude]

Brian,

Per your comment

"I don't think the vendor (or anyone) can change the language of a contract 
that has not expired in any way without the site's written approval.  If it's 
perpetual then I don't see how any vendor company can fight that.  They 
accepted the money and they have to stick with the terms. "

We actually had that occur.  Vendor B bought vendor A.  When Vendor B sent the 
next annual invoice, they automatically increased maintenance by 20%.  We 
didn't totally catch it until my boss, asked if the #'s were right, which was 
about 2 years later, and I after I saw it I went "what the @#$#*(@!", as over 2 
years, our annual maintenance cost had gone up by 50%.  Called Vendor B and 
their response was that 20%/year was their standard annual maintenance increase.

I pushed them that our contract for the 2 products from vendor A had totally 
different terms, that basically gave us flat charges and/or very minimal annual 
increases.  It took a bit, but they finally admitted, that they had not even 
pulled the contract language from Vendor A, and had to finally give in and 
lower the maintenance cost.

I'm not going to name the vendors, but that totally pissed me off.  

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Pommier, Rex]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, March 02, 2017 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

On Thu, Mar 2, 2017 at 3:00 AM, Dave Wade <dave.g4...@gmail.com> wrote:

> I am going to say something you gentlemen may not like...
>
> 1) Do you need the product?
> 2) Do you need continued support, e.g. for legal and compliance reasons?
> 3) is the company in financial difficulties?
>
> If the answer to all these is "yes" then paying the increased charges 
> may be your best option. If the company folds or files for protection  
> it matters not how many bits of paper you have, if there is no 
> business to honor the contracts you have then replacing the product 
> may be much more expensive. In my humble IBM is the biggest player of 
> these sorts of games and is doing an excellent job of squeezing the 
> last drop of blood from its traditional mainframe customers..
>
> .. and throwing lawyers at a problem usually drives the costs up even 
> more...
>


​I think you have some very valid points. I don't think that _any_ software 
company offers the following "option", but it is one that I'd like. What I 
_wish_ every company would "require" from a vendor is that should the vendor 
either "go out of business" or "sunset a product", that the customer would get 
a copy of the current source for the product, along with all internal 
documentation. No, I have not been taking any "funny pills". I do realize that 
perhaps all of the current z/OS vendors would like like hyenas if anyone asked 
this of them. Which is yet another reason that I am a FOSS advocate. An 
individual company might not be able to support "some product", but the 
"community" could possibly do so.



Hmmm,

The company will remain nameless, but several years ago I was dealing with a 
vendor (who will remain nameless) who had pretty much the same thing.  They 
already had their software in escrow and were willing to provide source if they 
went out of business.  We asked them, and they responded affirmatively - and 
put it in the contract - that if their company was sold to a large software 
vendor in New York that we would get their source code.  Fortunately that never 
happened but some vendors are willing to go that step.

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[zMan]

? That's pretty standard in every mainframe license contract I've ever
seen. Source escrow is a major PITA to do, but I've always had to do it for
just this reason.

OK, wait. Not for a product that gets sunsetted; that's an oversight in
contracts! But for vendors that die, it's in the contract.

/me notes to update contracts for any mainframe software HE'S involved in
buying in the future...

On Thu, Mar 2, 2017 at 8:53 AM, John McKown 
wrote:

> On Thu, Mar 2, 2017 at 3:00 AM, Dave Wade  wrote:
>
> > I am going to say something you gentlemen may not like...
> >
> > 1) Do you need the product?
> > 2) Do you need continued support, e.g. for legal and compliance reasons?
> > 3) is the company in financial difficulties?
> >
> > If the answer to all these is "yes" then paying the increased charges may
> > be your best option. If the company folds or files for protection  it
> > matters not how many bits of paper you have, if there is no business to
> > honor the contracts you have then replacing the product may be much more
> > expensive. In my humble IBM is the biggest player of these sorts of games
> > and is doing an excellent job of squeezing the last drop of blood from
> its
> > traditional mainframe customers..
> >
> > .. and throwing lawyers at a problem usually drives the costs up even
> > more...
> >
>
> ​I think you have some very valid points. I don't think that _any_ software
> company offers the following "option", but it is one that I'd like. What I
> _wish_ every company would "require" from a vendor is that should the
> vendor either "go out of business" or "sunset a product", that the customer
> would get a copy of the current source for the product, along with all
> internal documentation. No, I have not been taking any "funny pills". I do
> realize that perhaps all of the current z/OS vendors would like like hyenas
> if anyone asked this of them. Which is yet another reason that I am a FOSS
> advocate. An individual company might not be able to support "some
> product", but the "community" could possibly do so.
>
>
>
> >
> > Dave Wade
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> "Irrigation of the land with seawater desalinated by fusion power is
> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[John McKown]

On Thu, Mar 2, 2017 at 3:00 AM, Dave Wade  wrote:

> I am going to say something you gentlemen may not like...
>
> 1) Do you need the product?
> 2) Do you need continued support, e.g. for legal and compliance reasons?
> 3) is the company in financial difficulties?
>
> If the answer to all these is "yes" then paying the increased charges may
> be your best option. If the company folds or files for protection  it
> matters not how many bits of paper you have, if there is no business to
> honor the contracts you have then replacing the product may be much more
> expensive. In my humble IBM is the biggest player of these sorts of games
> and is doing an excellent job of squeezing the last drop of blood from its
> traditional mainframe customers..
>
> .. and throwing lawyers at a problem usually drives the costs up even
> more...
>

​I think you have some very valid points. I don't think that _any_ software
company offers the following "option", but it is one that I'd like. What I
_wish_ every company would "require" from a vendor is that should the
vendor either "go out of business" or "sunset a product", that the customer
would get a copy of the current source for the product, along with all
internal documentation. No, I have not been taking any "funny pills". I do
realize that perhaps all of the current z/OS vendors would like like hyenas
if anyone asked this of them. Which is yet another reason that I am a FOSS
advocate. An individual company might not be able to support "some
product", but the "community" could possibly do so.



>
> Dave Wade
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Dave Wade]

I am going to say something you gentlemen may not like...

1) Do you need the product?
2) Do you need continued support, e.g. for legal and compliance reasons?
3) is the company in financial difficulties?

If the answer to all these is "yes" then paying the increased charges may be 
your best option. If the company folds or files for protection  it matters not 
how many bits of paper you have, if there is no business to honor the contracts 
you have then replacing the product may be much more expensive. In my humble 
IBM is the biggest player of these sorts of games and is doing an excellent job 
of squeezing the last drop of blood from its traditional mainframe customers..

.. and throwing lawyers at a problem usually drives the costs up even more... 

Dave Wade

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Steve Beaver]

Companies like ASG have been playing those games since Allen lost ASG to the 
banks and creditors

Any way to squeeze out a buck

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Wednesday, March 1, 2017 7:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

> —SNIP-
> I was at a client a number of years back where the vendor up and qudrupled 
> their license charges, with no increase in features or functionality.  The 
> client had no choice, as the vendor product was critical, but I let that 
> vendor know that we would be looking to ditch them at the earliest 
> opportunity, and I have not recommended them to any other client since.
> 
> Regards,
> Tom Conley
——SNIP——

Same here. I have made every effort to get rid of vendor x software. I 
personally got 3 companies to drop their software (and saved a bundle).

A *LONG* (30 years) time ago there was a company that when we upgraded our 
hardware. The vendor was the first in line with a bill of 1 *MILLION* dollars.

We did everything we could do get rid of their software, unfortunetly  there 
was no other vendor out there offering anything close. The company I worked for 
put the company on notice that we would never buy anything from them again. The 
company was happy with their check and couldn’t have cared less.

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Edward Gould]

> —SNIP-
> I was at a client a number of years back where the vendor up and qudrupled 
> their license charges, with no increase in features or functionality.  The 
> client had no choice, as the vendor product was critical, but I let that 
> vendor know that we would be looking to ditch them at the earliest 
> opportunity, and I have not recommended them to any other client since.
> 
> Regards,
> Tom Conley
——SNIP——

Same here. I have made every effort to get rid of vendor x software. I 
personally got 3 companies to drop their software (and saved a bundle).

A *LONG* (30 years) time ago there was a company that when we upgraded our 
hardware. The vendor was the first in line with a bill of 1 *MILLION* dollars.

We did everything we could do get rid of their software, unfortunetly  there 
was no other vendor out there offering anything close. The company I worked for 
put the company on notice that we would never buy anything from them again. The 
company was happy with their check and couldn’t have cared less.

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Tom Conley]

On 2/28/2017 9:48 PM, JT wrote:

Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.




I was at a client a number of years back where the vendor up and 
qudrupled their license charges, with no increase in features or 
functionality.  The client had no choice, as the vendor product was 
critical, but I let that vendor know that we would be looking to ditch 
them at the earliest opportunity, and I have not recommended them to any 
other client since.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[zMan]

If it's truly a perpetual, unlimited-seat license, "No" is the correct
answer, and the vendor gets sleaze points for trying an end-run. If there's
a weasel clause, you may be SOL.

Will be very interested to hear how this plays out.

P.S. Would not be the first time a vendor (software or otherwise) has tried
such a ploy, of course, nor will it be the last. I remember during the OCO
wars at least one vendor had to provide source forever to Princeton
University because they had written it into the contract. The techies at
that vendor were not happy about it, not because they believed in OCO but
because they had to cut a special package for Princeton every release.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Allan Staller]

Yes. Several times with CA (back when there were numerous alternatives).
Tell the vendor NO. 
Honor the contract and receive some revenue, or force the addendum and receive 
no revenue!


Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.




::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Brian Westerman]

We maintain over 100 sites either fully or partially, and we run into this type 
of problem from time to time.

We had a recent problem where our Software AG software attempted to increase 
the cost based on SAG MSU's instead of IBM MSU's, even though the box had not 
changed (just the location was moved 2 miles away from the old data center) 
which we tangled with them over (and won).  

Some of the sites we help manage are University and County/State Government 
sites which seem to have been convinced several years back by vendors when the 
sites began to shrink in size to purchase "one-time-charge" and "perpetual" 
licenses, and it has come back to bite the vendors as the sites are still 
around.  Some vendors will allow them to upgrade to the "current" version at 
any time, but we found that some are very strict about the version they can 
run.  The worst ones were those that said as long as they don't change the 
version it was okay to keep running, knowing that the older version isn't 
supported on a newer z/OS release.  Unless it specifically says that the 
version is restricted in the original (perpetual) license though, they can't 
force the issue.  

Agreements, when they are vague in the restriction language are held against 
the company (or person) who created the agreement, and in most cases that's the 
vendor.  We have been through countless disagreeements with vendors to help the 
client get what they were promised and we have not lost yet.  In a VERY few 
cases, we were even able to re-instate licenses that were completely dropped 
without going through another big initial charge.  Compuware was particularly 
nice about that for several sites we manage. 

I don't think the vendor (or anyone) can change the language of a contract that 
has not expired in any way without the site's written approval.  If it's 
perpetual then I don't see how any vendor company can fight that.  They 
accepted the money and they have to stick with the terms. 

Sometimes I feel that some of the vendors were just trying to get extra money 
from sites that they felt were going to disappear, and unfortunately for them 
the sites are still kicking.

Which vendor is giving you problems?  I can check with the Client Services 
people here and see if we have been through this type of problem with them in 
the past and tell you what we did to handle it.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Jack J. Woehr]

Timothy Sipples wrote:

If a vendor wants to charge $2
per user hair follicle per fortnight


If that's head hair (as opposed to beard hair) I'd be in great demand, we'd get 
the software for next to nothing.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Software vendor trying to force MSU based contract

[Timothy Sipples]

John Thinnes wrote:
>A vendor for a mainframe data entry product used for the
>last 30 years (with a perpetual unlimited seat license)
>has sent us a contract addendum where they increase the
>price by 60+% and include language to change to a MSU
>based license. The use of this product is dwindling while
>our MSU foot print is growing.

Any/every vendor can decide what to charge and how to charge for its
products, within a few legal limitations. If a vendor wants to charge $2
per user hair follicle per fortnight, that's probably legal.

Any/every customer has the option not to purchase (or to stop using) a
vendor's product if they cannot reach a mutually acceptable agreement.

In my view, a MSU-based license can be perfectly fine, even better than
fine, if the product is eligible for reasonable sub-capacity licensing
terms. Then at least you can run the product in its own softcapped LPAR,
assuming it can function that way. For example, if it's a CICS-based
product, perhaps it's possible to run the product in its own, separate CICS
region(s) in a separate, softcapped LPAR (or LPARs). You might have some
reconfiguration to handle the new license terms, but it's doable.

If a MSU-based product is not eligible for reasonable sub-capacity
licensing, and if the product does not represent at least a substantial,
reasonably steady fraction of your total machine workload (now and into the
forecast future), then that discrepancy can be a significant problem. If
you're absolutely stuck with such terms then you might be able to segregate
that product on a "penalty box," meaning a separate physical machine. As
examples, the "penalty box" could be your DR machine (otherwise idle and
with limited permanent capacity), your dedicated Coupling Facility machine,
or a machine only running other operating systems, such as an otherwise
Linux only machine. Or a new machine you buy or lease expressly as a
"penalty box." It could be IBM's machine ("IBM Cloud Managed Services on z
Systems"), or it could be another hosting company's machine, assuming the
vendor offers "hosting company" (i.e. sub-capacity) licensing terms to such
parties.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Software vendor trying to force MSU based contract

[JT]

Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.


JT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN