Source Code Escrow 182
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."
source code escrow not very useful (Score:5, Informative)
(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.
More popular in the 1980s. (Score:5, Informative)
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 [yahoo.com], but it's a minor business.
Iron Mountain has a software escrow business, and they offer some stories of software released from escrow. [dsiescrow.com] The most common situation is bankruptcy of a supplier.
Re:source code escrow not very useful (Score:5, Informative)
Other things that microsoft would like to protect are:
a) obvious security holes that anyone who looked at the code could pick out
b) the source code to IE, so people don't release a patched version that doesn't suck.
c) DirectX, so windows will always remain the system to play games on. Imagine if we had the directx source. Within a couple months there could be a stable linux fork of directx and all windows games would work perfectly in linux.
d) Secrets. There are all kinds of things that windows could be doing that nobody knows about exept for one guy at MS who coded it in. If the source was open
e) The #1 reason is really money. If the source for windows was open it would be just that much easier to get free copies of windows. Even better than that, they would get Windows Lite. Just like everyone uses Kazaa Lite. If the source for windows was open there would be a no IE no Media Player stable version roaming the net. People would switch to it so fast. MS would lose all its revenue from desktop OS licenses.
f) File formats. If we had the source to office the doc file format would be wide open among others. Presently doc files are supported for importing/exporting in non MSOffice word processors, but it never goes quite right. Justification is missing, or fonts break. With the file formats open nobody would have a reason to use office.
g) Driver database. This kind of goes with the NTFS thing I talked about, but windows has a huge database of device drivers in it. With access to the source for all these drivers linux or any other OS (SkyOS or BSD) would have equivalent hardware support to windows.
If you get the games (directx) and the hardware support, there just wont be a reason for people like me to dual boot anymore. If MS opens its source people will look at it and fork it and pieces of it. They wont maintain and develop it. They will chop it to bits and turn lead into gold. Thus being the end of Microsoft's monopoly.
Their source code isn't some secret ingredient. It's the only thing seperating them from certain doom.
Re:A better way to avoid this problem (Score:3, Informative)
It's been around a while - I remember hearing about Rethink Beer [rethinkbeer.com] back during the height of the
My escrow experience (Score:4, Informative)
No, Escrow can be complete and accurate (Score:5, Informative)
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.
Re:Not a new idea ... (Score:1, Informative)
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.
My company benefitted from escrowed code... (Score:2, Informative)
Escrow is an old idea, but a very good one.
Re:Specific case where it hasn't worked well (Score:3, Informative)
Re:Not a new idea ... (Score:2, Informative)
Re:Not a new idea ... (Score:2, Informative)
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
Escrow is evidence something is wrong. (Score:3, Informative)
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 [slashdot.org]: "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.
Normal part of contracts (Score:2, Informative)
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.
Re:Anyone succeed in a rebuild from escrowed sourc (Score:2, Informative)
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.)