IP deposit and source code escrow
We will fix what your product looked like and on which day, and write escrow terms that say exactly when, and on what proof, your customer gets a copy of the source.
When you need a deposit or escrow
A copy turned up last month
You know which of you was first. Showing it needs a version, a date and something that fixed both before the argument started.
The customer will not sign
A large buyer wants the source held by a third party in case you stop supporting the product. The clause is in their template already.
Two founders claim one file
Both worked on it, neither wrote anything down, and the repository history only starts where somebody set the repository up.
The contractor kept the repository
The build lives in an account you do not control. Getting a copy is one problem; proving what was in it on a given day is another.
Your only copy is a laptop
Everything that matters sits on one machine with no record of when each part appeared. That is enough to work with and not enough to argue with.
What you get
- A dated record per version
- Escrow terms with named triggers
- Deposits your customer accepts
- A schedule for refreshing them
What is required for a deposit and escrow
A dispute over a copy is decided on dates and documents, and the date is the one part nobody makes in advance. Afterwards it has to be assembled out of other people's traces, and the pieces nobody fixed are the pieces that stay missing.
Two separate jobs travel under one word. One fixes what existed and when. The other puts a copy of the source in the hands of somebody neutral, to be handed on if a named thing happens.
Two jobs, one word
Fixing the date
A version is recorded so that later you can show this exact content existed on that day. It answers a question about time and says nothing about who owns the work.
Holding the source
The copy sits with the holder the contract names — a depositary, a bank, a specialised service or another person the parties agree on — and goes to your customer only on the events named there. It answers a question about continuity and says nothing about dates.
How a date gets fixed
The mechanism behind it never sees your files. The standard for time stamping requires the authority to stamp only a hash of the material, to refuse to examine that hash beyond checking its length, and to leave any identification of the requester out of the token it issues.
What comes back is a signed token carrying a trustworthy time value and its own unique number, asserting that a given datum existed at a given point in time. Your code never leaves your building, and the proof still works, because anyone can recompute the hash from the file you kept.
What escrow has to settle
- The events that release the copy, written so a stranger can tell whether one has happened.
- What is deposited: the source, the build instructions, the dependencies, the keys, and the documentation to rebuild it.
- Verification: whether anybody ever checked that the deposit actually compiles into the product you sold.
- Refresh: how often a new version replaces the old one, and who is told when it does not.
- What the customer may do with the code after release, and what stays outside that permission.
Which parts of the product a right can hold at all is technology protection; acting on a copy already on sale is protection from clones.
What has to come from you
- The versions you want fixed, and the dates you can already show
- The customer contract with the escrow clause in it
- The build: what it takes to turn the source into the product
- Who signs, and who is allowed to ask for a release
Sources: the requirement to stamp only a hash of the material, not to examine it further, and to leave the requester unidentified in the token is in the time-stamp protocol standard, section 2.1.
Stages of work
Deciding what is worth fixing — 2–3 working days.
Not every commit needs a record. We will pick the points that would actually be argued about: the first working version, each release, the material a contractor delivered, the design files behind the look.
Recording the versions.
For each chosen point we will fix the content and the day, keep the file that the record was made from, and write down how the two are checked against each other later.
A record without the file it was made from proves nothing, so both are stored together.
Reading the escrow clause you were sent.
The clause arrives from the customer's own template. We will read what it releases, on which events, and what the customer would be allowed to do with the code afterwards.
Writing the release conditions.
The events are written so that a person outside the deal can tell whether one has happened: a named insolvency step, a missed support obligation after a written warning, an end of the product.
We will also write what the customer may not do, because a release is a licence and its limits belong in the same document.
Agreeing what a deposit contains.
Source alone does not rebuild the product. The list has to cover the build instructions, the dependencies and their versions, the configuration and whatever secrets the product needs to run.
The refresh schedule.
A deposit made once ages into a deposit of something you no longer sell. We will set how often it is replaced and who is told when a replacement is late.
The wider practice this belongs to is IP & Content.
Our case studies
FAQ
Discuss
the Task
Speak to our team
Speak to our team. Tell us about your task –
we’ll help you with it in any jurisdiction.