R&D Agreements — The Small Print

Joel Hochreutener , Kurt Sutter

Collaborations in R&D are a great way to develop new products or services. If a company lacks knowledge in a field, it can subcontract external experts to tap into their expertise. Or, in joint R&D situations, two parties can share skills, swap ideas, and create something new and amazing.

The potential gains are substantial.

And so are the risks.

In our work, we have seen numerous R&D collaborations. Many of them worked great, but others ended in strife and tears.

For a solid cooperation, there are some questions that should be addressed at the outset. Here are the most important ones, in our view:

A)???? The parties’ goals and interests: The parties usually have different motives for going into the project, and that’s okay. But the motives should be discussed and reviewed for compatibility before entering a collaboration.

B)????? Project definition: What is the topic of the collaboration? What is each party's task? When should these tasks be completed?

C)????? Deliverables and reporting: What are the required results?

D)???? Termination: When and how does the project end?

E)????? Payment: What is to be paid, when is it due, and does payment depend on the results?

F)????? Intellectual property: How to handle IP issues?

G)???? Confidentiality: When and how can project-related information be disclosed to third parties?

H)???? Liabilities and warranties: What if the delivered results don’t perform as expected or cause conflict with third parties?

While it’s a good idea to settle point A) even before deciding to collaborate, the other points (and more) should be addressed in a contract.

A good contract helps to avoid problems. And if problems arise, it helps settling them without irreparable harm to the collaboration.

Let us have a closer look at the points that should be addressed in an R&D contract.

Project Definition

The definition of the R&D topics and tasks is usually the core of an R&D contract. What is the subject matter and goal of the collaboration and which party is supposed to do what?

The project definition not only assigns tasks to the parties, but it also defines the nature of the collaboration. Is this a development order where one party is obliged to deliver a well-defined work result with predefined properties? Or do we have a research contract where the outcome is hard to predict?

The definition of the project may be straightforward or complex. To avoid later conflict, it should be precise. What is expected from each party?

Another important aspect of the project definition is the timeline. When are the results to be delivered?

Often, the project definition includes a series of milestones. This helps breaking down the complexity. Milestones are particularly useful if the outcome of the project is unknown — this is often the case for projects involving research where, at the outset, it is unclear if and how a given goal can be achieved.

Deliverables and Reporting

The “deliverables” are closely tied to the project definition. What does each party have to deliver? The contract must define the contents of the deliverables as well as their form.

For example, if the nature of the project allows to define the features or properties of the work product clearly, it should be part of the contract.

On the other hand, e.g., in research-focused collaborations, the deliverables may depend on the insights gained during the project. However, even in that case, the contract can, e.g., list the questions to be addressed in a report to be delivered at a given milestone.

The contract should also define the form and scope of the reporting. For example, it can specify if drawings, source code, experimental data, ML training material and parameters, etc. are to form part of the reporting.

Termination

Proper termination clauses help to prevent later disputes.

Many projects, in particular those focusing on development, will end with the delivery of the work product.

Other projects, in particular research-focused projects, may have to be terminated when it becomes clear that a desired goal cannot be achieved. In such cases, milestone reviews, with the option to terminate the collaboration, can be essential.

Depending on the project and work product, parts of the contractual obligations should remain in place even after completion of the actual project. Often, one party may have to provide, for some years, support services. For example, if part of the work product is a software, the developer may have the obligation to provide bug fixes.

Payment

In most (but not all) R&D collaborations, one party will pay the other party for work and/or expenses. Obviously, the contract should define the amount, due dates, and other details for such payments.

Payment particulars may, e.g., be tied to deliverables and/or the completion of certain project milestones.

Intellectual Property

Most R&D contracts will have to address IP issues, e.g., regarding copyright, patents, and designs. For example:

• Who owns the IP generated during the collaboration, and who can use it? Is there a duty to report such generated IP to the other party? If one party has the right to protect generated IP, what are the duties of the other party to support that?
• How can it be ensured that the IP-Rights are transferred from the employees to the respective party? For example, one or both of the parties can be obliged (i) to disclose the names of the employees working on the project and (ii) to confirm that the rights to the inventions are automatically transferred from the employee to the respective party by law or by written agreement with the employees. Said party or parties may also confirm that the respective employees are bound to secrecy.
• What about “background IP”, i.e., the intellectual property the parties already owned when signing the contract or develop outside the project? If the use of the project results may infringe such background IP, the contract should address the issue.
• What about “freedom-to-operate” in view of third-party IP? Does any of the contract parties have to assess this risk or even be liable for later infringement? For example, what about third-party patents, the use of third-party software, or the use of copyrighted material for training or operating AI?

Confidentiality

Usually, at least one of the parties in an R&D collaboration is interested in confidentiality. Keeping an idea secret may make sense, e.g., for competitive advantage or until a patent application is filed.

On the other hand, researchers may want to publish their results. Or one of the partners may want to employ third party help (e.g., by using student work or by employing external services), which may disseminate information to others.

In most cases, an R&D contract should implement a non-disclosure agreement and define rules how and when results may be published or disclosed to third parties. It also should clearly define the scope of the confidentiality (what information it applies to) and if marking information as confidential is mandatory.

Liabilities and warranties

Liability for damages resulting from using project results and warranties for features of the work products may also be part of the contract. In development assignments, they are common. In pure research contracts, they may make less sense. The extent of liabilities and warranties needs to be assessed on a case-by-case basis.

And What Else?

This list of points to be addressed in an R&D contract is incomplete. There are further topics that may be relevant, such as:

• Do we have a “subcontracting” type of situation (where one party basically subcontracts the other to do R&D) or do we have a “joint R&D” configuration (where both parties collaborate at an equal level)? If it’s the second type, competition rules may apply, e.g., in the EU.
• Who are the responsible persons within the parties and who should be involved in the communication between the parties? This may be of particular importance if one of the parties is a large entity with a complex internal structure, such as a university.
• In an international context, it may be necessary to keep an eye on local technology expert restrictions, patent filing restrictions, or quirky inventors-rights legislation.

As you can see from the above, an R&D contract needs to address many issues. And the details depend on the nature of the collaboration — there is no one-size-fits-all solution.

When entering an R&D collaboration, start by reviewing the parties’ motives. Make sure they are compatible.

If yes, take your time to write a solid contract with the required small print. It’s worth it, we’ve seen it time and again.

#R&D #contracts #research #development #ip

Artwork hand-crafted but contains AI-generated elements