Verification: The Key to Effective Software Escrow

By: In: Technology Escrow On: Jan 24, 2012
Verification: The Key to Effective Software Escrow

Statistics show that over 70% of all software escrow deposits sent in for analysis are incomplete and required additional input from the developer in order to be compiled.

A software escrow arrangement is an excellent vehicle for protecting all parties involved in licensing technology, but the value of the escrow arrangement is heavily dependent on the quality of the escrow deposit materials.

So, why is verification so important?

Let’s start with a quick review of the escrow process. A developer creates a new application and licenses it to a company that wants to use it. The user is concerned about relying on software from a developer with an unproven track record.

What if the developer goes out of business?  How will the user get bugs fixed or new features added? What if something unexpected happens that affects the users’ ability to run the software?

To solve this problem, in addition to the application itself, the user wants to be able to get access to the source code so that they (or someone they contract with) can maintain the application if the developer is no longer around to do so. They want leverage to control their future and investment.

Naturally, the developer doesn’t want to give the user the actual source code, because that is their valuable intellectual property. Giving away the source code is like giving away their business.

So the user and developer agree to give the code to an escrow services provider (a trusted third party), like Iron Mountain, who will keep the code safe and only release it to the user if certain conditions are met, like the developer going out of business or discontinuing support.

An escrow deposit can consist of many things – source code files, scripts, libraries, data files, etc.  – whatever is needed to reproduce and maintain the actual application.

However, while the developer gives a box full of code, so to speak, to the escrow services provider, until that box is actually opened and the contents analyzed, we don’t really know what is inside it.

People make mistakes – even if the developer is completely diligent in their escrow deposits – there may be files, libraries, or scripts that they simply forgot to include. And when some disaster strikes and the source code is released from escrow, that is not the time to find out files are missing and the code won’t compile.

If requested, verification services can be done on any escrow deposit by the escrow services provider. Verification is the process of making sure that the correct code needed to compile the application has been deposited, that all of the code needed to compile the application has been deposited, and that the instructions and processes are included.

Any errors that are discovered are reported back to the developer, who will then correct the problems and issue another release to the escrow services provider. This process I repeated until all errors have been fixed.

There are several different levels of verification that can be performed and it may not be necessary to always perform extensive verification for each escrow deposit. Let’s first take a look at the major levels of verification that can be performed.

The first level of verification is to simply make sure that all of the correct files have been included in the deposit including build instructions and third party tools.

This may sound simple, but there can be hundreds or even thousands of files associated with a complete set of the source code and they can be distributed across a complex directory structure. Verifying that the right files are included in the right places is the first step towards making sure that the developer didn’t simply make a simple mistake in collecting all the files that are needed. In this stage we make sure that the developer actually deposited what they said they would deposit.

The next step is to actually compile the code. This is a major step towards making sure that a complete set of the source code has been deposited. If any file, script or library is missing that will show up during compile as an error. This step tells us that what the developer meant to deposit included everything that they needed to deposit.

Of course, just compiling the code doesn’t tell us that it works correctly. A file could be present but might include the wrong revision that had some bug or incompatibility in functionality. There are two steps that can be done to make sure that not only are all the files included in the escrow deposit, but that they are the correct files. The first option is binary comparisons, and the second is functionality testing.

Binary comparisons can be done when a release of the application has been made to the user at the same time that a deposit of the source code has been made with the escrow services provider. The escrow services provider can compile the source code and then do a binary comparison between the compiled application and the version of the application that was released to the user.

This guarantees that the source code that resides with the escrow services provider is the same source code that was used to compile the application release at the user since the binary applications compare.

The last method of verification is actual functionality testing. Even if we can be sure that the source code that was deposited is the correct and complete source code, does it meet all the user’s functional requirements?

The user may receive a new release but not actually deploy it for some time. In this case, the user does not want to find out later that while the correct code has been escrowed, that code has some major functionality that is broken or not included.

In this final verification step the escrow services provider will actually set-up, configure and install the user’s production environment and run test cases to verify that all the functionality is working correctly.

This may sound like a lot of worrying about something that surely doesn’t happen often. Forgetting to include key components? Depositing the wrong ones? That doesn’t really happen, does it?

Sadly, it has proven to be the rule, not the exception.

Missing files, wrong files, incomplete lists of files…what if these problems were not discovered until it was too late to fix them?  It would be like finding out your insurance didn’t really cover you after your house had burned down.

And verification is a common practice in other industries as well. Mortgage companies insist on a home inspection, life insurance companies require physicals, etc. As Ronald Reagan said during the arms reduction treaties, “Trust, but verify!”

Analysts like Gartner agree: If you don’t plan to do regular audits or verification that the version of the software you are using is in escrow, the agreement may be worthless…If the vendor fails behind the source code deposits, and has incomplete or unusable deposits, the escrow agreement could be worthless.

Escrow is a key insurance plan for any business that wants to reduce the risk from critical software that they rely on.  But performing escrow without verification is like buying insurance without knowing what is being covered.

When a problem arises, you might be okay – or you might not. If you don’t want to gamble with your company’s future, verification needs to be a key component in your escrow program. Trust your business partner, but verify that no one has made any mistakes

For more information on escrow and escrow verification, part of our intellectual property management solution, please visit our website. You can also sign up to receive your free copy of our popular publication, “Escrow for Dummies” – it’s the smart thing to do!

Related Links:

← If You’re Living in the Cloud, You Need Protection Is there a hole in your disaster recovery plan? →

Leave A Comment

*

About the author

Tara Holt

Tara is a senior product manager for Iron Mountain Data Management. She is responsible for developing Iron Mountain applications that help our customers manage their offsite tape backup inventory and other data management programs. Tara has over 16 years of experience as a technical writer, business/systems analyst, project manager, and product manager and has worked for Iron Mountain for more than 13 years. Tara holds a BA in English and Journalism from the University of Connecticut and is working on her MA in Professional Writing at Regis College. In 2010, Tara received her Product Management Certification (PMC) from Pragmatic Marketing.