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."
Not a new idea ... (Score:5, Interesting)
What if the escrow goes bust as well? (Score:2, Interesting)
Build Environment ? (Score:5, Interesting)
Also, i wonder if these agreements are just the tip revisions of a bunch of files ? If so, you'd lose the incredible documentation provided by SCM changelogs. And if the SCM database is held in escrow, what if the software licensee doesn't have a valid license for the SCM system the code was developed with ? What if the SCM / build tools provider goes under, or has some problem ?
It'd be interesting to actually read one of the documents. The legal nonsense just to buy a house is absurd enough.. imagine trying to write a legal document that basically gives you a guarantee that you can survive without some random software company in India.
Has anyone succesfully executed a SC escrow action (Score:3, Interesting)
If I was a software supplier, I would certainly agree to somthing like this - there simply is no downside. For one, I can usually put the "source" in escrow but no-one really know if it's enough for someone to move forward.
Also, if the company goes into bankruptcy, the bankruptcy judge may have some reasons to intervene in such agreements.
An escrow contract simply does not compete with true open source software.
Hire an expert (Score:3, Interesting)
Re:More popular in the 1980s. (Score:2, Interesting)
The biggest consumers of tape backup software demand, and receive, source code escrow agreements from Veritas, Legato - etc.
Nothing like having your tape b/u s/w company go under, and you sitting on all that tape data.
Not really useful (Score:0, Interesting)
(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.
Re:source code escrow not very useful (Score:5, Interesting)
Bzzzzt! Wrong. Code is usually put in escrow after a team of developers, either from the client or a third party, examines it (under an NDA) and comes to a conclusion that if the vendor goes bust they would be able to maintain it. This gives the client the option that their own people or a third party could take over if need arises.
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.
Microsoft code will not be put under escrow any time soon, I suspect. The arrangement usually fits the situation where a small software vendor (e.g. a startup) delivers a software product to a bigger company. The bigger company is concerned that the small vendor may go under, but they have some assurance that they - or another software company - can pick maintenance up with the escrow code. Since they are big compared to the vendor the additional resources will not be prohibitive. They were paying the vendor for support, too. Now they will be paying someone else, or allocate a few people of their own.
What is put in escrow is negotiated - this would normally include everything that is needed to maintain the product, including a working build system, older revisions and logs, documentation, etc. Again, the package is examined before put in escrow, and someone whom the client trusts says, in a pinch I will be able to do it.
Normally the client would still prefer the vendor to stay afloat and provide the service though. Escrow is the second line of defense, and as such it is useful. From the clients point of view it is open source, but they are not in a rush to modify or redistribute it.
Re:Compile-by-escrow? - (Score:4, Interesting)
There are a number of factors that determine how useful the source code is to a client, including:
It seems to me that source escrow could be made more useful if the escrow agent not only compiled the binary supplied to the client, as the parent suggests, but also studied the source and issued a report on factors like the above. This would allow potential purchasers to assess the risk that they were taking. This could affect the choice of software and possibly pricing - some buyers might be willing to pay more for software with lower risk, or might be willing to buy riskier software at a lower price on the theory that they could estimate what it would cost them to deal with less useful source if it came to that. And since many of the same factors tend to be correlated with code quality, a positive report on this front would also give some confidence in the quality of the program. Obviously open source provides the maximum protection, but if that is not an option, a system like this would seem to be helpful.
Effective as administrative grease (Score:5, Interesting)
We were a medium large company with a package we wanted developed. For reasons I wasn't in on it wasn't being done in-house. The big concern was the small shop we were considering hiring going belly-up halfway through, or just as bad not being responsive to future maintenance issues or possible further development.
So I suggested escrow and it reassured the right folks in the right offices and the outside developer was also agreeable. So the next week our lawyers wrote something everybody was happy with and the contract was given and the project went ahead. A month or so later along with delivery of the application we got the code we'd paid for, our coders looked it over and liked the internals, it passed our QA, all good.
Later we paid for some bells and whistles to be added by the original developer. I also know our coders made some trivial changes to the cosmetic side. Beyond that it's probably still running pretty much as-was.
The escrow bit was really there to reassure folks; it sounded good and responsible to the folks nervous about hiring a small shop. In reality it probably would have cost us more in legal fees and meeting time (plus come-up-to-speed time for the coders) to rescue & reuse the escrowed code then just sending out the contract again or doing it in-house. But as administrative grease it worked fine.
Oh, Open Source? First off that company didn't think that way (insurance/HMO-type folks) so that battle would have been twice as tough as escrow was. Furthermore as the code was intended to touch our partners/owners/clients letting it free could have freaked them out too. These days at least they'd have heard of the OS though might still be hard to sell on actually implementing it (it'd publicize their internal data structures or something.)
Would I do it again? Sure in that kind of butt-covering situation. In an adversarial situation, particularly one possibly turning such early on, it'd be far too easy to poison (the benefits could never outweigh the costs of that sort of disaster anyhow).
I'd also not go with escrow alone for something big and complex and vital, too hard for someone else to pick up. In that situation either we'd bring it in-house, make damn sure of the developers, or perhaps require our interests being protected with our own team actively involved and vetting it.
But used it once, to good effect, yes.
Re:source code escrow not very useful (Score:5, Interesting)
It seems like a binary proposition to me:
You either beleive linux and open source are having no effect whatsoever on the computing industry, or you beleive that Microsoft marketing is having trouble dealing with linux/OSS
Let me assure you. MS is losing sales to OSS software. They take it so seriously that there are direct channels of communication within the comapany that go very high in order to attempt a mitigation of any technical (or other) blockers in an OSS vs Microsoft competitive situation.
It is my understanding that it is possible for a leaf-node sales person to have director/VP level ears, in a matter of hours, if necessary, when linux is involved.
Incidentally, this is what lots of people have been asking for, I think. MS is competing on technical merit, on management, on features, on security, and even on cost.
Re:Which oldest software is still in production? (Score:5, Interesting)
In 1989-1990 I was involved in a project that implemented a system that would have to be maintained for at least 10 (preferably 15) years.
The project was related to a mobile telephone network that predated GSM.
The people deciding the hardware and software platform chose the Digital Equipment Corporation VAX running VMS. Furthermore, a couple of Compaq PCs were used, running MS-DOS and using some very special cards in ISA slots.
In hindsight, what can we see:
- Digital Equipment Corporation no longer exists
- the VAX line was replaced by the Alpha
- which is being discontinued as well
- VMS I don't know, is it still maintained?
- MS-DOS isn't used by anybody anymore
- PCs with ISA slots are now very hard to get
- but fortunately: the network for which this was all developed was taken out of production after about 5 years, to be replaced by GSM.
I thing to sit out its entire 15-year maintenance would have been kind of tricky. Maybe with proper monitoring of end-of-sale announcments and buying some spares at the right time, it could have been pulled off.
Re:Has anyone succesfully executed a SC escrow act (Score:5, Interesting)
A major misconception (Score:4, Interesting)
When shopping for a tool, I don't look at how beautiful it is, or how elegant. Does it do the job I need it to do, and is it effective at doing so.
Software is the same way. Does this particular piece of software do the job that it's intended to do so, does it do it in an efficient manner that does not affect productivity or security in a negative fashion.
I honestly do not care how elegantly or clean the code is written, or that if I gave you four weeks of additional development time you could slim down the code by removing a few extraneous lines here and there. It quite simply does not matter.
This is why American programmers are failing when it comes to foreign competition. They view themselves as computer scientists -- or worse, digital artists of a sort -- and demand exorbant salaries for a job that someone shoved through two years of tech school can accomplish.
I am a network engineer -- I design and maintain telecommunications systems. I know that in a heartbeat there is probably someone out there that could snatch my job away from me at a moment's notice and for a significant paycut.
If American programmers would realize the same -- and accept the lower salaries that the global market is pushing on them -- then they may have a chance to compete.
Specific case where it hasn't worked well (Score:4, Interesting)
It doesn't work well.
The main type of disaster (from the perspective of the user) is that the company forgets about business - concentrates on raising their share price or getting bought rather than on their product and customers - and is then bought.
This does not trigger the excrow.
THe companies that effectively fail are also bought, for not very much, and invariably by a company which has its own product in the area of work and wishes to recoup the cost of buying these new (and disgruntled) customers by selling them that product.
So the escrow doesn't trigger, the code is kept secret, support goes away, and the business and healthcare implications of a forced change of software and file formats are not avoided.
Open Source software and the development model that comes with it offer an alternative, and I would say are a necessary although not of themselves sufficient condition for stable satisfactory medical record software to be provided for periods approaching the duration of patients, doctors, Practice, hospitals (100, 30, 200, 300 years)
In the US there is the interesting and FOIA public domained VistA software for hsopitals, with the WorldVista not-for-profit interested in assisting anyone else to roll it out.
The UK NHS is currently in the process of procuring a large-scale computerisation of hospitals and data-spine to soak everyone's medical records into, and I suspect various aspects of previous efforts will repeat themselves. I place no reliance in escrow in avoiding trouble with this. Nor do I think FLOSS is a panacea, but I am convinced our chances would be better.
Anyone succeed in a rebuild from escrowed source? (Score:5, Interesting)
My own personal experience--and of course I'm rendering myself vulnerable to remarks about the competence and professionalism of the companies I've worked at--it is that it is very, very, very rare for any source code depository that is not in active daily or near-daily use to be current, or even consistent enough to build. I don't say it can't be done. I just question, in practice, how often it _is_ done.
a) I've worked at a company that made a big deal of sending all their source to "secure offsite storage." What this meant in practice was labelling diskettes (this was a while ago) and sending them to this company. When, finally, an occasion arose to retrieve some of this source, it transpired that the company simply stored them--and had no way of finding or retrieving a particular diskette, even if you knew which diskette you needed and could tell them exactly what it said on the label.
b) Another company was developing a software product under contract to a company I worked at. We were supposed get the source to each and every version they released to us. In practice, most of the time any particular source archive they sent to us would not build or did not match the binaries. (This could, of course, gone undetected if we had simply been filing the archives away instead of actually trying to build from them).
Re:Common Misconception (Score:3, Interesting)
If I could mod you up I would, and that quote alone is competing for my sig file:
Do you know what the difference between the illegal immigrant house painter that does cash-only jobs and the US programmer that holds your view point is ?
One of them is a pretentious asshole, and may have invested more heavily in formal education.
Really sums it up I'd say, and I'm an american programmer!
Re:Sounds like a good idea (Score:3, Interesting)
However, this happened in the U.S. (the buyer was German, but had a large presence in the U.S.) If a U.S. company tries to enforce an escrow agreement against an Indian vendor, I'm not sure how that would work.
Re:source code escrow not very useful (Score:2, Interesting)
I doubt it. I know very talented people who have written their own proprietary NTFS drivers that support write operations, and who did it by reverse-engineering, despite having access to the source (under one of the new licensing plans). MS' NTFS source code is a big, tangled mess tied up with everything else in Windows and it would be harder to try and make sense of it than to start from scratch yourself.
a) obvious security holes that anyone who looked at the code could pick out
Again, the source isn't nearly as much help as you'd like to think it is. Much more useful here are the efforts of people like the Samba developers to document the protocols, because then it's easy to write a packet constructor to try and
overflow buffers on the recipient. (Yes, I'm a security researcher, and I've done this in the lab
b) the source code to IE, so people don't release a patched version that doesn't suck.
Wouldn't know... haven't ever reverse-engineered IE personally, although I know some folks who have.
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.
That strikes me as a bit ambitious, don't you think? I mean, the folks at MS have spent years developing the DirectX API; I think it might take a little more than a few months to build a compatibility layer for Linux. (Of course, you'd be able to fix lots of bugs in DX while you were at it
d) Secrets. [...] Maybe there's some hidden precursor to some spyware or some DRM. If the source stays secret they can't get in trouble for what is or isn't in it.
Did you install the last Windows Media Player update? You installed Windows DRM support with it. It was mentioned right there in the EULA and on the download site for the service pack.
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. [...] 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. [...]
i) I agree with you on the money thing entirely
ii) There already is a Lite version of windows which is exactly what you describe. Check out at LitePC.com [litepc.com].
f) File formats. If we had the source to office the doc file format would be wide open among others. [...] With the file formats open nobody would have a reason to use office.
Actually, Microsoft just published it's XML document schemas for Word, Excel and InfoPath from Office 2003 (see here [microsoft.com]). So now anyone can read and write Office 2003 documents.
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.
Except that said huge driver database consists of third-party drivers and is not part of the source code database, but rather distributed with Windows in the installer package. Sorry to burst your bubble there, but Microsoft couldn't open-source most of those drivers even if they wanted to.
Old idea, inappropriate context -- DON'T DO IT ! (Score:2, Interesting)
In contrast, we always gave the code to customers in custom jobs / work-for-hire situations, so escrow wasn't an issue.
Most of the Indian shops are explicitly work-for hire -- custom jobs writen for internal apps or apps that the customer will be selling as packaged products. In this case, I would NEVER EVEN CONSIDER letting them keep the code. If they continue to discuss it for more than about two minutes, the conversation is over and we're down the street to their competitors. Period.
That is just my attitude based on the principle of the thing -- we are buying custom code and it is ours. Add to that my experience with at least one Indian shop. They were to produce code for a specific module with a well specified interface to other modules. After several months of back-and-forth, a piece of work that looked good (UI) was produced, but it had bugs. Attempting to integrate it without source code would have been impossible. As it was, once we really examined the source, we rejected the project and trashed the code. We rewrote it outselves in less than a month with a new hire fronm MIT with 2 years experience.
Would I ty outsourcing to India again? Yes, with the right circumstances and even more tightly defined specs (heck with their 'dedicated project managers' and consultants), and frequent intermideate source code review.
But, it is my considerd opinion that any manager that agrees to let those guys hang onto code, even with escrow, is seriously breaching his or her duty to protect the company and its employees.