Charles, First, thank you for the debate. I enjoy and appreciate your insight. Very well stated!
Regarding the case I mentioned, it was not a licensee/user, but a competitor. Long story, but not one I feel comfortable going into any further detail about. Regards, Mitch -----Original Message----- From: Charles Mills <[email protected]> To: IBM-MAIN <[email protected]> Sent: Thu, May 8, 2014 5:45 pm Subject: Re: Vendor Source Code > how does your scenario differ from hiring a new programmer and telling him e has to support an application that has been around for years Obviously we could invent hypothetical scenarios which were the same or ifferent. I think it is at least plausible that in your scenario there ould be some documentation and appropriate tools such as compilers, and erhaps in-house skills. ("Your" scenario application is written in COBOL nd the shop has COBOL programmers; the escrowed application is written in ORTRAN and there are no FORTRAN skills in-house.) But Yes, best case, your cenario is similar to identical. But of course there is no preceding rawn-out court fight and hopefully no crisis (unlike "it blew up and we inally figured out the vendor is out of business"). > they were taken to court by a competitor, and the competitor won the case Interesting. The competitor must have been a licensee, with an escrow greement, and the vendor must have breached the support agreement. Unusual o say the least. > bankruptcy is typically financially oriented. Contract language for real" property ... Bankruptcy is bankruptcy. Software is intellectual property. Bankruptcy asically trumps contracts. If I were a creditor of a bankrupt software ompany I would be in court arguing that the source code should be sold to he highest bidder to help satisfy the software company's debts to me and thers, not given away due to an executory agreement. What would the court ay? We would be paying lawyers to find out, wouldn't we? (Meanwhile, the oor customer's critical processing is still waiting on a bug fix.) Escrow may work in certain circumstances. I think it is problematic to the oint of having little benefit. Your mileage may vary. Charles -----Original Message----- rom: IBM Mainframe Discussion List [mailto:[email protected]] On ehalf Of Mitch ent: Thursday, May 08, 2014 5:12 PM o: [email protected] ubject: Re: Vendor Source Code Charles, My first question is this: how does your scenario differ from hiring a new rogrammer and telling him he has to support an application that has been round for years, but none of the previous developers or support staff are ith the company any longer? However, your point about what happens if and hen you do have to get access to the code from a no longer existent vendor. his is true, but also I would be surprised if any company would put omething into a production environment without first testing it, whether it s if the vendor product "blows up" or something changes in the client's nvironment. I represented a vendor (who shall remain unnamed) and a situation happened here they had their product code in escrow, they were taken to court by a ompetitor, and the competitor won the case. The vendor then had to make heir current version of their product available as per contract. A end ser organization should ensure that any escrowed source is always the atest version as per contract stipulations. Lastly, bankruptcy is typically financially oriented. Contract language for real" property is handled differently than financial obligations. Again, , unfortunately, learned this first hand. BTW, IMHO, any vendor that is orth their salt will keep their various versions held in escrow up to ate. ---------------------------------------------------------------------- or IBM-MAIN subscribe / signoff / archive access instructions, end email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
