Developers: Legal Tips for Young Players – Record Keeping

Brendan Scott, October 2008

Records Records Records

In the mid 90s I acted for a large government institution in a dispute over the implementation of a failed search engine development being carried out by one of the worlds’ largest developers/systems integrators.   As is usual in litigation both sides conducted “discovery” – where you produce to the other side any documents of yours which are relevant to the dispute.   Part of the discovery related to the backups of the actual code of the software being developed.  In theory each side should have had a monthly back up for 12 months – that’s what they told us.  When it came to recovering from the backups we discovered most could not be restored.  Out of 24 copies which should have been available, only (I think) 2 could be recovered.   Neither of two large organisations (each of which might fairly be regarded as a paragon of record keeping) were able to keep adequate records.

Small and medium enterprises typically have poor record keeping processes.  Without records, it can be very difficult to prove any point you’re trying to establish – especially if the other side has kept their own (self serving) records.  A good record keeping system will permit you to understand what was happening at a particular time and this can have a lot of important consequences.

Structure Your Records

A record keeping system not only records information, it also structures and stores it in an ordered fashion.   This can sometimes mean having to replicate the record in a number of different places if it happens to be relevant to a couple of different things.   If you don’t keep your records in a structured way you might, in theory, be able to reconstruct what was happening from the jumbled mass of disparate notes you have kept, but, in all likelihood, you won’t be able to do so as a matter of practice.  It is unwise to rely on an after the fact search to find relevant documents.   You might choose to structure things implicitly through the file system.  Alternatively you can use meta-data in a document management system.  However, my experience (now somewhat dated) with document management systems has been that structure is poorly represented (my impression was that they made it easy for me to find other people’s documents, but rarely my own).

Maintain Separation of Projects

A failure to properly structure your files (whether physical or electronic) can have legal implications.  For example, if you fail to maintain a clear demarcation between the open and closed source work that you do, the code from one area may contaminate the other, potentially leading to untold heartache.  Indeed, this applies pairwise to any two  projects you are working on.  Particularly important is that you maintain a strict demarcation between any of your personal coding infrastructure (eg common libraries that you may have developed and reuse for multiple clients) and the specific projects you are working on.

For example, if you were to lump your private libraries into a directory shared with a client project that might seem to a judge (who are not renowned for their understanding of coding practices) as if they formed a single work – which may be bad if you’ve assigned IP as part of your engagement.

Make Notes

In some cases records can serve as a substitute for an express contract.  Equally, where a contract is ambiguous or apparently overreaching, consistent record keeping can, over time, establish some certainty within that ambiguity or can put bounds on the scope of an overbroad contract.  Such records might include, for example, notes of conversations where decisions have been made about what is in or out of scope, or emails which have been sent to this effect.  To the extent there is ambiguity don’t be shy in recording your understanding of the events.  While courts may not necessarily take your view of the world (as instantiated in your records) as gospel, it’s better than having nothing.  Send the notes to the other side prefaced by something along the lines of “This is what I understood we are doing going forward: ….”  This gives them an opportunity to correct you if you’re wrong.  If they don’t it will look odd for them to argue it was wrong at a later date.

Date it

To the extent practicable notes the date the note is taken should be included as part of the note.  This makes it easier to date the note – which can be crucial.  Often cases ride on when a person knew or said something.  If you have an undated note of what was said, it may not end up helping your case if you are unable to place it in relation to some critical date.  For example a note that the other party said “don’t worry, the contract has nothing in it that you should be concerned about” will have a completely  different consequence if it can be proven to be said the day before you sign (perhaps it induced you to sign) as opposed to the day after (when it can have had no effect on your decision to sign).  In addition, courts will generally pay more attention to a record which is contemporaneous with the details it records rather than one which attempts to reconstruct the situation at a later date.

Never use automatic date fields in documents if they will auto-update at some later time.  Date fields may seem like a good idea at the time, but once they update, their value is lost.  If you must use date fields, have some process by which they are converted to plain text on save (eg when the note is finished, or the relevant document has been sent).

Developers: Legal Tips for Young Players – Contracts

Brendan Scott – September 2008

In this series of posts we look at a number of generic legal issues which are relevant to developers, and especially to open source developers working for themselves or in small or medium enterprises.

