Slashdot Mirror
Source Code Escrow
Makarand writes "According to this article in The Economic Times (India) Software companies in India
are embracing the trend where source code for the software being bought or sold
is
kept safe with an escrow agent
with carefully drafted agreements. This allows
the buyer to get hold of the source code in cases where software was licensed from a
start-up which has now folded or a breach of contract regarding the maintenance services
that were agreed upon can be proven. The source code is automatically released
upon the occurrence of any of the events mentioned in the escrow agreement and the
buyer will be able to study the source code and continue to provide support services
for the software bought without relying on the employees of the software supplier."
If the developer goes out of business, getting the source code by itself is almost always useless: almost no single customer will have the resources to maintain and extend it. Source code is only cost effective if there is a community of users and developers, and that requires releasing the code under an open source license ahead of time.
(For the same reason, Microsoft source code isn't their crown jewels, as they always claim: even if people got access to it, they couldn't develop and maintain it anyway. The main reason Microsoft doesn't want their sources released is probably marketing--the "Coca Cola Secret Formula" gimmick--and the probably embarrassing state of it.)
Another problem with source code escrow agreements is that people don't know whether the code deposited with the agent will even compile or be complete. And the agents themselves disappear or misplace code.
Some of the early source code escrow companies themselves went bust. You need a software escrow agent that's likely to be around for decades. There are still companies offering software escrow services, but it's a minor business.
Iron Mountain has a software escrow business, and they offer some stories of software released from escrow. The most common situation is bankruptcy of a supplier.
Ok, who's gonna be the first one to make some caffeinated beer?
.com bubble. I think they were the first to sell caffeinated beer...
It's been around a while - I remember hearing about Rethink Beer back during the height of the
I had the lead for my former company's purchase of a customized Learning Management System. My employer was a privately held retail chain which could barely keep the configuration straight on our POS, and had already replayed the whole custom software development death march several times. But the lawers insisted that we obtain a "Source Code Escrow" for our $250k LMS purchase. I asked them under what conceivable circumstances they thought we would actually put together a team to take the code back into development, or even to create the build environment for debugging (and recursion testing, rinse, wash, repeat). I escalated to VPs, who basically said "Gotta have Source Code Escrow" while having no clue what would really be involved. So we paid for and got it. The LMS company indeed went belly up during the dotcom bust and we abandoned their product for an off the shelf system from a more stable vendor. But they still have the right to dig that old code out of escrow should they desire!
----- Indecision is the key to flexibility.
Another problem with source code escrow agreements is that people don't know whether the code deposited with the agent will even compile or be complete
Escrow is just like software, its goodness or badness varies with the people involved. Nearly two decades ago I worked at a medium sized company that sold equipment to the phone company. Everything went into version control. Source code, documentation, compilers, libraries, tools, config files, etc. Developers produced a release candidate, passed along CRCs of all files to QA. QA wiped a PC's hard drive, grabbed the candidate from version control, built it for themselves, and verified the CRCs matched. QA only tested what they built for themselves. When a candidate was approved and released to the phone company that release was also sent to the escrow company designated by the phone company. And of course checklists documented the process above.
I can't see how this differs from the concept of a notary.
In France, Belgium and almost all countries where Napoleon once waved the scepter, the function of "notary" was introduced.
Whenever there's a contract where both parties want nonrepudiation, they use that person to ensure legality of the contract, safekeeping of the definitive version of the contract, and to ensure that the actions necessary will be taken when certain events happen.
For instance, in Belgium no one buys a house without a notary. People also use it for things like their last will. He also can perfectly used to keep sourcecode. In fact, all notaries are obliged to ensure safekeeping for at least 25 years personally and after that, documents are moved to the repository of the order of notaries.
BTW, the absence of a notary isn't the only defect of the American legal system.
about 20 years ago. We used some software written by Arthur Andersen called "Lexicon" and "Base V". This was software that we used to develop all of our applications, and the source to these products was kept in escrow. One day A.A. decided they didn't want to maintain these products any more, and we got the code from escrow. The code was written in Basic Assembly Language, but we were able to maintain it ourselves with no problem. This was fortunate, because absolutely everything we ran depended on this software.
Escrow is an old idea, but a very good one.
Our escrow agreement with the NCC (the escrowers) wasn't like that - one of the triggering events *is* the takeover of the software vendor, or support going away.
Oolite: Elite-like game. For Mac, Linux and Windows
Notaries in the US aren't holders of document repositories, as they are in many European countries. They witness signatures, sure, but they sure don't keep original copies of everything they notarize for 25 years. They just stamp and sign the original document, which is retained by the client.
AFAIK, the notary dates back to the Roman Empire. It is a component of likely every civil law system since. The notary existed before the Napoleonic Code, however, it was refined and developed further under the Code. Of course, America's legal system is derived more from common law, than civil law. The public notary has been part of the American legal system since before the country was founded. I do grant that the role of the notary is more formalized and mayhap stronger under the Napoleonic Code.
/. readers I have not read the article, so (unlike most /. readers) I can't actually comment on it.
I do agree there are defects under the common law systems. There are also defects under the civil law systems and under the Napoleonic Code. All legal systems (or any other systems) have defects. We have to work them out. That is one of our roles in a civil society.
None of which is particularly relevant to source code escrow, since that doesn't require anything other than an independent third party - if that.
I've done source code escrow for code I've written, or made sure it was added to contracts for code hired or purchased by others, for close to thirty years. Most of the time no third party has been used. It's just been a clause saying that the source code was available at the office of the developer. That gave them the right to get the source code if the default conditions in the contract applied. The defaults included dissolution of the developer, inability or refusal of the developer to support the product, etc.
When we used a third party, it was a third party lawyer, or safe deposit box at a bank, the developer's lawyer, a third party developer who agreed to take over development, etc.
A more formalized source code escrow mechanism would be beneficial to everyone. As most
-- Dan Jenkins, Rastech Inc.
When the companies of one nation have their software written by another nation, it is like teaching people from another family to make a living, rather than teaching members of your own family.
Code written by Indian programmers will find its way into programs that are owned by Indian companies. The Indian companies will eventually compete against the companies who paid to have the software written.
Having source code in escrow misses the point. The point is that arms-length management of coding just doesn't work. It doesn't work even if done inside one company. Arms-length, detached management may seem to work in the short term, but there are numerous failures over time. So, if you think you need source code escrow, already something has gone wrong with your management.
For many business applications, the biggest intellectual challenge in producing code that is enduringly useful is in the communicating and management, not strictly in the coding itself.
I'm not the only person who thinks this. See comment #7812340: "Programming a decent size application is mostly communication and management challenges, not coding."
The article referenced by Slashdot, in the India Times magazine Economic Times, is an advertisement for a point of view, as is the Slashdot story. The real purpose of the article is to sell US and UK companies on the idea that the Indian company should be allowed to own the source code of the programs that it writes. Here is a quote from the article:
'Similarly Sanjay Deshmukh, business development director, Business Objects, states: "The customer who gets the source code, if the stipulated events occur, has only limited rights and can use the same only for support related activities. The customer cannot make commercial use of the same by reproducing it." '
Note that the recommended "stipulated events" are unlikely to occur without a VERY costly legal battle waged in two nations. Here is a quote:
'Subash Menon, president and CEO, Subex Systems, says, "The customer has to establish that they are unable to obtain support from Subex, causes could range from bankruptcy or discontinuation of that software product." Subex Systems has entered into such agreements only for its customers in North America.'
What are the chances that Mr. Menon will ever agree that he can't support software written by his own company? Zero. So, escrow is just a tax on the uninformed. If Mr. Menon goes bankrupt, what are the chances that his valuable interests will not be sold to another company? Zero again. Even if Mr. Menon and his employees all die in some terrible accident, Subex Systems will live on as a legal entity, because there is money in making it do so.
I've developed and sold several products where I or my company have licensed them to a corporation. Each time the source code and environment had to be held in escrow with certain release conditions.
The most common was if I were to be out-of-commision or unreachable (at my choice of contact mechanisms) for more than two weeks.
The conditions and location have been generally very open to negotiation. For example, I added certain clauses and contact mechanisms to the standard software one, but I also removed some other restrictions because I didn't feel they were needed. As long as the contingency is covered, everybody is happy. It was a bit scary the first time for me, because I'm entrusting my leverage (excluding my skill and domain knowledge, which actually is the far greater leverage) to faceless lawyers, but I now rely on escrow as an advantage. It sooths the fears of the corporates.
Absolutely, anyone can build from an escrowed source. If the developer wants them to be able to.
We sell software. Fairly specialised software to a small number of customers. We put the code into escrow for a number of reasons. One is so that if we go out of business our customers aren't completely screwed. They can get together and use either some of their in-house developers or an external developer and have the code maintained. An added bonus is that it makes the customers happy to have that safety net.
(Another advantage is that the code escrow company also acts as an additional off-site backup for our code tree. Should something go horribly wrong and our development sites were to all be destroyed by an earthquake there'd still be yet another copy of the development tree at the code escrow company. And the code escrow company is a lot cheaper than most off-site data backup agencies...)
We cut each build from a CVS tree that contains all the source and configuration information. Immediately after a release build is done, we burn the CVS tree to CD. If it passes all the QA, we ship the CD to the escrow company.
Anyone with perl and a C++ compiler can build the full application from that CD. So, in our case, every escrowed source release can be retrieved and rebuilt (and the escrow company specialises in code escrow, and has for many years, so they're pretty good at version and media tracking).
If I were doing it again I'd create the build environment around Vesta rather than CVS, so guaranteeing that it can be rebuilt from archives to a bit-identical binary at any time, but Vesta wasn't really stable for production use when we started this project.
So code escrow works for us, but we (the software developer) are actively using it, rather than doing so grudgingly because a customer requires it, and that may not be the usual case. But it could be improved massively, by updating to newer technology. I don't want to have to ship CDs - I want to rsync or scp data. In fact, there's a lot to be said for giving the source not only to the escrow company, but also giving it (encrypted) to every customer, and giving the password to another escrow company that didn't need to do anything more than have an arrangement to release a password to each of our customers if we were to go under. There's a potential market there.
What's the advantage of having a code escrow company do this, rather than just having in our contract the commitment to release source if we go bust? Simple - many of the ways in which we could go bust, as a small company, could involve everyone involved being dead, or could involve legal action that ties all our assets up in court for years. In either case the escrow company can release the data as an independent third party.
(And why don't we "just open source our code" as many here suggest? It just doesn't work that way in the particular section of business we're in. In some fields it can work, in others it doesn't. We're in one where it doesn't. It's not that we're an anti-open-source company - just the opposite, we release a few open-source packages, and have a policy of going open-source with in-house tools where they'd be of broader value.)