Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Software Businesses

Source Code Escrow 182

Posted by michael from the my-precious dept.
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."
This discussion has been archived. No new comments can be posted.

Source Code Escrow More

Source Code Escrow

Comments Filter:

  • Not a new idea ... (Score:5, Interesting)

    by taniwha ( 70410 ) on Friday December 26, 2003 @02:02AM (#7811418) Homepage Journal
    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

  • What if the escrow goes bust as well? (Score:2, Interesting)

    by Anonymous Coward
    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.

    • Re:Sounds like a good idea (Score:5, Insightful)

      by EvilTwinSkippy ( 112490 ) <yoda@nOSpAM.etoyoc.com> on Friday December 26, 2003 @03:41AM (#7811652) Homepage Journal
      Except of course that there is no guarentee that the source is in a finished state. What if the company takes the big walk in the middle of a project? What if the company says that the project has met all requirements, yet the code is useless for the intended purpose.

      These are very real possibilities. They are also common outcomes in IT projects of years past. A source escro is mostly an agreement between a finished software vendor and a client. Between a company and a sub-contractor it's simply CYA. (And not a very good form at that.)

      • One startup that I had the misfortune of dealing with failed to properly honor their source code escrow agreement and put the wrong source in the escrow (after I was done dealing with them thank goodness). They got spanked by their larger customer in court big time and went under. Most escrow agreements allow for building from the escrowed source and testing it, so deliberately checking in a crippled version is dangerous.

        However, this happened in the U.S. (the buyer was German, but had a large presence

        • I think the contract could easyly cover the clause to put the source code in a differnt country. E.G. int a source forge like CVS. An escrow agreement could be made that the customer regulary gets the code, but gains he right to modify and create derived works only in case of breeches or bancruptcy.
          At least that is what I would do, I would demand monthly buildable sources as well as build and test scripts whcih get into a "escrow safe" under my supervision.

          angel'o'sphere

  • source code escrow not very useful (Score:5, Informative)

    by penguin7of9 ( 697383 ) on Friday December 26, 2003 @02:07AM (#7811433)
    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.
    • if the company goes bust, it's old employees who worked on that source, will become available too. pay them a slightly bigger slice and attract them to your cause and benefit.
    • Situations where you would use this I think would be where Company A wants a specific product, let's call it WhizBangAccountingProgram. They have a specific list of features they want. They don't feel like hiring programmers themselves, to they contract it out to a company to make it for them (and only them). Thus if this company goes under, they get at least part of what they were paying for. At least, that's where it makes sense to me.

      I don't think it would get used at a point when said company is de

      • Specific case where it hasn't worked well (Score:4, Interesting)

        by midgley ( 629008 ) on Friday December 26, 2003 @07:36AM (#7811955) Homepage Journal
        In the specific case of General Medical Practice (Family Practice) software in the UK code escrow has been common for many years.

        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.

    • You think marketing is the only reason MS doesn't want their sources released ?

      Let me tell you what. Microsoft sales / marketing is getting a BEATING re: the whole Open Source vs Closed Source issue. Open Source for better or worse is a giant buzz and people that have no idea why they do or dont want it are asking about it all the time.

      If opening the source to all of MS's products boiled down to a bullet point on a marketing brochure, don't you think they'd have done that by now ?

      Your assertion about M
      • You think marketing is the only reason MS doesn't want their sources released ?

        You bet, although I'm not sure how conscious they are of it. Microsoft views and presents itself as an advanced technology company. Releasing their source code would be tantamount to an admission that they really don't have any interesting, new technology.

        Let me tell you what. Microsoft sales / marketing is getting a BEATING re: the whole Open Source vs Closed Source issue. Open Source for better or worse is a giant buzz a
        • I think his point was that the fact that no one else could maintain and develop based on the code base was not the reason the code was being kept secret.

          Among the other reasons you mentioned such as revealing potentially embarassing bugs in the source code, the main reason is the fact that having the source code available would allow competitors to develop software that equalled all the existing features of Windows essentially for free - killing any brand advantage. Software has a virtually zero marginal c
          • 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.
      • Let me tell you what. Microsoft sales / marketing is getting a BEATING re: the whole Open Source vs Closed Source issue. Open Source for better or worse is a giant buzz and people that have no idea why they do or dont want it are asking about it all the time.

        I highly doubt MS is losing the marketing war. If your assertion is correct, how come companies aren't using open-source software? Where are the linux sales? How many are using mySQL? Or Postgresql? How many use Openoffice.org?

        Sivaram Velauthapi

        • Re:source code escrow not very useful (Score:5, Interesting)

          by bmajik ( 96670 ) <matt@mattevans.org> on Friday December 26, 2003 @04:27AM (#7811721) Homepage Journal
          How many business run on linux now compared to 1 year ago. 5 years ago. 10 years ago.

          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.

    • The biggest problem I would have with this type of escrow situation is that there is no way to know how clean and maintainable the code is until the original developers are gone. Are there comments, are they meaningful. Is the code easy to follow, or does it look like this [ioccc.org]?

      Will my in-house programmers be able to work with it right away, or will they spend the next 6-9 months just figuring out how it works? Will *anybody* but the original programmer know anything about how it works?

      • Many escrow firms do a "Full Verification" escrow process, where the customer can go and have a look at some of the source code, and a build is demonstrated in front of the customer. That code is then immediately burned onto CD/DVD to go into escrow. Whilst you might get unlucky and only pick the really nice code examples to inspect, it's unlikely.
      • The biggest problem I would have with this type of escrow situation is that there is no way to know how clean and maintainable the code is until the original developers are gone

        With open source, sorry to say that, you have the same problem. Except one might realize it early enough, but if your contract does not cover "to write maintainable code" and does not define, what maintainable is, you have bad luck anyway.

        angel'o'sphere

        • there is no way to know how clean and maintainable the code is

          With open source, sorry to say that, you have the same problem.

          But with open source you can have someone look over *all* the code any time you want. And, if you actually have any in-house programmers they have the option of asking the developer questions like, "What are you doing here in this function? I don't understand it." It's reasonable to expect that at this point you still have a good relationship with your developer and can expect

      • Who said the original developers would be gone? I have found that the original developers get hired on a contract basis to perform maintenance on the existing escrow deposits. The fact that it is in escrow simply means the group handling the bankruptcy is not directly involved. The terms for the escrow release are met, and it is released to a new group (composed of staff from the original company).

        Also, many escrow companies will test and verify the software to ensure that it is "maintainable". That do
    • Your logic is sound, but having useless source code is going to be better than NO source code.

      Worst comes to worst you can take the code and outsorce it to some indian company to do something with it. ;)

    • Re:source code escrow not very useful (Score:5, Informative)

      by Apreche ( 239272 ) on Friday December 26, 2003 @02:31AM (#7811506) Homepage Journal
      You're right, except for one thing. The reason microsoft doesn't want its source code disclosed is to protect its proprietary properties. For example, NTFS. Right now we only have NTFS read only, and we can write ntfs by actually using microsofts ntfs.sys file. With the source code there would probably be an NTFS kernel patch inside a week that worked perfectly.
      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 ./ers would comb it over with the finest comb and uncover all of ms dirty secrets if any. Maybe there's an algorithm that is patented by someone else. 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.
      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.
      • For example, NTFS. Right now we only have NTFS read only, and we can write ntfs by actually using microsofts ntfs.sys file. With the source code there would probably be an NTFS kernel patch inside a week that worked perfectly.

        But that would still not matter much because development would still be driven by Microsoft--they could make incompatible changes and put it into the next Windows update and all that open source effort would be useless.

        Ultimately, what matters for market control is control of the co
        • 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
      • On your point (b), I think that IE is currently almost unmaintainable, hence the new month-long turnaround on patches. Remember, this is a product that has been evolving with the WWW, so it has been extended in ways that the original designers never dreamed of.

        So, there will never be a patched version of IE6 that doesn't suck. I have heard that the next version of IE is a re-write though, so code quality should be better then.

        Its all moot though; we will never see the source code of anything MS unless t

      • Re:source code escrow not very useful (Score:2, Interesting)

        by Anonymous Coward
        With the source code there would probably be an NTFS kernel patch inside a week that worked perfectly.
        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 yoursel
      • 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
      • If the source was open ./ers would comb it over with the finest comb and uncover all of ms dirty secrets if any.

        Hahaha, the ./ers would be the ones to do this?

        You're a funny man.

    • That all assumes that the escrowed code actually gets released to the buyer. If the developer declares bankruptcy, the code becomes an asset that can be used to pay creditors, so the judge may nullify the escrow contract so the software can be sold for more money.

    • Re:source code escrow not very useful (Score:5, Interesting)

      by __aanekd3853 ( 225915 ) on Friday December 26, 2003 @02:52AM (#7811556)
      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.

      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.

    • 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 anywa

      • But those problems are yours, not the developer's. You're going to have to come up with a much, much better argument if you want to convince companies to GPL their stuff. "So we can develop it further and maintain it if you go bust!" isn't going to cut it, I'm afraid.

    • No, Escrow can be complete and accurate (Score:5, Informative)

      by AHumbleOpinion ( 546848 ) on Friday December 26, 2003 @04:16AM (#7811703) Homepage
      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.
    • 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.

      So you're saying that there is no other company on earth capable of maintaining and developing the Windows source if given the chance? Not IBM, not Sun, not some new, "thrown together just for this" division of one of the huge multinationals? Not when it would open up an entire new market, with the potential to reach some 95% of all desktop PCs?

      If that's true
    • If the developer goes out of business, getting the source code by itself is almost always useless

      No. If the developer goes out of business, you're screwed. If you have the code in escrow, you may be less screwed. Not necessarily, but possibly.

      almost no single customer will have the resources to maintain and extend it.

      Escrow is usually expensive, and is only done by companies that can afford it. Companies that are big enough to be able to do something with the code. True, in most cases, the compan

  • Build Environment ? (Score:5, Interesting)

    by bmajik ( 96670 ) <matt@mattevans.org> on Friday December 26, 2003 @02:08AM (#7811438) Homepage Journal
    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.

  • Has anyone succesfully executed a SC escrow action (Score:3, Interesting)

    by ozzee ( 612196 ) on Friday December 26, 2003 @02:09AM (#7811439)

    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.

  • This is not new. And it's not that useful. (Score:5, Insightful)

    by Anonymous Coward on Friday December 26, 2003 @02:11AM (#7811442)
    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.

  • lawyerware (Score:4, Funny)

    by Doc Ruby ( 173196 ) on Friday December 26, 2003 @02:11AM (#7811443) Homepage Journal
    I'd love to see a patch to SourceForge which allows a lawfirm to use an RFC protocol to validate access to the escrow.
  • Nothing new here. And not a very viable concept. The company who insists the code be put in escro will get an assurance that something has been put in escro, but if the relationship has so little trust between parties that a third party needs to be brought in, then the developer may very well not put a full copy of everything in escro. If the company wanting the assurance doesn't find out until the developer no longer exists, they have little recourse. And if they find out before that, then the developer'

    • Hire an expert (Score:3, Interesting)

      by benjamindees ( 441808 )
      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.
      • The problem with that is it involves bringing in a developer to look at the "secret" code. Sure, that's what an NDA is for, but you can only sue an NDA violator for what he has. A multi-million dollar company putting it's most valuable secret into the hands of somebody who doesn't have a million to be sued out of is a big risk, one that's bound to come up craps for somebody.
    • not a very viable concept... if the relationship has so little trust between parties that a third party needs to be brought in, then the developer may very well not put a full copy of everything in escro

      On the contrary it is a viable concept. I draft escrow agreements for clients of mine and the situation you describe is well anticipated. It is dealt with by me or a consultant going to the source provider and building the binaries and then validating the binaries produced against the normally supplied sy

    • It depends on the escrow contract. Think of a company which would normally use only Open Source software, but tempted to choose a closed source solution subject to an escrow agreement. That company almost certainly would insist on certain terms for release from escrow {quite likely for dispute resolution purposes as well as in event of supplier's inability to fulfil obligation, and possibly in any case after a fixed period of time} and would do well to insist that the binary they receive should be ident

  • More popular in the 1980s. (Score:5, Informative)

    by Animats ( 122034 ) on Friday December 26, 2003 @02:19AM (#7811463) Homepage
    Source code escrow was quite common in the early days of microcomputer software. Back then, the software companies were little and their customers were big, and they had to keep the big companies happy. Now, it's the other way round.

    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:More popular in the 1980s. (Score:2, Interesting)

      by Anonymous Coward
      This is also used for tape backup, and similar types of software.

      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.

  • Real men don't use code escrow agents, they upload their code to an FTP site and let everyone else put up mirrors.

  • Compile-by-escrow? (Score:4, Insightful)

    by LostCluster ( 625375 ) * on Friday December 26, 2003 @02:44AM (#7811535)
    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.

    • Re:Compile-by-escrow? - (Score:4, Interesting)

      by belmolis ( 702863 ) <billposer@@@alum...mit...edu> on Friday December 26, 2003 @03:17AM (#7811608) Homepage

      There are a number of factors that determine how useful the source code is to a client, including:

      1. does the client need to change the program's functionality or simply want a version that runs on a new platform, works with new hardware, or can be linked with improved libraries?
      2. is the source written to a widely used standard in a widely used language (e.g. POSIX C)?
      3. is the source well written?
      4. is it well commented and supplied with other necessary documentation?
      5. is it appropriately modularized, so that parts that are likely to need to be changed can easily be isolated?
      6. does it rely entirely on generic hardware interfaces, or are there aspects that deal with particular pieces of hardware at low-level?

      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.

  • 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)
    • It's pretty funny for Slashdot to report the idea of software escrow as "News".

      Yes you CAN encrypt the source as you suggest. But then you have to put the pass phrase into escrow. No bigee, but you do have to do that to make your proposal work.

      Theoretically, it is easier (and maybe a little safer) to escrow a pass phrase than it is to escrow a bunch of source media, but not much easier in this day of data DVDs and high-volume tapes.

      The idea of encrypted escrow has been around for a long time, actuall

  • Another symptom of programming viewed as a commd. (Score:4, Insightful)

    by jstockdale ( 258118 ) * on Friday December 26, 2003 @03:08AM (#7811586) Homepage Journal
    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.

    • Common Misconception (Score:5, Insightful)

      by bmajik ( 96670 ) <matt@mattevans.org> on Friday December 26, 2003 @04:41AM (#7811740) Homepage Journal
      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.


      • 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:Common Misconception (Score:4, Insightful)

        by Pfhreakaz0id ( 82141 ) on Friday December 26, 2003 @10:22AM (#7812340)
        BUT... in my experience, the hardest part of programming is having people who:

        a: understand the company's business and spec. the application. and

        b: Understand the technical stuff to ensure a quality product.

        people who can do a and b together (with the communication skills to boot) tend to get paid pretty well -- like me. Failing that, you have to have people in group a and b who trust each other and communicate well. This means speaking the same first native tounge. No matter how complete the spec, there will be a hundred thousand things not in the spec that are decided by people talking together. Programming a decent size application is mostly communication and management challenges, not coding. This is why outsourcing (in my experience) always costs more than having it done in house, even by an outside consultant who is hired per-hour to sit inside.
        • i'd be pretty wary of making native tongue arguments. shooting from the hip, they seem reasonable, because we all had that foreign grad student acting as TA for one of our college classes that was totally unintelliglbe and made the class suck.

          On the other hand, I would postulate that the average Indian involved in contractual software development speaks and writes english better than the average American. Especially if you want to talk about concise or technical writing. Think about all of the people th

    • A major misconception (Score:4, Interesting)

      by Uhlek ( 71945 ) on Friday December 26, 2003 @06:56AM (#7811914)
      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.

      • Programmers are still rare (Score:4, Insightful)

        by solprovider ( 628033 ) on Friday December 26, 2003 @10:17AM (#7812311) Homepage
        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.

  • My escrow experience (Score:4, Informative)

    by jp93023 ( 84606 ) <jim.jperry@net> on Friday December 26, 2003 @03:18AM (#7811610) Homepage
    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!
  • We've been holding donations for yet-to-be completed software at SourceSupport [sourcesupport.org] 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.

  • Effective as administrative grease (Score:5, Interesting)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Friday December 26, 2003 @03:23AM (#7811616) Homepage Journal
    I've used escrow.

    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.

    • 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.

      This isn't just escrow. You actually got the source along with the executables. That's even better than escrow since you can look it over and change it. It's like purchasing the source without the right to redistribute.

  • 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.

  • Even non-compiling source code is useful (Score:5, Insightful)

    by mib ( 132909 ) <mib@post.com> on Friday December 26, 2003 @06:56AM (#7811915)
    I've seen a lot of people comment that unmaintained source code is not useful. This is a fairly big assumption, and I'd wager few of you have actually been in the situation of losing a mission critical piece of software due to vendor abandonment.

    I have. Several times.

    Even non-compiling source code is very useful, for at least two reasons, and likely many more.

    1. 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.

    2. 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

  • Anyone succeed in a rebuild from escrowed source? (Score:5, Interesting)

    by dpbsmith ( 263124 ) on Friday December 26, 2003 @08:05AM (#7811985) Homepage
    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).

    • 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.

  • 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 th

  • Escrow is evidence something is wrong. (Score:3, Informative)

    by Futurepower(R) ( 558542 ) on Friday December 26, 2003 @11:14AM (#7812596) Homepage

    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.
  • ... 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.
  • 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 c
  • 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 thei

  • Normal part of contracts (Score:2, Informative)

    by Fringe ( 6096 )
    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 remov
  • I have seen this requirement in many RFQs
  • Uh, maybe it's not obvious, maybe it is, but how does anyone ever know the source accurately represents the product?

Slashdot Top Deals

"The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud

Close