Charles,

My first question is this:   how does your scenario differ from hiring a new 
programmer and telling him he has to support an application that has been 
around for years, but none of the previous developers or support staff are with 
the company any longer?  However, your point about what happens if and when you 
do have to get access to the code from a no longer existent vendor.  This is 
true, but also I would be surprised if any company would put something into a 
production environment without first testing it, whether it is if the vendor 
product "blows up" or something changes in the client's environment.

I represented a vendor (who shall remain unnamed) and a situation happened 
where they had their product code in escrow, they were taken to court by a 
competitor, and the competitor won the case.  The vendor then had to make their 
current version of their product available as per contract.  A end user 
organization should ensure that any escrowed source is always the latest 
version as per contract stipulations.

Lastly, bankruptcy is typically financially oriented.  Contract language for 
"real" property is handled differently than financial obligations.  Again, I, 
unfortunately, learned this first hand.  BTW, IMHO, any vendor that is worth 
their salt will keep their  various versions held in escrow up to date.

Respectfully,

Mitch McCluhan



-----Original Message-----
From: Charles Mills <charl...@mcn.org>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Thu, May 8, 2014 3:32 pm
Subject: Re: Vendor Source Code


The usual term for this is "source code escrow." A third party holds the
ode with a contract that says that if the vendor goes out of business or
ails in some way then you get the source code. The third party charges, and
o the vendor may charge you.
There are two or three HUGE problems with source code escrow:
1. Thing about your own programs. You hire a guy or gal. You sit him or her
own with all of the documentation and relevant tools and help from your
xperienced people. How long before he or she is productive? Three months?
ow, suppose this vendor product blows up and it turns out the vendor is out
f business. You are going to go to court, get the software from the escrow
gent, get the necessary platforms and tools -- and fix the bug, all quickly
nough to make a difference to your business?
2. Unless you have an elaborate verification process, what if you get the
ource code and discover that through malice or oversight, the source code
s five versions back out of date and missing three critical include files?
3. A contract that says "we will do X in the future" -- in this case, give
ou access to our source code -- is what is called an "executory contract."
ankruptcy courts are very reluctant to enforce executory contracts because
he whole point of bankruptcy is tear up whatever came before and give the
ebtor a fresh start.
Charles
----Original Message-----
rom: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
ehalf Of Dno
ent: Thursday, May 08, 2014 1:18 PM
o: IBM-MAIN@LISTSERV.UA.EDU
ubject: Vendor Source Code
Hi,
> We're looking to purchase a sw product and our lawyers are looking at the
's and c's to see if we can have the right to their source code. At my
revious job we did this for BMC, we kept it at IMAR. I guess I never
nderstand why, so I'm asking if anyone our there does this and for what
eason. If the company went out of business what would the source code do
or us? Would we give it to another third party to maintain for us? I
ppreciate the feedback.
----------------------------------------------------------------------
or IBM-MAIN subscribe / signoff / archive access instructions,
end 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

Reply via email to