With source code escrow (SCE), a developer gives assurance to its licensee that business-critical software will be maintained by the developer or, if necessary by the licensee, using the source code and related materials the developer deposits (the Deposit Materials) with InnovaSafe. (We make the Deposit available upon a developer’s written instructions.) Because it is one of their most valuable assets, no developer puts source code in escrow unless he or she is confident in their commitment to maintain the application.
SCE is a form of insurance. It compensates the “policyholder” (licensee) for a loss. Instead of paying cash to settle a claim as an insurer would for profits lost due to business interruption, InnovaSafe releases the Deposit Materials, after the developer’s failure to maintain, to enable a licensee to maintain the software to prevent business interruption.
Insurance and SCE help manage risk. They do not reduce it. For example, no company would ever conclude that because they have business interruption insurance, they can do without data recovery procedures. That would be insane. It is cheaper to reduce the risk of business interruption by paying for redundant systems, including a duplicate data center, then paying the insurance premium and picking up a claim check for “lost profits.”
Yet, this is exactly what licensees do with SCE, telling themselves, in effect, “If the developer doesn’t maintain the application, I can have access to and use the source code.” But, risk reduction is just beginning.
Enter technical verification of Deposit Materials. It is a process where InnovaSafe with the assistance of the developer, both acting to benefit the licensee, to ensure that the Deposit can be assembled, compiled, and built into executable programs and is usable if the Deposit Materials are ever released to the licensee (Beneficiary). Generally speaking, the party requesting the verification pays for the verification and the cost for this service is small as compared to the cost of reducing the risk of business interruption.
Is there a need for technical verification? You bet there is. An industry axiom says that around 90% of Deposits are incomplete, because they are complex, not because of anything a developer does intentionally.
Here’s a thought. What would the marketplace for business-critical software look like if a developer included a technically verified SCE in its standard offer to its customers? For example, would it cut a SaaS vendor out of the herd? Think about it.
Your comments?
0 Comments