What are contracts for?

People think of contracts as setting out rights and obligations of the parties to the contract.  In one sense, this is their point.  However, it ignores the process – negotiation – by which one arrives at a finished contract.  During negotiation, each side seeks to clarify what it is obliged to do, and what it wants the other party to do.  This process can often reveal unstated assumptions of one, or both parties.  Typically each party has agreed on a certain outcome but has not necessarily gone into the details of how that outcome will be achieved.  In some cases the outcome presupposes that one or the other of the parties must do certain things during the course of the contract – which they hadn’t realised they’d have to do (or perhaps that the contract is dependent upon some third party doing something).  The process of negotiation fleshes out the details surrounding the deal and identifies dependencies.

Engaging a lawyer will help to identify these details.  While this is part of the lawyer’s training, the mere process of having to explain the commercial deal to the lawyer makes you think about what these details are or should be.   A lawyer can also assist in identifying strategic issues that you may not have thought of.  For example, often there can be substantial issues in transitioning into or out of a relationship.  If these are not covered in the agreement you take you luck at the time.  If you happen to be on less than amicable terms with the counter party, you may rue an inadequate disengagement process.

Contracts and Timing

Rule 1 – Get advice before you sign, not after

This may seem like simple advice, but it happens from time to time that someone asks for an explanation of an agreement that they’ve just entered into.   When getting advice on a contract, the earlier the better.  Once you have signed a contract, there is usually little that a lawyer can do to help you (if it’s a rubbish contract).  They may be able to tell you how bad a mistake you’ve made, but you may not want to engage (and pay) them for that privilege. This is particularly bad in contracts which determine ownership of something (because when you sign the ownership changes).

Getting advice immediately before you sign is better than after – but not much.  It is usually difficult (although not necessarily impossible) to retrieve a position which has been negotiated away earlier.   This is because certain avenues of approach to strategic issues which are raised by the contract can be closed off in the course of negotiation.

Rule 2 – Sign the contract before you perform it, not after.

A practice sometimes honoured in the breach, is to sign the contract before you start performing it (or, worse, after you’ve completed it).  Often there is much goodwill between the parties, so they may be willing to begin performing the contract before they have signed – or even finished negotiating it.  As you get further into performance, one of the parties will be increasingly at risk if the negotiations break down – and therefore will lose leverage to negotiate an appropriate outcome.  For example, imagine you engage a builder to renovate your home, but have them start before the contract is finalised.  If you find some aspect of the contract which you cannot resolve you may discover that the builder abandons the job just after they’ve removed your roof and you will be with no quick means of engaging a third party (or if you have tendered for the work the other tenderers may want to raise their prices).

Rule 3 – Have a contract

In addition to being somewhat self serving, this advice is actually in your interests too.  Having a contract doesn’t necessarily mean that you have something in writing nicely formatted and prettily presented.  Rather, it means that, to the best you are able given the circumstances both you and the other party have a clear understanding of what is involved.  It is, of course, better if this is in writing and better still if you both sign and date it.  The reason writing is a good idea is that people’s memories are fundamentally flawed and you can be guaranteed that, as time goes on, your understanding of the deal and the other party’s will gradually drift away from each other until they are unrecognisable.  Having a written contract avoids the risks from a poor memory by having something that doesn’t change all that much over time.

If you do have a contract write it working from generics to specifics (“You must buy me a coffee.<generic obligation>  You must ensure it is a regular cappuccino from the cafe on the corner.  You must deliver it to me, still warm, at 9am on Friday.  You must ensure that, at the time you deliver it to me at least 25% of the contents of the cup are milk froth” <specific details>).  That way if, for whatever reason, you don’t get down to details, then at least your headline concerns are covered to some extent (“You must buy me a coffee.”) and the other obligations might be able to be filled in by context.

Rule 4 – If you don’t have a contract keep a record

Keeping a record of (eg making a written note of) your own understanding of what you’re required to do is still better than nothing, especially if it is dated.  A court will pay more attention to a contemporaneous document, than to the recollections of either party after the fact.  In addition, making a note may also help you to identify some of the details that you would have uncovered during the negotiation process as described above.

More on records in my next post…