>Thanks for the tip.

You're welcome.

>Documenting what's in it, is one thing. But documenting all the STEPS TO PRODUCE is another thing, agree? Clients can be impressed by thick paper bundles, but do they contain all relevant information? I guess this requires a serious attempt to write knowledge down in a Word document.

If you supply all the source code necessary to compile the application, there wouldn't be much left to document, would there? I suppose the person compiling it would need to know how to run VFP, open the project file, and click the Build button, but that's about it.

>Yes, we too have Escrow companies. But a cheaper alternative is a notary. (Is that a word/position in the States?)

In the U.S. a notary (actually called a "notary public") is a person authorized to perform certain official duties. Probably the most frequent use is to witness and authenticate a signature on a document. People who are notary publics generally have other full-time jobs, often clerical positions in a business or government entity. In this country I think it would be uncommon to ask a notary public to hold software in escrow. One might use an attorney for this purpose in some cases, and an attorney's office is likely to have at least one person working there who is a notary public, but it would typically be the attorney, not the notary public, who acts as the escrow agent.

>You mention an interesting point: Giving proof that the backup actually is complete and enough to compile. This may be a task for the escrow company, but the client and the developer/company might also agree on some third party, for example an alternative developer/company that is trusted by both parties. Eventually, the developer and the third party developer might gonna sit toegether. The third party developer goes through the procedures and verifies that all works. After having approved, the 'restore' is removed. This procedure should ensure that the third party developer does not sneakily view the source code.

Depending on the level of trust between the client and the developer, a third party may or may not be necessary. Probably the client would feel more comfortable knowing an independent third party had verified the software could be compiled from the escrowed source code. Using an independent third party also helps the developer make sure he/she did not unintentionally omit something that's needed to compile the app. It's very easy to overlook something unless you do the build on a clean machine or a virtual machine with nothing but VFP installed.

>I think it's logical that VFP is not part of the backup. Afterall, if someone else takes over, it will have to be a professional VFP developer who has an own copy.

Agreed, although nobody except Microsoft has the source code to core VFP itself, so that's a moot point.

>A problem may arise with commenrcial products, like Installshield or Molebox. It can't be assumed that they are part of the standard toolkit of the new developer. However, without such tools, the backup won't ever become 'complete'.

There's a difference between the source code needed to compile the app and the tools needed to build an installer for the app after it's been compiled. Unless your agreement with your customer states otherwise, IMO the developer only needs to be concerned with escrowing the source code and other components required to build the VFP executable. You might also deposit the Inno Setup script or InstallShield project necessary to build an installer for the app, but you would probably not want to have to supply your customer with a copy of Inno Setup or InstallShield or Molebox itself.