Does anyone have experience with code escrow? I am looking for some advice in using code escrow for trading software. For example, how to limit appropriation of IP by employer who didn't pay for IP creation. If someone used code escrow for things like that, would appreciate a chance to communicate by PM.

I don't understand the situation. Usually money is held in escrow. In the case of code, I would withhold code until money is delivered. The nice thing about code is that compiled code can describe source code better than source code can describe itself, and can be made prohibitively difficult to pirate.Edit: Even java and C# - you didn't, did you?

Code escrow is usually used when you buy software, part of the deal is that a copy of the code for each release of the software gets put to an escrow, so that if the software company goes bankrupt, the licensee of the software has access to the code. Your situation sounds more like you want license the software to you employer, in which case maybe they are demanding a code escrow, is that it, sounds a little odd?

zerdna's on the other side. he's selling the code. his client wants to put his code in escrow, i suppose, to protect themselves. it's a common practice. e.g. a client gets the binary code, but asks to put the src to escrow. if zerdna goes down, then they'll be able to obtain the sources and continue operations. this is all done through 3rd parties, who provide that sort of service

I did that about 15 years ago when I negotiated a large-scale sale of a C-based Excel add-in to a major bank. They wanted the source code in escrow to deal with small vendor risk. Think about it from the buyer?s perspective. You do a software deal with a small vendor, you depend on that software and maybe a year later a key person on the vendor side (maybe the only person) gets hit by a bus. Or decides to exit the business. Or goes barking mad (it has happened, believe me).One very important practical problem to deal with is platform change. Say, for example, you've made an Excel add-in and suppose later Microsoft fundamentally changes the Excel API. So your agreement must clearly identify whether you are putting the algorithms into escrow or the interface to other software. Try to avoid the latter since you have no control over what other vendors do; well designed code is separable in that sense.The buyer should pay for the escrow arrangement, it's for their protection and they should be pleased to do so. Likely they would use an intellectual property legal firm. It is also very common and reasonable for the vendor to ask you to prove that the source code that will go into escrow actually compiles into the executable code that you've sold them. Laptops are very handy for that purpose.From the vendor's perspective it is very important to have a reasonable sunset clause on the arrangement. How long is highly deal dependent.

