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."
not just something that happens in India ... I put source into escrow as part, of a contract at least 15 years ago, and it certainly wasn;t a new idea then
Then you're truly fucked.
A way for a buyer to obtain the source code in case of a bad situation, such as the writer of the source goes bankrupt? Sounds like a good idea to ensure you get your source code from somebody, just in case.
Ah am not a crook! (\(-__-)/)
...then pony up the BUX!!!! And have you ever thought that maybe the software buying company doesn't want a COMPETITOR to have access to it? If I had just contracted for some custom software that would give my business an edge, I sure as hell would want for me to be the only ones to be using it. OSS means jack shit to me if all it does is help my competitors pull even with me, on my dime! Fuck that.
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.
At least they mentioned documents and manuals related to the code. However, even with that, one thing that's over looked is the build system / environment. For any project interesting enough to put in code escrow, the build /cms system used is probably necessary.
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.
My opinions are my own, and do not necessarily represent those of my employer.
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.
Source code escrow is a very old idea. I used it at my last job when in a situation where the two parties had not had a great relationship.
The trouble with the code escrow is that, of course, if the relationship (or the programmers' company) goes to hell then the buyer of the code will have a big lump of code that may or may not be obfuscated. It's questionable whether the code can be completed at all, let alone brought to market in a reasonable time period.
Another problem is that the escrow company we used charged fees for receiving the source code discs in the mail, additional fees if you actually wanted them to insert them in a computer and report what files existed, and exorbitant fees if you had the nerve to want them to compile and link the files. I don't know if they even offered the ability to run the resulting application to see what happened (i.e. to see whether the developer sent you the source for your project, or sent you the source for gcc running on a Sun 3).
It seems like a market opportunity for an IT-oriented company that has spare cycles, if any of those exist. Could be a nice sideline business. Advertising should be pretty easy; we had a hard time even finding the one (not very good) escrow service that we used.
I'd love to see a patch to SourceForge which allows a lawfirm to use an RFC protocol to validate access to the escrow.
--
make install -not war
Open source. Feeding no one. and no one. and no one still. Then your programmers die from lack of food.
Sure. Open source, however, has its own set of associated problems.
Unless an escro company is in the loop enough to do actual releases, then there will not be a viable system that confirms what is in escro is what the client needs.
I'm an American. I love this country and the freedoms that we used to have.
And have you ever thought that maybe the software buying company doesn't want a COMPETITOR to have access to it?
If it's commercial software, then a COMPETITOR can simply buy it. Open source is a more cost-effective to that kind of commercial development.
If I had just contracted for some custom software that would give my business an edge, I sure as hell would want for me to be the only ones to be using it.
If you paid for the development of software that gives your business a competitive advantage, then you wouldn't need escrow--you'd own the code. Obviously, that's not the case under discussion.
(You might still want to open source the code because you might find that it's cheaper to share future development and maintenance costs with your competitors than to go it alone, but that's a separate matter.)
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.
Insightful? wtf?
"If it were open source like it SHOULD BE"
Very well, i'm not busy right now so i suppose i'll feed this troll.
Who are you to declare that all source code should be free (which seems to be what you're implying, correct me if i'm wrong)?
If a company pours money and resources into developing some software they have a right to decide whether or not they want to release the source openly. I think that's enough said.
> they have a right to decide whether or not they want to
> release the source openly.
Presumably then they are OK bearing the responsibility of knowing they're code could end up locked away or lost when company X goes bust.
It's a tradeoff, and OSS is the best all round solution
"and OSS is the best all round solution"
I keep hearing this, but i've hardly seen anyone backing this up with any meaningful arguments (don't get me wrong i'm not agains OSS as such).
Programmers don't need food. That's what Caffeine and Beer were invented for, to keep legions of coders alive.
There could be. Lawyers have consultants who help them with all sorts of stuff, including software. It wouldn't be so hard to have an expert verify the source code by compiling and comparing it against the binary software released.
"I assumed blithely that there were no elves out there in the darkness"
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.
HOW'S MY POSTING? CALL 1-800-POSTING
I liked this idea better when it was called "open source".
I design user interfaces for a free network management application,
One way to assure that the customer is getting binaries that corrispond to the source in escrow would be to have the code given to the escrow company by the vendor, and then have the client pick up the binary directly from the escrow company... therefore delivering binaries that don't match the code would be impossible. Of course, the vendor should do they test-complies against the escrow's compiler to assure they work, but once there's a "release" the code is locked away at the escrow and the client gets the resulting binary with no room for monkey business on the way there.
would be to have a nightly build which gets encrypted and uploaded to the client ftp site, or site of their choosing. then if the supplier goes bust have instructions to release the passphrase to each client so they can unlock the code they paid for. this way you can be sure the code thats released to you under the escrow agreement is 1. working 2. is up to date 3. no middle man (cheaper)
If you mod me down, I will become more powerful than you can imagine....
Programmers don't need food. That's what Caffeine and Beer were invented for, to keep legions of coders alive.
Ok, who's gonna be the first one to make some caffeinated beer? I might vote for you in the next overlord election!
But It is a step forward.. Well Kinda :)
Legacy Software isn't allways great to keep around other than to read Archived Data.
Running your company on software that was developed 20+ years ago... Come on.. Its time to upgrade your software and migrate from legacy systems.. There isn't a need to constantly run the lastest and greatest... But there is a line to be crossed and migrating can increase effeciceny.
Who needs WiFi when we can have Packet Over Sheep! http://datacomm.org/PoS-InternetDraft.txt
There is still room for monkey business.
:
Unless the escrow company does a code audit, how can you garuntee that the make file doesn't look like this:
mainapp.exe
cp splash.jpg mainapp.exe
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
Outsourcing to India, worrying about receiving proper code, escrow. All seem to be symptoms of the perverted view corporations have taken when viewing source code and programming as neither science nor art, but just another commodity. The problem is, that we're not talking corn or soy beans here, we're talking about a system designed for a particular reason. Anyone that has gone through a proper programming education (not that I'm claming to have done so, I'm in the middle of my undergrad career at Stanford but am considering CS) would be horrified at this approach. But it seems that many businesses are content not with how well a chunk of code is designed, but whether or not it functioned.
Code escrow is just another deluded side of this, a result of management types thinking CS is just "coding" and disregarding the quality of their product.
Quality, Functionality, Low Price. Pick two of the three.
Thinking that you're going to get _any_ use out of the cheapest functional code once it has been taken out of context (and probably not properly documented, or readable) is lunacy.
**AA: a bunch of mindless jerks who'll be the first against the wall when the revolution comes
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.
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.
We've been holding donations for yet-to-be completed software at SourceSupport for some time now.
Despite a few submissions to slashdot we have yet to get posted. Every other day I get an email wondering why we don't let the slashdot crowd in on it. o-well.
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.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Presumably then they are OK bearing the responsibility of knowing they're code could end up locked away or lost when company X goes bust.
No. Escrow has been used for many decades so that the above is a non-issue.
Feeding the middle man. and the other middle man. and the other middle man again, ad infinitum
woohoo. you meam we ALL get fed?
If it were open source like it SHOULD BE then there's no reason to have this 'solution' to a problem that would be 'non existent'.
Actually escrow is an earlier solution. Open Source is the relative new comer.
I did not say that Microsoft could release their source code into the public domain and not suffer consequences (they might or they might not be able to, but that's a harder argument to make). I said that they don't depend on secrecy of their source code for their business. There is a big difference between non-secret source code on the one hand, and open source or public domain on the other.
Sun Java, for example, is available in source form to anybody who wants it, but not under an open source license. The SCSL allows you to look at Sun's code, but it contaminates you with Sun intellectual property and does not permit you to release your own version of Sun's JRE without paying them.
Actually it may work, but what happens to the update. Getting the source code sounds fun but it normally drives up the development cost to learn someone else code rather than code from scratch.
Chris ,
Php Programmers.
You've never watched the Drew Carey show, have you?
But seriously...
Let's face it this is the same mindless decision making process that turned sexy into a bunch of anorexic bubbleheads running in swimsuits and music into the uninspired crap typified by the Backstreet Boys and Brittney Spears.
For whatever reason they don't seem to want to cater to anyone with an IQ greater than 90, and certainly no one older than 14.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
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.
Feeding the middle man?
In the current open source landscape, the programmer is the one primary not being paid.
Every offshore programmer I've met has had a far better grasp of the English language than you have, my friend.
Or to put it another way, nice troll.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
This comes up time and time again. There is an underlying assumption which is often voiced that there is a substantial quality difference between US code and Indian code.
This is usually bolstered with stuff like "art" and "quality", and "design".
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.
If people wanted "design" and "quality" and "art", nobody would buy Kia's. South Korea and Taiwan wouldn't have booming economies, and 95% of the clothes you wear wouldn't be made by children in malaysia.
But, as it turns out, by and large nobody gives a crap about those, or, they've made the determination that outsourced ultra cheap labour does the job acceptably well given the cost incurred.
Programming is no different. It's not like 50 years of American software engineering has produced an obelisk of invincible bug free code. No, we had Y2k, Windows 95, and a US vs Metric bug in a satellite.
Coding for Coding's sake is not a national treasure, it is not an art form, and really, it has nothing tod o with making money. IS/IT are a COST CENTER. Hiring programmers does NOT SELL SHOES. It does NOT SAVE LIVES. Everybody should be looking to save money on software development unlesss their business is software development! Otherwise it is an expense and subject to the inhouse vs outsourced discussion, just like any other expense!
Now, if your point had been "it's a shortsighted view to think you'll come out financially ahead by outsourcing software development to indian labor instead of using off the shelf stuff or using US based consultants", then you'd have an argument. But instead it smacks of idolization of the US intellect and the programmers-guild mentality so prevalent in the US/unix world.
My opinions are my own, and do not necessarily represent those of my employer.
And does it have source code? Is it still compilable? (perhaps those used in space research fit this bill.)
It seems like the task of designing a system that will be live after few decades has become easier now. The key task here is to reduce the number of dependencies on multiple sources. If a major corporation would indeed like to make sure their systems will survive for decades, they could do so:
- Make sure chip and board designs are maintained, and can, at any time, be reproduced. Many design houses can offer this.
- Deployable distribution along with specifications and documents. Can be archived for very long time. Dependencies such as highly available storage should be virtualized, and dependency be removed.
- The core production software. Direct third party dependency here. But, investing in open source software definitely helps here.
- Software enhancements made in-house; can be controlled with planned archiving and reproduction methods.
If this can become a fad, then new solution-oriented companies would emerge with a very high inclination towards open source software.
-Vinod
The one downside I can think of is that it offers your customers an incentive to drive you out of business...
Has anyone ever been involved with a project where escrow has done anything other than make management types feel warm and fuzzy?
I've just finished implementing a project where we are delivering a web service to a very large stuffy customer who insisted on an escrow aggreement, so they can continue to support the service if we go bust. To me this seemed kind of dumb, because I just can't see anybody coming in fresh to an app that's been hacked on by 20 different people over the last 5 years being able to actually make any sense of the system at all, not to mention that littered throughout the code are all sorts of assumptions about OS's, mail servers, domain names etc that would make it nigh on impossible to actually set up the application in a totally new environment.
Maybe on something like a missile guidance system, where the problem domain is well known, and the application itself has a well defined scope, it may be possible to take something out of escrow and give it to a new contractor to work on, but 9 times out of 10, if the originator goes belly up I'd think the old code is pretty much useless.
When programmers were rare, when the ability to develop digital solutions to real problems was an uncommon skill -- then software was science and art. However, today, programmers are a dime a dozen (at least in the states, overseas they're closer to three cents per bakers dozen) Software is now a tool to do a particular job.
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.
I have. Several times.
Even non-compiling source code is very useful, for at least two reasons, and likely many more.
Interoperability/data extraction
Chances are if your software is abandoned, you're migrating to something else. Getting that data out of your old system is a lot easier if you can see the code that put it in there, as is writing a compatible system.
Maintenance by Reverse Engineering
Just seeing how things works allows you to extend the life of software by working around and fixing new problems. A good example is some abandonware we had that was locked by license key to a fixed hostid. A trawl through the source code would have allowed us to reverse engineer a license key generator and easily move the system to a new host. (In the end we had to fix this with judicious use of LD_PRELOAD and fake gethostid() and hostname() calls, but making a new license key would have been much nicer.)
From a business point of view, I'd like all software to be licensed under a source escrow arrangement.
- mib
I wouldn't lump code escrow into the same category as moving IT jobs to India. It's just a way to ensure you get the product you pay for if the vender goes out of business. I worked for a tech start up in the late 90s. We had a great product, but weren't very good a marketing it. We struck a deal with a much larger company to market the product. Part of that deal is that we put the code in escrow in case we went out of business. Shortly afterwards of course, we did go out of business and the much larger company got the code. So did all of our customers. The much larger company continued development and most of us ended up working for them + had some lucrative consulting gigs working for ex-customers of company 1 since the ex-customers all had a copy of the source too. For a closed source solution, it is an excellent way of making sure you don't take everyone down with you.
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.
We escrowed code for many years, a local law firm set it up and served as the agent. Once in a while a customer would even ask for a copy so they could install it and compile the system. They figured if our company went out of business they would have a reasonable chance of hiring an ex-employee to maintain the product until they found a replacement. Sounded good in a sales pitch anyway.
Not a rhetorical question.
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).
"How to Do Nothing," kids activities, back in print!
"We're an apex predator with the fecundity of a base level herbivore... We're a virus with shoes..." RazorJAK
We ask for it, and we ask for it from some large companies as well. If we are going to spend 5 and 6 figures on software, it always goes into the contract. Never had to use it (knock on wood), but we fight for it. Cheers
This sounds like a good opportunity for the Be Operating System sources. Not that I'm much on closed source systems, BeOS was just so nice to use. With the release of Linux 2.6 and soon to be eminent branching to FreeBSD 6.0-CURRENT, we're seeing brighter desktop systems comming forth. The competion heating up in the windowing world is exciting, and it's nice to have BeOS in there as a benchmark.
What I don't understand is how some other firm is supposed to be able to pick up the source and start maintaining it. I develop *really small* projects at work and even though I do careful documention, and comment all of my code well, mostly because I am required too, when I have to get another team member involved as an expert, It often takes me more time to familiarize him/her with the codebase then it ends up taking us to write whatever module we are working on together when we final sit down to witeboard and then code. So if the IT director walks into my cube on monday and says "SmallSoftwareHouse went belly up, here is the code form our escrow account." It could be days, weeks, or months before we could make even trivial changes safely deployable in a production enviornment, depending on size of the codebase. That would be with good documentaion. If something had to get fixed fast we would be fu-bar.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
It is incredibly bad business for any company to be using a product from a company that is about to fail without the code in escrow AND A STATED MIGRATION PLAN. Otherwise you have the situation where the code is bought by another company that decides to drop the product. For a software producer to protect the customers requires a contract that states that the customers gain access and all rights to the source if there is no official release in one year or so. Maybe any patch counts as an official release. Or maybe it requires that at least 10% of feature requests are filled. The point is to have some determination that the code is being maintained. If a software company drops a product FOR ANY REASON, then the code becomes available.
The list of the new owners should also be open. Let companies have less rights if they want to stay off the list. As soon as the customers get the source, they would open source it. It would only requires one customer to place it under GPL. Of course, it would only requires one customer to make it public domain. All of the customers should communicate to decide what should be done with the code. This would be difficult if their names are not specified. (Lawyers: When reading a will, are the names of all beneficiaries released?)
Or the dying company could specify the license and set up the organization to maintain it. Would you trust them to plan to keep their customers happy once they are dead?
---
About Microsoft's code:
Bill and I know that MS will be dead in the very short term. Bill even told Steve. That is why development has been stalled on most of their products; there is no reason to waste the money now. If MS survives to 2005, then they can slap something together for release in 2006. Note that they have not reduced the PR budget.
If MS's code was in escrow in a usable form, then somebody would try to maintain it when MS dies. While it might be NICER to companies to maintain that code, it would be BETTER if they migrated to a better platform. Do you really want any code from MS to survive their death? Think about the pay raises for now in-demand Linux and Unix and Apache and PostgreSQL and other non-MS techies because every company in the US wants to migrate away from MS and wants it done yesterday.
I spend my life entertaining my brain.
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.
MS is *finally* competing on all that stuff. Just look what all it took to get them into that position, when after all those years they competed solely via monopolistic bullying and marketing hype. If the rest of the IT world ever relents, you can safely bet your last penny that MS will revert back to the way they were in a heartbeat.
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.
Please do not compare programming to engineering.
Engineers have one best method for accomplishing something. There may be several valid alternatives, but the difference between the alternatives can be measured.
Programming is still an art. Forget all the hype. Scientific analisys of various algorithms is very useful, but rarely affect real world solutions. First a business manager makes the primary decision about which technology to use. Not only does the manager have no knowledge of the technologies, this decision often contradicts the advice if the technical advisors. Then a project manager cuts the work into pieces and assigns them to porgrammers. Again, the knowledge of what pieces ahould be grouped for one programmer is ignored. And the assignment starts with the manager's favorite programmer taking the interesting pieces, regardless of the programmer's skill level or suitability. Then the programmers do their thing, which usually involves getting high on caffeine and using the mystical energy to conduct the thoughts of higher powers into electronic form.
---
American programmers vs. others:
I talked to a German programmer. After currency exchanges, she was making less than half what an American with her skill level would make, but she may have had a better standard of living.
I talked to a company that has outsourced some of their work to India. The big problem is that the work returns to exactly meet their specifications. American programmers translate business needs into code. The Indian programmers translate specifications into code. If those specifications are wrong, then the code is wrong. And the specifications are always wrong because programming is an art and requires flexibility during the coding process. This company solved this issue by adding a translation layer of managers and programmers between the specification writers and the outsourced programmers.
American programmers are arrogant individualists. This is good. They will tell you when a proposal is stupid. They will suggest better ways. The employable ones will still do the work when management insists on using the worst technology with even worse algorithms, but at least management knows they are being stupid. (Not that it matters after the project fails; the programmers usually still get the blame.)
No one shoved through two years of tech school can produce an application that is as fast, usable, and useful as an experienced business analyst/programmer. And much of that experience is still concentrated in the US. (I have friends from around the world, but they work here. Guess where Torvalds lives now?)
Disclaimer: I am not suggesting that all American programmers are better than all non-American programmers. Just suggesting that Americans have arrogance that has proven useful for programmers.
Yes, I know I am proving your point about American programmers. But we are worth the price. My customers insisted I raise my rate this year, and I was already in the 3-digit hourly. There may not be anybody in the world who could replace me.
I spend my life entertaining my brain.
Just insist on genuine Open Source Software.
Hello, "what if the code is useless"?? Well cripes, don't you think the person paying for it will be making use of the COMPILED VERSION?!/!?
duh
Several companies I worked with also use source code escrow agreements for closed source software. We wouldn't get it for general purpose software that costs from $100's to $1000's. Escrow agreements are viable for vertical markets, very specialized software such as Mortgage Processing, Insurance Claims Processing, Insurance Agency Management Systems, and other specialized enterprise software. You won't yet find too much open source software in the vertical markets because, I'd argue, the needs are too specialized and varied. The money is there for sure. But these industries can't rely on the open source community to develop their software because their needs are specialized. They don't have much motivation to release developed software into to the public domain because, as the software is specialized, it's like publishing your business processes. You help your competitors.
So when such software is purchased, it's from a vendor which has a relatively narrow market and therefore is expensive ($10,000's-$1,000,000's). The escrow agreement is a nice compromise that allows a company to invest in a smaller IT company that is producing what you consider mission critical software.
Getting a source code escrow agreement depends on how badly the IT vendor wants your contract.
this is commonplace and is normal business practice, nothing new here.
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.
Here is my reply: Escrow is evidence something is wrong.
LOL.
The view that seems cynical is often the reality. Quoting from the parent post, about how programming is often managed:
"First a business manager makes the primary decision about which technology to use. Not only does the manager have no knowledge of the technologies, this decision often contradicts the advice if the technical advisors. Then a project manager cuts the work into pieces and assigns them to porgrammers. Again, the knowledge of what pieces ahould be grouped for one programmer is ignored. And the assignment starts with the manager's favorite programmer taking the interesting pieces, regardless of the programmer's skill level or suitability. Then the programmers do their thing, which usually involves getting high on caffeine and using the mystical energy to conduct the thoughts of higher powers into electronic form."
... when I worked for a small software house many years ago. We used to strip out all the unnecessary whitespace, and rename all variables to aa0000, aa0001 and so on. If they had to, they could recompile, and even bug fix, but enhancements would be difficult.
Some clients even wanted paper copies, so we printed it all out in 4-pt. To save paper, obviously.
--
E_NOSIG
As with most legal things, any large corporation worth its salt would be able to trigger the release of source under inappropriate conditions: for instance, demanding that you port to an exotic processor and forcing source release if you can't afford the resources to do so.
For this reason, the one time we had to sign an escrow agreement (20 years ago) with a large Japanese manufacturer, we encrypted the source without telling them.
You can see why I had to AC this.
You mean apart from IBM?
Or did you not know that IBM does Open Source Software.
The only ones shying away from it are Microsoft and SCO.
Everybody else is finally "getting" open source. In a computer battle, I'm not sure I want to be on the side of Microsoft and SCO, but then everybody has their own sense of morality.
We would never screw you by putting fake source code into the escrow bank. What kind of people do you think we are?
If a company has a true concern, there is another way to address the code-escrow problem ("solution") - for a price. Buy the actual source code.
Make the contract one such that what is being bought is not just the binaries or install modules, but the source code along with them. At each release, incremental build, etc... these are shipped to the customer.
Of course, these may be of limited value to the customer without a replication of the original development environment, but this addresses some issues of code escrow. It also firmly and immediately establishes ownership over the (source) code with the customer. If the client-code writing firm wants some rights to parts of the code it is developing for the customer, that can be negotiated.
I have seen a comment about certain areas of coding problem requiring more assumptions than others (someone above mentioned something about missile systems being a well-known domain with few assumptions. I question that.) If you are developing to a specific business environment / platform with many specifics and assumptions - mail server addresses, protocols, etc - - - DOCUMENT IT IN THE CODE !
The client company and the originating firm can draft (or find) a set of coding standards for the code to be developed to. There can be walkthroughs and reviews - a big part of the overall equation is whether the customer is willing to truly pay for traceable, reliable, unambiguous, well-documented and delivered code, or if the customer just wants a big band-aid-kit and to provide a minimal assurance of covering its butt if the developing company gets into trouble.
Sam Nitzberg
sam@iamsam.com
http://www.iamsam.com
I'd suggest that it is quite hard to define "support going away" What is the point at which failure has occurred?
Similarly, I would be wary about the definition of takeover. One needs to make sure there is no way an acquiring comapny could camouflage their takeover, thus blocking the escrow.
Realistically, I suppose, the point at which support has gone away is the one at whcih one iss told it is necessary to migrate to a new application, and clearly this escrow is potentially useful then, and strengthens the purchaser's hand before that.
As a small software vendor, I've used escrow a number of times to solve the problem of 'what if you go out of business?', when selling packged products. In this 'shrink-wrap' context, it is very appropriate. The customer is getting the benefit of the lower prices associated with repeat/volume sales of a packaged product, and needs some kind of solid assurance that they will not be screwed if a small shop goes out of biz, is bought/merged, etc, since the SW will be used to run the customer's business.
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.
Maybe that's why it's so hard to get the suits to buy Open Source ... No escrow.
Now if we could only get Sourceforge and co to offer an Escrowal service :)
We have provided escrow services as a matter of course for the software companies my firm represents.
However, changes in the nature of software development and use as pointed out by others make escrow almost useless.
Another situaton that has come up is the case of Application Service Providers. Say you sign up for an ASP service that handles your HR and payroll. What is your recourse if the ASP goes bankrupt? SHould each of the ASP clients get access to the source code to rebuild the environment on their own or collectively hire someone else to do it?
If you don't want to repeat the past, stop living in it.
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.
I have seen this requirement in many RFQs
Oh well, what the hell...
But untrue. HAving the source doesn't imply you can use the source for whatever you like. Microsoft could certianly include the source with Windows, but simply not license it for any sort of redistribution or development. They do, indeed, license out their source under certian cricumstances. Plenty of universities have a copy of the source to all versions of Windows. This includes such things as IE and DirectX. Yet we've seen no Linux DX implementation. Why? Because they'd break their license by doing so.
A somewhat similar situation exists with the profesional Inprise compilers. They ship with the larger part of their source code included. However, Inprise notes what you can and can't distribute and in what forms, very carefully in their license. Some of it, you can't even reuse in a distributed binary, so you have to have the compiler on teh system you intend to run the app on.
Then there's plenty of other flaws with your arguments, I'll address a few:
a) Right, like those obvious BIND hols that somehow managed to stay hidden, despite source availability, for years until someone happened across them? OR how about OpenSSH holes? Wu-ftpd holes? Sorry, but the source being available doesn't mean bug free software. The problem is that security holes result from something noone though of before. The BIND team though they were secure, they didn't see any way to exploit it, neither did anyone else that looked over it. Then one day, someone figured out a way, that had been there forever, but no one had noticed. Just because source is public, doesn't mean that there are no security holes. That is proven time and time again with holes in OSS.
b) There already is a version of IE that doesn't suck. It's called MyIE2. Supports tabbed browsing, popup blocking, a muli-search bar, gestures, disabling flash, and more. It's free, just Google for it. See the thing is, Internet Explorer, like so much of Microsoft's software, is composed of two parts. Part one is the engine that does all the work. That is availabel as a COM control and is able to be (and is indeed) called by many other programs, MS and third party. The second part is the little EXE that ties it all together with a UI to run. MyIE2 uses the same engine, but with a different and more powerful UI. No source needed.
c) Ummmm no. You'd not only need to implement the DirectX APIs, you'd need to implement the Win32 APIs and lower level functions for loading Windows style executables. Also, DirectX isn't the simple thing most people think it is. It's not a 3d interface, that's only part of it. It deals with all kinds of input and output, 2d, 3d, sound, music, keyboard, network, etc. It also encompasses things like DirectShow, the system responsible for video and audio playback and the codecs and filters thereof (Media player again is just a UI wrapper that calls a COM engine to do the work). It's not like you are talking a weekend project, it would be a major undertaking to try and implement DirectX and Win32 in another environment.
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.)
Sounds like a good setup if you ask me. Just wish they would make a law that says when a company no longer supports a software product that the purchaser is allowed access to the full source code. Like for instance the Windows95 I paid for that Microsoft no longer supports or upgrades.
Why? They are paying you for your expertise in a particular business specialty. Buying your software in the first place, only to kill you later seems like a bad business strategy, when I could just kill you now, right?
I agree with you about how Open Source should be law in the end. In the meantime, however, source code escrow is a good half-measure, and provides customers with a modicum of protection against suppliers going bust -- which is itself a serious argument against closed source software {if both the software and the supplier go T.U. then so are you, and it's technically illegal for anybody to sort it out. I think this has happened on at least one occasion before, with customers left high and dry}.
I also think that there should be a requirement that source code in escrow should be allowed to be opened in case of a dispute where, say, the customer suspects a bug in the software and the vendor insists otherwise. The source could be examined by an independent panel of experts to determine the existence or not of a fault.
If Source Code Escrow became standard practice, or if it was demonstrated in real life that the system worked {either through a company being saved from disaster through the use of Source Code Escrow, or a spectacular failure that would have been prevented by Source Code Escrow} then it would be worthwhile petitioning for it to become law. Open Source would be safe either way, of course; if the law said the source code had to be to be accessible in an emergency, Open Source would automatically satisfy this requirement because it would be accessible even outside an emergency.
Of course, all these services would be a great way for third parties to make money - escrow agencies, programming experts and teams of lawyers would all be demanding payment. Some people might find it more cost-effective simply to release their software Open Source in the first place.
Je fume. Tu fumes. Nous fûmes!
Uh, maybe it's not obvious, maybe it is, but how does anyone ever know the source accurately represents the product?
I've been involved with projects where the source was put into eschrow, and it seems to work well.
Consider a small company "us" with 200 staff trying to sell a product to a very big customer (them) to run on each of their 10,000 servers.
"them" have done a dilligence test and the product is suitable. However they want to guarantee future support. They need to know that, if they find a critical bug in two years time, they can get it fixed.
The eschrow includes all build tools, plus documentation showing OS versions, procedures etc. On an agreed day, a staff member from "us" and another from "them" meet at the eschrow place.
Insert CD #1 and click install, and everything installs cleanly.
Type "make myproduct" and it builds with no compiler warnings.
Run through some tests to validate that it is the correct product and everyone is happy.
If, in a few years time, "us" go bankrupt or are bought out by somebody who is not interested in giving support, "them" take posession of the source and it is their responsibility to find some contractors that can do the maintenance work.
It is not as good as an open source product, but where trade secrets prevent open source release, it is a pretty good compromise.
Source code escrow has been around for a long time.
Why do companies in India want to use it now?
Come on, companies have been trying to use source code control systems (SCCS) for a while to parse out sub-projects to groups in India to work on ("offshore" is sometimes a name for this practice).
This is done specifically to ensure that companies outside the USA do not have access to the full source code base for a particular product.
This is their (people in India) way of fighting back. Once a small company (someone's brother) enters into one of these agreements then all source associated with the "failed" project is now in escrow and must be handed over (as a full usable product) under the legal system in India and the legal system of the USA (watch, they'll demand and get source code to major systems in the future - not just the portions developed in India).
You can argue all you want but however they get it (legally or illegally) it will be theirs under Indian law and there is no reason they can't sell their wares (legally) in the USA.
I learned this in a ClearCase course where a large US organization was planning on having a non-US company do a lot of work for them. It seemed odd to me then but clear to me now that this is a very dangerous way to work.
Show this email to your CTO the next time someone from the executive thinks saving a few bucks in India is a good idea! (I'm being serious.)
It's like all risk management strategies - you have to apply some common sense.