“Having loose ends in an intellectual property collaboration agreement can lead to disaster.”
An inventor has a brilliant idea but doesn’t have the capability to implement it. He needs a developer (on a contract basis) who has the required technical expertise to help with the implementation. Now, you play a crucial role in defining the terms of the contract between the inventor and the developer. You need to lay out an IP collaboration agreement so that both parties have a fair deal while collaborating over the project.
In this article, I am going to cover four requirements to help you design an agreement that is able to satisfy the interests of both the parties by following the guiding principle of concreteness. I will conclude by sharing a yardstick that can help you determine if you have met the requirements successfully.
Alternatively, you can watch this video to understand the requirements for concrete drafting.
IP Collaboration Agreement | 4 Requirements
In order to draft an effective intellectual property collaboration agreement, you must account for four things. The contract must be:
- On specification: be very clear on whatever is being delivered
- On budget: a milestone-based payment system can protect the interests of both parties
- On time: a systematic approach to tracking progress can prevent development from going off the rails
- And demonstrate fairness: neither party should feel tricked
These items may sound simple, but it is very important to get all four requirements on point in order to deliver a concrete intellectual property collaboration agreement. The watch word here is “concrete.”
Requirement #1 – On Specification
The first requirement is to be ‘on specification.’ This means that you must be very clear on what is being delivered. This may not be as simple as it sounds, particularly when the project is in the research and development stage, as the inventor may provide a good idea of the final product, but not supply detailed requirements for its implementation. It may be the case, for instance, that an A/B test is required as part of development, the results of which will lead the project in one of two different directions. The agreement needs to cover both potential paths and must be equipped to fill-in where documentation of the software development is lacking.
The Guiding Light of Concreteness
To deal with situations like this, or whenever in doubt, my advice is to return to the guiding light of concreteness. It may also help to think of the contract you are preparing as a mutual service agreement rather than a delivery agreement. It is possible that the project will involve a design or testing phase, which can cause understanding of the final product at time of drafting to be fuzzy. The mutual service agreement must lay out a framework to ensure that at the project’s conclusion, regardless of what is being delivered, both parties are liable to protect each others’ rights. You also may find it useful to look to training materials or any other documentation associated with the product, to help you mention development requirements in a more concrete way.
Always make sure all hidden requirements by both parties are not hidden (pun intended) in the contract.
Requirement #2 – On Budget
The second requirement for a concrete intellectual property collaboration agreement is to be on budget. Here some issues arise due to deviating interests: the buyer wants to pay less, and the developer wants to be paid more. A client needing a research and development agreement with their developer, might wonder why the developer’s budget is so high or why, during the course of development, they demand more money than the amount initially set. This client may want to have the product delivered before making the payment. The developer, in contrast, may well desire to be paid in full before beginning work on the project. To ensure a harmonious working relationship, you will need to ensure that these kinds of issues are addressed up front in the agreement you draft.
Milestone-Based Payment System
One strategy for avoiding friction in these scenarios is to adopt a milestone-based payment system in which payments are linked to each specific phase of a project, as they are completed. This allows your client to have greater transparency around what is being delivered and allows developers to be more specific about the job description and payments they are charging. This arrangement might be structured with an initial payment, followed by milestones and an end-payment upon completion, to keep both parties on the same page throughout the development process.
One thing to keep in mind is that it might not be possible to set a concrete budget at the start of a project because the developer might not know how much time will be required for research, or how extensive that research will be, until development is underway. Therefore, it can be useful to suggest that the development process be systematically tracked, in parallel to milestone payments, to ensure that the terms remain as concrete as possible.
Requirement #3 – On Time
I recall a case where the buyer kept-on paying the developer without tracking the progress of the project, only to discover that what the developer delivered some time later was completely unusable. This not only wasted tremendous resources but ruined the relationship between the buyer and the developer. This is a reminder that it is important to cover the time aspect in the agreement. You can suggest the concept of time-bound milestones tied to variable payments on terms favorable to both parties, and further recommend that the agreement include provisions for scheduling regular meetings to track the development progress.
Requirement #4 – On Fairness
The fourth and final requirement in a concrete intellectual property collaboration agreement is that neither party should feel tricked. Two parties working together generally desire a good relationship throughout the course of engagement. However, contracts can be written in such a way that the parties may have divergent assumptions and incentives when things do not go as expected. In these types of situations, you should ‘play the tape till the end.’ Let’s look at a few examples where finesse is needed to ensure there is no perception of unfairness, from both the buyers’ and the developers’ perspectives.
Buyers’ Perspective
On situation where a buyer may feel that the developer is behaving unfairly is when the developer does not want to provide source code to the buyer. The developer may suggest that the buyer should make an additional payment to buy the source code, as the developer believes the source code is his intellectual property right. Further the developer might state that as the code is his expression of an idea, he has claim to any copyright or patent that might be filed on the resulting work product. In such scenarios, even though the buyer was not actually tricked, but rather unclear on the terms upfront, he may well feel that he was being tricked. Therefore, if source code will be produced as part of development, it is important that there be either agreed pricing for the intellectual property transaction, or clarity in the ownership of the code mentioned in the contract itself.
Developers’ Perspective
A situation where a developer feels that the buyer is being disingenuous may arise when the buyer changes his mind during development, and decides to discontinue working with the developer. This can be completely catastrophic for the developer, as it means a planned revenue source is unexpectedly derailed. The buyer likely has valid reasons for making such a decision such as a change in business model or that he is selling the license to someone else. To cover for such situations the intellectual property collaboration agreement should be concrete, with clauses that account for such eventualities, to ensure that neither buyer, nor developer, is primed for unpleasant surprises.
The Yardstick
The contract should be recognizable. In any of the situations where things are not going as mutually agreed, the developer and the buyer should be able to look at the intellectual property collaboration agreement and be able to identify a possible way out without needing your help. But what if the involved parties are not able to resolve the conflict and your intervention becomes necessary? Then, of course, you can offer your assistance, which may include performing research or finding people with subject matter expertise, to gain additional knowledge about the situation that can help identify what could be done to make things correct.
Wrap-Up
Clearly specifying:
- software development requirements
- a milestone-based payment system
- a structured approach for timely tracking of the development progress
- and ownership of the intellectual property (e.g. source code)
can help you prepare a concrete intellectual property collaboration agreement.
Even after careful drafting, there remains a small possibility of conflict between the parties, at which point, seeking help from subject matter experts can help you find a way out.
Disclaimer – “The statements and views expressed in this posting are my own and do not reflect those of my law firm, are intended for general informational purposes only, and do not constitute legal advice or a legal opinion.”
No comment yet, add your voice below!