Collaboration Agreements: It’s good to talk

I will declare my interest at the outset: I am a commercial lawyer and my business is drafting contracts.

You would therefore expect nothing other than for me to extol the virtues of detailed contracts written by expert lawyers.

However, the first stage that many developers need to overcome is an open discussion with their collaborators about their respective expectations.

When a new collaboration starts it is an exciting time. All parties are keen to explore the potential that the relationship holds and start enthusiastically sharing and developing their ideas. Some of these collaborations will lead to nothing, a few may change the World, but most will lead to something interesting.

Sometimes everyone is happy to continue a free flow of ideas and developments without any restriction on the way in which these ideas and developments are used by each other. However, once you start sharing your code or other work or developing new code specifically for a potential project, you are likely to want to place some restrictions on the way in which this can be used by the other parties. The restrictions may relate to sharing in future profits or restricting, or guaranteeing, the way in which code can be used in the future.

A clear and open discussion at the outset of any collaboration with all collaborators discussing your respective intentions is essential. This may be a very brief discussion if the arrangements are simple and agreed, but could be a very detailed discussion exploring the potential outcomes of a project.

The issues to discuss will vary with each project, but some key issues that you should consider as a minimum include:

• The purpose/objective of the collaboration
• What you are each committing to do
• The existing code, or other IP, you are each contributing
• What, if any, rights you each have to each other’s code
• What happens when the collaboration comes to an end
• Often this discussion leads naturally to recording the terms of the collaboration.

This may simply be done through an exchange of emails or, if it is more complex, the parties may want to move on to a more formal legal agreement. However, regardless of the outcome, the discussion will help to ensure that you all understand each other’s expectations. Far better to understand at the outset and not after expending months of time and money only to discover that others view the collaboration differently.

Without any documented agreement the courts are left to determine whether there was any intention to create a legally binding agreement and, if so, what the terms were. Where the parties have not even discussed any of the key issues it is extremely difficult for the courts to make any reasonable decision.

I often see developers reluctant to have these discussions for fear of damaging a strong friendly relationship. This is a mistake and often is an indication that the relationship is not as strong or as open as you want to believe. The purpose of the discussion and a good Collaboration Agreement is not to leave legal traps for the unwary, but to ensure that all parties go into the relationship with a common purpose and understanding. The aim is to remove the need or likelihood for future disputes.When documenting your agreement this should evolve from your discussions to reflect the project and the people involved. You should not force your project to fit a template document however “standard” it may be. I often see template Collaboration Agreements which force unnecessary bureaucratic procedures which actually restrict collaboration.

Finally, all projects evolve over time and you should keep talking and update your agreements to reflect the changes.

I will be exploring some of the issues that need to be considered in these discussions and agreements in more detail in my session, Building Successful Tech Collaboration at NorDevCon. In the meantime, if you would like to discuss any issues arising from this article please contact me on 01603 703233 or james.tarling@ashtonslegal.co.uk