On 8 May 2014 22:09, Mitch <mitc...@aol.com> wrote: > And for the likes of the larger ISVs, I would guess all of their product > source >code is in escrow and kept up to date. Maybe not so much for the "mom and >pop" software >companies, but the big ones, yes.
I think it's exactly the "mom and pop" ISVs that are more likely to be required by buyers to have escrow arrangements in place. Few companies are in a position to require e.g. IBM to do much of anything. Particularly in the mainframe world, it's common for customers to be hundreds or thousands of times larger than small ISVs. In passing, it's certain that there are long-time customers of prominent ISVs with agreements still in place that no vendor would sign today -- things like perpetual licences and even maintenance to "the product and all successor products". While I can't speak to my current employer's practices, in past lives I have seen a number of escrow agreements from both the customer and ISV sides. They are often strangely weak and strong in different places, and not infrequently dangerous for both sides. It's easy, but mostly quite correct, to blame lawyers who don't have any real understanding of the software development and maintenance process for this. Some problems not yet mentioned: What happens if the escrow company itself declares bankruptcy, is acquired (under adverse or friendly circumstances) or perhaps worse, simply fails to perform as expected in the crunch? What if they lose the escrowed material, or allow it to be stolen, or deliver damaged, unreadable, or just plain blank media? All of these have happened. Is it feasible for the customer to test these procedures? Escrow agreements are generally part of the contract between vendor and customer, and require in turn that the vendor maintain an agreement with an acceptable escrow company. (In passing, there are fewer escrow companies now than there were say ten years ago.) Usually the customer has no direct relationship with the escrow company, and so -- as Charles Mills points out -- will end up arguing with other creditors in bankruptcy court over the assets. On the flip side, the customer-vendor contract language that triggers (or allows the customer to trigger) the escrow clause is often -- because of customer demands -- very liberal in the events that do so; a mere change of control wouldn't be expected to allow the customer to get the source, but I have seen agreements that effectively specify just that. Not what the vendor thought was being agreed to, but the language was evidently borrowed by lawyers from that used in the employment contracts with senior execs/founders. (Thankfully, none of these was attempted to be enforced by a customer.) Escrow agreements rarely describe what happens to the ownership of the source and product in the case of the escrow clause being triggered. Even if the escrow company hands over the package immediately upon the trigger, the customer may yet not have all the legal rights to continue to use it in any meaningful way, even if the technical ability is there, and could easily find itself again in court arguing with creditors. What if the product is written in a language or using tools or libraries from a third party, or otherwise unavailable to the customer or its hired technical people? For example IBM's PL/X is not generally available, but it was briefly available to ISVs, and probably some have continued to use it. A customer would be unable to compile the code they got from escrow. So I rather agree with Charles that these agreements offer more comfort than real effect. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
