>For documenting what's in a project, I use Rick Schummer's excellent Project Lister. It hasn't been updated in a while, but it does a fine job and is available for free (I think) from http://whitelightcomputing.com/prodprojectlister.htm.

Thanks for the tip. 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.


>In the U.S., the intermediary for holding source code would typically be an escrow company that specializes in escrowing software. You and your customer enter into a legal agreement with the escrow company covering the terms under which you must deposit the source code and under which they are allowed to release the source code to the customer. There is usually a fee for this service, and it may not be inexpensive - several hundred dollars at least. Also, your customer may require you or the escrow company to prove that your source code submission is complete and can be used to compile the application in executable form from the source code you've submitted. This is a service the escrow company might offer, again for a fee.

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

I was also thinking of the possibility to send encrypted CD-Roms to the customer and sending the decryption key to the Escrow company or notary only one time. That will probably be cheaper for the client.

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.


>Escrowing source code can lead to issues when you use 3rd party products in your application, products for which you may have a license to deploy in object code form as part of your compiled application, but for which you do not have a license to distribute source code. I am not an attorney, but IMO that type of license does not allow you to deposit the 3rd party source code with an escrow company, so you can see where this could become an issue if your customer requires you to submit "complete" source code to the escrow company. If push comes to shove, somebody may end up having to buy a new license for each of those 3rd party products, and you probably don't want that somebody to be you.

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.

InnoSetup is an example of freeware and I assume that it can legally be part of the backup.

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'. Such tools are often two-part. One part is the tool itself. The other part contains the scripts. The scripts should be part of the distribution without a doubt. The tools themselves are indeed a possible cause of debate between the developer and the client. Whatever, the documentation should make very clear how and where the tool should be installed.

In my case I use Molebox. The tool is downloadable. That's why I also include that download on the backup. The remaining issue is the license key. Hah! Should I feel free to give that one also? The problem here is that it depends. For what reason does the client use the backup? If it's because of a conflict, then I'd say "No, yoú won't get it", because it's a personal license. If it's because of force majeure, then I'd say "Eventually, because I'm no longer able to use it and I grant you the right to use it from now on". But of course, that would imply that the license number was transfered to many parties, and that's not in agreement with the license of, in this case, Molebox.



>As to whether or not customers get source code in the first place, IMO that's entirely up to what you negotiate with your customers (unless things are different in the Netherlands).
>
>
>>Hi,
>>
>>My customers do get backups of the source code on CD-Rom, preferably sent to an intermediary agent like a notary who is only allowed to give the source code to the client in case of force majeure.
>>
>>I have started to streamline the process of creating the backup. Reason is that all too often the hastily created backup contained omissions that led to unusable backups. Documentation is an item too.
>>
>>Do your customers get source code backups? If no, why not? If yes, do you have any tips?