I've negotiated code escrow, though I've mostly been on the management side vs developers.PM if you have specific queries.There are few things that you may need to think about.Firstly, what is the source code ? I'm going to use C++ for examples here, but it applies to any language.As a professional Zerdna, your code will have meaningful variables, comments, etc.You won't have (for instance) named your variables named v1,v2..v817Such a thing is easily achieved with search and replace and taking comments out is trivial, changing them to mislead, not much harder.Also you've used #includes, not run the preprocessor and handed that over.All the above will produce idential binaries and if you google "code obfuscation" you will discover many more.These techniques apply to Java, Python or VB, indeed I have used the C++ preprocessor on VB for good reasons (at the time)One household name bank paid me good money to write code that did an obscure address calculation that meant that almost any change to the source code would cause mysterious crashes, they didn't trust one subset of their developers...(It's a vicious lie that this was my incompetence, honest guv)A wise counterparty will engage an escrow agent (or trusted third party like me) to validate that the code is of "good quality" as well as checking that it compiles.I've been one of those since if the relationship is not strong then almost by definition the T3P suggested by one is not trusted by the other.Some programs will not work in different versions of the same lanaguage; DavidJN uses his example of a C Excel Addin, and I will share that very few Excel addins compiled with VC++ 6 will make with later versions and the error message is wilfully misleading.Lots more and you want to make clear what happens if a new environment means something that looks like a bug appears. Just because it crashes, doesn't mean it's a bug, or maybe it does, arguing that is expensive, best to havea support contract so that they only need escrow if you disappear.It follows that a full build process must be included, make / project files together with the names and version of tools used.Another wise move is to have agreed a process where later versions / bug fixes et al can be added, be aware this adds to cost.If I was negotiating the buy side of this, I'd be happy to buy some options on your time for fixes, working with new system versions etc.It is critically important that you get the terms of release right and you have to take into account that their lawyers are their lawyers.IP lawyers do seem to vary in quality more than other types, some have almost no useful knowledge of IT.They may try for "if there is any breach of this agreement" kind of text.You want that to be more along the lines of "buyer shall notify the seller who will have (say) 30 days to remedy", and the remedies need to be specific and listed.gcc and C++ change regularly, you don't want them to be able to say "if a port is needed to a new version or platform, we get the code"They'll want language that if you cease business or disappear that they can get access and if you can't/won't fix a bug a T3P can adjudicate.Also the escrow agent must have a contractual obligation to try and get into contact with you first.For the avoidance of doubt, their lawyers are not trusted third parties.

"... I will share that very few Excel addins compiled with VC++ 6 will make with later versions and the error message is wilfully misleading."I have worried a great deal about this but it turns out I am a very lucky fellow because still I use VC+ 4.0 (yes, four!) and have yet to experience any problems up to W7/Excel 2010. Probably because I just do functions using the C API. I found I ran into problems with VC+ 5.0 and later so I ditched them in favour of the older version.

The problem in <= VC6 is the amazingly shit Microsoft sample code...Rather than zero terminated strings, the Excel interface has l-strings like many Basic or Pascal implementations, the first byte determines the length.Registering functions requires that you supply a name in this format, and that will be based upon a string literal in your codeI'm going to skip over non-relevant bits to make it a little clearerYou have a function called "Catweazel".Ms decided to recommend that the literal is instead " Catweazel", and that the initialisation function does thischar *Name = " Catweazel";Name[0] = strlen (Name); //some coerciion needed hereThat looks easy to spot but the example code spreads this over several functions.In C++ there is no concept of read only, instead there is const which is not the same thing at all, being more of a promise not to change rather than a rule.After C++ 6 Ms decided to make literals read only which has some good points, but it meant that the initialisation code now tried to write to read only memory, marked as a such ata processor level.Excel takes some steps to protect itself against badly behaved addins so it doesn't crash, no that would be too easy.It tells you that the XLL has the wrong format, based upon the way it fails during load.So when I hit this problem myself I was running a new version of VC++ which included a new linjker so I wasted a pathetic amount of time trying to persuade the linker to generate the right format of DLLSinc it was doing this already, the most I could achieve was to stop it producing the right form of DLL, quite a trick since there is little you can actually do wrong here.The reason all this crap matters to Zerdna is that in a new environment you hit problems that make no sense and where the diagnostics mislead you. Also it may be a year or two from now when exactly why you did something a particular way may be rather less clear than it was at the time.That's why an escrow agreement must have a sensible amount of time for you to remedy issues, the issue I site above took me days to get round (if you ever use it , you owe me a beer), but I had the luxury that no one was standing over my shoulder needing it ready now.This was a compilation issue and a reasonable person with a decent level of tech know how will readily concede that a port between compiler versions has a very wide spread of timescales, sometimes it will be nearly zero, sometimes it will suck up your life.At IBM labs I got sucked into a horridly horrid problem with one of their network adapters. Some would work, others would not.By this point the systems were on viciously expensive Intel ICEs trying to step through code to work out why two identical cards behaved so differently, hard to do in a real time connectivity environment.The Intel diagnostics were utterly unhelpful "Invalid opcode" which means "you've jumped to the wrong address in the machine code and the shit I find here isn't anything I can execute"...except it wasn't.Intel was telling the truth (for a change)The compiler generated opcodes for this processor which was designed for communications equipment, but Intel had decided that it wasn't all that good and had re-implemented it from scratch using the reference manual as the definition of working.The compiler developers had found a really cool instruction in the old version of the processor and so the compiler generated it, without telling the C developers, (look up my post about why you need some knowledge of assembler)Intel had kept the part number identical, so depending on what patch of the processor used, you were executing on a processor with an incompatible instruction set.This is an example of where a better programmer can be at least two whole orders of magnitude more productive than the average, indeed it's not clear that an average programmer could ever have solved this problem given infinite time.Again going back to Zerdna, you should try to hold out for legal language of the form "the supplier shall respond within 7 days", note I don't say "fix"Also you want the right to bring in the extra help if it's an issue outside your skills, partly because we all have boundaries, but also because you want to choose who gets to see your code.I'm assuming in all this that although the majority of the code is nothing special, but that there are some clever routines and tricks.If possible then you want to segment the escrow.Since I don't know your system, I will imagine that it's some sort of quant calculation thingIt accepts data, screws wiith it, then sends it somewhere elseEven if it doesn't currently come in that packaging I'd encourage you to think about doing it like that...The data sucking may be FIX or TibCo and is the part that is most vulnerable to issues outside your control.The calculation parts are the opposite, things you understand at a deep level and presumably your client doesn't.Then it gets shoved out onto the network or onto a screenThis segmentation means you can set up the Escrow so that if your input mechanism goes tits up, they don't get access to your clever calculations.Also, if you want to delegate network or GUI or Excel interfacing to someone who's got more time/skill than you, there is no need for them to have access to the clever calculations.

Ideally, a program should be separated into an interface, which code can be open, and a set of dll's with know interfaces or lib or so files with headers. I think I could generate higher present value this way, than by giving someone code so dependent on me that he won't even use it wihout a code escrow.If somebody has so little confidence in you and your estate that they would not be happy with a variable support contract, you have probably already destroyed and need to fix your pricing power.

Guys, thanks for your comments. Dominic, really appreciated your advice, it hit on few things i didn't think of -- nothing works like being in the trenches. I sent you a PM.

Zerdna, aren't you a little old for a business model used by teenagers?

QuoteOriginally posted by: farmerZerdna, aren't you a little old for a business model used by teenagers?No Sir, it's you who is wise beyond your years.